Application Architecture

Introduction

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 application. 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 potential 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?rated into another application (e.g., in a MES application). But they will also have application logic covering common functionality like managing connections, creating 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 be further divided into two parts: the higher level functions like managing connections 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.