2018 International Conference on Mechatronics, Electronics and Automotive Engineering (ICMEAE)

Interpretation and Emulation for Telegrams of the

KNX Standard on MATLAB Simulink
Ariel A. Lopez-Aguilar, Sergio A. Navarro-Tuch, M. Rogelio Bustamante-Bello,
Javier Izquierdo-Reyes and Luis A. Curiel-Ramirez
Escuela de Ingenieria y Ciencias
Instituto Tecnologico y de Estudios Superiores de Monterrey
Ciudad de Mexico, Mexico

Abstract—The KNX Standard was developed by the Konnex
Association for the design of home automation applications,
so the Engineering Tool Software (ETS) was created for the
control of smart buildings and it works with its own protocol,
the KNXnet/IP protocol. However, the KNXnet/IP protocol is
designed exclusively for home automation applications and it is
intended to be implemented in different areas, such as biometric
applications, for future projects. To achieve this, it is proposed
to understand and emulate the operation of the KNXnet/IP
telegrams. Wireshark software was used to interpret the protocol
telegrams and replicate their operation using MATLAB/Simulink
tools. The development of the program on MATLAB/Simulink
managed to effectively emulate the behavior of the KNXnet/IP
protocol and establish an adequate communication between the
computer and the KNX control board.
Index Terms—Home Automation, KNX, Telegrams, MATLAB,
Simulink.
I. I NTRODUCTION
The KNX Standard is an open standard developed by
Konnex Association for home automation and building control
(ISO/ICE 14543, CENELEC EN 50090, CEN EN 13321-1,
GB/Z 20965), based on home automation protocols BatiBus,
the European Installation Bus (EIB) and the European Home
System (EHS) [1]. KNX Standard supports different communi-
cation media such as Twisted Pair (KNX TP), Powerline (KNX
PL), Radio Frequency (KNX RF) and tunneling IP (KNX IP)
[2]. For purposes of this article, the communication media
used is KNX IP.
KNX Standard works with its own system, KNX system.
The KNX system is a bus system for building control, making
every device in a KNX system use the same transmission
method and exchange data via a common bus network. The
KNX system uses a decentralized bus system [3], this means
that if one device does not function, the others continue to
work correctly.
For planification, project design and commissioning of KNX
installations, both the designer and the electrical installer
have one program that combines project design and start-up
tools for these installations, this program is the Engineering
Tool Software (ETS) [4]. The communication between the
devices is using telegrams. The telegrams [3] are data packets
containing data that will be exchanged in a bus system.
Finally, one of the key features of the KNX operating
mode is the use of an address system, which means that
each bus within a KNX system has a physical and group
address. The physical addresses are used for initialization,
programming, operations diagnostics. Group addresses are
used for communication during operations, as well as for
communication via multicast [2].
The propose to emulate the KNX telegrams is using soft-
ware for simulation of models and system, as well as data
acquisition tools. In this case, MATLAB/Simulink software
will be used for the emulation of KNX telegrams; and the use
of Wireshark software for reading and interpretation of the
data that will be sent to the KNX control board.
II. T HE KNX NET /IP P ROTOCOL
KNXnet/IP Protocol was developed for the exchange of
KNX telegrams between devices in a KNX system via Ether-
net. Ethernet [5] is a IEEE Standard (802.3) for local and wide
networks. Generally, Ethernet is used for local area networks
in conjunction with Internet. This standard defines the physical
layers in the transmission media in the OSI model. However,
the operation of the network layer has yet to be defined.
The network layer is managed through the Internet Protocol
(IP), this protocol [6] is used to send data packets between
devices in a network through IP addresses. KNX systems
are decentralized, User Datagram Protocol (UDP) is for the
transport layer. UDP protocol is one of the most used protocols
for building control, and it is needed in systems where there is
no problem that some data packets go missing [3]. The overall
behavior is shown in Figure 1.
The system that works with KNXnet/IP uses two communi-
cation methods via Ethernet: Tunneling and Routing, and both
use UDP protocol.
A. KNXnet/IP tunneling
Tunneling is used for KNX system applications in which
KNX telegrams are sent in a connection-oriented manner using
a framework IP. This method is applied when a physical
address is used as a destination address. The communication
always takes place via IP device that is being used for
tunneling.
B. KNXnet/IP routing
Routing method is used when it is needed to send telegrams
simultaneously in a connectionless manner to different devices

978-1-5386-9191-5/18/$31.00 ©2018 IEEE 129

DOI 10.1109/ICMEAE.2018.00031
in a router KNXnet/IP. Every KNX telegram will be sent to
their corresponding group address via router KNXnet/IP.
Fig. 1. OSI model reference for the KNXnet/IP protocol.
As shown in Figure 2, each KNXnet / IP system [7] contains
the following elements:
• IP network to be used as a backbone for the exchange of
data between devices.
• KNX subnetwork that will be used as communication
medium.
• KNXnet/IP router for the connection between IP network
and KNX subnetwork.
Fig. 2. KNXnet/IP system.
KNXnet/IP router uses the IP communication methods
unicast and multicast.
• Unicast: It is used for tunneling and management op-
erations in which there is a direct communication as
well as a confirmation. Each KNXnet/IP router should
be configured to send data to a predefined list of devices.
• Multicast: There is no communication between channels.
There is always information being transmitted between all
the KNXnet/IP routers that are within the same multicast
IP address. Each telegram must be filtered depending on
the group address indicated by the telegram.
130
III. KNX NET /IP T ELEGRAMS
KNX telegrams managed by KNX are data packets that are
exchanged between devices within a KNX network system.
The KNX telegrams are generated when an event occurs in
the bus. All the devices that are addressed on the bus send an
acknowledgment of receive, better known as ”Acknowledge”
or ”ACK”, of the telegram simultaneously [4].
Each KNX telegram consists of bus-specific data and use-
ful information that informs about the event that has taken
place. The data is transmitted in 8-bit characters. The KNX
telegram also informs about the detection of errors during the
transmission, guaranteeing a high level of reliability.
The KNX telegram (Figure 3) is composed by these sec-
tions:
• Header Length: Its main purpose is to indicate the start
of the telegram. It never varies.
• Protocol version: Indicates which version of the
KNXnet/IP protocol is being applied.
• KNXnet/IP Service Type Identifier: Indicates which ac-
tion will be performed.
• Total Length: Indicates the number of total bytes that the
KNXnet/IP telegram contains.
• KNXnet/IP - Body: Contains all the information neces-
sary for the performance of the requested function.
Fig. 3. KNXnet/IP Telegram.
IV. KNX NET /IP T ELEGRAMS I NTERPRETATION
Wireshark software was used for the interpretation of the
KNXnet/IP telegrams. Wireshark is an open-source protocol
analyzer [8]. Wireshark was used to read and analyze the data
traffic in the KNXnet/IP network (Figure 4).
When a KNXnet/IP telegram is opened in the Wireshark
interface, it is shown its content (Figure 5). In this case, the
KNXnetIP telegram opened is the Connect Request telegram.
Its information is related about how the data packet was
 Fig. 4. Data traffic in the KNXnet/IP System.
encapsulated and how it will operate. The part that will be
used is the KNXnet/IP section. The KNXnet/IP telegram is
composed by two parts, header and body. Wireshark indicates
us how the telegram bytes are organized and their function
within the telegram. However, only raw data is needed for the
creation of our own telegrams in the MATLAB environment,
raw data is indicated in the lower part of the Wireshark
interface; Another important point is that the raw data used
in the KNXnet/IP protocol is written in hexadecimal. For the
emulation of the KNXnet/IP protocol behavior, the sequence
of the KNXnet/IP telegram structure must follow the exact
same order.
Fig. 5. Connect Request Telegram structure.
V. KNX NET /IP T ELEGRAMS E MULATION ON
MATLAB/S IMULINK
The system we use (Figure 6) interacts through a LAN
connection between the PC (as client), switch, KNXnet/IP
router and the KNX module. An important point of this system
is that it uses UDP protocol for its communication, but it
also works in a connection-oriented manner, this means KNX
telegrams will be repeated in case theres an error in the
communication.
131
Using Wireshark, it was found that the KNX system devices
must be configured first before sending orders to the actuators
and sensors. The order of the execution of the KNX telegrams
obtained using ETS is the following:
• Connect Request
• Connect Response
• Device Configuration Request
• Device Configuration Acknowledge
• Description Request
• Description Response
• Device Configuration Request
• Device Configuration Acknowledge
• Disconnect Request
• Disconnect Acknowledge
To achieve an effective connection between the computer,
the KNXnet/IP router and the KNX devices, an UDP protocol
object must be created first in the MATLAB environment. It
is very important that the Local Host, the Remote Host and
the Remote Port are defined in the UDP object, this data is
obtained from the Wireshark interface.
Fig. 6. KNXnet/IP System Configuration.
From the KNXnet/IP telegram raw data read in the Wire-
shark interface, a new variable in the MATLAB environment
is created and saved in the MATLAB workspace, this variable
will act as our KNXnet/IP telegram. In the Figure 7, there is
a comparison between the data saved in the variable and the
raw data in the Wireshark interface.
The raw data in the KNXnet/IP telegram is written in
hexadecimal, and although the MATLAB environment can
work with alphanumeric variables, the MATLAB / Simulink
environment does not accept this type of variables. So, a
translation from hexadecimal to decimal must be applied in
all the telegrams that will be sent. During the realization of
this paper, the MATLAB and MATLAB/Simulink version used
in the experiment is MATLAB R2015a.
Fig. 7. Connect Request KNXnet/IP Telegram in Wireshark and MATLAB
constant
KNXnet/IP telegrams are sent and received entirely in form
of 8 bit characters. MATLAB/Simulink blocks that could send
and receive data in this manner are To Instrument and Query
Instrument blocks, respectively. To Instrument block [9] opens
an interface to the KNXnet/IP router, initialize the router and
sends the KNXnet/IP telegrams to the router. Query Instrument
block [10] does the same steps as To Instrument block, but
in this case, it queries the data from the router. Both blocks
parameters do not required to be modified, they only need
to call the UDP object located in the Matlab workspace to
generate a communication between the PC and the KNX
Module.
Each KNXnet/IP telegram that will be sent are stored in
a MATLAB/Simulink Constant block connected to the To
Instrument block (Figure 8), this Constant blocks call the
KNXnet/IP telegrams created as variable from the MATLAB
workspace.
Fig. 8. Connect Request and Connect Response MATLAB/Simulink program.
132
VI. R ESULTS
A MATLAB/Simulink interface was developed to create a
communication between the PC and the KNX devices without
the need of the ETS (Figure 9). This program can send and
receive KNXnet/IP telegrams.
Fig. 9. MATLAB/Simulink interface to configure KNX module.
The received KNXnet/IP telegrams data were stored on
the MATLAB workspace in a 2D array format, making them
accessible to be read and take the elements needed to modify
other KNXnet/IP telegrams (e.g. Communication Channel ID)
that will be sent. The data obtained from the KNXnet/IP router
is accommodated without indicating which bit corresponds
to each part of the KNXnet/IP telegram. In Figure 10, it is
shown how Wireshark was used to verify that the obtained
KNXnet/IP telegram bits (raw data) are correctly positioned
in the MATLAB variable saved in the workspace.
Fig. 10. Connect Response comparison between Wireshark and MATLAB
Variable
For the validation of this experiment, Wireshark tool was
used to observe the data packets traffic in the network through
the Ethernet layer. In figure 11, the wireshark interface is pre-
sented showing the traffic of data ordered by communication
protocol.
This first approach allows us to create a connection through
the KNXnet/IP protocol to configure the devices within the
system to make the KNX module ready to make modifications
in a living space.
 Fig. 11. Connect Request and Connect Response MATLAB/Simulink program.

VII. C ONCLUSIONS & F UTURE W ORK

Konnex Association developed an accessible and easy to
understand standard. The KNX standard follows a logical
sequence of simple operation, making it simple to replicate
in other programming media, and as a proposal, an commu-
nication interface was made in MATLAB/Simulink software.
However, modifications must be made in the program for
the reception of KNXnet/IP telegrams because the system
uses UDP protocol creating an asynchronous communication,
this means that the time period of reaction of the devices
will not be same. Asynchronous communication may cause
errors when the Query Instrument block is activated because
it opens the channel for an exact period of time to acquire all
KNXnet/IP telegrams bits and some bits could go missing.
As a future work, a MATLAB/Simulink program will
be developed for create a communication using KNXnet/IP
telegrams to control actuators and get data from sensors
with the modifications mentioned before. The final step is to
adapt our programs to make the KNXnet/IP protocol work
with biometric measuring instruments and implement them in
experiments related to health care and user experience.
R EFERENCES
[1] H. Ning, W. Ya-Hu and T. Yi. Research of KNX Device Node and
Development Based on the Bus Interface Module in 29th Chinese Control
Conference, China, 2010, pp. 4346-4350.
[2] W. S. Lee and S. H. Hong. KNX ZigBee Gateway for Home Automation
in 4th IEEE Conference on Automation Science and Engineering, USA,
2008, pp. 750-755.
[3] Konnex Association, ”KNX Basics”, Konnex Association, Belgium.
[4] Konnex Association, Telegrama KNX TP, Konnex Association, Belgium.
[5] IEEE Standard for Ethernet, IEEE Standard 802.3, 2012
[6] https://tools.ietf.org/html/rfc791 A
[7] S. Cavalieri, Analysing Congestion in KNXnet/IP Communication System
in 2011 IEEE Int. Conf. Ind. Technol., pp. 244249, 2011.
[8] M. F. Borja, Anlisis de trfico con Wireshark, INTECO, p. 52, 2011.
[9] Mathworks. To Instrument. Available:
https://www.mathworks.com/help/instrument/toinstrument.html
[10] Mathworks. Query Instrument. Available:
https://www.mathworks.com/help/instrument/queryinstrument.html

133