|
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.
|
Marian Hönsch,
Generic Profiles Team Leader,
Technical Working Group,
EnOcean Alliance |
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.
Layer approach
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
communication itself.
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.
Generic
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.
Future-proof interoperability
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.
Editor's
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.
This
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.
footer
[Click Banner To Learn More]
[Home Page] [The
Automator] [About] [Subscribe
] [Contact
Us]
