® 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." } ] } ] } }}