customercare@matrikonopc.com Read More
 
 
MatrikonOPC Driver Search
Click below to begin your MatrikonOPC Server Search.
MatrikonOPC Driver Search
  0 item(s) in your cart.
Total: $0.00 Checkout
MatrikonOPC On Facebook MatrikonOPC - Google+ MatrikonOPC On Twitter MatrikonOPC On LinkedIn MatrikonOPC On YouTube MatrikonOPC Blog

Download: OPC Unified Architecture (OPC UA) Part 1 - Concepts RC1.00

This specification presents the OPC Unified Architecture concepts. Included are the OPC UA system concepts, OPC UA object model, and the OPC UA address space structure.

OPC Unified Architecture (OPC UA) is targeted for Service Orientated Architectures (SOA), enterprise architectures and applications built by combining loosely coupled and interoperable services. What the original OPC Data Access (OPC DA) specification was to COM, OPC UA is to Web Services, except UA encompasses a much larger scope. Regardless of ‘What’ type of information you wish to move, OPC UA describes ‘How’ to achieve this.

The OPC UA documentation is a set of layered specifications broken into multiple parts. It is purposely described in abstract terms in the Base and Functional Parts and in the Implementation Parts, is integrated with existing technology on which OPC UA products can be built. This layering is purposely intended to isolate changes in the OPC UA specification from changes in the technology used to implement it.

‘Classic’ OPC has served the industrial world very well for the last ten years, but any true standard or institution must continue to evolve and grow. There are three primary factors that influenced the decision to move forward with the OPC UA architecture:

  • The major OPC installation base, Microsoft is focusing their future efforts on Web Services and SOA applications. In addition, there is increasing pressure from end users looking for OPC support on Linux and other non-Windows platforms.
  • OPC is no longer a simple point-to-point solution, and is becoming the backbone of increasing complex OPC architectures, that involve multiple specifications. Vendors and users require a single interface that exposes the key functional areas of OPC.
  • The OPC Foundation would get more and more requests from clients and other institutions to leverage its standards to aid those who are defining other industry standards at a granularity below the interface level.

For all these reasons and more, it seemed obvious it was time for the OPC specifications and organization to evolve to the next stage.

The OPC UA documents can be very loosely categorized as Base, Functional and Implementation Parts. The Base Parts include:

    Part 1 - Concepts
    Part 2 - Security
    Part 3 - Address Space
    Part 4 - Services
    Part 5 - Information Model

These documents describe the basic concepts, design and abstract interfaces for all OPC UA application, regardless of its functionality. These Parts are completely independent of the ‘plumbing’ or underlying implementation infrastructure.

The Functional Parts include:

    Part 8 - Data Access
    Part 9 - Alarms and Conditions
    Part 10 - Programs
    Part 11 - Historical Access

These Parts are what really give the Unified Architecture it’s name. These Parts encapsulate the essence of the classic OPC specifications, namely OPC Data Access (DA), OPC Historical Data Access (HAD), OPC Alarms & Events (OPC A&E), and OPC Complex Data. Additional OPC UA Parts are anticipated for OPC Batch and OPC Data eXchange (OPC DX). These Parts do not introduce any new services or concepts beyond the Base Parts. They are primarily Information Model extensions, and define how to use the Base Parts to deal with a common functional model in a standard way. This multiple Part model is designed to allow other key Functional documents or Companion Specifications to evolve. Currently the are active collaborations with groups such as EDDL (Electronic Device Description Language), ISA S95 and S88, and MIMOSA.

The Implementation Parts include:

    Part 6 - Mappings
    Part 7 - Profiles

These Parts really describe where the rubber really hits the road. They detail how the abstract specifications layer onto existing technologies or accepted standards such as TCP, XML, SOAP, HTTP, WS-* specifications and Web Security applications. The Profiles document actually falls under multiple categories, but can be generally classified as Implementation. Since OPC UA covers such a wide range of functionality, a more elaborate system was needed to ensure proper levels of compliance. The Profiles Part outlines multiple levels on functionality that an OPC UA product can implement. This will give clients and servers much more granularity in determining the expected level of functionality each product will offer.

Due to the scope that OPC UA encompasses, the structure and depth of material to absorb on understanding how to implement OPC UA is much more involved as compared to the OPC COM Specifications. It is recommended that developers and architects read the introductory articles and in-depth presentations available on the OPC Foundation Website.






     

 
 

© 2017 Honeywell International Inc.
Home | Search | Site Map | Privacy Policy | Terms Of Use | Contact