Award winning manufacturer of IT-based building automation.
Generic Language for EnOcean Networks
With Generic Profiles, the EnOcean Alliance has further developed the standardized interoperable communication of energy harvesting wireless solutions. It allows multi-functional products that flexibly adapt to a variety of applications.
Generic Profiles Team Leader,
Technical Working Group,
A core task of the EnOcean Alliance is to ensure the interoperability
of EnOcean-based devices. For this, the Alliance’s Technical Working
Group (TWG) has defined and maintains application profiles (EnOcean
Equipment Profiles, EEP) that enable a device from vendor A to
communicate with a sensor from vendor B and to connect to a gateway
from vendor C. This seamless data exchange gives the users the freedom
of choice to create an individual automation system according to
specific requirements – independently from the manufacturer.
Increasing application variants
The variety of energy harvesting wireless products and applications has continuously increased. That’s why the TWG was looking for an addition to EEPs which is particularly suitable for new product designs that are intended to describe the energy harvesting wireless data encoding independently of the application. This addition is called “Generic Profiles”. It is the first generic language for the communication of energy harvesting wireless solutions. Both, EnOcean Equipment Profiles and Generic Profiles, describe the data communication of products utilizing the EnOcean radio protocol to enable manufacturers to develop interoperable products. The key strength of Generic Profiles is to allow devices to have self-described dynamic communication.
Generic Profiles define the grammatical rules for all options of data
encoding for ultra-low power and energy harvesting radio communication.
Due to this generic language, the same product can be mapped
dynamically to different applications. As a result, Generic Profiles
offer a standardized path for future applications.
Similar to the OSI model (Open Systems Interconnection), Generic
Profiles communication define part of the application and presentation
layers. Excluding the session and transport layer, serial or any other
communication type (e.g. TCP/IP) can exchange the Generic Profiles
messages independently from the radio and its frequencies. Computer
network protocols are using abstraction layers for hiding
implementation details for a particular set of functionality. To
confine this, abstraction layers for Generic Profiles communication are
applied as well.
Covering all parameters
The data sent over the air is generally the result of an analogue-to-digital conversion, the state of a counter in the transmitting device or similar information. To conserve energy, these raw measurements are transmitted directly, using only as many bits as the native conversion produces. To determine the actual value, it is necessary to have a set of parameters to transform the pure digital values into physical units. Declaring this set of parameters will enable the receiver to recalculate the originally measured value as a preparation for further processing.
Generic Profiles include a language definition with a parameter selection that covers every possible measured value to be transmitted. Therefore, the approach does not only define parameters for the value recalculation algorithm but also includes specific signal definition (e.g. physical units).
Self-description of communication
For every measurement, the set of parameters has to be transmitted
before the first operational data exchange. This is done during the
teach-in process. Here, devices exchange for one-time information about
how to interpret data which will be exchanged in the data
communication. Using this process, the device describes its future
Therefore, a generic teach-in procedure allows a device to connect to different radio partners. The teach-in process has a bidirectional character and consists of two consecutive messages: After the receiver has been switched into the learn mode, the transmitter broadcasts a teach-in request message. If the receiver has bidirectional communication capabilities, then it can send a teach-in response addressed to the transmitter as confirmation. This is required to enable commissioning devices to see and document the teach-in result.
Automated processing of digital data is only possible if all information about the acquisition type of the received data is available. Through this classification, a value can be combined with its physical unit. Therefore, three different main parameters (channel type, signal type, value type) have to be communicated. The interpretation of received data messages is based on two conditions: First, the message has to be accepted. That means that it has to carry a valid EnOcean ID that is known by the receiver or it can address the receivers EnOcean ID. Secondly, the receiver has to be aware of the user data structure. As this structure is almost infinitely variable due to the generic approach, the transmitter has to transmit its channel characteristics before the data communication in the teach-in process. Following the guidelines of the defined communication layers and Generic Profiles, every generic EnOcean device can exchange data with compatible devices.
Freedom of choice
OEMs still have the freedom of choice to integrate specific EEPs,
Generic Profiles or both. Networks can combine EEP-based devices with
products using Generic Profiles. In this case, only the receiving side,
e.g. a controller solution, needs to cover both data interfaces. Wired
systems that process batteryless radio don’t need any change as the
data interface remains transparent. This brings unique flexibility to
new batteryless product developments and ensures the future-proof
characteristics of existing ones.
In the future, new product developments can use the generic system specification for seamless interoperable communication. This applies above all to dynamic solutions, such as temperature sensors which can be used in warm or cold environments. Here, the sensors need the flexibility to cover different ranges of temperature.
Using Generic Profiles, multi-purpose sensors, which measure temperature, humidity and presence, can now send their future data communication format in the teach-in telegram to the receiving system. There, the data is connected on the application level. The application automatically adjusts to this generic definition and sends back the information to the sensors, which values it accepts or can process. If devices work bidirectionally, they can negotiate the accepted channels in a dialogue.
Profiles is the first generic language for the communication of energy
harvesting wireless solutions. They take the interoperability of
EnOcean-based devices to the next level and ensure that future
solutions of different vendors can communicate with each other – even
with increasing application and function varieties.
Generic Profiles are a new communication convention that adds to the interoperability principle of the EEPs. This generic language definition is particularly suitable for new product designs, which are intended to be mapped dynamically to different applications. In this case, OEMs can insert the generic language definition instead of several profiles for the various use cases. Finally, Generic Profiles allow easier and faster product development but meet stronger certification requirements. They mark a significant leap in ensuring the interoperability of future energy harvesting wireless solutions – even when the variations of application increase.
note: This article respresents a major evolution in control languages.
For insight and perspective you may wish to reread the following
summary of the
evolution of control languages.
“The Past and Future of Control Languages” A call to the industry to speed their evolution to open protocol for control languages.
Why do we need change?
The problem as I see it is that all large building automation vendors only allow changes to their internal control languages using their proprietary software. Just because they all use BACnet or Lon or EnOcean has no effect on the access to the control language which controls the relationship of how the open standards interact.
This creates a problem when global strategies are implemented such as DR (Demand Response). These global implementations not only involve all of the vendors' proprietary control languages but all of their installing partners who have written the strategies.
article sets the mold for other protocols to get on with development
of their Generic Network Control Languages and the ability to do
protocol conversion on the fly. Great work EnOcean.
About the Author
Marian Hönsch is Product Manager and Software Architect at EnOcean. In
this position, he is responsible for EnOcean software products and
security concepts. In the EnOcean Alliance, he actively contributes to
the Technical Working Group, where he led the Generic Profiles team. In
addition, he is member of the Alliance’s EEP Approval Committee. Marian
holds a bachelor in Informatics and a Master of Science magna cum laude
in Software Engineering.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]