F O U N D A T I O N. OPC Unified Architecture. Specification. Part 1: Concepts. Version 1.00

Transcription

1 F O U N D A T I O N Unified Architecture Specification Part 1: Concepts Version 1.00 July 28, 2006

2 Unified Architecture, Part 1 iii Release 1.00 CONTENTS Page FOREWORD... vi AGREEMENT OF USE... vi 1 Scope Reference documents Terms, definitions, and abbreviations terms AddressSpace Alarm Attribute Certificate Client Communication Stack Complex Data Event EventNotifier Information Model Message Method MonitoredItem Node NodeClass Notification NotificationMessage Object Object Instance ObjectType Profile Program Reference ReferenceType RootNode Server Service Service Set Session Subscription Variable View Abbreviations and symbols Structure of the series Specification Organization Core Specification Parts Part 1 Concepts Part 2 Security Model Part 3 Address Space Model Part 4 Services... 5

3 Unified Architecture, Part 1 iv Release Part 5 Information Model Part 6 Service Mappings Part 7 Profiles Access Type Specification Parts Part 8 Data Access Part 9 Alarms and Conditions Part 10 Programs Part 11 Historical Access Overview Introduction Design goals Integrated models and services Security model Integrated AddressSpace model Integrated object model Integrated services Sessions Redundancy Systems concepts Overview Clients Servers Real objects Server application AddressSpace Publisher/subscriber entities Service Interface Server to Server interactions Service Sets General SecureChannel Service Set Session Service Set NodeManagement Service Set View Service Set Attribute Service Set Method Service Set MonitoredItem Service Set Subscription Service Set Query Service Set... 18

4 Unified Architecture, Part 1 1 Release Scope This specification presents an overview on the Unified Architecture concepts. 2 Reference documents The Unified Architecture Specification is organized as a multi-part document. While describing the concepts, this part will refer to these parts of the specification: [UA Part 2] Specification: Part 2 Security Model, Version 1.0 or later [UA Part 3] Specification: Part 3 Address Space Model, Version 1.0 or later [UA Part 4] Specification: Part 4 Services, Version 1.0 or later [UA Part 5] Specification: Part 5 Information Model, Version 1.0 or later [UA Part 6] Specification: Part 6 Mappings, Version 1.0 or later [UA Part 7] Specification: Part 7 Profiles, Version 1.0 or later [UA Part 8] Specification: Part 8 Data Access, Version 1.0 or later [UA Part 9] Specification: Part 9 Alarms and Conditions, Version 1.0 or later [UA Part 10] Specification: Part 10 Programs, Version 1.0 or later [UA Part 11] Specification: Part 11 Historical Access, Version 1.0 or later 3 Terms, definitions, and abbreviations For the purposes of this specification, the following definitions apply. 3.1 terms AddressSpace The collection of information that an Server makes visible to its Clients. See [UA Part 3] for a description of the contents and structure of the Server AddressSpace.

5 Unified Architecture, Part 1 2 Release Alarm A type of Event associated with a state condition that typically requires acknowledgement. See [UA Part 9] for a description of Alarms Attribute A primitive characteristic of a Node. All Attributes are defined by, and may not be defined by Clients or Servers. Attributes are the only elements in the AddressSpace permitted to have data values Certificate A digitally signed data structure that describes the capabilities of a Client or Server Client A software application that sends Messages to Servers conforming to the Services specified in this set of specifications Communication Stack A layered set of software modules between the application and the hardware that provides various functions to encode, encrypt and format a Message for sending, and to decode, decrypt and unpack a Message that was received Complex Data Data that is composed of elements or more than one primitive data type, such as a structure Event A generic term used to describe an occurrence of some significance within a system or system component EventNotifier A special Attribute of a Node that signifies that a Client may subscribe to that particular Node to receive Notifications of Event occurrences Information Model An organizational framework that defines, characterizes and relates information resources of a given system or set of systems. The core address space model supports the representation of Information Models in the AddressSpace. See [UA Part 5] for a description of the base Information Model Message The data unit conveyed between Client and Server that represents a specific Service request or response Method A callable software function.

6 Unified Architecture, Part 1 3 Release MonitoredItem A Client-defined entity in the Server used to monitor Attributes or EventNotifiers for new values or Event occurrences and generate Notifications for them Node The fundamental component of an AddressSpace NodeClass The class of a Node in an AddressSpace. NodeClasses define the metadata for the components of the Object Model. They also define constructs, such as Views, that are used to organize the AddressSpace Notification The generic term for data that announces the detection of an Event or of a changed Attribute value. Notifications are sent in NotificationMessages NotificationMessage A Message published from a Subscription that contains one or more Notifications Object A Node that represents a physical or abstract element of a system. Objects are modelled using the Object Model. Systems, subsystems and devices are examples of Objects. An Object may be defined as an instance of an ObjectType Object Instance A synonym for Object. Not all Objects are defined by ObjectTypes ObjectType A Node that represents the type definition for an Object Profile A specific set of capabilities, defined in [UA Part 7], to which a Server may claim conformance. Each Server may claim conformance to more than one Profile Program An executable Object that, when invoked, immediately returns a response to indicate that execution has started, and then returns intermediate and final results through Subscriptions identified by the Client during invocation Reference An explicit relationship (a named pointer) from one Node to another. The Node that contains the Reference is the source Node, and the referenced Node is the target Node. All References are defined by ReferenceTypes.

7 Unified Architecture, Part 1 4 Release ReferenceType A Node that represents the type definition of a Reference. The ReferenceType specifies the semantics of a Reference. The name of a ReferenceType identifies how source Nodes are related to target Nodes and generally reflects an operation between the two, such as A Contains B RootNode The beginning or top Node of a hierarchy. The RootNode of the AddressSpace is defined in [UA Part 5] Server A software application that implements and exposes the Services specified in this set of specifications Service A Client-callable operation in an Server. Services are defined in [UA Part 4]. A Service is similar to a method call in a programming language or an operation in a Web services WSDL contract Service Set A group of related Services Session A logical long-running connection between a Client and a Server. A Session maintains state information between Service calls from the Client to the Server Subscription A Client-defined endpoint in the Server, used to return Notifications to the Client. Generic term that describes a set of Nodes selected by the Client (1) that the Server periodically monitors for the existence of some condition, and (2) for which the Server sends Notifications to the Client when the condition is detected Variable A Variable is a Node that contains a value View A specific subset of the AddressSpace that is of interest to the Client. 3.2 Abbreviations and symbols A&E Alarms and Events API Application Programming Interface COM Component Object Model DA Data Access DX Data Exchange HDA Historical Data Access HMI Human-Machine Interface MES Manufacturing Execution System PLC Programmable Logic Controller

8 Unified Architecture, Part 1 5 Release 1.00 SCADA SOAP UA UML WSDL XML Supervisory Control And Data Acquisition Simple Object Access Protocol Unified Architecture Unified Modelling Language Web Services Definition Language Extensible Mark-up Language 4 Structure of the series 4.1 Specification Organization This specification is organized as a multi-part specification, as illustrated in Figure 1. Multi-Part Specification Core Specification Parts Part 1 - Concepts Part 2 - Security Model Part 3 - Address Space Model Part 4 Services Access Type Specification Parts Part 8 Data Access Part 9 Alarms and Conditions Part 10 - Programs Part 11 Historical Access Part 5 Information Model Part 6 Service Mappings Part 7 Profiles Figure 1 Specification Organization The first seven parts specify the core capabilities of. These core capabilities define the structure of the AddressSpace and the Services that operate on it. Parts 8 through 11 apply these core capabilities to specific types of access previously addressed by separate COM specifications, such as Data Access (DA), Alarms and Events (A&E) and Historical Data Access (HDA). Readers are encouraged to read Parts 1 through 5 of the core specifications before reading Parts 8 through 11. For example, a reader interested in UA Data Access should read Parts 1 through 5 and 8. References in [UA Part 8] may direct the reader to other parts of this specification. 4.2 Core Specification Parts Part 1 Concepts This specification describes the concepts applicable to Servers and Clients Part 2 Security Model [UA Part 2] describes the model for securing interactions between Clients and Servers Part 3 Address Space Model [UA Part 3] describes the contents and structure of the Server s AddressSpace Part 4 Services [UA Part 4] specifies the Services provided by Servers.

9 Unified Architecture, Part 1 6 Release Part 5 Information Model [UA Part 5] specifies the standard types and their relationships defined for Servers Part 6 Service Mappings [UA Part 6] specifies the transport mappings and data encodings supported by Part 7 Profiles [UA Part 7] specifies the Profiles that are available for Clients and Servers. These Profiles provide groups of Services or functionality that can be used for conformance level certification. Servers and Clients will be tested against the Profiles. 4.3 Access Type Specification Parts Part 8 Data Access [UA Part 8] specifies the use of for data access Part 9 Alarms and Conditions [UA Part 9] specifies use of support for access to Alarms and conditions. The base system includes support for simple Events; this specification extends that support to include support for Alarms and conditions Part 10 Programs [UA Part 10] specifies support for access to Programs Part 11 Historical Access [UA Part 11] specifies use of for historical access. This access includes both historical data and historical Events. 5 Overview 5.1 Introduction Unified Architecture (UA) is a platform-independent standard through which various kinds of systems and devices can communicate by sending Messages between Clients and Servers over various types of networks. It supports robust, secure communication that assures the identity of Clients and Servers and resists attacks. defines standard sets of Services that Servers may provide, and individual Servers specify to Clients what Service sets they support. Information is conveyed using standard and vendor-defined data types, and Servers define object models that Clients can dynamically discover. Servers can provide access to both current and historical data, as well as Alarms and Events to notify Clients of important changes. can be mapped onto a variety of communication protocols and data can be encoded in various ways to trade off portability and efficiency. 5.2 Design goals provides a consistent, integrated AddressSpace and service model. This allows a single Server to integrate data, Alarms and Events, and history into its AddressSpace, and to provide access to them using an integrated set of Services. These Services also include an integrated security model. also allows Servers to provide Clients with type definitions for the Objects accessed from the AddressSpace. This allows standard information models to be used to describe the contents of

10 Unified Architecture, Part 1 7 Release 1.00 the AddressSpace. allows data to be exposed in many different formats, including binary structures and XML documents. The format of the data may be defined by, other standard organizations or vendors. Through the AddressSpace, Clients can query the Server for the metadata that describes the format for the data. In many cases, Clients with no pre-programmed knowledge of the data formats will be able to determine the formats at runtime and properly utilize the data. adds support for many relationships between Nodes instead of being limited to just a single hierarchy. In this way, an Server may present data in a variety of hierarchies tailored to the way a set of Clients would typically like to view the data. This flexibility, combined with support for type definitions, makes applicable to a wide array of problem domains. As illustrated below, is not targeted at just the telemetry server interface, but also as a way to provide greater interoperability between higher level functions. Corporate Enterprise Manufacturing, Production and Maintenance HMI MES SCADA Adv. Control Control Batch PLC Data PLC Industrial Industrial Networks Data Networks??...?? DCS DCS Acquisition??...?? Acquisition Figure 2 Target Applications is designed to provide robustness of published data. A major feature of all servers is the ability to publish data and Event Notifications. provides mechanisms for Clients to quickly detect and recover from communication failures associated with these transfers without having to wait for long timeouts provided by the underlying protocols. is designed to support a wide range of Servers, from plant floor PLCs to enterprise Servers. These Servers are characterized by a broad scope of size, performance, execution platforms and functional capabilities. Therefore, defines a comprehensive set of capabilities, and Servers may implement a subset of these capabilities. To promote interoperability, defines standard subsets, referred to as Profiles, to which Servers may claim conformance. Clients can then discover the Profiles of a Server, and tailor their interactions with that Server based on the Profiles. Profiles are defined in [UA Part 7]. The specifications are layered to isolate the core design from the underlying computing technology and network transport. This allows to be mapped to future technologies as necessary, without negating the basic design. Mappings and data encodings are described in [UA Part 6]. Two data encodings are defined in this part: XML/text

11 Unified Architecture, Part 1 8 Release 1.00 UA Binary In addition, two transport mappings are defined in this part: TCP SOAP Web services over HTTP Clients and Servers that support multiple transports and encodings will allow the end users to make decisions about tradeoffs between performance and XML Web service compatibility at the time of deployment, rather than having these tradeoffs determined by the vendor at the time of product definition. is designed as the migration path for clients and servers that are based on Microsoft COM technology. Care has been taken in the design of -UA so that existing data exposed by COM servers (DA, HDA and A&E) can easily be mapped and exposed via. Vendors may choose to migrate their products natively to or use external wrappers to convert from COM to and vice-versa. Each of the previous specifications defined its own address space model and its own set of Services. unifies the previous models into a single integrated address space with a single set of Services. 5.3 Integrated models and services Security model General security is concerned with the authentication of Clients and Servers, the authentication of users, the integrity and confidentiality of their communications, and the verifiability of claims of functionality. It does not specify the circumstances under which various security mechanisms are required. That specification is crucial, but it is made by the designers of the system at a given site and may be specified by other standards. Rather, provides a security model, defined in [UA Part 2], in which security measures can be selected and configured to meet the security needs of a given installation. This model includes standard security mechanisms and parameters. In some cases, the mechanism for exchanging security parameters is defined, but the way that applications use these parameters is not. This framework also defines a minimum set of security Profiles that all UA Servers must support, even though they may not be used in all installations. Security Profiles are defined in [UA Part 7] Session establishment Application level security relies on a secure communication channel that is active for the duration of the application Session and ensures the integrity of all Messages that are exchanged. This means users need to be authenticated only once, when the application Session is established. The mechanisms for establishing secure communication channels and application Sessions are described in [UA Part 4] and [UA Part 6]. When a Session is established, the Client and Server applications negotiate a secure communications channel and exchange software Certificates that identify the Client and Server and the capabilities that they provide. Foundation-generated software Certificates indicate the Profiles that the applications implement and the certification level reached for each Profile. The details of each Profile and the Certificates are specified in [UA Part 7]. Certificates issued by other organizations may also be exchanged during Session establishment. The Server further authenticates the user and authorizes subsequent requests to access Objects in the Server. Authorization mechanisms, such as access control lists, are not specified by the UA specification. They are application- or system-specific.

12 Unified Architecture, Part 1 9 Release Auditing User level security includes support for security audit trails, with traceability between Client and Server audit logs. If a security-related problem is detected at the Server, the associated Client audit log entry can be located and examined. also provides the capability for Servers to generate Event Notifications that report auditable Events to Clients capable of processing and logging them. defines standard security audit parameters that can be included in audit log entries and in audit Event Notifications. [UA Part 5] defines the data types for these parameters. Not all Servers and Clients provide all of the auditing features. Profiles, found in [UA Part 7], indicate which features are supported Transport security security complements the security infrastructure provided by most web service capable platforms. Transport level security can be used to encrypt and sign Messages. Encryption and signatures protect against disclosure of information and protect the integrity of Messages. Encryption capabilities are provided by the underlying communications technology used to exchange Messages between applications. [UA Part 7] defines the encryption and signature algorithms to be used for a given Profile Integrated AddressSpace model The set of Objects and related information that the Server makes available to Clients is referred to as its AddressSpace. The AddressSpace represents its contents as a set of Nodes connected by References. Primitive characteristics of Nodes are described by -defined Attributes. Attributes are the only elements of a Server that have data values. Data types that define attribute values may be simple or complex. Nodes in the AddressSpace are typed according to their use and their meaning. NodeClasses define the metadata for the AddressSpace. [UA Part 3] defines the NodeClasses. The Base NodeClass defines Attributes common to all Nodes, allowing identification, classification and naming. Each NodeClass inherits these Attributes and may additionally define its own Attributes. To promote interoperability of Clients and Servers, the AddressSpace is structured hierarchically with the top levels standardized for all Servers. Although Nodes in the AddressSpace are typically accessible via the hierarchy, they may have References to each other, allowing the AddressSpace to represent an interrelated network of Nodes. The model of the AddressSpace is defined in [UA Part 3]. Servers may subset the AddressSpace into Views to simplify Client access. Clause describes AddressSpace Views in more detail Integrated object model The Object Model provides a consistent, integrated set of NodeClasses for representing Objects in the AddressSpace. This model represents Objects in terms of their Variables, Events and Methods, and their relationships with other Objects. [UA Part 3] describes this model. The object model allows Servers to provide type definitions for Objects and their components. Type definitions may be subclassed. They also may be standardized or they may be system-specific. ObjectTypes may be defined by the Foundation, other standards organizations, vendors or end-users.

13 Unified Architecture, Part 1 10 Release 1.00 This model allows data, Alarms and Events, and their history to be integrated into a single Server. For example, Servers are able to represent a temperature transmitter as an Object that is composed of a temperature value, a set of alarm parameters, and a corresponding set of alarm limits Integrated services The interface between Clients and Servers is defined as a set of Services. These Services are organized into logical groupings called Service Sets. Service Sets are discussed in Clause 7 and specified in [UA Part 4]. Services provide two capabilities to Clients. They allow Clients to issue requests to Servers and receive responses from them. They also allow Clients to subscribe to Servers for Notifications. Notifications are used by the Server to report occurrences such as Alarms, data value changes, Events, and Program execution results. Messages may be encoded as XML text or in binary format for efficiency purposes. They may be transferred using multiple underlying transports, for example TCP or web services over HTTP. Servers may provide different encodings and transports as defined by [UA Part 7]. 5.4 Sessions requires a stateful model. The state information is maintained inside an application Session. Examples of state-information are Subscriptions, user credentials and continuation points for operations that span multiple requests. Sessions are defined as logical connections between Clients and Servers. Servers may limit the number of concurrent Sessions based on resource availability, licensing restrictions, or other constraints. Each Session is independent of the underlying communications protocols. Failures of these protocols do not automatically cause the Session to terminate. Sessions terminate based on Client or Server request, or based on inactivity of the Client. The inactivity time interval is negotiated during Session establishment. 5.5 Redundancy The design of ensures that vendors can create redundant Clients and redundant Servers in a consistent manner. Redundancy may be used for high availability, fault tolerance and load balancing. The details for redundancy are found in [UA Part 4]. Only some Profiles [UA Part 7] will require redundancy support, but not the base Profile.

14 Unified Architecture, Part 1 11 Release Systems concepts 6.1 Overview The systems architecture models Clients and Servers as interacting partners. Each system may contain multiple Clients and Servers. Each Client may interact concurrently with one or more Servers, and each Server may interact concurrently with one or more Clients. An application may combine Server and Client components to allow interaction with other Servers and Clients as described in Clause Clients and Servers are described in the clauses that follow. Figure 3 illustrates the architecture that includes a combined Server and Client. UA client Client requests Server responses Published notifications Combined UA server and client Client requests Server responses Published notifications UA server Figure 3 System Architecture 6.2 Clients The Client architecture models the Client endpoint of client/server interactions. Figure 4 illustrates the major elements of a typical Client and how they relate to each other. Client Client-Application Requests to send service requests Delivery of received service responses Requests to send publishing requests Delivery of received notifications Communication Stack Client API Req Msg Rsp Msg Publ Msg Notif Msg To UA server From server To server From server Figure 4 Client Architecture The Client Application is the code that implements the function of the Client. It uses the Client API to send and receive Service requests and responses to the Server. The Services defined for are described in Clause 7, and specified in [UA Part 4]. Note that the Client API is an internal interface that isolates the Client application code from an Communication Stack. The Communication Stack converts Client API calls into Messages and sends them through the underlying communications entity to the Server at the request of the Client application. The Communication Stack also receives

15 Unified Architecture, Part 1 12 Release 1.00 response and Notification Messages from the underlying communications entity and delivers them to the Client application through the Client API. 6.3 Servers The Server architecture models the Server endpoint of client/server interactions. Figure 5 illustrates the major elements of the Server and how they relate to each other. Server Application Real Objects Server AddressSpace Node Node Node Monitored Item Node View Node Node Node Node Node Subscription Subscription Server API Communication Stack Req Msg Rsp Msg Publ Msg Notif Msg From client To client From client To client Figure 5 Server Architecture Real objects Real objects are physical or software objects that are accessible by the Server application or that it maintains internally. Examples include physical devices and diagnostics counters Server application The Server application is the code that implements the function of the Server. It uses the Server API to send and receive Messages from Clients. Note that the Server API is an internal interface that isolates the Server application code from an UA Communication Stack. This may be a standard implementation provided by the Foundation or it may be a vendor-specific implementation AddressSpace AddressSpace Nodes The AddressSpace is modelled as a set of Nodes accessible by Clients using Services (interfaces and methods). Nodes in the AddressSpace are used to represent real objects, their definitions and their References to each other.

16 Unified Architecture, Part 1 13 Release AddressSpace organization [UA Part 3] contains the details of the meta model building blocks used to create an AddressSpace out of interconnected Nodes in a standard, consistent manner. Servers are free to organize their Nodes within the AddressSpace as they choose. The use of References between Nodes permits Servers to organize the AddressSpace into hierarchies, a full mesh network of Nodes, or any possible mix. [UA Part 5] defines standard Nodes and References and their expected organization in the AddressSpace. Some Profiles will not require that all of the standard UA Nodes be implemented AddressSpace Views A View is a subset of the AddressSpace. Views are used to restrict the Nodes that the Server makes visible to the Client, thus restricting the size of the AddressSpace for the Service requests submitted by the Client. The default View is the entire AddressSpace. Servers may optionally define other Views. Views hide some of the Nodes or References in the AddressSpace. Views are visible via the AddressSpace and Clients are able to browse Views to determine their structure. Views are often hierarchies, which are easier for Clients to navigate and represent in a tree Support for information models The AddressSpace supports information models. This support is provided through: a) Node References that allow Objects in the AddressSpace to be related to each other. b) ObjectType Nodes that provide semantic information for real Objects (type definitions). c) ObjectType Nodes to support subclassing of type definitions. d) Data type definitions exposed in the AddressSpace that allow industry specific data types to be used. e) companion standards that permit industry groups to define how their specific information models are to be represented in Server AddressSpaces Publisher/subscriber entities MonitoredItems MonitoredItems are entities in the Server created by the Client that monitor AddressSpace Nodes and their real-world counterparts. When they detect a data change or an event/alarm occurrence, they generate a Notification that is transferred to the Client by a Subscription Subscriptions A Subscription is an endpoint in the Server that publishes Notifications to Clients. Clients control the rate at which publishing occurs by sending Publish Messages Service Interface General The Services defined for are described in Clause 7, and specified in [UA Part 4] Request/response Services Request/response Services are Services invoked by the Client through the Service Interface to perform a specific task on one or more Nodes in the AddressSpace and to return a response.

17 Unified Architecture, Part 1 14 Release Publisher Services Publisher Services are Services invoked through the Service Interface for the purpose of periodically sending Notifications to Clients. Notifications include Events, Alarms, data changes and Program outputs Server to Server interactions Server to Server interactions are interactions in which one Server acts as a Client of another Server. Server to Server interactions allow for the development of servers that: a) exchange information with each other on a peer-to-peer basis, this could include redundancy or remote Servers that are used for maintaining system wide type definitions, b) are chained in a layered architecture of Servers to provide: 1) aggregation of data from lower-layer Servers, 2) higher-layer data constructs to Clients, and 3) concentrator interfaces to Clients for single points of access to multiple underlying Servers. Figure 6 illustrates interactions between Servers. Network Client Server server interface client interface Interactions between servers client interface server interface Server Figure 6 Interactions between Servers

18 Unified Architecture, Part 1 15 Release 1.00 Figure 7 extends the previous example and illustrates the chaining of Servers together for vertical access to data in an enterprise. Enterprise Network Client Client Server Enterprise Semantic Layer Operations Network Server Client Client Server Process Semantic Layer Plant Floor Network Server Client Server Client Device Semantic Layer Figure 7 Chained Server Example 7 Service Sets 7.1 General Services are divided into Service Sets, each defining a logical grouping of Services used to access a particular aspect of the Server. The Service Sets are described below. The Service Sets and their Services are specified in [UA Part 4]. Whether or not a Server supports a Service Set, or a specific Service within a Service Set is defined by its Profile. Profiles are described in [UA Part 7]. 7.2 SecureChannel Service Set This Service Set defines Services used to discover the security configuration of a Server and to open a communication channel that ensures the confidentiality and integrity of all Messages exchanged with the Server. The base concepts for UA security are defined in [UA Part 2]. The SecureChannel Services are unlike other Services because they are typically not implemented by the UA application directly. Instead, they are provided by the communication stack that the UA application is built on. For example, a UA Server may be built on a SOAP stack that allows applications to establish a SecureChannel using the WS-SecureConversation specification. In these cases, the UA application simply needs to verify that a WS-SecureConversation is active whenever it receives a Message. [UA Part 6] describes how the SecureChannel Services are implemented. A SecureChannel is a long-running logical connection between a single Client and a single Server. This channel maintains a set of keys that are known only to the Client and Server and that are used to authenticate and encrypt Messages sent across the network. The SecureChannel Services allow the Client and Server to securely negotiate the keys to use. The exact algorithms used to authenticate and encrypt Messages are described in the security policies for a Server. A Client must select one of the security policies supported by the Server when it creates a SecureChannel. When a Client and Server are communicating via a SecureChannel they must verify that all incoming Messages have been signed and/or encrypted according to the security policy. A UA

19 Unified Architecture, Part 1 16 Release 1.00 application must not process any Message that does not conform to the security policy for the channel. A SecureChannel is separate from the UA Application Session; however, a single UA Application Session may only be accessed via a single SecureChannel. This implies that the UA application must be able to determine what SecureChannel is associated with each Message. A communication stack that provides a SecureChannel mechanism but that does not allow the application to know what SecureChannel was used for a given Message cannot be used to implement the SecureChannel Service Set. The relationship between the UA Application Session and the SecureChannel is illustrated in Figure 8. The UA applications use the communication stack to exchange Messages. First, the SecureChannel Services are used to establish a SecureChannel between the two communication stacks, allowing them to exchange Messages in a secure way. Second, the UA applications use the Session Service Set to establish a UA application Session. Client Server UA application Session UA application Communication Stack SecureChannel Communication Stack Figure 8 SecureChannel and Session Services When a Client establishes a SecureChannel it may provide a user identity. This user identity may be different from the user identity provided when the Client opens the UA Application Session. 7.3 Session Service Set This Service Set defines Services used to establish an application-layer connection in the context of a Session on behalf of a specific user. 7.4 NodeManagement Service Set The NodeManagement Service Set allows Clients to add, modify, and delete Nodes in the AddressSpace. These Services provide a standard interface for the configuration of Servers. 7.5 View Service Set Views are publicly defined, Server-created subsets of the AddressSpace. The entire AddressSpace is the default View, and therefore, the View Services are capable of operating on the entire AddressSpace. Future versions of this specification may also define Services to create Client defined Views. The View Service Set allows Clients to discover Nodes in a View by browsing. Browsing allows Clients to navigate up and down the hierarchy, or to follow References between Nodes contained in the View. In this manner, browsing also allows Clients to discover the structure of the View.

20 Unified Architecture, Part 1 17 Release Attribute Service Set The Attribute Service Set is used to read and write Attribute values. Attributes are primitive characteristics of Nodes that are defined by. They may not be defined by Clients or Servers. Attributes are the only elements in the AddressSpace permitted to have data values. A special Attribute, the Value Attribute is used to define the value of Variables. 7.7 Method Service Set Methods represent the function calls of Objects. They are defined in [UA Part 3]. Methods are invoked and return after completion, whether successful or unsuccessful. Execution times for Methods may vary, depending on the function they are performing. The Method Service Set defines the means to invoke Methods. A Method must be a component of an Object. Discovery is provided through the browse and query Services. Clients discover the Methods supported by a Server by browsing for the owning Objects that identify their supported Methods. Because Methods may control some aspect of plant operations, method invocation may depend on environmental or other conditions. This may be especially true when attempting to re-invoke a Method immediately after it has completed execution. Conditions that are required to invoke the Method may not yet have returned to the state that permits the Method to start again. In addition, some Methods may be capable of supporting concurrent invocations, while others may have a single invocation executing at a given time. 7.8 MonitoredItem Service Set The MonitoredItem Service Set is used by the Client to create and maintain MonitoredItems. MonitoredItems monitor Variables, Attributes and EventNotifiers. They generate Notifications when they detect certain conditions. They monitor Variables for a change in value, status or timestamp; Attributes for a change in value; and EventNotifiers for newly generated Alarm and Event reports. Each MonitoredItem identifies the item to monitor and the Subscription to use to periodically publish Notifications to the Client (see Clause 7.9). Each MonitoredItem also specifies the rate at which the item is to be monitored (sampled) and, for Variables and EventNotifiers, the filter criteria used to determine when a Notification is to be generated. Filter criteria for Attributes are specified by their Attribute definitions in [UA Part 4]. The sample rate defined for a MonitoredItem may be faster than the publishing rate of the Subscription. For this reason, the MonitoredItem may be configured to either queue all Notifications or to queue only the latest Notification for transfer by the Subscription. In this latter case, the queue size is one. MonitoredItem Services also define a monitoring mode. The monitoring mode is configured to disable sampling and reporting, to enable sampling only, or to enable both sampling and reporting. When sampling is enabled, the Server samples the item. In addition, each sample is evaluated to determine if a Notification should be generated. If so, the Notification is queued. If reporting is enabled, the queue is made available to the Subscription for transfer. Finally, MonitoredItems can be configured to trigger the reporting of other MonitoredItems. In this case, the monitoring mode of the items to report is typically set to sampling only, and when the triggering item generates a Notification, any queued Notifications of the items to report are made available to the Subscription for transfer. 7.9 Subscription Service Set The Subscription Service Set is used by the Client to create and maintain Subscriptions. Subscriptions are entities that periodically publish Notification Messages for the MonitoredItem assigned to them (see Clause 7.7). The Notification Message contains a common header followed

21 Unified Architecture, Part 1 18 Release 1.00 by a series of Notifications. The format of Notifications is specific to the type of item being monitored (i.e. Variables, Attributes, and EventNotifiers). Once created, the existence of a Subscription is independent of the Client s Session with the Server. This allows one Client to create a Subscription, and a second, possibly a redundant Client, to receive Notification Messages from it. To protect against non-use by Clients, Subscriptions have a configured lifetime that Clients periodically renew. If any Client fails to renew the lifetime, the lifetime expires and the Subscription is closed by the Server. When a Subscription is closed, all MonitoredItems assigned to the Subscription are deleted. Subscriptions include features that support detection and recovery of lost Messages. Each Notification Message contains a sequence number that allows Clients to detect missed Messages. When there are no Notifications to send within the keep-alive time interval, the Server sends a keep-alive Message that contains the sequence number of the last Notification Message sent. If a Client fails to receive a Message after the keep-alive interval has expired, or if it determines that it has missed a Message, it can request the Server to resend one or more Messages Query Service Set The Query Service Set allows Clients to select a subset of the Nodes in the address space or in a View based on some Client-provided filter criteria. The Nodes and their Attributes selected by the Query Service are called a result set. The result set may be a flat set of Nodes, or it may preserve the structure by returning References connecting the Nodes in the result set. Servers may find it difficult to process queries that require access to runtime data, such as device data, that involves resource intensive operations or significant delays. In these cases, the Server may find it necessary to reject the query.