8 Application Architecture
8.1 Introduction
This chapter describes an abstract architecture for OPC UA applications with different layers having defined responsibilities regarding OPC UA functionality. Afterward the deliverables of the OPC Foundation and their features are listed and it is pointed out how these are reflected in the abstract architecture.
8.2 Architectural Overview
When you intend to develop an application based on OPC UA you first have to think about what it should do by specifying the requirements and the functionality. Having that in mind you normally start designing the architecture of your applica-tion. Thereby certain design goals (e.g., portability, performance, or security) have to be agreed upon before first architectural concepts are developed. In this chapter, we will take a look at OPC UA from the design perspective and introduce a poten-tial application scenario. We expect that this scenario will be applied by many application vendors. The main design goal thereby is the reuse of components and artifacts.
In this scenario, we assume that we have to develop an OPC UA client and a server. Both client and server will have application logic covering functionality tailored to concrete use cases. For example, the server has to access special data sources (e.g., data bases, devices, or other applications) or the client has to be integ-application logic covering common functionality like managing connections, cre-ating and processing OPC UA messages as well as securing them. Since we defined reuse as our main design goal it would make sense to separate use-case-specific and common functionality when designing the architecture. The common part can tions and processing Service messages and lower level functions like encoding, securing, and transmitting messages. The part providing the higher level functions can be considered as a Software Development Kit (SDK) and the part with the lower level functions can be represented by a protocol stack. The client and server applications are layered on top of the SDK. Based on these blocks we come to a very high level architecture shown in Fig. 8.1.
The above-described software layers are named as Application, SDK, and Stack and are described in more details in the following sections.
255
DOI: 10.1007/978-3-540-68899-0_8,be further divided into two parts: the higher level functions like managing connec-W. Mahnke et al., OPC Unified Architecture ,rated into another application (e.g., in a MES application). But they will also have ? Springer-Verlag Berlin Heidelberg 2009
Fig. 8.1 Architectural overview
8.3 Stack
As mentioned in Sect. 8.2, the Stack is a common part covering lower level func-tionality. In this section, we want to structure the Stack further into different parts
leading to a more detailed architectural view like the one shown in Fig. 8.2.
Fig. 8.2 Stack overview
8.3.1Interfaces
First of all, the layers above need somehow to access the Stack in order to send and receive messages. Both client and server can use the same stack since it pro-vides a lot of functionality that can be used for both sides such as encoding and securing messages. However, there are also functions specific to each side. For
8 Application Architecture
256
example the client is only sending requests and processing responses, whereas the server processes requests and sends responses. Therefore an access layer (i.e., interface) is needed for both the client- and the server-side (Client and Server API in the figure). They could, for example, offer methods for configuring the Stack, for managing the connection establishment, for sending OPC UA Service mes-sages, and for notifying the layers above when messages are received.
The encoding and the decoding of messages are processed in the Encoding Layer. Once data structures representing Service messages are provided from the API layer they are serialized according to the special rules defined by OPC UA and passed to the layer beneath for further processing. Service messages received from the Security Layer are deserialized and passed as arguments of callback functions registered by the upper layer.
8.3.3Security Layer
Encoded Service messages passed by the Encoding Layer to the Security Layer are then secured. Secured in this context means that depending on the configura-encrypted or only signed. In scenarios in which applications are running in iso-lated environments there must also be the possibility to disable message security by configuration. In addition, special security headers and footers are appended providing information for the receiver on how to decrypt the message and how to verify the signature of the message. The Security Layer of the receiver has to check the security headers and footers of incoming messages to know how they were secured. Depending on that messages are first decrypted and afterward the signature of the message is verified or only the signature is verified or none of these activities are done (in the case the message was not secured).
8.3.4Transport Layer
The Transport Layer is responsible for transmitting and receiving messages as well as for dealing with errors at Network Layer. Before transmitting messages special transport headers are appended containing special information for example about the type and the length of the message. The Transport Layer of the receiver verifies whether it is well-formed meaning whether the type can be identified or whether the message is not too long 1 before forwarding it to the Security Layer.
1In UA TCP, the maximum message lengths are negotiated and verified at Transport Level. 257
8.3 Stack 8.3.2Encoding Layer
tion of the Secure Channel (Sect. 7.5.2.1) outgoing messages are signed and
8.3.5Platform Layer The reuse factor of the Stack can be increased by adding an additional layer to this model – the Platform Layer. The basic idea thereby is that all other layers of the Stack are developed in platform-neutral manner. Only the Platform Layer contains for managing sockets, threads, or cryptographic operations (e.g., encrypting and signing messages). This means that only the Platform Layer has to be changed in order to port the Stack to another platform, the other parts of the code can be reused.
8.4 Software Development Toolkit
On top of the Stack, the SDK Layer is located covering the higher level function-ality. This layer can be in general composed of three parts which are illustrated in Fig. 8.3.
Fig. 8.3 SDK overview
8.4.1UA-Specific Functionality
The UA-specific part represents the implementation of the concepts and the Services specified in OPC UA. Note, that all the different aspects (like Sessions, Events, or Nodes) depicted in Fig. 8.3 have to be addressed by both the client and the server.
8 Application Architecture
258
However, the semantic of these aspects for client and server is different (e.g., Client creates a Session request and server processes the client’s Session request).
One important aspect is the management of OPC UA Sessions. As we learned the connection establishment of OPC UA includes creating a Secure Channel, establishing a Session, and activating the Session. The SecureChannel Services should be implemented in the Stack Layer to reduce the complexity in the SDK. Therefore, the Secure Channels should also be managed in that layer. The Session Services (i.e., CreateSession, ActivateSession, and CloseSession) are implemented in the present model in the SDK Layer. However, managing OPC UA Sessions does not only mean processing the Service requests and responses. There has also to be special logic behind like associating Sessions with the Secure Channel that secures the exchanged messages for that context. In addition, Sessions are run on behalf of users that have to be authenticated and authorized. Furthermore there are special Session parameters that have to be taken care of like the lifetime of the session or used locales. Such tasks are handled by a management class which can be called as a Session Manager.
Another important aspect is working with Nodes. Nodes are very essential to OPC UA and are used for organizing Address Spaces as well as for providing attribute values. Address Spaces in OPC UA reside on the server-side allowing clients to access and manipulate them via the NodeManagement and Attribute Service Sets. This means that on the server-side there has to be entities managing the Nodes (e.g., Node Manager) of the Address Space (i.e., Nodes and References) and the manipulation of the values contained in the Nodes (e.g., I/O Manager). Other concepts and Services like Subscriptions, Events, and History can be approached in a similar way.
OPC UA defines certain diagnostics information for Services and exposes it in the Address Space. It contains for example information about how often Services have been called. Managing this information is also a task for the SDK Layer since is also manages the Services of which the upper layer may not be aware of.
8.4.2Common Functionality
The second part of the SDK Layer covers more general functionality that has to be implemented by clients and servers.
OPC UA exchanges certificates in order to establish secure connections. Before using them it has to be verified whether a received certificate can be trusted or not. OPC UA specifies what part of a certificate has to be validated to be trusted, how-ever, it does not state how it has to be validated. Therefore common functionality has to be provided allowing the applications to validate certificates and accessing their associated certificate stores. An alternative to implementing that function-ality in the SDK is using the Stack for that purpose. Since the Stack is a common component that should be used for large range of applications it is assumed that all applications use the same way of validating certificates. In heterogeneous 259
8.4 Software Development Toolkit
environments, it sometimes can make more sense to implement that in SDK or even in the Application Layer when different sources for gathering certificates or certificate-related information (e.g., certificate revocation lists, private keys, or validation rules) have to be consumed.
Other important topics that belong to the common part are application configu-ration and logging.
8.4.3Interfaces
The last part of the SDK discussed in this context represents the interfaces to the Application Layer. Client interfaces are needed for sending requests to the server and for receiving responses from it (i.e., callback interfaces). On the server side some interfaces for initializing and configuring the SDK should be provided as well as for integrating underlying systems acting as data providers.
8.5 Application
The Application Layer includes in principle two kinds of applications: clients and servers. The way how the architectures of these applications look like differs very much depending on the concrete scenario.
8.5.1Client
One example for an OPC UA client application is a generic browser used for exploring and manipulating the Address Space provided by a server. The main tasks of the client is visualizing data provided by the SDK Layer and translating user interactions into calls to the SDK’s API. The design of such an application from the functionality point of view can be quite simple which is shown in Fig. 8.4.
Fig. 8.4 Example of a high-level client architecture
8 Application Architecture
260
8.5.2Server
In principle there are two kinds of server applications: one managing the whole address space in the main memory and another one accessing underlying systems for gathering Address Space information.
In the first case, the Address Space is stored in a special data source (e.g., data-base or XML file) and completely loaded into the main memory when the server starts up. This provides a fast access to information contained in the Address Space requested by clients.
In the second case, an OPC UA server facades an underlying system like a device, controller or DCS. In the last case, typically several sources are accessed, like a configuration database and several controllers. It is expected that many sys-tem vendors will first head such an approach in order to smoothly migrate existing applications to OPC UA. The main responsibilities of this layer are reading and writing data from the underlying system. A SDK could for example provide spe-cial callback interfaces for exchanging data in a simple way to reduce the complexity of the server implementation on top of the SDK. An example of that architecture is given in Fig. 8.5.
Fig. 8.5 Example of a high-level server architecture
8.6 Deliverables Provided by the OPC Foundation
The OPC Foundation provides a set of deliverables that can make your life easier when developing OPC UA applications. Some of the deliverables follow the archi-tecture described in Sect. 8.5. All of them are available in the so-called UA SDK. It contains thereby various Stacks, libraries, and sample applications.
261
8.6 Deliverables Provided by the OPC Foundation
8.6.1 Stacks
Both an ANSI-C-based and a C#-based Stack is provided with the UA SDK.
A Java-based Stack was under development at the time when this book was writ-ten. It is recommended to use the UA stacks provided by the OPC Foundation in order to ensure interoperability between applications implemented in different development environments.
The ANSI-C Stack is implemented according to the architecture depicted in Conversation for the Security Layer, and UA TCP for the Transport. For securing messages and validating certificates, the OpenSSL crypto library is applied and integrated in the platform-specific part of the Stack.
Alternatively there is also a .NET Stack written in C# which does not have a Platform Layer. Therefore the architecture is different to the one shown above. For the Encoding Layer it supports UA Binary and XML, UA-SecureConversation and WS-SecureConversation as Security Layer protocols, and the transport protocols UA TCP and SOAP/HTTP. However, only the following combinations of the pro-tocols (also named as Stack profiles or mappings schemes; see Chap. 6 for more details) can be used:
?
HTTP/SOAP, WS-SecureConversation, UA Binary ?
HTTP/SOAP, WS-SecureConversation, XML ?
HTTP/SOAP, WS-SecureConversation, UA Binary, and XML 8.6.2 SDKs
There are two C#-based libraries contained in the UA SDK: a client library and a server library. These libraries can be considered as the SDK Layer described ear-lier. Both are providing the base functionality for handling the UA protocol and for processing common tasks regarding logging, security, and configuration. The server library provides special interfaces that can be used to integrate underlying systems for example in order to read or write certain values. The client library implements a NodeCache for buffering Nodes and References. In addition to the client and server libraries, the SDK also provides a C#-based discovery server used by clients for identifying running endpoints of the server they can connect to. C++-based UA SDKs for clients and servers were developed by a group of early adopter companies and are available as commercial libraries from Unified Automation. They are using the ANSI-C stack and are providing platform layers for different operating systems. Similar to the .NET UA SDK, the C++ SDKs are implementing common UA functionality to reduce the development effort for UA applications and are defining interfaces to integrate the application-specific infor-mation with the SDK.
8 Application Architecture
262? UA TCP, UA-SecureConversation, UA Binary.
Fig. 8.2. It supports UA Binary encoding for the Encoding Layer, UA-Secure-
8.6.3 Applications
The OPC Foundation’s UA SDK provides both a sample client and server application written in C#. The client application is a generic OPC UA browser offering the base OPC UA functionality like browsing the Address Space, reading and writing Node attributes, subscribing for data changes and Events, and also more sophisti-cated concepts like calling Methods or using Views. Therefore, it is a powerful tool for learning and exploring the concepts of OPC UA. The server uses an in-memory Address Space including standard Nodes as well as an example describing a boiler and its components.
8.7 Summary
8.7.1 Key Messages
This chapter describes how the architecture of an OPC UA application typically looks like. The main design goal is thereby the reuse of artifacts (e.g., code and components). Therefore the following layers with certain responsibilities are defined: Application Layer, SDK Layer, and Stack Layer.
The Stack is responsible for the lower level functions like encoding and decod-ing messages, securing messages, as well as sending and receiving messages. In addition to that, it has a Platform Layer containing only platform-specific code whereas the other layers are written in platform neutral manner. This facilitates the portability of the Stack to other platforms.
The SDK contains higher level functionality covering UA-specific functions and common functions. The UA-specific part implements the OPC UA concepts and Services whereas the common part deals for example with configurations and logging. Additionally the server-side of the SDK provides interfaces in order to integrate other systems used as data providers.
The Application Layer covers the use-case-specific part of the functionality. Clients could, for example, process data received from the SDK in a special way in order expose it to the user. Servers could access underlying systems in order to expose its information via OPC UA to clients.
The OPC Foundation offers a set of OPC UA standard deliverables that system vendors can reuse. Some of the components already implement similar architec-ture as described in this chapter.
8.7.2 Where to Find More Information?
More information about the OPC UA standard deliverables can be found on the OPC Foundation Web site (https://www.doczj.com/doc/1f11650549.html,/). More information 263
8.7 Summary
2648 Application Architecture
about the C++ SDKs can be found at the Unified Automation Web site (http:// https://www.doczj.com/doc/1f11650549.html,). Finally, the Web site of the OPC programmers’ connection (https://www.doczj.com/doc/1f11650549.html,/) provides a section with SDKs that can a useful source when intending to implement OPC UA applications.
8.7.3 What’s Next?
In Chap. 8 – System Architecture – different variants of OPC UA client–server concepts are introduced like chained or aggregating server. In addition, some related concepts regarding redundancy, discovery, and auditing are introduced.
全国经典旅游景点一览表 北京 故宫博物院、天坛公园、颐和园、（八达岭-慕田峪）长城旅游区、明十三陵景区、恭王府景区、石花洞风景名胜、店人遗址、什刹海、京杭大运河、八大处、密云县古北口镇、九渡河镇、东坝古镇、王四营 燕京八景：太液秋风、琼岛春阴、金台夕照、蓟门烟树、西山晴雪、玉泉趵突、卢沟晓月、居庸叠翠 天津 古文化街旅游区（津门故里）、盘山风景名胜区、大悲禅院、文庙、挂甲寺、五大道租借区、平津战役纪念馆、天塔湖风景区、南市食品街、周恩来邓颖超纪念馆、大沽口炮台、九龙山国家森林公园、九山顶自然风景区、八仙山国家级自然保护区、霍元甲纪念馆、凯旋王国主题公园、意式风情区 上海 明珠广播电视塔、野生动物园、科技馆、豫园、陆家嘴、外滩万国建筑群、路步行街、世博园 重庆 大足石刻景区、巫山（小三峡）、武隆喀斯特旅游区(天生三桥、仙女山、芙蓉洞) 、酉阳桃花源景区、奉节小寨天坑、白帝城、青龙瀑布红岩革命纪念馆、抗战遗址博物馆、綦江黑山谷景区、南川金、武陵山大裂谷、飞庙 河北 ：避暑山庄及周围寺庙景区
：山海关景区、北戴河风景名胜区 ：安新白洋淀景区、野三坡景、大慈阁 ：西柏坡景区、清西陵 市：清东陵、南湖景区 ：崆山白云洞、峡谷群 江 ：园林（拙政园、虎丘、留园）、昆山周庄古镇景区、金鸡湖景区、吴江同里古镇景区、寒山寺、网师园、狮子林、沧浪亭、环秀山庄、退思园、锦溪镇、周庄镇、同里镇、甪直镇、木渎镇、虎丘、乐园、玄妙观、盘门三景、乐园 ：钟山-陵园景区、夫子庙-淮河风光带景区、明孝陵、鸡鸣寺、玄武湖、灵谷寺、总统府、朝天宫、江南贡院、莫愁湖、燕子矶、阅江楼、雨花台、明城墙、甘熙宅第、瞻园、栖霞寺、汤山温泉、博物院、、莫愁湖、长江大桥、梅花山、白鹭洲公园、中华门、将军山风景区、阳山碑材、静海寺、天妃宫 ：影视基地三国水浒景区、灵山大佛景区、鼋头渚风景区、锡惠公园、灵山胜境、善卷洞、竹海 ：恐龙城休闲旅游区、武进太湖湾旅游度假区、嬉戏谷、中华孝道园、中国春秋淹城旅游区、淹城春秋乐园、淹城野生动物世界、淹城遗址、大运河、天宁风景名胜区、红梅公园、东坡公园、舣舟亭、红梅阁、青枫公园、亚细亚影视城、武进市新天地公园、天目湖旅游度假区、南山竹海、吴越弟一峰、熊猫馆、天目湖御水温泉、茅山风景名胜区、茅山盐湖城 ：瘦西湖景区、高邮旅游集聚区、宝应旅游集聚区、仪征旅游集聚区、抗日战争最后一役纪念馆、大明寺、个园、仙鹤寺、汉陵苑、神居山、盂城驿、龙虬庄遗址、镇国寺塔、文游台、古悟空寺、中国邮驿文化城、高邮湖芦苇荡湿地公园、高邮湖滩郊野公园 ：濠河风景区、博物苑、狼山、如皋水绘园 ：梅兰芳纪念馆、溱湖国家湿地公园、溱潼古镇、兴化垛田风光带、凤城河景区 ：三山景区（金山-北固山-焦山）、茅山、赤山、宝华山、南山、伯先公园、英国领事馆、西津渡、蒜山、招隐寺、圌山、五柳堂、五卅演讲厅、扬中园博园 ：云龙湖、云龙山、龟山汉墓、祖园、邳州艾山风景名胜区、马陵山风景区、沛县汉城、汉画像石艺术馆、窑湾古镇、蟠桃山佛教文化景区、安湖湿地公园、博物馆、大洞山风景区、
第1位—美国大峡谷-TheGrandCanyon 美国大峡谷是一个举世闻名的自然奇观，位于西部亚利桑那州西北部的凯巴布高原上，总面积2724．7平方公里。由于科罗拉多河穿流其中，故又名科罗拉多大峡谷，它是联合国教科文组织选为受保护的天然遗产之一。
第2位—澳大利亚的大堡礁—GreatBarrierReef 世界上有一个最大最长的珊瑚礁群，它就是有名的大堡礁—GreatBarrierReefo它纵贯蜿蜒于澳洲的东海岸，全长2011公里，最宽处161公里。南端最远离海岸241公里，北端离海岸仅16公里。在落潮时，部分的珊瑚礁露出水面形成珊瑚岛。 第3位—美国佛罗里达州—Flori—dl
佛罗里达风景最亮丽的棕榈海滩是全球著名的旅游天堂之一，适宜的气候、美丽的海滩、精美的饮食、艺术展览和文艺演出，即使是最挑剔的游客，在棕榈海滩也能满意而归。每年的四月，棕榈海滩的艺术活动是最丰富多彩的，包括各种海滩工艺品展览，其中于4月4 日启动的棕榈海滩爵士节以展示美国最杰出的爵士音乐而赢得了艺术爱好者的青睐。 第4位—新西兰的南岛-Soutls—land
新西兰位于南太平洋，西隔塔斯曼海与澳大利亚相望，西距澳大利亚1600公里，东邻汤加、斐济国土面积为二十七万平方公里，海岸线长6900千米，海岸线上有许多美丽的海滩。 第5位—好望角一CapeTown
好望角为太平洋与印度洋冷暖流水的分界，气象万变，景象奇妙，耸立于大海，更有高逾二干尺的达卡马峰，危崖峭壁，卷浪飞溅，令人眼界大开。 第6位—金庙-GoldenTemple
金庙位于印度边境城市阿姆利则。作为锡克教的圣地，阿姆利则意为“花蜜池塘”。金庙由锡克教第5代祖师阿尔琼1589年主持建造，1601年完工，迄今已有400年历史。因该庙门及大小19个圆形寺顶均贴满金箔，在阳光照耀下，分外璀璨夺目，一直以来被锡克人尊称为“上帝之殿”。 第7位—拉斯维加斯-LasVegas
北京:八达岭故宫什刹海圆明园玉渊潭龙庆峡 十三陵天安门香山颐与园天坛十渡 百花山潭柘寺雍与宫幽谷神潭紫竹院黑龙潭 康西草原中央电视塔 澳门 : 妈祖阁大三巴牌坊澳门文化中心澳门博物馆玫瑰圣母堂竹湾海滩辽宁 : 沈阳故宫千山昭陵玉佛苑本溪水洞金石滩 虎滩乐园鸭绿江大桥辽宁省博物馆棒棰岛大孤山风景名胜区海王九岛 赫图阿拉城怪坡星海公园 重庆; 三峡大坝葛洲坝瞿塘峡歌乐山巫峡渣滓洞 白帝城白公馆丰都鬼城石宝寨芙蓉洞缙云山 金佛山宝顶山四面山 西藏: 珠穆朗玛峰大昭寺然乌湖布达拉宫纳木错墨脱 圣湖八廓街扎什伦布寺桑耶寺神山色拉寺 羊卓雍湖哲蚌寺罗布林卡古格王朝日喀则绒布寺 青海; 青海湖塔尔寺茶卡盐湖鸟岛日月山坎布拉 格尔木柴达木盆地北禅寺东关清真大寺黄河源孟达天池 倒淌河 宁夏: 沙湖西夏王陵贺兰山岩画长江源青铜峡108塔沙坡头 玉皇阁中卫高庙宏佛塔 台湾: 宝岛美景阿里山日月潭阳明山玉山太鲁阁 台北故宫板桥林家花园野柳赤嵌楼溪头秀姑峦溪 鹅銮鼻合欢山七美岛 山西: 五台山恒山平遥古城壶口瀑布乔家大院云冈石窟 王家大院北武当山晋祠悬空寺显通寺日升昌票号 广胜寺庞泉沟应县木塔南山寺善化寺 黑龙江: 大兴安岭漠河镜泊湖太阳岛吊水楼瀑布冰雪大世界 极乐寺亚布力滑雪场扎龙自然保护区圣索菲亚大教堂 甘肃; 嘉峪关莫高窟玉门关郎木寺伏羲庙麦积山石窟 炳灵寺石窟崆峒山 湖北: 三峡神农架武当山黄鹤楼归元寺葛洲坝 东湖西陵峡五道峡大九湖九畹溪香溪源 燕子垭 内蒙古: 呼伦贝尔草原成吉思汗陵阿斯哈图石林赤峰五当召响沙湾 扎兰屯锡林浩特达里诺尔湖大青沟格根塔拉草原黑里河 天津: 古文化街盘山食品街独乐寺大沽口炮台天后宫 天成寺舍利塔太平寨千像寺八卦城清真大寺蓟县白塔 新疆: 塞里木湖喀纳斯那拉提草原吐鲁番魔鬼城火焰山 交河故城高昌古城喀什博斯腾湖阿尔泰山白杨沟 博格达山楼兰卡拉库里湖罗布泊果子沟艾丁湖