Architecture of Interoperable Information Systems

The Architecture of Interoperable Information Systems (AIOS) is a reference architecture for the development of interoperable enterprise information systems. If enterprises or public administrations want to engage in automated business processes with other organizations, their IT systems must be able to work together, i.e. they need to be interoperable. The AIOS represents a generic building plan for these organizations to develop interoperable information systems by systematically adjusting and extending their internal information systems. The AIOS was described in a doctoral thesis and is based on the results of various research projects on interoperability.^[1] It is independent from specific products or vendors but describes generically the different layers, views, relationships and technical means needed to efficiently establish interoperable information systems. To this aim it combines concepts from service-oriented architecture, Collaborative Business and Business Process Modelling. It can be seen as complementary to ARIS, a well-known architecture for internal information systems and business processes.

YouTube Encyclopedic

1/3
Views:
27 526
1 448
1 467

Transcription

In this video, I'll be introducing you to the PI Interface for OPC DA. I'll explain how data collection works. I'll give some architecture recommendations and finally I'll enumerate the different steps that you need to accomplish to install and configure your very own PI Interface for OPC DA. The PI Interface for OPC DA is used to collect data from an OPC DA server. But in order to understand what an OPC DA server is, we first need to understand what OPC DA means. OPC stands for OLE for process control. DA stands for data access. So OPC DA is a standard to communicate data across automation systems. So let's take a step back. Here we have a bunch of different vendors with different automation systems. These systems are speaking different languages. And the PI System also speaks its own language. So these languages need to be translated and people in the automation industry came up with the OPC Standard. So this is a standard way to expose data on these systems. And a standard way of collecting data on these systems. So it's basically a standard that was created to facilitate data sharing. How does data sharing actually work using the OPC DA standard? Well first we have our data source. And this data source is connected to an OPC DA server. This OPC DA server is collecting data off the data source and exposing it using the OPC DA standard. And it's making it available to different applications. These applications are called OPC DA clients. So these are applications whose job it is to translate the data from the OPC DA standard into whatever protocol is needed for their data sync. So basically on the PI System, the OPC DA client is the PI Interface for OPC DA. And the data sync is the PI Data Archive. So the OPC DA Server once again is translating the data from the data source and the PI Interface for OPC DA is translating the data from the OPC DA Server for the PI Data Archive to be able to accept it. And once the data reaches the PI Data Archive, it can then be reached by various different PI clients. So at this point you might be wondering where do I install these different components? Well, you have a couple of different options. But what we recommend is to install the OPC DA Server and the PI Interface for OPC DA on the same node. This greatly facilitates the installation process. And it also reduces the points of failure, since both of these are on the same node. However, it is possible to install the OPC DA server and the PI Interface for OPC DA on different nodes. However, this will require an additional step of configuring DCOM security. This is important to keep in mind. So those of you who are a bit more familiar with the PI Interface for OPC DA, might recall that we also have the PI Interface for OPC HDA. And you might be wondering why you would use the PI Interface for OPC HDA or the PI Interface for OPC DA. Well, these are simply different protocols for different standards for the OPC standards. So as we know, DA stands for data access whereas HDA stands for historical data access. So an OPC server might be either OPC DA or OPC HDA compliant. So OPC DA means that the OPC server is going to be getting real-time data. So data that is going to be updating on a periodic basis. Whereas an OPC HDA server would have a bunch of historical or archived data. And the OPC HDA client would be getting all of this data at once and sending it to its data sync. The quick answer might be, if your OPC server is OPC DA compliant, then you would use the PI Interface for OPC DA. And if your OPC server is OPC HDA compliant, then you would use the PI Interface for OPC HDA. But a lot of OPC servers can actually be used for both OPC DA and OPC HDA. So a better answer would be, it depends what kind of data you want to collect. If you want to collect real-time data, so data that's going to be updating periodically, then you'll want to use the PI Interface for OPC DA. So next question, let's say we have a bunch of different OPC DA Servers. We have multiple OPC DA Servers. Do we need to install the PI Interface for OPC DA multiple times? No. All we need is a single PI Interface for OPC DA installation and we need to configure multiple instances of the PI Interface for OPC DA. To do that, we need the PI Interface Configuration Utility. And even if you only have the single OPC DA server, you'll need the PI Interface Configuration Utility. Since this is the GUI that's used to create instances of the PI Interface for OPC DA. And to configure them and to also to maintain them. So you'll need to install both of these components. OK, so we've gone over all of the basics. Now what are the steps that we are going to need to go through? So the first step is going to be to install the PI Interface for OPC DA and the PI Interface Configuration Utility. Next, we are going to need to make sure that our OPC server has a good status and it has data updating. And we'll do this using the PI OPC Client Tool which is installed when you install the PI Interface for OPC DA. Next, we'll want to configure a new instance of the PI Interface for OPC DA using the PI Interface Configuration Utility. Then we'll want to create PI points to collect data from the OPC server. And finally once we've done all of that, we need to make sure to configure buffering with the PI Buffer Subsystem to make sure that if ever, our PI Interface for OPC DA losing its connection with the PI Data Archive, it will be able to continue collecting data and buffer this data. So in the upcoming playlist, I'll be showing you how to complete all the steps required to start collecting data from an OPC Server. And once you've done that, you can check out our PI Buffer Subsystem playlist in order to learn how to configure buffering.

Definition

Similar to the automation of processes inside organizations, the automation of cross-organizational business processes is an important trend. In this endeavor, collaborating organizations rather strive for a loose coupling of their information systems instead of a tight integration: the collaborating information systems should be able to work together but retain as much independency as possible. This characteristic is also called interoperability, or in the context of collaborating organizations, Business Interoperability, i.e. the capability of autonomous organizations to execute a collaborative business process among them.

Information systems are systems that process information, i.e. they capture, transport, transform, store and offer information. Following the conception prevailing in information systems research, an information system comprises not only the hardware and software of an enterprise, but also the related human actors, business functions and processes as well as organization structures.^[2] This broad understanding is for example also embodied by the Zachman Framework.

Architecture is defined as the “fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”.^[3] Sinz defines an information system architecture as the building plan of an information system in the sense of a specification and documentation of its components and their relationships covering all relevant viewpoints as well as the constructions rules for the creation of the building plan.^[4]

Accordingly, an Architecture of Interoperable Information Systems can be defined as the building plan of a cross-organizational information system, which enables organizations to execute a collaborative business process among them.

Background and Application

Following the work on interoperable information systems conducted in European Research Projects^[5] in 2010 the Architecture of Interoperable Information Systems (AIOS) was published as a reference for the construction of loosely coupled, interoperating information systems and for the systematic, model-based enactment of collaborative business processes.

The AIOS aims primarily at large organizations that want to interoperate with each other. To this aim it describes how internal information system elements can be systematically connected with the information systems of collaboration partners. The main elements of the AIOS are:

Description of the different data types comprised in interoperable information system as well as their relationships. This is also called the static part, or the structure of the architecture. It tells organizations which information elements (e.g. descriptions of messages, exchange sequences, roles and services) they have to provide to collaboration partners and how they can optimally correlate these to internal elements.
Description of different building paths for implementing or adjusting interoperable information systems. This is also called the dynamic part of the architecture. It tells organization, how to iteratively develop the elements mentioned above.
Concept for the technical components needed to implement the architecture, for example design tools, internal and externally visible repositories.

One element comprised in the third category is a "BII-repository", in which each organization publishes the content of its Business Interoperability Interface (BII) to collaboration partners. Since it comprises external views on information system elements, it provides publishing and discovery functionalities as needed in service-oriented architecture: In the BII, the externally relevant processes, services, organization structures etc. are described on various levels of technical granularity, enabling other organizations to search also for business-level elements and not only for technical artifacts. Here, different from the traditional SOA approach, instead of one central service directory, various partner-specific repositories are implemented.

Structure

The static part of the architecture builds on three orthogonal axes: Enterprise Dimensions, Levels of technical Granularity and Collaborative Views.

Collaborative views

Similar to private, public and global views as known from business process and workflow modeling, in the AIOS, corresponding private, public and global views on information system elements are provided.

The private view comprises the only internally visible information system elements.
The public view acts as an interface to the internal, private system elements; it protects internal systems and enables interoperability without the need for a significant change to the internal systems. This public view describes the information system boundaries of an organization to its collaboration partners and connects internal and external information systems, thereby also providing the content of the Business Interoperability Interface of an organization.
The global view can be used to correlate and connect the public views of different systems.

Enterprise dimensions

To describe business processes comprehensively this axis provides distinct views on processes, functions, data, and organizational elements.

In the organizational dimension, roles, units and other organization elements relevant for the collaboration are described and related to internal elements. This ensures for example, that the collaboration partners have a common understanding of the interacting roles.
In the data dimension, document types used in the collaboration are defined and related to internally used document types.
In the function dimension, business functions and services offered in the collaboration are described.
In the process dimension, the processes that each organization offers are described as well as how these public processes are related to adjacent processes of partner organizations.

Thus, in combination with the axis "collaborative views", private, public and global views on processes, functions, data, and organizational roles are provided.

Levels of technical granularity

The description of system elements on different levels of technical granularity supports a systematic development of collaborative information systems, starting with the business requirements definition and going all the way down to the code level. Apart from the construction aspect, thereby also a multi-dimensional interoperability description is provided, facilitating the synchronization of collaborating systems on each level. Similar to for example ARIS and OMG's MDA three levels are used:

Business Level: Here the processes to be automated are described from a technique independent level. In MDA this level is referred to as CIM level.
Technical Level: Here the IT concept is described. Therefore, the models from the first level are technically enriched, for example, instead of business functions now components are described, but still on a coarse-grained, conceptual level. Since the models on the second level represent the basis for an automated generation of executable code, they might have to be further adapted to fit implementation level constraints.
Execution Level: Here the models are machine interpretable and can be used during runtime in the execution of processes.

References

^ Ziemann (2010): Architecture of Interoperable Information Systems - An enterprise Model-based Approach for Describing and Enacting Collaborative Business Processes. Logos, 2010. Logos was so kind to permit the free download of a copy here. A summary can be found here: Ziemann (2012): Architecture of Interoperable Information Systems - Reference Architecture for Collaborations between Public Administrations. In: Krallmann, H., Zapp, A. (Eds.): Bausteine einer vernetzten Verwaltung. Berlin, Erich Schmidt Verlag, 2012, pp. 165.
^ Compare for example Becker & Schütte (2004, p. 33): Handelsinformationssysteme – Domänenorientierte Einführung in die Wirtschaftsinformatik 2nd Edition, Redline Wirtschaft, Frankfurt or Gabriel(2008): Informationssystem. Enzyklopädie der Wirtschaftsinformatik, Online Lexikon. Oldenbourg Wissenschaftsverlag, Germany.
^ IEEE (2007): IEEE 1471 Website, IEEE Std. 1471 Frequently Asked Questions (FAQ) - Version 5.0, 19 July 2007. http://www.iso-architecture.org/ieee-1471/ieee-1471-faq.html Archived 2011-08-28 at the Wayback Machine, ac-cessed: May 2009
^ Sinz (2002): Architektur von Informationssystemen. In: Rechenberg, P., Pomberger, G. (eds.): Informatik-Handbuch. 3rd Edition, Hanser, München, pp. 1055-1068
^ Interop NOE (2004 to 2007, project number IST-2004-508011), ATHENA (2004 to 2007, “Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application”, project number IST-2004-507849) or R4eGov (2006 to 2009, project number IST-2004-026650)

This page was last edited on 1 April 2024, at 14:17

From Wikipedia, the free encyclopedia