3 Engineering IoT Networks
161
OPC server. The last piece is called Quality which gives a basic understanding if
the data is valid or not.
• OPC Alarm & Events (AE) It is fundamentally different from the DA model
simply due to the fact that events do not have a current value. This means that
this protocol always is a subscription-based service where the clients gets all the
events that come in. In terms of data that comes with the event, there is no tags
and therefore not any name and quality, but there is of course a Timestamp. But
like in the case with DA, there is no store in the server, and once the event is
transferred, the server forgets it was ever there.
• OPC Historical Analysis (HDA) The difference between DA, AE, and HDA is
that HDA contains historical data and you can call for a large amount of past
data. The model therefore supports long record sets of data for one or more data
points. It was designed to provide a unified way to get out and distribute historical
data stored in SCADA.
• Programs (Prog). It specifies a mechanism to start, manipulate, and monitor the
execution of programs.
Other organizations can build their models on top of the UA base or on top
of the OPC information model, exposing their specific information via OPC-UA.
Examples for standards already working on mappings to OPC-UA are Field Device
Integration (FDI) combining Electronic Device Description Language (EDDL) and
Field Device Tool (FDT) both used to describe, to configure, and to monitor devices,
and PLCopen, a standard for PLC programming languages. Additional vendorspecific information models will be defined using directly the OPC-UA base, the
OPC models, or other OPC-UA-based information models.
3.5 IoT Network Design Methodology
In Sect. 3.1 we described the general structure of an IoT application and its specific
characteristics:
• strict dependence between application and communication aspects;
• system-of-systems nature;
• strict relationship with the environment.
Because of these characteristics, the design of IoT network structure can be a
complex task, and the huge amount of opportunities provided by standard technologies (as the ones described in previous sections) can be an issue. Furthermore IoT
applications can be heterogeneous, i.e., they may involve more than one technology
in the same scenario. For instance, a LR-WPAN technology can be used inside
some buildings that are then connected together by using a LP-WAN technology.
Research work addressed this problem. In [92] a communication-aware design flow
is proposed together with a communication-aware formal specification of the whole
161
OPC server. The last piece is called Quality which gives a basic understanding if
the data is valid or not.
• OPC Alarm & Events (AE) It is fundamentally different from the DA model
simply due to the fact that events do not have a current value. This means that
this protocol always is a subscription-based service where the clients gets all the
events that come in. In terms of data that comes with the event, there is no tags
and therefore not any name and quality, but there is of course a Timestamp. But
like in the case with DA, there is no store in the server, and once the event is
transferred, the server forgets it was ever there.
• OPC Historical Analysis (HDA) The difference between DA, AE, and HDA is
that HDA contains historical data and you can call for a large amount of past
data. The model therefore supports long record sets of data for one or more data
points. It was designed to provide a unified way to get out and distribute historical
data stored in SCADA.
• Programs (Prog). It specifies a mechanism to start, manipulate, and monitor the
execution of programs.
Other organizations can build their models on top of the UA base or on top
of the OPC information model, exposing their specific information via OPC-UA.
Examples for standards already working on mappings to OPC-UA are Field Device
Integration (FDI) combining Electronic Device Description Language (EDDL) and
Field Device Tool (FDT) both used to describe, to configure, and to monitor devices,
and PLCopen, a standard for PLC programming languages. Additional vendorspecific information models will be defined using directly the OPC-UA base, the
OPC models, or other OPC-UA-based information models.
3.5 IoT Network Design Methodology
In Sect. 3.1 we described the general structure of an IoT application and its specific
characteristics:
• strict dependence between application and communication aspects;
• system-of-systems nature;
• strict relationship with the environment.
Because of these characteristics, the design of IoT network structure can be a
complex task, and the huge amount of opportunities provided by standard technologies (as the ones described in previous sections) can be an issue. Furthermore IoT
applications can be heterogeneous, i.e., they may involve more than one technology
in the same scenario. For instance, a LR-WPAN technology can be used inside
some buildings that are then connected together by using a LP-WAN technology.
Research work addressed this problem. In [92] a communication-aware design flow
is proposed together with a communication-aware formal specification of the whole