010 OPC UA data source integration

  • Status: accepted
  • Deciders: partners

Context and Problem Statement

There are potential existing data sources already providing an OPC UA interface.

Here we want to outline how integration of OPC UA data sources can be accomplished and if these are treated differently to other data clients due to the higher complexity of OPC UA.

Decision Drivers

  • portability: consider consequences of feature parity between OPC UA and South API for involved parties

Considered Options

  • mapping to South API and back to North API/OPC UA with already outlined functionality
  • assume a South API independent direct connection from OPC UA data sources to north bound OPC UA to be defined in later iteration

Decision Outcome

As long as the OPC UA data client does not require more functionality than the south API provides, there is no reason to use another API than the South API.

If there are additional requirements that do not match the intention and structure of the South API or would lead to an increased complexity for other data clients, than fallback to option:
assume a South API independent direct connection from OPC UA data sources to north bound OPC UA to be defined in later iteration

Pros and Cons of the Options

Since no immediate action is required for the chosen option it is still possible to revert this decision without having spent effort and chose to integrate OPC UA data sources with South API compatible data clients.

mapping to South API and back to North API/OPC UA with already outlined functionality

  • Good, because only a single data source integration via South API must be implemented by transformation engines
  • Bad, because feature parity between South API and OPC UA or between a OPC UA feature subset must be considered and potential limitations must be defined and might limit usability of existing data sources
  • Bad, because even if direct OPC UA knowledge is not required by data client implementors it might still "leak through" via South API specifications

assume a South API independent direct connection from OPC UA data sources to north bound OPC UA to be defined in later iteration

  • Good, South API must not enable full feature set of OPC UA
  • Good, because transformation engine implementors should already be familiar with OPC UA features
  • Bad, because transformation engine implementations must handle an additional data source type