May 022012
 
Artículo Domótica

El “European Installation Bus” (EIB) es un standard englobado en KNX para la interconexión de dispositivos domóticos en una red descentralizada.

En una instalación domótica podemos encontrar numerosos dispositivos para el control de la luz, temperatura, automatismos de puertas y persianas, etc. En general, estos dispositivos se agrupan en “sensores” y “actuadores”. Cada uno de estos dispositivos se comunica con los demás enviando y recibiendo “telegramas” (paquetes de información) por el bus.

Físicamente el medio que implementa el bus puede ser:

  • Un cable de par trenzado (TP) que se tiende paralelo a la instalación eléctrica.
  • Una comunicación inalámbrica
  • La propia red eléctrica previamente existente (PowerLine, PL)

Topología de una red EIB sobre TP

Una red EIB sobre TP se estructura en varios niveles:

  • Un segmento de línea permite conectar hasta 64 dispositivos (denominados APT). Cada segmento de línea cuenta con una fuente de alimentación que suministra energía a los dispositivos que se conectan al mismo.
  • Una línea puede constar de hasta 4 segmentos de línea
  • Un área consta de una línea principal, a la que se pueden conectar hasta 15 líneas adicionales mediante “acopladores de línea” (AL).
  • Por último, una línea backbone permite conectar hasta 15 áreas.

Direccionamiento de los dispositivos

En un bus EIB, cada dispositivo es identificado mediante una dirección física y una o varias direcciones de grupo.

La dirección física de 16 bits tiene la estructura AAAA-LLLL-CCCCCCCC, en donde:

  • AAAA identifica el área (de 1 a 15)
  • LLLL identifica la línea dentro del área (de 1 a 15)
  • CCCCCCCC identifica el componente dentro de la línea.

El valor AAAA=0 se aplica a los dispositivos conectados directamente a la línea que interconecta las distintas áreas.

El valor LLLL=0 se aplica a los dispositivos conectados a la línea principal de un área.

Por último, el valor CCCCCCCC=0 identifica al acoplador de línea (AL) o de área (AA)

Filtrado de telegramas por los acopladores de línea

Cuando se configura un acoplador de línea, se le proporciona una tabla con las direcciones de los dispositivos conectados directamente a dicha línea.

Cuando el acoplador recibe un telegrama, comprueba si la dirección de destino se encuentra en la tabla. Si no es así, envía el telegrama al resto de las líneas, pero si el telegrama está dirigido a un dispositivo local, sólo lo entrega en la línea en donde se encuentra conectado el dispositivo.

Estructura de un telegrama IMI

En el interior del bus, los telegramas que intercambian los dispositivos tienen la siguiente estructura (IMI, Internal Message Interface):

Control / Origen / Destino / Contador / Longitud / Datos / Comprobación

  • Control: 8 bits
  • Origen: 16 bits
  • Destino: 16 bits mas 1 bit (0: dirección física, 1: dirección de grupo)
  • Contador: 3 bits
  • Longitud: 4 bits. Indica el número de bytes del campo de datos
  • Datos: de 1 a 15 bytes.  Datos útiles
  • Comprobación: 8 bits para detectar errores de transmisión.

 Conectividad con el bus desde el exterior

TP-UART

La manera de establecer una conexión al bus desde el exterior ha ido evolucionando a lo largo del tiempo. Históricamente, se han utilizado transceivers TP-UART (Twisted Pair – Universal Asynchronous Receiver/Transmitter) que convierten las señales utilizadas en el par trenzado a bytes en un puerto serie RS232.

BCU

Posteriormente, aparecieron los dispositivos BCU (Bus Coupling Unit) que también permiten acceder al bus por puerto serie, y además incorporan un microprocesador que implementa el protocolo de comunicación del bus en el lado TP, y un protocolo externo (EMI, External Message Interface) en el lado RS232.

Hay dos modalidades de BCU, denominadas BCU1 y BCU2.

Los acopladores BCU1 son más antiguos, y tienen algunas limitaciones. Disponen de poca memoria, y utilizan un interfaz RS232 de tipo PEI16, que es un protocolo asíncrono con un handshake basado en tiempos críticos. Este handshake sólo se puede implementar en un PC mediante un driver de bajo nivel.

Para evitar las limitaciones de los acopladores BCU1, se desarrollaron los acopladores BCU2. Estos acopladores disponen de más memoria, y utilizan un interfaz RS232 de tipo PEI10/FT1.2, sin los problemas de tiempos críticos de PEI16.

USB, EIBnet/IP

Por último, aparecieron los dispositivos que permiten conectarse al bus desde una red IP y desde un puerto USB.

La conectividad con la red IP se realiza a través del la dirección multicast 224.0.23.12:3671 mediante el envío de paquetes UDP

También es posible establecer una conexión uno-a-uno con la dirección IP del dispositivo que se conecta al bus.

Protocolo cEMI

En cuanto a la estructura de los telegramas intercambiados entre el bus y el exterior (EMI, External Message Interface), también han ido evolucionando, pasando por las especificaciones EMI1, EMI2 y finalmente cEMI (Common External Message Interface).

La estructura de una trama cEMI es de la forma:

    +---------+---------+--------+--------+--------+--------+---------+---------+--------+---------+
    | Header  | Conn    |  Msg   |Add.Info| Ctrl 1 | Ctrl 2 | Source  | Dest.   |  Data  |   APDU  |
    |         | Header  | Code   | Length |        |        | Address | Address | Length |         |
    +---------+---------+--------+--------+--------+--------+---------+---------+--------+---------+
      6 bytes   4 bytes   1 byte   1 byte   1 byte   1 byte   2 bytes   2 bytes   1 byte   2 bytes

        Header          = Ver más abajo la estructura del header
        Conn Header     = Header de conexión que incluye un channel ID y número de secuencia
        Message Code    = Ver más abajo los posibles códigos de mensaje cEMI
        Add.Info Length = 0x00 - no additional info
        Control Field 1 = 
        Control Field 2 = 
        Source Address  = 0x0000 - filled in by router/gateway with its source address which is
                          part of the KNX subnet
        Dest. Address   = KNX group or individual address (2 byte)
        Data Length     = Number of bytes of data in the APDU excluding the TPCI/APCI bits
        APDU            = Application Protocol Data Unit - the actual payload including transport
                          protocol control information (TPCI), application protocol control
                          information (APCI) and data passed as an argument from higher layers of
                          the KNX communication stack

El Header es de la forma

        Header Length (1 byte) = 0x06
        KNXnet version (1.0)   = 0x10
        Service type descriptor (2 bytes)
        Total length (2 bytes)

        El Service type descriptor puede ser:
        		SEARCH_REQUEST 0x0201
		        SEARCH_RESPONSE 0x0202
		        DESCRIPTION_REQUEST 0x0203
		        DESCRIPTION_RESPONSE 0x0204
		        CONNECTION_REQUEST 0x0205
		        CONNECTION_RESPONSE 0x0206
		        CONNECTIONSTATE_REQUEST 0x0207
		        CONNECTIONSTATE_RESPONSE 0x0208
		        DISCONNECT_REQUEST 0x0209
		        DISCONNECT_RESPONSE 0x020A
		        TUNNEL_REQUEST 0x0420
		        TUNNEL_RESPONSE 0x0421
		        DEVICE_CONFIGURATION_REQUEST 0x0310
		        DEVICE_CONFIGURATION_ACK 0x0311
		        ROUTING_INDICATION 0x0530

El Connection Header contiene:

        Header Lenght (1 byte) = 0x04
        channel id (1 byte)
        sequence number (1 byte)
        reserved (1 byte) = 0x00

Los posibles códigos de mensaje cEMI son:

    FROM NETWORK LAYER TO DATA LINK LAYER
        Data Link Layer  Message
        Primitive	 Code
        ---------------  -------
        L_Raw.req          0x10	 	 
        L_Data.req         0x11	 Data Service. Primitive used for transmitting a data frame
        L_Poll_Data.req    0x13	 Poll Data Service	 

    FROM DATA LINK LAYER TO NETWORK LAYER
        Data Link Layer  Message
        Primitive	 Code
        ---------------  -------
        L_Poll_Data.con    0x25	 Poll Data Service	 
        L_Data.ind         0x29	 Data Service. Primitive used for receiving a data frame
        L_Busmon.ind       0x2B	 Bus Monitor Service	 
        L_Raw.ind          0x2D	 	 
        L_Data.con         0x2E	 Data Service. Primitive used for local confirmation that a frame was sent
                                 (does not indicate a successful receive though)
        L_Raw.con          0x2F

Los dos bytes de control tienen la estructura:

         Control Field 1

          Bit  |
         ------+---------------------------------------------------------------
           7   | Frame Type  - 0x0 for extended frame
               |               0x1 for standard frame
         ------+---------------------------------------------------------------
           6   | Reserved
               |
         ------+---------------------------------------------------------------
           5   | Repeat Flag - 0x0 repeat frame on medium in case of an error
               |               0x1 do not repeat
         ------+---------------------------------------------------------------
           4   | System Broadcast - 0x0 system broadcast
               |                    0x1 broadcast
         ------+---------------------------------------------------------------
           3   | Priority    - 0x0 system
               |               0x1 normal
         ------+               0x2 urgent
           2   |               0x3 low
               |
         ------+---------------------------------------------------------------
           1   | Acknowledge Request - 0x0 no ACK requested
               | (L_Data.req)          0x1 ACK requested
         ------+---------------------------------------------------------------
           0   | Confirm      - 0x0 no error
               | (L_Data.con) - 0x1 error
         ------+---------------------------------------------------------------

         Control Field 2

          Bit  |
         ------+---------------------------------------------------------------
           7   | Destination Address Type - 0x0 individual address
               |                          - 0x1 group address
         ------+---------------------------------------------------------------
          6-4  | Hop Count (0-7)
         ------+---------------------------------------------------------------
          3-0  | Extended Frame Format - 0x0 standard frame
         ------+---------------------------------------------------------------

Apéndice A – Códigos de mensaje EMI1/EMI2/cEMI

                           IMI1 EMI1 EMI2  cEMI  default comment
                                     /IMI2       dest.    
L_Busmon.ind               29   49   2B     2B   PEI
L_Raw_Data.req                       10     10   LL
L_Raw_Data.con                              2F    
L_Raw_Data.ind                              2D    
L_Data.req                 11   11   11     11   LL
L_Data.con                 2E   4E   2E     2E   NL      EMI1/IMI1: TL
L_Data.ind                 29   49   29     29   NL      EMI1/IMI1: TL
L_Poll_Data.req                      13     13   LL
L_Poll_Data.con                      25     25   NL
N_Data_Individual.req                13          LL
N_Data_Individual.con                4E          TCL
N_Data_Individual.ind                49          TCL
N_Data_Group.req                     22          NL
N_Data_Group.con                     3E          TLG
N_Data_Group.ind                     3A          TLG
N_Data_Broadcast.req                 2C          NL
N_Data_Broadcast.con                 4F          TLC
N_Data_Broadcast.ind                 4D          TLC
N_Poll_Data.req                      23          NL
N_Poll_Data.con                      35          TLG
T_Connect.req              23   23   43          TLC      EMI1/IMI1: TL
T_Connect.con                        86          MG       
T_Connect.ind              33   43   85          MG       
T_Disconnect.req           24   24   44          TLC      EMI1/IMI1: TL
T_Disconnect.con                     88          MG       
T_Disconnect.ind           34   44   87          MG       
T_Data_Connected.req       21   21   41          TLC      EMI1/IMI1: TL
T_Data_Connected.con                 8E          MG       
T_Data_Connected.ind       39   49   89          MG       
T_Data_Group.req           22   22   32          TLG      EMI1/IMI1: TL
T_Data_Group.con           3E   4E   7E          ALG
T_Data_Group.ind           3A   4A   7A          ALG
T_Data_Broadcast.req       2B   2B   4C          TLC
T_Data_Broadcast.con                 8F          MG 
T_Data_Broadcast.ind       38   48   8D          MG
T_Data_Individual.req      2A   2A   4A          TLC
T_Data_Individual.con      3F   4F   9C          MG
T_Data_Individual.ind      32   42   94          MG
T_Poll_Data.req                      33          TLG
T_Poll_Data.con                      75          ALG
M_Connect.req                                   
M_Connect.con                                   
M_Connect.ind                        D5          User     PEI if User is not running
M_Disconnect.req                                
M_Disconnect.con                                
M_Disconnect.ind                     D7          User     PEI if User is not running
M_User_Data_Connected.req  31   31   82          MG
M_User_Data_Connected.con            D1          User     PEI if User is not running
M_User_Data_Connected.ind  59   49   D2          User     PEI if User is not running
A_Data_Group.req                     72          ALG
A_Data_Group.con                     EE          User     PEI if User is not running
A_Data_Group.ind                     EA          User     PEI if User is not running
M_User_Data_Individual.req           81          MG
M_User_Data_Individual.con           DE          User     PEI if User is not running
M_User_Data_Individual.ind           D9          User     PEI if User is not running
A_Poll_Data.req                      73          ALG
A_Poll_Data.con                      E5          User     PEI if User is not running
M_InterfaceObj_Data.req              9A          MG
M_InterfaceObj_Data.con              DC          User     PEI if User is not running
M_InterfaceObj_Data.ind              D4          User     PEI if User is not running
U_Value_Read.req           35   35   74          ALG
U_Value_Read.con           55   45   E4          User
U_Flags_Read.req           37   37   7C          ALG
U_Flags_Read.con           57   47   EC          User
U_Event.ind                5D   4D   E7          User
U_Value_Write.req          36   36   71          ALG
U_User_data                         >D0          User
PC_SetValue.req            46   46   A6          MG      In BCU2 not posted to MG but handled in PEI module
PC_GetValue.req            4C   4C   AC          MG      In BCU2 not posted to MG but handled in PEI module
PC_GetValue.con            4B   4B   AB          PEI
PEI_Identify.req                     A7          -
PEI_Identify.con                     A8          PEI
PEI_Switch.req                       A9          -
TM_Timer.ind                         C1         User

 

 Publicado por en 1:49 pm

  Una respuesta a “Introducción a EIB/KNX”

  1. […] hemos comentado en nuestro anterior artículo de introducción a las redes domóticas EIB/KNX, la conectividad física con el bus puede realizarse de distintas formas, mediante puerto serie, […]

 Deja un comentario

(requerido)

(requerido)