The “European Installation Bus” (EIB) is the standard adopted by the KNX specification for the interconnection of home appliances in a decentralized network.
In a building we can find many devices for the control of illumination, temperature, doors and blinds, etc. Overall, these devices can be classified in two broad groups of “sensors” and “actuators”. Each of these devices communicates with the other devices by sending and receiving “telegrams” (data packets) to/from the bus.
Physically, the bus can be implemented on several media:
- A twisted pair (TP) cable, running along the power line.
- Wireless communication.
- The existinig power line itself (PL)
Topology of an EIB network over TP
An EIB network is structured in several levels:
- A line segment can have up to 64 devices (called APT) attached. Every line segment has its own power supply, providing power to the devices connected to the segment.
- A line can have up to 4 line segments attached to it.
- An area is made up of a main line, that can have up to 15 more lines connected to it by means of “line couplers”.
- Finally, a backbone line can have up to 15 areas connected to it.
Addressing of the devices
In a EIB bus, every device is identified by means of a unique physical address, and one or more group addresses.
The physical address is 16 bits long and has the format AAAA-LLLL-CCCCCCCC,where:
- AAAA identifies an area (from 1 to 15)
- LLLL identifies a line inside a given area (from 1 to 15)
- CCCCCCCC identifies a device inside a line
The value AAAA=0 is used for devices directly connected to the backbone line
The value LLLL=0 is used for devices directly connected to the main line of a given area.
Finally, the value CCCCCCCC=0 identifies a line coupler or area coupler
Filtering of telegrams by line couplers
When a line coupler is configured, it is given a table with the addresses of devices directly connected to the line.
When the line coupler receives a telegram, it checks if the destination address is in the table. If it is not, the telegram is sent to the other lines. Otherwise it is sent only to the line being served by the line coupler
Structure of an IMI telegram
Inside the bus, the telegrams interchanged by devices are structured as IMI (Internal Message Interface):
Control / Origin / Destination / Counter / Length / Data / Checksum
- Control: 8 bits
- Origin: 16 bits
- Destination : 16 bits plus 1 bit (0: physical address, PA; 1: group address, GA)
- Counter : 3 bits
- Length : 4 bits. Number of bytes in the data field
- Data: de 1 a 15 bytes. Payload
- Checksum: 8 bits to detect transmission errors.
Connectivity to the bus from outside
TP-UART
The way external applications connect to the bus has evolved over time. Historically, TP-UART (Twisted Pair – Universal Asynchronous Receiver/Transmitter) transceivers have been used. These transceivers convert the signals employed in the twisted pairs to bytes in an RS-232 serial port. However, the TP-UART does not perform data processing, and relies on an external driver to implement the protocols.
BCU
Later, BCU (Bus Coupling Unit) devices where developed. These BCUs also expose the bus to the outside world by means of a RS-232 serial port, and besides they incorporate a micro-processor that handles the IMI communication protocol in the TP side, and an external protocol (EMI, External Message Interface) in the RS232 side.
There are two types of BCU, named BCU1 and BCU2.
The BCU1 couplers are older, and have some limitations. They have an small amount of memory, and employ a PEI16 type of serial port. PEI16 is an asynchronous protocol with a critical timing kind of handshake. This handshake can only be implemented in a personal computer by means of an specialized low-level driver.
To overcome the limitaions of the BCU1 couplers, the newer BCU2 couplers were developed. These couplers implement more memory, and a RS-232 interface of type PEI10/FT1.2, that is not based on critical timing as the PEI16.
USB, EIBnet/IP
Finally, new devices that implement USB and ethernet interfaces were developed
The IP connectivity is done by sending/receiving UDP packets to the multicast address 224.0.23.12:3671
It is also possible to establish a one-to-one connection against the IP address of the gateway device connected to the bus.
cEMI protocol
The structure of telegrams exchanged between the bus and the outside world (EMI, External Message Interface), has suffered also an evolution, from the initial EMI1, EMI2 specifications (dependant on the physical media) to cEMI (Common External Message Interface).
The structure of a cEMI frame is:
+---------+--------+--------+--------+--------+---------+---------+--------+---------+| Header | Msg |Add.Info| Ctrl 1 | Ctrl 2 | Source | Dest. | Data | APDU || | Code | Length | | | Address | Address | Length | |+---------+--------+--------+--------+--------+---------+---------+--------+---------+ 6 bytes 1 byte 1 byte 1 byte 1 byte 2 bytes 2 bytes 1 byte 2 bytes Header = See below the structure of a cEMI header Message Code = See below. On Appendix A is the list of all existing EMI and cEMI codes 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 |
The Header structure is:
Header Length (1 byte) = 0x06KNXnet version (1.0) = 0x10Service type
descriptor (2 bytes)Total length (2 bytes)Existing service
type descriptors: 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 |
cEMI message codes are:
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 |
The two control bytes structure is:
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------+--------------------------------------------------------------- |
Appendix A – EMI1/EMI2/cEMI message codes
IMI1 EMI1 EMI2 cEMI default comment /IMI2
dest. L_Busmon.ind 29 49 2B 2B PEIL_Raw_Data.req 10 10 LLL_Raw_Data.con 2F
L_Raw_Data.ind 2D
L_Data.req 11 11 11 11 LLL_Data.con 2E 4E 2E 2E NL EMI1/IMI1: TLL_Data.ind 29 49 29 29 NL EMI1/IMI1: TLL_Poll_Data.req 13 13 LLL_Poll_Data.con 25 25 NLN_Data_Individual.req 13 LLN_Data_Individual.con 4E TCLN_Data_Individual.ind 49 TCLN_Data_Group.req 22 NLN_Data_Group.con 3E TLGN_Data_Group.ind 3A TLGN_Data_Broadcast.req 2C NLN_Data_Broadcast.con 4F TLCN_Data_Broadcast.ind 4D TLCN_Poll_Data.req 23 NLN_Poll_Data.con 35 TLGT_Connect.req 23 23 43 TLC EMI1/IMI1: TLT_Connect.con 86 MG
T_Connect.ind 33 43 85 MG
T_Disconnect.req 24 24 44 TLC EMI1/IMI1: TLT_Disconnect.con 88 MG
T_Disconnect.ind 34 44 87 MG
T_Data_Connected.req 21 21 41 TLC EMI1/IMI1: TLT_Data_Connected.con 8E MG
T_Data_Connected.ind 39 49 89 MG
T_Data_Group.req 22 22 32 TLG EMI1/IMI1: TLT_Data_Group.con 3E 4E 7E ALGT_Data_Group.ind 3A 4A 7A ALGT_Data_Broadcast.req 2B 2B 4C TLCT_Data_Broadcast.con 8F MG
T_Data_Broadcast.ind 38 48 8D MGT_Data_Individual.req 2A 2A 4A TLCT_Data_Individual.con 3F 4F 9C MGT_Data_Individual.ind 32 42 94 MGT_Poll_Data.req 33 TLGT_Poll_Data.con 75 ALGM_Connect.req
M_Connect.con
M_Connect.ind D5 User PEI
if User is not runningM_Disconnect.req
M_Disconnect.con
M_Disconnect.ind D7 User PEI
if User is not runningM_User_Data_Connected.req 31 31 82 MGM_User_Data_Connected.con D1 User PEI
if User is not runningM_User_Data_Connected.ind 59 49 D2 User PEI
if User is not runningA_Data_Group.req 72 ALGA_Data_Group.con EE User PEI
if User is not runningA_Data_Group.ind EA User PEI
if User is not runningM_User_Data_Individual.req 81 MGM_User_Data_Individual.con DE User PEI
if User is not runningM_User_Data_Individual.ind D9 User PEI
if User is not runningA_Poll_Data.req 73 ALGA_Poll_Data.con E5 User PEI
if User is not runningM_InterfaceObj_Data.req 9A MGM_InterfaceObj_Data.con DC User PEI
if User is not runningM_InterfaceObj_Data.ind D4 User PEI
if User is not runningU_Value_Read.req 35 35 74 ALGU_Value_Read.con 55 45 E4 UserU_Flags_Read.req 37 37 7C ALGU_Flags_Read.con 57 47 EC UserU_Event.ind 5D 4D E7 UserU_Value_Write.req 36 36 71 ALGU_User_data >D0 UserPC_SetValue.req 46 46 A6 MG In BCU2 not posted to MG but handled
in PEI modulePC_GetValue.req 4C 4C AC MG In BCU2 not posted to MG but handled
in PEI modulePC_GetValue.con 4B 4B AB PEIPEI_Identify.req A7 -PEI_Identify.con A8 PEIPEI_Switch.req A9 -TM_Timer.ind C1 User |
—
扫一扫
2076
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
