2 Introduction to KNX/EIB 2.1 Purpose of KNX/EIB A Building Automation System (BAS) [02] is a network of (programmable) devices that control the environmental condition of a building like lighting and shading, heating, ventilation and air conditioning (HVAC). It aims at improving control, monitoring and administration of technical building subsystems to gain cost efficiency and building control and to improve comfort for the ‘occupants. Management and configuration of an integrated BAS becomes easier and allows reduction of management tools. Security critical subsystems like access control and security alarm systems have been implemented as stand-alone systems. This is due to the fact that they depend on the underlying control systems to be reliable and robust to avoid malicious manipulation of devices and traffic However, today the demand for a tighter integration of the traditional BAS and security control systems exists. ‘The EIB (European Installation Bus) [04] is a fieldbus designed to enhance electrical installations in homes and buildings by separating the transmission of control information from traditional electrical wiring. Its main applications are solutions in lighting, window blinds control and HVAC systems. EIB is based on an open specification, maintained until recently by the EIBA (EIB Association, {05]). The newly emerged KNX standard [06] is a combination of EIB, Batibus and EHS (European Home System), combining their best aspects. EIBA, EHS Association and Batibus Club International formed the Konnex Association, accordingly. KNX/EIB installations are hierarchically structured, end devices are topologically arranged in lines and areas. Lines are interconnected with each other by line couplers (LC). Up to 15 lines can be combined to an area, backbone couplers (BC) can combine up to another 15 areas. A maximum of 256 devices can be addressed in a line. Thus, a completely extended KNX/EIB system can accommodate up to 57600 devices. Page 10KNX/EIB Simulation 2 Introduetion to KNX/EIB Figure 2.1: KNX/EIB network with different areas and backbone line Logically, KNX/EIB is a peer-to-peer system. Devices communicate with each other without the presence of a dedicated master. In general, two types of communication can be distinguished: ‘management communication using unicast and broadcast and process data communication ing multicast communication, 2.2. Introduction to the KNX/EIB Protocol 2.2.1 KNX/EIB and the OSI reference model ‘The Open Systems Interconnection (OSI) model splits the complex tasks of data communication into 7 defined sub-areas, referred to as layers [07]. Each layer interacts with the layer above and below. A layer, the service provider, provides a service to the layer immediately above, the service user. The interface between both layers defines how the service user can access the service of the service provider, specifies the parameters and the result to be expected. A protocol defines a set of rules and conventions that is being used by layers of the same level, allowing communication between devices. Page IKNX/EIB Simulation 2 Introduetion to KNX/EIB ‘Communication between layer N and layer (N-1) via its services or its interfaces respectively ‘ocours via a Service Data Unit (SDU). Communication between two peer layers is done via a Protocol Data Unit (PDU) which consists of the user data, the Interface Control Information (ICI) and the layer specific Protocol Control Information (PCD. Examining the KNX protocol, not all layers of the OSI protocol are necessary. Only 5 out of 7 layers are being used by the KNX standard, These are: © Physical Layer © Data Link Layer © Network Layer © Transport Layer © Application Layer OSI Model KNX/EIB 7 Application Layer 7. Application Layer 6. Presentation Layer 6 5 Session Layer 5 - 4 Transport Layer 4 Transport Layer 3) Network Layer 3) Network Layer 2 Pala Vink Vaya 2) Mala Vink Vayer 1, Physical Layer 1. Physical Layer Figure 2.2: KNXJEIB layers ++ OSI layers Focusing on the communication of peer layers, there are 4 different service primitives: request (req), indication (ind), confirmation (con) and response (res). Services need not always to make use of each of the service primitives and can be classified as follows: Locally confirmed services comprise of a request, an indication and a confirmation. The local service user calls the layer N service provider. A request and the corresponding PDU is being ‘generated and passed on to the layer (N-1) until itis given over to the physical medium. On the receiver side, the peer layer N is activated with an indication, the enclosed PDU is decoded and the data passed to the layer above Page 12