5,839 views
KNX Architecture
Building Control technology as provided by KNX is a specialized form of automated process control, dedicated to the needs of home and building applications. One premise for KNX is to furnish a radically decentralized, distributed approach; hence the term network.
The KNX Device Network results from the formal merger of the 3 leading systems for Home and Building Automation (EIB, EHS, BatiBus) into the specification of the new KNX Association. The common specification of the “KNX” system provides, besides powerful runtime characteristics, an enhanced “toolkit” of services and mechanisms for network management.
On the KNX Device Network, all the devices come to life to form distributed applications in the true sense of the word. Even on the level of the applications themselves, tight interaction is possible, wherever there is a need or benefit. All march to the beat of powerful Interworking models with standardized Datapoint Types and “Functional Block” objects, modelling logical device channels.
The mainstay of S-(“System”) Mode is the centralized free binding and parameterisation (typically with the PC-based ETS tool). It is joined by E (“Easy”)-mode device profiles, which can be configured according to a structured binding principle, through simple manipulations – without the need for a PC tool. These configuration modes share common run-time Interworking, allowing the creation of a comprehensive and multi-domain home and building communication system.
The available Twisted Pair and Powerline communication media are completed with Radio Frequency (868 MHz band).
KNX explicitly encompasses a methodology and PC tools for Project Engineering, i.e. for linking a series of individual devices into a functioning installation, and integrating different KNX media and configuration modes. This is embodied in the vendor-independent Engineering Tool Software (ETS) suites for Windows.
Elements of the KNX Architecture
KNX specifies many mechanisms and ingredients to bring the network into operation, while enabling manufacturers to choose the most adapted configuration for their market. Figure 1 below shows an overview of the KNX model, bringing the emphasis on the various open choices. Rather than a formal protocol description, the following details the components or bricks that may be chosen to implement in the devices and other components a full operational system.
As essential ingredients of KNX, we find in a rather top-down view.
- Interworking and (Distributed) Application Models for the various tasks of Home and Building Automation; this is after all the main purpose of the system.
- Schemes for Configuration and Management, to properly manage all resources on the network, and to permit the logical linking or binding of parts of a distributed application, which run in different nodes. KNX structures these in a comprehensive set of Configuration Modes.
- Communication System, with a set of physical communication media, a message protocol and corresponding models for the communication stack in each node; this Communication System has to support all network communication requirements for the Configuration and Management of an installation, as well as to host Distributed Applications on it. This is typified by the KNX Common Kernel.
- Concrete Device Models, summarized in Profiles for the effective realization and combination of the elements above when developing actual products or devices, which will be mounted and linked in an installation.
Applications, Interworking and Binding
Central to KNX’ application concepts is the idea of Datapoints: they represent the process and control variables in the system, as explained in the section Application Models. These Datapoints may be inputs, outputs, parameters, diagnostic data,…The standardized containers for these Datapoints are Group Objects and Interface Object Properties.
The Communication System and Protocol are expected to offer a reduced instruction set to read and write (set and get) Datapoint values: any further application semantics is mapped to the data format and the bindings, making KNX primarily “data driven”.
In order to achieve Interworking, the Datapoints have to implement Standardized Datapoint Types, themselves grouped into Functional Blocks. These Functional Blocks and Datapoint Types are related to applications fields, but some of them are of general use and named functions of common interest (such as date and time).
Datapoints may be accessed through unicast or multicast mechanisms, which decouple communication and application aspects and permits a smooth integration between implementation alternatives. The Interworking section below zooms in on these aspects. To logically link (the Datapoints of) applications across the network, KNX has three underlying binding schemes: one for free, one for structured and one for tagged binding. How these may be combined with various addressing mechanisms is described below.
Basic Configuration Schemes
Roughly speaking, there are two levels at which an installation has to be configured. First of all, there is the level of the network topology and the individual nodes or devices.
In a way, this first level is a precondition or “bootstrap” phase, prior to the configuration of the Distributed Applications, i.e. binding and parameter setting.
Configuration may be achieved through a combination of local manipulations on the devices (e.g. pushing a button, setting a codewheel, or using a locally connected configuration tool), and active Network Management communication over the bus (peer-to-peer as well as more centralized master- slave schemes are defined).
As described in the corresponding section below, a KNX Configuration Mode:
- picks out a certain scheme for configuration and binding
- maps it to a particular choice of address scheme
- completes all this with a choice of management procedures and matching resource realizations.
Some modes require more active management over the bus, whereas some others are mainly oriented towards local configuration.
Network Management and Resources
To accommodate all active configuration needs of the system, and maintain unity in diversity, KNX is equipped with a powerful toolkit for network management. One can put these instruments to good use throughout the lifecycle of an installation: for initial set-up, for integration of multi-mode installations, for subsequent diagnostics and maintenance, as well as for later extension and reconfiguration. Network Management in KNX specifies a set of mechanisms to discover, set or retrieve configuration data actively via the network. It proposes Procedures (i.e. message sequences) to access values of the different network resources within the devices, as well as identifiers and formats for these resources – all of this in order to enable a proper Interworking of all KNX network devices. These resources may be addresses, communication parameters, application parameters, or complex sets of data like binding tables or even the entire executable application program.
The network management basically makes use of the services offered by the application layer. Each device implementing a given configuration mode (see below) has to implement the services and resources specified in the relevant “profile” (set of specifications, see below).
For managing the devices, these services are used within procedures. The different configuration modes make use of an identified set of procedures, which are described in the “configuration management” part. As indicated above, and further demonstrated in the Configuration Modes section below, KNX supports a broad spectrum of solutions here, ranging from centralized and semi- centralised “master-slave” versions, over entirely peer-to-peer to strictly local configuration styles.
However, mechanisms and Resources are not enough. Solid Network Management has to abide by a set of consistency rules, global ones as well as within and among profiles, and general Good Citizenship. For example, some of these rules govern the selection of the (numerical value of) the address when binding Datapoints.
But now, we first turn our attention to how the Communication System’s messaging solutions for applications as well as management, beginning with the physical transmission media.
Communication: Physical Layers
The KNX system offers the choice for the manufacturers, depending on his market requirements and habits, to choose between several physical layers, or to combine them. With the availability of routers, and combined with the powerful Interworking, multi-media, and also multi-vendor configurations can be built.
The different media are :
- TP 1 (basic medium inherited from EIB) providing a solution for twisted pair cabling, using a SELV network and supply system. Main characteristics are: data and power transmission with one pair (devices with limited power consumption may be fed by the bus), and asynchronous character oriented data transfer and half duplex bi-directional communication. TP 1 transmission rate is 9600 bit/s.
TP1 implements a CSMA/CA collision avoidance. All topologies may be used and mixed ( line, star, tree, ….) - PL 110 (also inherited from EIB) enables communication over the mains supply network. Main characteristics are: spread frequency shift keying signalling, asynchronous transmission of data packets and half duplex bi-directional communication. PL 110 uses the central frequency 110 kHZ and has a data rate of 1200 bit/s.
PL110 implements CSMA and is compliant to EN 50065-1 (in the frequency band without standard access medium protocol). - RF enables communication via radio signals in the 868,3 MHz band for Short Range Devices. Main characteristics are: Frequency Shift Keying, maximum duty cycle of 1%, 32 768 cps, Manchester data encoding.
- Beyond these Device Network media, KNX has unified service- and integration solutions for IP-enabled (1) media like Ethernet (IEEE 802.2), Bluetooth, WiFi/Wireless LAN (IEEE 802.11), “FireWire” (IEEE 1394) etc., as explained in the KNXnet/IP section below.
Communication: Common Kernel and Message Protocol
The Communication System must tend to the needs of the Application Models, Configuration and Network Management. On top of the Physical Layers and their particular Data Link Layer, a Common Kernel model is shared by all the devices of the KNX Network; in order to answer all requirements, it includes a 7 Layers OSI model compliant communication system.
- Data Link Layer General, above Data Link Layer per medium, provides the medium access control and the logical link control.
- Network Layer provides a segment wise acknowledged telegram; it also controls the hop count of a frame. Network Layer is of interest mainly for nodes with routing functionality.
- Transport Layer (TL) enables 4 types communication relationship between communication points: one-to-many connectionless (multicast), one-to-all connectionless (broadcast), one-to-one connectionless, one-to-one connection-oriented. For freely bound models (see below), TL also separates (“indirects”) the network multicast address from the internal representation.
- Session and presentation Layers are empty.
- Application Layer offers a large “toolkit” variety of application services to the application process. These services are different depending on the type of communication used at transport layer. Services related to point-to-point communication and broadcast mainly serve to the network management, whereas services related to multicast are intended for runtime operation.
Remember KNX does not fix the choice of microprocessor. Since in addition, KNX covers an extensive range of configuration and device models, the precise requirements governing a particular implementation are established in detailed Profiles, in line with the Configuration Modes. Within these boundaries, the KNX developer is encouraged to find the optimal solution to accommodate his implementation requirements! This is expounded in later sections.
Related articles
31,716 views
Designing a quality grounding system is not only for the safety of employees but also provides the protection required for buildings and equipment.
Ungrounded systems may provide greater continuity of operations in the event of a ground fault. However, the second fault will most likely be more catastrophic than a grounded system fault. Whenever ungrounded systems are used in a facility, the maintenance personnel should receive training in how to detect and troubleshoot the first ground on an ungrounded system.
Electrical systems can be operated grounded or ungrounded, depending on the condition of the systems use. Electrical systems are grounded to protect circuits, equipment, and conductor enclosures from dangerous voltages and personnel from electrical shock. See NEC Sections 110-9, 110-10, 230-65, 250-1, and 250-2 that list the requirements to provide this protection.
“Grounded” means that the connection to ground between the service panel and earth has been made. Ungrounded electrical systems are used where the designer does not want the overcurrent protection device to clear in the event of a ground fault.
Ground detectors can be installed per NEC Section 250-5(b) FPN to sound an alarm or send a message to alert personnel that a ground fault has occurred on one of the phase conductors. Ground detectors will detect the presence of leakage current or developing fault current conditions while the system is still energized and operating. By warning of the need to take corrective action before a problem occurs, safe conditions can usually be maintained until an orderly shutdown is implemented.
Grounded Systems
Grounded systems are equipped with a grounded conductor that is required per NEC Section 250- 23(b) to be run to each service disconnecting means. The grounded conductor can be used as a current-carrying conductor to accommodate all neutral related loads. It can also be used as an equipment grounding conductor to clear ground faults per NEC Section 250-61(a).
A network of equipment grounding conductors is routed from the service equipment enclosure to all metal enclosures throughout the electrical system. The equipment grounding conductor carries fault currents from the point of the fault to the grounded bus in the service equipment where it is transferred to the grounded conductor. The grounded conductor carries the fault current back to the source and returns over the faulted phase and trips open the overcurrent protection device.
Note: A system is considered grounded if the supplying source such as a transformer, generator, etc., is grounded, in addition to the grounding means on the supply side of the service equipment disconnecting device per NEC Sections 250-23(a) or 250-26 for seperately derived systems.
The neutral of any grounded system serves two main purposes: (1) it permits the utilization of line- to-neutral voltage and thus will serve as a current-carrying conductor to carry any unbalanced current, and (2) it plays a vital role in providing a low-impedance path for the flow of fault currents to facilitate the operation of the overcurrent devices in the circuit. (See picture below).
Consideration should be given to the sizing of the neutral conductor for certain loads due to the presence of harmonic currents (See NEC Sections 210-4 and 310-10).
A grounded system is equipped with a grounded (neutral) conductor routed between the supply transformer and the service equipment.
Ungrounded Systems
Ungrounded systems operate without a grounded conductor. In other words, none of the circuit conductors of the electrical system are intentionally grounded to an earth ground such as a metal water pipe, building steel, etc. The same network of equipment grounding conductors is provided for ungrounded systems as for solidly grounded electrical systems. However, equipment grounding conductors (EGCs) are used only to locate phase-to-ground faults and sound some type of alarm.
Therefore, a single sustained line-to-ground fault does not result in an automatic trip of the overcurrent protection device. This is a major benefit if electrical system continuity is required or if it would result in the shutdown of a continuous process. However, if an accidental ground fault occurs and is allowed to flow for a substantial time, overvoltages can develop in the associated phase conductors. Such an overvoltage situation can lead to conductor insulation damage, and while a ground fault remains on one phase of an ungrounded system, personnel contacting one of the other phases and ground are subjected to 1.732 times the voltage they would experience on a solidly neutral grounded system. (See picture below).
Note: All ungrounded systems should be equipped with ground detectors and proper maintenance applied to avoid, as far as practical, the overcurrent of a sustained ground fault on ungrounded systems. If appropriate maintenance is not provided for ungrounded systems, a grounded system should be installed to ensure that ground faults will be cleared and the safety of circuits, equipment, and that personnel safety is ensured.
An ungrounded system does not have a grounded (neutral) conductor routed between the supply transformer and the service equipment because the supply transformer is not earth grounded.
High impedance grounding
Electrical systems containing three-phase, three-wire loads, as compared to grounded neutral circuit conductor loads, can be equipped with a high-impedance grounded system. High-impedance grounded systems shall not be used unless they are provided with ground fault indicators or alarms, or both, and qualified personnel are available to quickly locate and eliminate such ground faults.
Ground faults must be promptly removed or the service reliability will be reduced. See NEC Section 250-27 for requirements pertaining to installing a high-impedance grounding system. (See picture below).
A high-impedance grounding system has a high-impedance unit, installed between the grounded (neutral) conductor and the grounding electrode conductor, which is used to regulate fault current.
Source: DOE HANDBOOK – ELECTRICAL SAFETY
.
