Simplifying Control Panel Design for Home and Building Automation Over KNX
June 14, 2022
Blog
The adoption of smart technology in businesses has increased over recent years, creating a more automated world. One of the ways to enable automation is through actors that are networked to a central controller. This includes smart actuators that execute decisions based on data. The data used may be aggregated by cloud services, as well as collected locally by using other connected actors, such as smart sensors.
This level of automation is instrumental in improving energy efficiency, as well as giving companies and homeowners greater control over their immediate environment. It enables features such as monitoring, remote management, utility measurement, and enhanced security.
There are numerous types of networks that enable this level of building management and automation, but the KNX® protocol is the only open and vendor-independent standard worldwide, with close to 400 million networked devices deployed globally.
There are over 500 member companies in the KNX association and more than 93,000 installation partners. Together they have developed over 8000 certified products deployed in at least 190 different countries. The KNX network is versatile and extensible, supporting 256 addressable devices on a 1000m segment, and up to 256 segments in a network.
The communication protocol of the KNX bus is standardized through several international and regional standards (Table 1) and is administered by the KNX Association. It brings together the strengths of several legacy buses to create an OSI-based protocol that can be deployed over various media, including twisted pair, RF, and IP.
International |
ISO / IEC 14543-3 |
European |
EN 50090 |
USA |
ANSI / ASHRAE 135 |
China |
GB/T 20965 |
Table 1. KNX Bus International and Regional Communication Standards
Perhaps the most popular of these media is the simple twisted-pair wiring. In this configuration, the cabling carries both data and power, but the power provided is purely to supply the node’s circuitry; any power required by an actuator would need to be provided separately. In this respect, it is similar to copper telephone cabling.
Interoperability in Smart Buildings
That analogy could be extended to describe the way devices from different suppliers are compatible in a KNX network. Interoperability is a key requirement for any infrastructure that encourages multiple suppliers and manufacturers. In this case, interoperability is ensured through a certification program, managed by the KNX Association. Part of the certification requires manufacturers to demonstrate compliance with key parts of the KNX specifications covering the protocol features and supported profiles. Products must also meet the internetworking requirements of the standard data types and optional functional blocks.
KNX is connecting the automated world.
This level of compliance can present a challenge for OEMs, which is not the intention of the KNX Association. It is in their interest and the interest of the wider ecosystem to make it as simple as practicably possible to bring new products to market. To support this, the association offers a simpler route of certification for new products based on a product that has been previously certified.
The official terminology is a Derived Product, or OEM Product, and it applies if the product being used is sourced from a KNX Association member and that product has already been certified. The OEM is then free to sell their product, with its own label attached, without any further testing required.
This inherited compliance relates to the two most critical elements of the system, the physical layer, and the software stack. If these elements are certified and present without modification, then the OEM product is considered to be compliant and can be marketed as such.
Making KNX Simpler
In order to accelerate the adoption of building automation applications, onsemi has developed the industry’s first KNX pre-certified System-in-Package (SiP). The NCN5140S features all critical and certifiable elements of a KNX device, including the physical layer (PHY) and media access controller (MAC), together with the software stack. These elements are integrated into the NCN5140S, along with an Arm® Cortex®-M0+ based microcontroller.
Since the PHY and stack are pre-certified, products based on the NCN5140S are considered to be derived, or OEM products. As such, the new products only need to carry a KNX Declaration of Product Modification, instead of undergoing full compliance testing. This can significantly save OEMs time and cost when developing new KNX products.
The SiP has been designed for the development of network controllers, which normally take the format of a user panel for controlling lights, HVAC systems, window blinds and shutters, and access systems.
The NCN5140S can be further customized by using a software tool that allows installers to configure the panels during installation. This is carried out using the Engineering Tool Software, or ETS, which is a manufacturer-independent configuration tool made available by the KNX Association. The ETS is used to access the details of certified products, held in a database, and to configure the certified products.
Since this high-level customization does not change the underlying firmware, the certification is not affected and so the SiP can be used as the basis for multiple products. The same would not be true for control panels developed from the constituent parts of the system. It is this pre-integration and certification that allows products based on the NCN5140S to be assessed as Derived Products.
Simplifying Capacitive Touch Sensing
Developing touch-sensitive interfaces can be difficult. They tend to operate by detecting small changes in capacitances, in the order of pico Farads. While care still needs to be taken in the way the PCB is designed, the firmware needed to interface to capacitive touch-sense buttons is also provided by onsemi. This application software, along with the certified stack, is provided as a binary. The file needs to be programmed into the NCN5140S during assembly, but once installed they can be configured during installation using an ETS.
There are effectively three stages that OEMs must carry out during final assembly and installation:
- Flash the binary file to the microcontroller in the NCN5140S
- Configure the product’s unique network ID and application options, which is carried out over the KNX bus interface
- Set the device parameters by using the KNX ETS database.
As an example, during production, the NCN5140S can be programmed and then configured with a unique network ID. At this point the number and type of inputs would be defined (up to 8 generic or capacitive touch-sensitive buttons) as well as the operating mode (such as switching or dimming). The type and number of outputs (simple or RGB LEDs) would also be set.
The installer would configure the services offered by the controller using the ETS database. This could include the device name, the switch behaviour, dimming parameters, timers (if applicable), and scenes (such as dimming levels for different times, rooms, or daylight conditions).
Conclusion
The KNX protocol is a powerful platform for delivering home and building automation. There is a growing demand for this level of automation, which could work in collaboration with things like smart energy meters to help make buildings of all types more energy efficient.