®
F O U N D A T I O N
OPC Unified Architecture
for
The Internet Of Things
Draft Version 0.00.01
February 22, 2012
OPC UA for ISA-95
Draft 0.00.01
ii
Specification
Type:
Unified Architecture for
the Internet Of Things
for OPC
Comments:
Report or view errata:
http://www.opcfoundation.org/errat
a
Title:
OPC
Unified Date:
Architecture
for
the Internet Of Things
February 22, 2012
Version:
Draft Version 0.00.01
Software:
MS-Word
Author
Thomas Burke
Source:
OPC_Unified Architecture for the
Internet Of Things_0.00.01.doc
Owner:
OPC UA
Status:
Draft Version
CONTENTS
Page
1
Concept ........................................................................................................................... 4
2
1.1 Overview ................................................................................................................ 4
M2M Unified Architecture Models ..................................................................................... 6
3
Standard Information Model ............................................................................................. 7
3.1
4
Standard Objects and Address Spaces ................................................................... 7
3.1.1 NodeId ........................................................................................................ 8
3.1.2 Variables and DataTypes ............................................................................ 8
3.1.3 Events ........................................................................................................ 9
Standard Message Mappings ........................................................................................... 9
4.1
4.2
4.3
5
Overview ................................................................................................................ 9
Format .................................................................................................................... 9
Structure ............................................................................................................... 10
4.3.1 Header ...................................................................................................... 10
4.3.2 Body ......................................................................................................... 11
4.3.3 Example .................................................................................................... 11
Standards Security Model .............................................................................................. 11
6
Standard Services Model ............................................................................................... 11
6.1
7
Overview .............................................................................................................. 11
6.1.1 DeviceRegistration / Application Registration ............................................ 13
6.1.2 DeviceDiscovery ....................................................................................... 13
6.1.3 ApplicationDiscovery ................................................................................. 14
6.1.4 AddDevice / AddApplication ...................................................................... 14
6.1.5 DeleteDevice / DeleteApplication .............................................................. 14
6.1.6 ReadValue ................................................................................................ 15
6.1.7 UpdateValue ............................................................................................. 15
6.1.8 CreateSubscription ................................................................................... 15
6.1.9 RemoveSubscription ................................................................................. 16
6.1.10 PublishData .............................................................................................. 16
6.1.11 InvokeAction ............................................................................................. 16
Use Cases ..................................................................................................................... 17
8
Apendix A ...................................................................................................................... 19
8.1.1
8.1.2
8.1.3
8.1.4
NameSpace Definitions Example .............................................................. 19
CreateSubscription Request Example ....................................................... 19
CreateSubscription Response Example ..................................................... 20
Publish ...................................................................................................... 21
OPC UA for ISA-95
ii
Draft 0.00.01
FIGURES
Figure 1 – TR-50 Reference Architecture ............................................................................... 4
Figure 2 - Simple M2M Implementation .................................................................................. 6
Figure 3 – Objects and Address Space ................................................................................... 7
Figure 4 - Events .................................................................................................................... 9
Figure 5 - ERP Monitoring Application .................................................................................. 17
Figure 6 – ERP AddressSpace Example ............................................................................... 17
Figure 7 - ERP CreateSubscription Example ........................................................................ 18
Figure 8 - ERP WriteResponse Example .............................................................................. 19
OPC UA for ISA-95 Internet Of Things
iii
Draft 0.00.01
TABLES
Table 1 - TR-50 Architecture Description ................................................................................ 5
Table 2 – Variables and DataTypes ........................................................................................ 9
Table 3 – Header Addressing Component ............................................................................ 10
Table 4 – Service Types ....................................................................................................... 12
Table 5 – Standard Services ................................................................................................ 13
Table 6 – Device/Application Registration ............................................................................ 13
Table 7 - DeviceDiscovery .................................................................................................... 13
Table 8 - ApplicationDiscovery ............................................................................................. 14
Table 9 – AddDevice / AddApplication .................................................................................. 14
Table 10 – DeleteDevice / DeleteApplication ........................................................................ 15
Table 11 - ReadValue ........................................................................................................... 15
Table 12 - UpdateValue ........................................................................................................ 15
Table 13 - CreateSubscription .............................................................................................. 16
Table 14 - RemoveSubscription ............................................................................................ 16
Table 15 - PublishData ......................................................................................................... 16
Table 16 - InvokeAction ........................................................................................................ 17
OPC UA for ISA-95
1
1.1
Draft 0.00.01
4
Concept
Overview
The number of connected devices is exploding and this creates a huge management
challenge and opportunity for the telecom operators that offer connectivity. This document outlines a
basis for a standard architecture which will facilitate the development of systems that can handle a
large number of connected devices for many different verticals. The following picture describe the
reference architecture, as per TR-50.1 ballot, is shown in the following figure:
home
home application
B1
B7
B5/B5'/
B9
B2/B2'
B4
B6
A1
node application
node
B3/B3'
B8
PoA application/PoA device
PoA
A3/A3'
A2
authentication, authorization and accounting
AAA-SD
Figure 1 – TR-50 Reference Architecture
The definitions of the entities described in the diagram are listed below :
Name
Description
PoA
Point of Attachment. Logical entity representing the connection of the PoA
device/application to the network infrastructure.
Home Application
The home application is a logical entity that is responsible for the business
logic, either directly or via supervision and interaction with node applications
and PoA applications and with PoA devices.
Node Application
The node application is a logical entity that acts as an intermediary between
the home application and the PoA application and between the home
application and the PoA device. The node application interacts with home
application, other node applications, PoA application or PoA device, and may
perform functions such as a data aggregation, storage, load balancing, etc.
PoA Application/Device
PoA application/Device is a logical entity that provides resources to node or
home applications or to other PoA applications. The PoA application/Device
interacts with home, node, other PoA applications or with PoA devices. The
PoA application may perform functions such as autonomous reporting of
values reported by devices, monitoring for values reported by devices that
exceed specified limits, trend analysis of values reported by devices, etc.
PoA Container
The container is a logical entity that provides services to the applications that
operate within it, and enforce security policies
AAA-SD
Provide authentication, authorization and accounting services to other entities
in the network to establish and enforce security policies. The services may
include generation of keys, generation and validati on of certificates, validation
of signatures, etc.
A1
Provides for interaction between the AAA-SD container and the home
application.
OPC UA for ISA-95 Internet Of Things
5
Draft 0.00.01
A2
Provides for interaction between the AAA-SD container and the node
application.
A3
Provides for interaction between the AAA-SD container and the PoA
application.
A3’
Provides for interaction between the AAA-SD container and the PoA device.
The realization of A3 and A3’ may be identical. The realization of A1,
A2, A3 and A3’ may be identical.
B1
Provides for interaction between the home application and a node application,
including bi-directional communication of control information, events and data.
B2
Provides for interaction between a PoA application and the home application,
including bi-directional communication of control information, events and data.
B2’
Provides for interaction between a PoA device and the home application,
including bi-directional communication of control information, events and data.
The realization of B2 and B2’ may be identical.
B3
Provides for interaction between a PoA application and a node application,
including bi-directional communication of control information, events and data.
B3’
Povides for interaction between a PoA device and a node application,
including bi-directional communication of control information, events and data.
The realization of B3 and B3’ may be identical.
B4
Provides for interaction between the different node applications, possibly in
different containers, including bi-directional communication of control
information, events and data.
The realization of B1 and B4 may be
identical.
B5
provides for interaction between the different PoA applications, Possibly in
different containers, including bi-directional communication of control
information, events and data.
B5’
Provides for interaction between the different PoA devices, possibly in
different containers, including bi-directional communication of control
information, events and data. The realization of B5 and B5’ may be identical.
The realization of B2, B2’, B3, and B3’ may be identical.
B6
Provides for interaction between the home applicatio ns and a node container,
including bi-directional communication of control information, events and data.
B7
Provides for interaction between the home application and a PoA container,
including bi-directional communication of control information, events an d data.
B8
Provides for interaction between node applications and a PoA container,
including bi-directional communication of control information, events and data.
B9
Provides for interaction between a PoA application and a PoA device,
including bi-directional communication of control information, events and data
Table 1 - TR-50 Architecture Description
An example of implementation can be considered as follows :
OPC UA for ISA-95
Draft 0.00.01
6
Home
Application
PoA Application
(Gateway)
(ERP
Client/Server)
Home
Application
(ERP
Server/Client)
M2M API
Message Bus
PoA Application
(Gateway)
PoA Device
PoA Application
(Gateway)
PoA Device
(Car)
Figure 2 - Simple M2M Implementation
The Message Bus refers to a highly scalable message exchange framework similar to what is
already provided by major telecom vendors as part of their cellular networks. The interface between
an application and this network depend on the telecom vendor’s implementation, however, a
standard HTTP/HTTPS interface will allow integration with Home Applications (like ERP system)
running on wired TCP/IP networks. PoA Containers using existing domain specific protocols will exist
and allow easy integration with existing applications and devices. A PoA device can be a device
designed to be connected directly to the message bus. It will use HTTP or a network specific
protocol to send and receive messages.
2
M2M Unified Architecture Models
Any flexible communication architecture must standardize behavior at several layers in order to
maximize interoperability. At each layer it must be possible to extend the architecture to meet
domain specific requirements.
The following four layers should be considered for any unified architecture:
1)
Standard Information Model
2)
Standard Services Model
3)
Standard Security Model
4)
Standard Message Mappings
The Standard Information Model:
 Defines a way to create and describe information models using standard primitives.
These standard primitives can be used to construct arbitrary information models that
meet many different application requirements. The standard primitives for M2M UA are
called Objects, Variables, Methods and References.
 The standard primitives allow generic consuming applications to explore and discover the
information models supported by any individual PoA application or device. In M2M UA the
collection of Objects that consuming applications explore is called an Address Space.
 Defines a standard way to represent common information. For example, all events, no
matter what domain, should have a common structure with some common fields like
“Message” and “Severity/Priority”.
The Standard Services Model:
 Defines standard services access the Address Space exposed by a PoA application or
device. For example, subscribe and publish are services which every domain needs.
OPC UA for ISA-95 Internet Of Things

Draft 0.00.01
7
Defines a standard template for creating new services when spe cific domains require
them.
The Standard Message Mappings
 Specifies the format and structure of the messages sent by any entity in the system.
 Each message should have a standard layout and common fields should be defined.
 It should be possible to extend the syntax to allow implementation specific features.
 Messages sent on a cellular network need to be batched to enhance compression.
 An extensible Message Syntax would allow messages to be combined together and then
unpacked at the end.
3
3.1
Standard Information Model
Standard Objects and Address Spaces
The M2M Informational Model is based on the concept of Objects collected together in an
Address Space.
An AddressSpace can include Objects from PoA devices and/or PoA Applications.
Objects contain:
 Variables which represent a data value.
 Methods that can be invoked
Object’s variables can be read or updated.
Object’s variables can produce notifications when their value changes.
Objects produce can produce events notifications.
The following figure provides an example of an AddressSpace that could represent the
information model for a PoA Container installed in a vehicle.
Address
Space
Door Unlock
Event
Event
Car
Door
Lock
Speed
Current
State
Unlock
Method
Speed
Alarm Event
Current
Value
Maximum
Speed
Variable
Object
Figure 3 – Objects and Address Space
All Sources of data and events would define the Objects that they expose.
Each Object would have a Type Definition which describes its structure (the Variables,
Methods and sub-Objects contained within it). These Type Definitions would be specified by SDOs
(Standards Development Organizations), device makers or telecom service providers. Smaller
Object Type Definitions specified by SDOs are reused to construct larger Object Type Definitions
specified by device makers or service providers. This will increase the amount of software that can
be re-used for different applications. For example, in the figure above the Type Definition for the
OPC UA for ISA-95
8
Draft 0.00.01
Speed Object could be reused in many different devices that have a sensor that measures speed. If
a specific vendor needed additional information associated w ith their speedometer (e.g. model
number) they can add additional Variables to the Speed Object without affecting applications that
understand the generic Speed Object.
3.1.1 NodeId




Each Object/Variable or Method (also called Nodes) is individually addressable with a value
called a NodeId.
NodeIds are specified by the source of the information and qualified by a namespace so they
can have a syntax optimized for the source. Short integer values are an option for small
devices using limited bandwidth cellular net works for communication.
Each Node also has a non-localized name called a BrowseName. This name is qualified by a
namespace so different information models do not need to worry about name collisions. The
BrowseName is used to construct BrowsePaths that also identify nodes with are components
of an Object.
The namespaces for NodeIds and BrowseNames are potentially long URIs; however, their
representation is optimized by using an integer instead of the URI at runtime.
3.1.2 Variables and DataTypes






The values of Variables represent the basic piece of information exchanged between
applications. Variables represent values which may be simple or complex .
Each value has a DataType which specifies the syntax and range for the value. Examples of
DataTypes are “UInt32”, “String” or “Double”.
Variables also have a ValueRank which indicates whether a Value is an array and, if it is one,
specify number of dimensions in the array.
DataTypes can also be structured values (sets of name-value pairs similar to the structure
types used in most programming languages).
o SDOs, companies and application developers can create new structured DataTypes.
The Type Definition for an Object also specifies the DataTypes and ValueRanks for all
Variables contained within it.
The DataTypes supported by a device are determined by the Device so a low cost device
only needs to support the simple DataTypes.
JSON has a limited type model and it is necessary to extend this model before it can be used to
define messages that meet the information modeling requirements of UA M2M applications. The
following table lists the data types which are extensions of the built in JSON data types. These
data types are derived from the XML data type specification and include types designed to
support the UA M2M information model.
Name
SByte
Byte
Int16
UInt16
Int32
UInt32
Int64
UInt64
Float
Double
ByteString
DateTime
NodeId
Description
A number between -128 and 127.
A number between 0 and 255.
A number between -32768 and 32767.
A number between 0 and 65535.
A number between -2147483648 and 2147483647.
A number between 0 and 4294967295.
A number between -9223372036854775808 and
9223372036854775807.
A number between 0 and 18446744073709551615.
A number which is a single precision floating point.
A number which is a double precision floating point.
A string which is a byte array encoded in base 64.
A string representing a DateTime value.
A string representing a NodeId for an Object, Variable or Method.
OPC UA for ISA-95 Internet Of Things
QualifiedName
LocalizedText
Draft 0.00.01
9
A string representing the invariant name of an Object, Variable or
Method.
A string representing text which has been localized.
Table 2 – Variables and DataTypes
3.1.3 Events



Events contain Variables like Objects. When an Event is reported it will include the values for
one of more of its Variables.
Subscriptions are used to select the Variables to include and to specify filters that use the
values of the Variables to determine if an Event should be reported.
Events can be requested by choosing an Object to subscribe to. Events always propagate up
the hierarchy so a client that subscribes to the “Car” object in the above example would
receive all events produced by any Object within the “Car” (See example below)
An Event Type Definition from the example above is shown in the following figure:
Objects can be
re-used in Event
Type Definitions
Speed
Alarm Event
Speed
Current
Value
Use the path to
specify values that
are used to determine
what events to report.
Car ID
Maximum
Speed
Driver ID
Specify the values that
should be included in the
event message with the
path.
SELECT
‘Speed/Current Value’, ‘Driver ID’
WHERE
Car ID == ‘ABC’
Figure 4 - Events
The figure above also illustrates the simply syntax that can be used to minimize the amount of
information sent to the subscriber by selecting variables of interest and/or using the variables to
select which events are reported. The paths are constructed f rom the BrowseNames of the Variables
and Objects (e.g Speed/Current Value)
4
4.1
Standard Message Mappings
Overview
The M2M message syntax should take in consideration requirements that are related to the specifics
of the PoA devices as well as the communication infrastructure. For example: it should have
minimum bandwidth requirements or it should be easy to implement on extremely low cost devices.
4.2
Format
The basis for the mappings should be a simple message based protocol designed to allow
applications to communicate via an enterprise service bus, message queue or similar infrastructure.
This protocol combines a flexible information model, message syntax and a loosely coupled
message exchange pattern. This protocol is designed for asynchronous mess age exchange over
networks with long latencies and tight bandwidth requirements.
OPC UA for ISA-95
Draft 0.00.01
10
Since the communication between different nodes needs to be fast and reliable as well as
lightweight, a JSON (text-based open standard for data interchange) it is suggested as ideal for the
implementation of these specs. The message syntax should also leverage existing infrastructure and
specifications. In addition for this reason, the message syntax should be based on JSON encoded
SOAP messages. This syntax will be designed to allow easy conversion to SOAP XML messages if
required by applications. In order to have an extensible architecture, a namespace concept should
be added to the current JSON specifications.
Within a message a namespace is denoted with a numeric prefix fo llowed by a colon (‘:’).
These numbers are indexes into a table contained in a message header. When comparing the
names of two fields in different messages the index is used to look up the URI and the URIs +
names are compared. Two names in the same docum ent can be compared directly. This makes the
UA M2M more efficient than standard XML where namespace prefixes can be change within a
document. The UA M2M convention is prevents the same URI from being replicated many times in
the same document; something which happens frequently with standard XML.
The NamespaceUris table is also used by the UA M2M in any NodeIds or QualifiedNames
that appear in the message body.
4.3
Structure
An UA M2M message has two parts:
 Header
 Body
4.3.1 Header
The header contains the following elements:
 Addressing - routing information
 Security – define the elements needed for confidentiality and integrity of the communication
o signing and encryption
o trusting
 Conversation – define the secure conversation between nodes
 Node Identity – define the unique identity of the nodes
4.3.1.1
Addressing
The standard fields in the header for addressability are defined in the following table:
Element
To
Category
Addressing
Data Type
From
Addressing
NamespaceUris
Addressing
RelatesTo
Addressing
MessageId
Conversation
SecureChannelId
Conversation
SecurityProperties
Security
Description
The URL of the recipient of the message.
This field is mandatory.
The URL for the sender of the message.
This field is mandatory.
An array of URIs for the Namespaces used in the
message.
A globally unique identifier for the message that
the current message is related to. This is used to
correlate a request with a response.
This field is optional.
A globally unique identifier for the message.
This field is mandatory.
A globally unique identifier for secure channel
between two applications. This field is optional.
Security elements, such as encryption algorithms,
certificates, signatures etc. This field is optional
Table 3 – Header Addressing Component
OPC UA for ISA-95 Internet Of Things
11
Draft 0.00.01
The Header can be modified to meet the needs for the network infrastructure.


For example, a JMS based implementation does not need the To/From elements since
they are provided by the JMS infrastructure so these elements can be removed and
added back in when the message is passed onto the application.
If the message is a JSON embedded in a SOAP message, security properties are not
required.
4.3.2 Body
The body contains the application specific portions of the message. The UA M2M defines
several message types which all implementers are expected to understand. Applications are free to
define additional messages as required.
The message body is the element that follows the header. The message body should have the
following elements:
 Message encoding
4.3.3 Example
The format of an UA M2M message is shown below:
{ "UAM2M" : {
"Header" : {
"To": "<opc ua application uri>",
"From": "<device hardware uri>",
"MessageId": "<message id>",
"RelatesTo": "<request message id>"
}
"Publish": {
"Status": 0,
"Results" :
[
{ "Value": 1234, Timestamp: "2011-08-30T12:23Z" }
]
}
}}
5
Standards Security Model
Security is concerned with the authentication of nodes, the integrity and confidentiality of their
communications, and the verifiability of claims of functionality.
The following should be considered in the model:
 Environment
 Security Objectives
 Security Threats to Architecture
 Security Architecture
 Profiles
 Node Authorization
 Node Authentication
 Auditing
6
6.1
Standard Services Model
Overview
The UA M2M protocol consist of a set of services types that are shown in the table below.
These types represent the minimal set that an implementation should follow. The current model
should have provisions for the types to be extendable as the implementation requires.
OPC UA for ISA-95
12
Service Type
Discovery Services
Service
ID
DS
SecureChannel Services
SCS
NodeManagement Services
NMS
View/Query Services
VQS
Attribute Services
AS
Method Services
MS
MonitoredItem Services
MIS
Subscription Services
SS
Type
Draft 0.00.01
Description
Allows the home application to discover PoA
Device/Applications within a PoA container and read
the security configurations required to establish a
secure communication
Allows the home application to establish a secure
channel to communicate with the PoA Container
Allows the home application to add/delete/update
PoA devices/application in a PoA container
Allows
the
home
application
to
browse
devices/applications in a PoA container
Allows the home application to read/update values in
an PoA device or application
Allows the home application to invoke methods on
the PoA container (either on PoA device or PoA
application)
Allows the home application to performed operations
on the PoA container, PoA device or PoA Application
to create, delete or update monitoring items
definitions.
Must
work
in
conjunction
with
Subscription Services.
Allows the home application to create, delete or
update subscriptions. Subscriptions are the mean for
the notifications on MonitoredItems to be send out.
Table 4 – Service Types
The standard services defined by this document are shown in the following table. Any
application can extend this list if necessary, however, it is expected that an application that needs
the functionality provided by a service will use the service and use an Information Model to provide
application specific functionality.
The following is the minimal list of services that should be consider on any implementation :
Service
DeviceRegistration
Service
Type
DS
ApplicationRegistration
DS
DeviceDiscovery
DS
ApplicationDiscovery
DS
AddDevice
NMS
DeleteDevice
NMS
AddApplication
NMS
DeleteApplication
NMS
ReadValue
AS
UpdateValue
AS
CreateSubscription
SS
Description
Should be used for the registration of a PoA device with the
home application.
Should be used for the registration of a PoA application with
the home application.
Should be used by the home application to retrieve the list of
PoA devices included to the PoA container
Should be used by the home application to retrieve the list of
the PoA devices that are attached to a PoA Application
Should be used by the home application to retrieve the list of
PoA applications included to the PoA container
Should be used by the home application to add a device to a
PoA either to a PoA container or a PoA application
Should be used by the home application to remove a device
to a PoA either to a PoA container or a PoA application
Should be used by the home application to add an applicaiton
to a PoA container
Should be used by the home application to remove an
applicaiton to a PoA container
Should be used for the home application to interact with a
PoA device to read a device’s value.
Should be used for the home application to interact with a
PoA device to update/write a device’s value.
Should be used by the home application to create
OPC UA for ISA-95 Internet Of Things
RemoveSubscription
SS
PublishData
SS
InvokeAction (Call)
MS
13
Draft 0.00.01
notifications when data changes or event occurs on a PoA
either in a PoA Application or PoA Device
Should be used by the home application to remove
notifications when data changes or event occurs on a PoA
either in a PoA Application or PoA Device
Should be used by the PoA (either a PoA applicati on or PoA
device) to send or report data changes or events to home
application.
Should be used by the home application to invoke
(synchronous) a pre-defined in the PoA (PoA application or
PoA device) callable action (method) that can perform tasks
on the PoA.
Table 5 – Standard Services
All of the Services except Publish and InvokeAction require a request-reply message pattern and
may not be suitable for high latency networks.
6.1.1 DeviceRegistration / Application Registration
This service is used by the PoA Devices and PoA Applications
registration/deregistration with the home/node application or with the infrastructure.
Request
Element
requestHeader
Poa
- poaURL
- poaDescription
Data Type
Response
Element
responseHeader
Data Type
during
the
Description
Common request header
PoA device or application to register
PoA URL that represents the device or application
PoA description of the device or application
Description
Common response header
Table 6 – Device/Application Registration
6.1.2 DeviceDiscovery
This service returns the PoA devices supported by the PoA container and all of the
configuration information required to establish a secure channel and a session. This service should
not require any message security but it may require transport layer security.
Request
Element
requestHeader
localeids[]
Data Type
Response
Element
responseHeader
nodeId[]
- deviceURL
- poaCertificate
- securityMode
Data Type
- securityPolicy
Description
Common request header
List of locals to be used
Description
Common response header
List of devices (nodes) that the PoA has
The PoA device URL
The PoA device certificate that the home application can use
The PoA device type of security that can be used by the home
application
The PoA device policy URL that can be used when securing the
messages
Table 7 - DeviceDiscovery
OPC UA for ISA-95
14
Draft 0.00.01
6.1.3 ApplicationDiscovery
This service returns the PoA applicataions supported by the PoA container and all of the
configuration information required to establish a secure channel and a session. This service should
not require any message security but it may require transport layer security.
Request
Element
requestHeader
localeids[]
Response
Element
responseHeader
nodeId[]
applicationURL
- poaCertificate
Data Type
Description
Common request header
List of locals to be used
Data Type
Description
Common response header
List of applications that the PoA container has
The PoA application URL
The PoA application certificate that the home application can
use
The PoA application type of security that can be used by the
home application
The PoA applicaiton policy URL that can be used when securing
the messages
- securityMode
- securityPolicy
Table 8 - ApplicationDiscovery
6.1.4 AddDevice / AddApplication
This service is used to add a new PoA device or application into AddressSpace of a PoA
container or PoA application.
Request
Element
requestHeader
nodesToAdd[]
- parentNodeId
Data Type
Response
Element
responseHeader
results[]
Data Type
Description
Common request header
List of nodes to be added.
The node id of the parent
Description
Common response header
List of values. The size and the order matches the
nodesToAdd[]
Overall operation result
The returned id of the node
- statusCode
- addedNodeId
Table 9 – AddDevice / AddApplication
6.1.5 DeleteDevice / DeleteApplication
This service is used to delete a new PoA device or application into AddressSpace of a PoA
container or PoA application.
Request
Element
requestHeader
nodesToDelete[]
- parentNodeId
Data Type
Response
Element
responseHeader
results[]
Data Type
Description
Common request header
List of nodes to be deleted.
The node id of the parent
Description
Common response header
List of values. The size and the order matches the
OPC UA for ISA-95 Internet Of Things
15
Draft 0.00.01
nodesToDelete[]
Overall operation result
- statusCode
Table 10 – DeleteDevice / DeleteApplication
6.1.6 ReadValue
This service is used to read one or more values of one or more PoA Device. For constructed
attribute values whose elements are indexed, such as an array, this service allows the home
application to read the entire set of indexed values as a composite, to read individual elements or to
read ranges of elements of the composite.
Request
Element
requestHeader
maxAge
timestampToReturn[]
Data Type
Common request header
Maximum age of the value to be read in milliseconds
An enumeration that specifies the timestamp to be returned
for each requested value
List of nodes (URL) and their values to read
nodesToRead[]
Response
Element
responseHeader
results[]
Description
Data Type
Description
Common response header
List of values. The size and the order matches the
nodesToRead[]
Table 11 - ReadValue
6.1.7 UpdateValue
This Service is used to write/update values to one or more value of one or more PoA device
Request
Element
requestHeader
nodesToWrite[]
- attributeId
- value
Data Type
Response
Element
responseHeader
results[]
Description
Common request header
List of the PoA entities and their value to write or update
The Id of the attribute that we need to update write
The value
Data Type
Description
Common response header
List of values. The size and the order matches the
nodesToWrite[]
Table 12 - UpdateValue
6.1.8 CreateSubscription
This service is used to create a subscription to a node so that data can be send back to the
requester using the “PublishData” service.
Request
Element
requestHeader
nodeID
itemsToMonitor[]
Data Type
Common request header
ID of the node making the subscription
A list of monitoring items that will be assigned to this
subscription
Identify the item in the AddressSpace of the PoA entity
The type of monitoring mode for the monitoring item
The requested monitoring attribute of the item in the
AddressSpace
- itemToMonitor
- monitoringMode
- requestedAttributes
Response
Description
Data Type
Description
OPC UA for ISA-95
16
Element
responseHeader
subscriptionID
Draft 0.00.01
Common response header
ID generated by the PoA Container / Application / Device
representing the subscription
List of status codes. The size and the order matches the
itemsToCreate[]
StatusCode returned for each monitoredItem request
PoA returned item id
results[]
- statusCode
- monitoredItemId
Table 13 - CreateSubscription
6.1.9 RemoveSubscription
This service is used to delete a subscription created by the “CreateSubscription” service
Request
Element
requestHeader
subscriptionID
monitoredItems []
Data Type
Description
Common request header
The PoA generated subscription id
List of monitored items to be deleted
Response
Element
responseHeader
results[]
Data Type
Description
Common response header
List of status codes as a results of the delete operation of
the monitored items
Table 14 - RemoveSubscription
6.1.10 PublishData
This service is used to send notification (based on data changes or events) to a node that
used the “CreateSubscription” service to register for notifications
Request
Element
requestHeader
subscriptionItems[]
- subscriptionId
subscriptionSequence
- results
Data
Type
Description
Common request header
List of subscriptions generating the data
The subscription id
The sequence of the data
The data being published
Table 15 - PublishData
6.1.11 InvokeAction
This Service is used to call (invoke) a method. Each method call is invoked within the context
of an existing session. If the session is terminated, the results of the method’s execution cannot be
returned to the Client and are discarded. This is independent of the task actually performed at the
PoA Container, PoA device or PoA node.
This service provides for passing input and output arguments to/from a method. These
arguments are defined by properties of the method. The sequence number in the service request
header is used by this service to detect duplicate requests. PoA entities are responsible for tracking
the sequence numbers used by this service and for discarding requests that contain a sequence
number that has already been used.
Request
Element
requestHeader
objected
methodId
inputArguments[]
Data Type
Description
Common request header
The ID of the PoA entity that defines a methodId
The ID of the method to be invoked in the objectid
List of arguments for the methodId.
OPC UA for ISA-95 Internet Of Things
Response
Element
responseHeader
callResult
- statusCode
inputArgumentResults[]
outputArguments[]
Data
Type
Draft 0.00.01
17
Description
Common response header
Result of the method call.
Overall status code of the call
List of status code for each argument
List of the output arguments
Table 16 - InvokeAction
7
Use Cases
The following example illustrates how these services are intended to be used. In this example, an
ERP monitoring application (home application) is connected via a Gateway (PoA Application) to a
UA M2M network with a large number of devices (see the following figure).
ERP
Monitoring
Application
PoA
Application
Gateway
M2M API
Message Bus
Device A
Device B
Device C
Figure 5 - ERP Monitoring Application
The gateway exposes a M2M AddressSpace that allows the ERP application to interact with the
devices on the network. A simple AddressSpace for the Gateway is shown in the following figure.
System
West
East
Device A
Device B
Device C
Figure 6 – ERP AddressSpace Example
In the first use case Device C is being added to the network by a technician at a remote site.
The technician provides some key provisioning information to the device which allows it to send
OPC UA for ISA-95
Draft 0.00.01
18
messages. The first thing the device does is send an unsolicit ed Publish message to the Gateway (at
an address provided by the technician). This Publish message will contain a “DeviceRegistration”
Event which includes the physical location of the device, the electronic address and name of the
device. When the Gateway receives the event it will recognize the new device and create an Object
in its address space. It will then report the event to ERP monitoring application if one is currently
listening. If one is not, the new device can be discovered by browsing the Gatew ay’s address space.
Once the ERP application has discovered the device it can interact with it directly using the
Browse and Read services to discover the Device and its current state. It can set up subscriptions
with the CreateSubscription service that tell the device to report events which certain conditions are
met. Once complete, the ERP application can ignore the device unless something happens. This
sequence is shown in the following figure.
ERP
Monitoring
Application
Gateway
Device C
DeviceRegistration
ApplicationRegistration
DeviceDIscovery
DeviceDiscpvery Response
Read
Read Response
CreateSubscription
CreateSubscription Response
Figure 7 - ERP CreateSubscription Example
In the second use case, the device goes into an alarm state and produces an Event. The ERP
monitoring application receives this event which includes information that identifies the device and
on why the alarm went off (e.g. temperature is outside of normal operating range). The ERP
monitoring application would now use the InvokeAction service to acknowledge the alarm (telling the
device that something is paying attention). The ERP application can the n attempt to lower the
temperature by reducing the set point for one of the device’s operating parameters.
OPC UA for ISA-95 Internet Of Things
ERP
Monitoring
Application
Draft 0.00.01
19
Gateway
Device C
Notification
(Temp Exceeded)
Notification
(Temp Exceeded)
InvokeAction(Acknowledge)
InvokeAction Response
Write (Set Point)
Write Response
Figure 8 - ERP WriteResponse Example
There are many other scenarios that can be met by thes e generic services that are combined with an
information model.
8
Apendix A
Examples of JSON implementation of the services model is presented below:
8.1.1 NameSpace Definitions Example
{ "UAM2M" : {
"Header" : {
"NamespaceUris": [
http://sdo.org/something,
http://company.com/somethingelse
]
}
"0:Message1": {
"0:Parameter1" : "string"
"1:Parameter1" : number
}
}}
8.1.2 CreateSubscription Request Example
{ "UAM2M" : {
"Header" : {
"To": "<opc ua application uri>",
"From": "<device hardware uri>",
"MessageId": "<message id>",
}
"Subscribe": {
"PublishingInterval" : 60000
"MonitoredItems" : [
{
"NodeId": "i=1234",
"ClientHandle" : 678,
"EventFilter" : {
"SelectClause" : [
"EventId",
"EventTime",
"Severity",
"Message"
]
OPC UA for ISA-95
20
Draft 0.00.01
"WhereClause" : [
{
"FilterOperator" : 0,
"AttributeOperand" : "EventType",
"LiteralOperand" : "i=5367"
}
]
}
}
]
}
}}
8.1.3 CreateSubscription Response Example
{ "UAM2M" : {
"Header" : {
"To": "<opc ua application uri>",
"From": "<device hardware uri>",
"MessageId": "<message id>",
"RelatesTo": "<request message id>"
}
"SubscriptionResponse": {
"Status" : 0,
"SubscriptionId" : "ABC"
}
}}
OPC UA for ISA-95 Internet Of Things
21
Draft 0.00.01
8.1.4 Publish
{ "UAM2M" : {
"Header" : {
"To": "<opc ua application uri>",
"From": "<device hardware uri>",
"MessageId": "<message id>",
"RelatesTo": "<subscription message id>"
}
"Publish": {
"SubscriptionId" : "ABC"
"EventNotifications" : [
{
"ClientHandle" : 678,
"EventFields" : [
{ "ByteString" : "123456ABCDEF" },
{ "DateTime" : "2011-08-30T12:23Z" },
{ "UInt16" : 200 },
{ "LocalizedText" : ":This is a message." }
]
}
]
}
}}