Category Archives: OPC UA

OPC UA Makes Process Observer Archetype Possible

Integration

Usually modern manufacturing automation systems consist of numerous different IT systems located at business management/operation and process control levels. It is a broad class of application domains where business IT and control systems are converged to make a large whole with the aim of improving performance as a result of the macro optimization and synergy effect. This domain is called Industrial IT. Frequently the systems are distributed geographically among multi-division organizations.

To deploy the above-mentioned convergence the systems have to be integrated – they must interoperate. After integration the systems should make up a consistent system, i.e. each subsystem (as a component) must communicate with the others. The final information architecture is strongly dependent on organization, culture, type of technology and target industrial process. Communication is necessary for exchanging data for production state analysis, operation actions scheduling, supervisory control and task synchronization in the process as a large whole.

To make up a consistent system as an ultimate result of the integration process the following architectures can be applied:

  • Peer to peer: manually created point-to-point links to meet short-term ad hoc objectives.
  • All in one: a product dedicated to both functions: process control and business management.
  • Process Observer: a consistent, homogenous real-time representation of the process control layer.
Process Observer

Fig. 1 Process Observer Archetype

Process Observer (Fig. 1) is a kind of a virtual layer, which is a “big picture” of the underlying process layer composed of unit data randomly accessible by means of a unified and standardized interface. It allows the process and business management systems, using international standards of data exchange to share data from plant floor devices. Process Observer is like a bridge connection between the plant-floor control and the process and business management levels.

Thereby, the structure of the links becomes systematic and the existing functionality of the upper layers is preserved. Using the Process Observer archetype the number of links between components can be substantially reduced and, what is very important it is a linear function of the number of nodes.

Now, the links can be used to gather the process data in a unified, standardized way (see fig.2).

Process Observer archetype greatly reduces the whole complexity and decreases interdependence by decoupling application associations and underlying communication routes. Additionally, it allows applying systematic design methodology and building information architecture independently of the underlying communication infrastructure.

Process Observer Deployment

Implementation

The Process Observer concept has been implemented in the CommServer™ software family. That communication server is optimized for applications in distributed process control systems. To provide a consistent sole representation of a distributed real-time process at the upper layer boundary – according to the model – the CommServer™ has to implement unique functionality, provide redundancy and optimize utilization of underlying communication infrastructure.

CommServer-Process Observer Implementation

Fig 2. CommServer-Process Observer Implementation

Functionality

Communication

To meet scalability and open connectivity requirements, the CommServer™ exposes the OPC Unified Architecture (OPC UA) to be consumed by upper layer applications. One of the main objectives of using the OPC UA is to provide a uniform bridge between digital plant-floor devices and systems providing services at the process and business management level. At the very beginning, this bridge was invented as a translator between vendor specific languages (protocols) used by the devices for data access and a widely accepted one – OPC. Therefore, each OPC UA server has to be equipped with a vendor specific component called DataProvider that implements selected protocol and communication infrastructure management functions. Popularity of the OPC UA standard grows, but still many applications do not support it. For that reason, another member of the family, DataPorter™ offers SQL and XML connectivity (Fig 2).

Process Simulation

CommServer™ does not only play the role of a translator and communication engine. Offering the possibility of creating simulators and publishing simulation data in the same way as the process data, the final process representation can be complemented by directly unavailable information obtained by processing current and historical values. To commence factory approval tests of any system, we need to build a testing environment. Using simulators instead of communication drivers, it is possible to seamlessly switch between production and test environments reducing the cost by order of magnitude.

Resource Monitoring

In a production environment, monitoring and management of the recourses that make up the information processing and communication infrastructure is often of the same importance as access to the real time process data. CommServer™ allows for publishing data gathered from the active network devices in the same way as the process data.

Server to Server Interactions

It is a scenario using interactions in which one Server acts as a Client of another Server. In the presented architecture it is implemented using a dedicated OPC Classic or OPC UA DataProvider. Server to Server interactions allow for the development of servers that: exchange data with each other on a peer -to-peer or vertical hierarchy basis to offer redundancy, aggregation, concentration or layered data access management.

3 levels of redundancy

Using the Process Observer archetype with only one common component responsible for interconnecting plant floor devices and process and business managements systems creates a single point of failure. To overcome it and eliminate the risk the proposed solution offers tree levels of redundancy to increase availability. They can be applied independently according to an appropriate analysis and assessment of the risk.

  • Hardware: To provide true fault tolerant systems redundant hardware can be used. This solution provides the same processing capacity after a failure as before. We have two options: boxes and components redundancy. The first one is achieved by using a primary server and a backup server. We can also use fault-tolerant hardware designed from the ground by building multiples of all critical components, such as CPUs, memories, disks and power supplies into the same computer in order to ensure reliability. In the event one component fails, another takes over the communication without skipping a beat. The fact of switching from one server to the other should be transparent for the clients.
  • Communication paths: To increase availability the CommServer™ assures redundancy of “data transmission paths”. It is designed to recover from a communication path failure by detecting the failed route and switching to another one if available. Paths redundancy improves robustness, because the same remote unit can be reached using different physical layers to eliminate single point failure dependency. The server is responsible for the selection of a route to transfer the data and to control availability of inactive paths. Duplication of the communication paths may be costly, because data transfer over distributed networks is usually not for free. The crucial feature of paths redundancy is the provision of the path multiplication without the necessity of transferring the same data over the network many times and controlling backup path availability at the same time.
  • Signals: For reliability, this feature allows to define replicated signals. Thus, if one signal fails, a second one is available as one OPC tag. To determine whether a fault has occurred (fault detection) and which one signal is affected (fault isolation) two methods are available: source and statistical ones. Source detection relays on information about signal quality received from a plat floor device. Statistical methods use the confidence level as an interval estimate of a population parameter.

Optimal communication

Engaging of an intermediate component as a driver for plant-floor devices is a middleware archetype used worldwide in thousands of applications.
But to provide a consistent sole representation of a distributed real-time process at the upper layer boundary – according to the model – the CommServer™ has to implement
unique features optimizing utilization of the underlying communication infrastructure:

  • Multi-Protocol Capability: many protocols can be implemented as DataProvider components and plugged-in and utilized simultaneously;
  • Multi-Medium Capability: any physical layer technology can be used to start building a communication stack;
  • Multi-Channel Connectivity: numerous independent communication routes can be activated simultaneously to gather raw process data;
  • Adaptive Retry Algorithm: each protocol retries to acquire data after a communication error, but adapting the number of retries to current conditions allows to increase greatly the whole bandwidth;
  • Adaptive Sampling Algorithm: is responsible for adjusting the plant floor devices sampling rate according to the current process state;
  • Optimal Transfer Algorithm: is responsible for minimizing the difference between the individual process data update rate as required by clients and the current sampling rate of process control units.

Related articles

Advertisements

OPC UA Makes Complex Data Processing Possible

From the definition, the Industrial IT domain is an integrated set of ICT systems. System integration means the necessity of the information exchange between them (the nodes of a common domain). ICT systems are recognized as a typical measure of processing information. The main challenge of deploying an Industrial IT solution is that information is abstract – it is knowledge describing a situation in the selected environment, e.g. temperature in a boiler, a car speed, an account balance, etc. Unfortunately machines cannot be used to process abstraction. It is also impossible to transfer abstraction from one place to another.

Fortunately, there is a very simple solution to address that impossibility, namely the information must be represented as binary data. In consequence, we can usually use both ones as interchangeable terms while talking about ICT systems. Unfortunately, these terms must be distinguished in the context of further discussion on the complex data, because before stepping forward we must be aware of the fact that the same information could have many different but equivalent representations – different binary patterns. For example, having interconnected system A and system B, system A can use one representation, but system B another one. Moreover, to integrate them, the transferred stream of bits may not resemble any of the previous ones. It should be nothing new for us, as it is obvious that the same information written as a text in regional newspapers in English, German, Polish, etc. does not resemble one another.

To understand a newspaper we must learn the appropriate language. To understand the binary data we must have defined a data type – a description how to create an appropriate bits pattern. Simplifying, the data type determines a set of valid values and rules needed to assign the information (understand the data) to a selected bits pattern. Therefore, to make two systems interoperable, apart from communication, they should be prepared – integrated to be able to consume data from each other, and so communication is only a prerequisite for interoperability.

The type is usually not enough to make the data meaningful. Referring to the above example the newspaper name (i.e. the location where the information came from) and timestamp (a single point in time when the information was valid) are attributes of the text that is representation of the information.

To have a similar ability to add common attributes to the representations of many information entities at the same time the complex data types must be used. Complex in this context means that the data type must additionally define a relationship between the components of the binary data, i.e. how to selectively get a component of the complex data.

The OPC UA offers two well-known and widely used relationships:

  • Arrays – components are indexed and all components must have a common data type.
  • Structures – components are named and components may have different data types.

Anyway, indexes and names must be unambiguous, and a complex data type has the responsibility to provide a precise definition of them, i.e. selectors of the components.

The complex data has a very important feature, namely all components are considered to be consistent with one another. For example, if we need to represent time at least three components must be distinguished: hour, minute, and second. In this case, even if there is no need to add any attribute to the binary data it must be consistent, i.e. it has to represent information in a single point in time. Other criteria for describing the data consistency could also be applied.

On the other hand using complex data simplifies data integrity if there is a need to store or transfer it. If intermediaries are present, the initial data creator and the ultimate consumer need to trust those intermediaries to help provide end-to-end data integrity, because each hop is processed separately. Thus, using complex data it can be processed and transferred as one item what finally mitigates any risk of integrity compromising.

Using the data type definitions to describe information exposed by a server allows:

  • Development against type definition.
  • Unambiguous association of the information with the data.

Having defined types in advance, clients may provide dedicated functionality, e.g. displaying the information in the context of specific graphics.

Typical scenarios can be recognized when we can define appropriate complex data types in advance. The OPC UA offers a variety of standard types ready to be used in common cases. If this out of the box set is not capable of fulfilling more demanding needs users may define custom data types. The OPC UA allows servers to provide data type definitions. The type definitions may be abstract, and may be inherited by new types to reflect polymorphism. They may be of generic use or they may be application domain specific. Custom types must have a globally unique identifier, which can be used to identify the authoring organization responsible for that type definition.

If the data publisher – an OPC UA server is not running in an environment capable of creating the complex data there must be taken special precaution to fabricate it if required. An example of this scenario is a standalone OPC UA server pooling data from plant floor devices using a custom protocol, e.g. MODBUS. If that is the case the protocol used to gather process data is usually not data complex aware. Reading and writing the data is accomplished using REQUEST/RESPONSE frame pairs. Moreover, one request can be used to read a set of values that has the same simple type only. The fabrication is an operation that uses group of requests to gather components and embeds them into a single value of a selected complex data type. It is optional server capability.

Related articles

Continue reading

An opportunity for research projects in Poland to be refunded

I would like to announce that the Government of Poland and the European Union economically support entrepreneurs in developing their research and development activities (project budget could be refunded even up to 85%). Since the beginning of the financial perspective 2007-2013, Poland has become the largest recipient of support under Cohesion Policy in the history of the European Union. In the financial perspective 2014-2020 the support is expected to be even stronger – the expected budget €72.9bn. There are many programs planned with small and medium-sized enterprises as its main target with the priority focused among others on:

  • Research and development of modern technologies
  • R&D infrastructure
  • Capital for innovation
  • Investments in innovative undertakings
  • Diffusion of innovation
  • Polish economy on the international market

The programs very well suit the needs of further acceleration of adoption of the OPC Unified Architecture as innovative integration technology. On the grounds of my experience I have prepared a series of articles (an exploration catalog) on the new scope of applications where OPC UA shall be recognized as a prerequisite. All of them have the common title pattern “OPC UA Makes <it> Possible”. This set of examples is an attempt to define the target scope for new R&D infrastructure or innovative undertakings. I described this concept in the article titled OPC Unified Architecture: Enabler of Future Solutions.

Additionally, Polish industry seeks for new innovative solutions aimed at improving economy by optimizing process control. One of the examples is the project Smart Heat Distribution System for Warsaw. My team has provided the feasibility study for this solution. As far as I know the project will start soon and the concept will be implemented over a few next years. We are also currently working on implementation of the Smart Factory concept at Japan Tobacco International.

Concluding, I would like to inform that undertaking common business activities together with Polish companies could be very beneficial as the result of:

  • Very strong support of research innovative projects by refunding their budgets up to 85%
  • A ready to be implemented vision of the research activities with the goal of working on new innovative application areas having global applicability and potential profitability
  • Real industry enquiries to apply the result of research outcomes mentioned above

Do not miss this opportunity. Let benefit from the synergy effect together – you will be welcome to Poland. To get more and obtain a document containing answers to frequently asked questions send me your expressions of interest.

About Mariusz in the OPC Foundation:

Since 2004 Mariusz has been a member of the OPC Foundation. As publications author and member of working groups: Europe Technology Expert, Early Adopter, Analyzer Device Interface, Acceleration Adoption, Mariusz is involved in projects related to the development of the tools and the information model for Analytical Devices released as a companion specification.

Mariusz is a Country Representative for OPC Europe.

Mariusz Postol, Ph.D. Eng.

OPC UA Makes Highly Distributed Network Control Systems Possible

Integration

Nowadays, to be on edge, modern manufacturing automation systems have to be involved. Usually they consist of numerous different IT systems located at business management/operation and process control levels. It is broad class of applications domain where business IT and control systems are converged to make a large whole with the aim to improve performance as the result of the macro optimization and synergy effect. This domain is called Industrial IT. Frequently the systems are distributed geographically in multi-division organizations.

To deploy the mentioned above convergence the systems have to be integrated – must interoperate with each other. From integration we should expect improved performance as a result of synergy and macro optimization effects.

After integration the systems should make up a consistent system, i.e. each subsystem (as a component) must communicate with each others. The final information architecture is strongly dependent on organization, culture, type of technology and target process. Communication is necessary for exchanging data for production state analysis, operation actions scheduling, supervisory control and task synchronization in the process as a large whole.

Vast majority of enterprises declare that difficulties with the integration of the existing systems are the most important obstacle to expand the process control and business management support. Other major integration problems are diversification of the existing systems, their quantity and non-unified data architecture.

Integration process results in Large Scale Distributed Network Control Systems (LSDNCS). Systems belonging to this class are usually created in a multi-step integration process. To succeed, the process has to be governed by a well-defined information and communication architecture.

Integration Models

System integration means necessity of the information exchange. To exchange information we need an association between components. Going further, to instantiate association, i.e. to make the component interoperable, we need at the same time a common:

  • information representation –  a language (data type),
  • underlying communication infrastructure – a transport (protocol + medium),

We must be aware that establishing an association we are actually building information architecture – system structure. It is worth stressing that selection of the architecture development has a great impact on the final robustness, maintainability, expandability, dependability, functionality, and last but not least implementation costs.

Generally we have three possibilities:

Peer to peer approach: Common integration practice is to achieve short-term ad-hoc objectives by manually creating/proprietary dedicated point-to-point links between the subsystems everywhere it is useful (see fig. 1). Using randomly this approach we can establish numerous independent links ((k+n)(n+k-1)/2 where k, n – number of business and process control components appropriately). The number rapidly grows, e.g. it is equal 1770 links for n=10 ; k=50, and finally we have to deal with rapidly growing complexity leading to the communication chaos, which is difficult to be maintained.

In this model the information and communication architectures are closely coupled. This approach is very popular, but adversely affects all of the solution features.

Peer to peer approach

Fig. 1

Totalitarian approach: One option to overcome the communication chaos problem is to use an “all in one” product dedicated to both functions: process control and business management (see presentation). Usually, it is provided as one complex, total system – let’s call it a supper-system. Most of the MES (Manufacturing Execution System) vendors offer theirs products as a panacea for all problems of the chaotic system integration.

Actually supper-system does not solve the problem, it only hides it under a not transparent cover and makes the solution very difficult to expand and vendor related forever.

In this model the system distribution is reduced, and as a consequence many associations can be instantiated on the same platform without necessity to communicate. This model reduces complexity by reducing communication needs.

If strictly observed it could be a dead end.

Process Observer approach: The Process Observer is a consistent, homogenous real-time representation of the process control layer. It is a kind of the virtual layer, which is a “big picture” of the underlying process layer composed of unit data randomly accessible by means of a unified and standardized interface (see presentation). It allows sharing data from plant floor devices by the process and business management systems, using international standards of data exchange. Process Observer is like a bridge connection between the plant-floor control and the process and business management levels.

Thereby, the structure of the links becomes systematic and the existing functionality of the upper layers is preserved. Now, they can gather the process data in a unified, standardized way (see fig.2).

Using the Process Observer archetype the number of links between components can be substantially reduced and, what is very important is a linear function of the number of nodes.

Process Observer model greatly reduces the whole complexity and decrease dependency by decoupling application associations and underlying communication routes. Additionally, it allows applying systematic design methodology and building information architecture independently of underlying communication infrastructure.

Fig. 2

Fig. 2

Related articles

Real-Time Communication for Large Scale Distributed Control Systems (Proceedings of the International Multiconference on Computer Science and Information Technology pp. 849–859 ISSN 1896-7094)

Process and business layers robust integration (white paper)

Communication management in the Process Observer Archetype (Proceedings of the 16th conference “Polish Teletraffic Symposium 2009”)

Large Scale Distributed Process and Business Management Integration (Proceedings of the 14th International Congress of Cybernetics and Systems of WOSC)

OPC UA Makes Global Security Possible

One of the main goals of the OPC Unified Architecture is to provide a consistent mechanism for the integration of process control and management systems. Security is a fundamental aspect of computer systems, in particular those dedicated to enterprise and process management. In this kind of application, security must be robust and effective. Security infrastructure should also be flexible enough to support a variety of security policies required by different organizations. OPC UA may be deployed in diverse environments – from clients and servers residing on the same hosts, throughout hosts located on the same operation network protected by the security boundary protections that separate the operation network from external connections, up to applications running in global environments using also Internet as a public network to establish interoperability. Depending on the environment and application requirements, the communication services must provide different protections measures to make the solution secure, therefore OPC UA specification must offer scalability.

We can observe rapid development of globally scoped applications for domains like health, banking, safety, etc. The globalization process is also observed in control engineering. The secure transfer of process control data over the Internet must, therefore, be addressed as the most important prerequisite of this kind of applications.

OPC UA Security is concerned with the authentication of clients and servers, the authorization of users, the integrity and confidentiality of their communications and the auditing of client-server interactions. To meet this goal, security is integrated into all aspects of the design and implementation of OPC UA Servers and Clients. The OPC Foundation has also addressed the security issues that arise from implementation. This includes independent reviews of all aspects of security starting from the design of in-depth security provided by the specification (which is built and modeled on the WS* specifications) to the actual implementation provided by the OPC Foundation. The OPC Foundation has chosen to use industry standard security algorithms and industry standard security libraries to implement OPC UA Security (see the OPC UA eBook).

Security is a “collaboration” of technology and rules describing how to apply this technology to improve protection of a system/network against malicious users. To deploy security the following functionality must be provided:

  • Authentication – to identify users and software;
  • Authorization – to limit the activity to that granted to the user or application;
  • Data integrity – to protect the data from being corrupted;
  • Data encryption – to protect information from being accessed by any unauthorized user or application;
  • Digital signature – to determine the data source.

From the list above we can conclude that authentication is a basic component that decides about the quality and robustness of security. Authentication is a process of recognition and confirmation of the identity of someone or something. It is used not only for deploying security. For example applications (including operating systems) use authentication to determine the execution context.

Generally speaking, authentication can be done on the basis of:

  • something you must know
  • something you must have

Username and password is something you know and must keep secrete (at least the password, but it is recommended both).

A certificate is an example of something you must have – no secret information is contained therein. Any certificate is a digitally signed record of identification data.

To use knowledge for authentication you must distribute it (distribute secret) everywhere the identity is confirmed (e.g. hundred of services use credentials to define the execution context).

The certificate is confirmed by the certificate issuer, i.e. Certificate Authority (CA). It is one single point where it is verified and, therefore, it is much easier to protect authentication process against abusing it. We must keep this fact in mind when considering whether use or neglect Public Key Infrastructure (PKI), which is all about issuing, distributing, using, and revoking of certificates.

To summarize, using PKI we can benefit from two very important capabilities offered by it:

  • Certificates may be distributed without limits; on the other hand it is almost impossible to      control distribution propagation of secret knowledge as there is no evidence of its existence;
  • It is much easier to control the validation process of something if it is not distributed over      many places.

Security mechanisms can be provided by diverse communication layers. Transport-level security is a solution limited to point-to-point messaging. In this case messages can be protected by establishing a secure connection (association) between two hosts using for example Transport Layer Security (TLS) or IPSec protocols. But, if intermediaries are present when using a secure transport, the initial sender and the ultimate receiver need to trust those intermediaries to help provide end-to-end security, because each hop is secured separately. In addition, to explicit trust of all intermediaries, other risks such as local storage of messages and the potential for an intermediary to be compromised must be considered. Thus, using only transport security limits the richness of the security solution to transport-specific features. OPC UA is a session centric communication. Hence, a security association must survive beyond a single transport connection.

To meet the above requirements, the OPC UA security architecture is defined as a generic solution that allows implementation of the required security features at various places in the application architecture. The OPC UA security architecture is structured in an application layer and a communication layer atop the transport layer.

The routine work of a client application and a server application to transmit plant information, settings, and commands is done in a session in the application layer. The application layer also manages user authentication and user authorization. OPC UA Client and Server applications identify and authenticate themselves with X.509 Certificates. Clients pass a user identity token to the OPC UA Server. The OPC UA Server authenticates the user token. Applications accept tokens in any of the following three forms: username/password, an X.509v3 certificate or a WS-SecurityToken.

A session in the application layer communicates over a secure channel that is created in the communication layer and relies upon it for secure communication. All of the session data is passed to the communication layer for further processing. The secure channel is responsible for messages integrity, confidentiality and applications authentication.

OPC UA uses symmetric and asymmetric encryption to protect confidentiality as a security objective. OPC UA relies upon the site cyber security management system to protect confidentiality on the network and system infrastructure, and utilizes the Public Key Infrastructure to manage keys used for symmetric and asymmetric encryption. OPC UA uses symmetric and asymmetric signatures to address integrity as a security objective.

More readings:

OPC UA vs OPC Classic -Security and Communication comparison
http://www.isssource.com/

OPC Unified Architecture: Enabler of Future Solutions

Introduction

Talking about acceptance and adoption of OPC Unified Architecture we usually focused on uniqueness and remarkable features of this standard with the goal of sending the message: “OPC UA is the best interoperability standard – it is much better then other classic solutions ever available” to the community.  Additionally, we are sending (circulating) this message over and over to other members of our close OPC UA community. My concern is if it is an effective approach because it looks like “the old shoes syndrome” – it is not enough to buy new ones only because there are much better new ones. We should rather say “don’t use your old shoes while jumping onto your windsurfing board only because they are comfortable – it is not very sensible”. On the grounds of my personal experience I am trying to imagine new unexplored yet fields of potential applications of the OPC UA. It is obvious that their number is uncountable, therefore a selection key must be applied. To follow the idea from the introduction above the “ENABLER” seems to be most appropriate to flag the technology, solution, application, model, approach, etc. that OPC UA makes possible.

The Exploration Catalog

To make my dreaming more useful for others, my first attempt is to prepare a series of short articles (a catalog) on new application scopes where OPC UA could be recognized as a prerequisite. All of them have a common title pattern “OPC UA Makes it Possible”. Today the catalog consists of:

  • OPC UA Makes Process Observer Archetype Possible: Process Observer is a kind of a virtual layer, which is a “big picture” of the underlying process layer composed of unit data randomly accessible by means of a unified and standardized interface. It allows the process and business management systems, using international standards of data exchange to share data from plant floor devices. Process Observer is like a bridge connection between the plant-floor control and the process and business management levels.
  • OPC UA Makes Complex Data Access Possible: The Industrial IT domain is an integrated set of ICT systems. System integration means the necessity of the information exchange between them (the nodes of a common domain). ICT systems are recognized as a typical measure of processing information. The main challenge of deploying an Industrial IT solution is that information is abstract – it is knowledge describing a situation in the selected environment, e.g. temperature in a boiler, a car speed, an account balance, etc. Unfortunately machines cannot be used to process abstraction. It is also impossible to transfer abstraction from one place to another.
  • OPC UA Makes Highly Distributed Network Control Systems Possible: Nowadays, modern manufacturing automation systems have to be involved. Usually they consist of numerous different IT systems located at business management/operation and process control levels. To deploy the convergence the systems have to be integrated – must interoperate with each other. From integration we should expect improved performance as a result of synergy and macro optimization effects.
  • OPC UA Makes Global Security Possible: We can observe rapid development of globally scoped applications for domains like health, banking, safety, etc. The globalization process is also observed in control engineering. The secure transfer of process control data over the Internet must, therefore, be addressed as the most important prerequisite of this kind of applications.
  • OPC UA Makes Cloud Computing Possible: Cloud Computing is defined as a method to provide requested functionality as a set of services. Following the Cloud Computing idea and offering control systems as a service, there is required a mechanism created on the service concept and supported abstraction and virtualization – two main pillars of the Cloud Computing paradigm.
  • OPC UA Makes Smart Factory Possible: In this case  “collaboration” is the key word. Analyzing the collaboration needs of the smart factory we must distinguish two dissimilar targets surrounding the factory: humans and applications. To make this collaboration well-defined in the information exchange and behavioral aspects, the collaboration platforms (e.g. SharePoint) and integration measures (OPC UA) must be integrated.
  • OPC UA Makes Smart User Interface Possible: It introduces a concept of semantic HMI that is an approach to relay the interface on discovering the meaning of process data using the metadata provided by plant floor measurement and control devices. Additionally, network-connected HMI needs special security precautions to be applied.
  • OPC UA Makes Production Traceability Possible: To use analyzers and track selected product and its ingredients parameters, complex data must be managed, i.e. created, transmitted, processed, and saved. To be useful, process data must be exposed in the context of well know semantics represented by the metadata.
  • OPC UA Makes Smart Utility Distribution Systems Possible: Following the concept of smart grids, more and more companies decide to start working on smart utility distribution systems (gas, water, chilly water, or even oil) to improve the performance and availability. The process is dispersed geographically and partially managed by independent operators. An active role of ultimate consumer is very important.

All the articles above are OPC UA related. For those looking for more information about this interoperability standard there are two articles providing very basic information, I hope, helping to follow the main topics.

  • OPC UA – Specifications: OPC Unified Architecture is described in a layered set of specifications issued by the OPC Foundation, that are broken into parts. It is purposely described in abstract terms and only in selected parts coupled (mapped) to existing technology on which software can be built. This layering is intentional and helps isolate changes in OPC UA from changes in the technology used to implement it.
  • OPC Unified Architecture: Main Technological Features: It focuses on new features of this interoperability standard including: service oriented architecture, object-oriented information model, abstraction and mapping, security, profiles, robustness.

Looking for the new application scope of OPC UA we must face up to managing team work aimed at exploring new undiscovered areas. On the grounds of experience gained while managing variety of innovative process control and business management projects I can say that their scope definition and budget estimation is always the most challenging task. Typically, if the estimated budget of any project is higher than the other ones, the solution provider is recognized as inefficient in one way or another. But there might be another reason if innovative projects are concerned, i.e. the provider’s know-how and extraordinary experience make a better assessment possible. Better always means higher in this context, so typically it puts the solution provider in an underprivileged position and leads to the “more stupid the better” issue. For an innovative project, the main reason why its critical parameters are hardly predictable is its innovative nature. From the definition, an innovation as a translation of an idea or invention into a product or service that creates value is an exploration into unexplored areas. The leader of the team must, therefore, face up to a high level of uncertainty. The following article provides some insights and a proposal with the goal of mitigating this issue.

  • Embedding Agile Principles as Contract Rules: It proposes a methodology framework that tightly couples agile management (to dynamically control the work scope and time framework) to workload tracking with the goal of maximizing the value for money.

Conclusion

To bring the presented ideas into solutions, more work is required with the aim of preparing comprehensive guidance collecting all that is needed to help deploy them in a real environment. Before trying to figure out what should be done to step forward, the audience of the outcome must be determined. Thus we should address the following needs:

  • For end users – adding solutions to requirements, but limited to feasible ones only
  • For integrators – adding solutions to portfolio, but limited to confirmed ones only
  • For vendors – adding features to products, but limited to required ones only

To create a foundation supporting deployment of the technology in new areas, the effort should be focused on:

  • Feasibilities studies: aimed at describing architecture (re-usable templates) as an interconnection of products making up a structure, product features required to interconnect them in a consistent way, business processes surrounding the solution in question, cost estimation, and solution profitability.
  • Pilot applications: aimed at providing proof of concept and “how to …” cookbook.
  • Best practice guidance: to maintain the quality and minimize application risks.

All the activities on the wish list above require an appropriate business model to happen, but this topic is outside this article scope. Good news is that governments and European Union support innovative projects in some countries, e.g. Poland, making the research and development much cheaper (up to 85% might be refunded). Since the beginning of the financial perspective 2007-2013, Poland has become the largest recipient of support under Cohesion Policy in the history of the European Union. In the financial perspective 2014-2020 the support is expected to be even greater. There are many programs planned with small and medium-sized enterprises as main targets with the priority focused among others on:

  • Research and development of modern technologies
  •  R&D infrastructure
  • Capital for innovation
  • Investments in innovative undertakings
  • Diffusion of innovation
  • Polish economy on the international market

Do not miss this opportunity – you will be welcomed to Poland.

OPC UA Makes Smart User Interface Possible

Modern control systems much appreciate the graphical user interfaces. “A picture is worth a thousand words”, but it seems that the future of Human Machine Interfaces in automation is far beyond that.

As opposed to the SCADA term, a lightweight local user interface of a machine is sometimes referred to as the human-machine interface (HMI) – in this context it is an embedded part of the machine. SCADA, on the other hand, is an all in one software package that consists of tightly coupled components implementing functionality to operate a system as a whole. It is worth noting that in spite of application kind this interface is a place where an interaction between someone responsible for making a decision and something responsible for the decision execution occurs. This post address the question what are the consequences if this interface is used, for example, to start drilling by a CNC machine, in one case, or alternatively to start moving remotely say load of 200MW from one power plant to another one in other case. After all, in both cases the operation can be initiated by pressing a virtual “ACCEPT” button on a touch screen. However, is it a sufficient reason to call this interface as an HMI device in both cases, and what is more important, can we use the same or similar solutions in all circumstances to decrease development and deployment costs?

In any cases, while interacting with a machine or with a system finely we operate a process. To operate effectively we must fulfill the following requirements:

  • Provide a representation of the process behavior and its current state – output interface;
  • Provide sensors to allow entering the operator decision – input interface;

The vendors of modern solutions – that meet highly demanded customer expectation – for this purpose employ 3D graphic, touch screen, voice recognition, motion tracking and many others technologies. However, communication with the user is only one aspect that we must focus on. To recognize others we have to look under the cover.

Automated processes are dynamic and stateful, so the interface has to provide an informative context for decision making. To reach this goal the process behavior must be tracked all the time by processing its variables to optimally adjust the screen content and expose the most important elements in an instant of time. Once there are more and more process variables within the automation systems, one has to choose, how to organize the structure of control system and mappings with the visualization purposes. Each variable can be recognized as a set of attributes: value, quality, timestamp and meaning. First tree attributes can be simply expressed as simple (primitive) or complex numbers and bind to the graphic on the screen in a generic way. The fourth (meaning) attribute is usually assumed that it does not change over the time, and therefore the interface behavior and appearance is designed (hard-coded) to express it in a communicative way. For example, we can distinguish a selected part of the screen to allow operator communicate with a chromatograph analyzer in a pharmacy automation process.

Unfortunately, this design time approach is often too rigid to seamlessly adapt for example exchange of the device by a new one from another vendor. Furthermore, hard-coded approach is useless when we must deal with multifunction devices that use pluggable components and variety of accessories. To avoid this unnecessary design cost and avoid proprietary solutions we need a next generation solution that can be called “Semantic HMI”. Semantic HMI is an approach that relays on discovering the meaning of process variables using the meta-data provided by the plant floor measurement and control devices, like analyzer, PLC, DCS, etc. In this approach the meta-data must be provided as a context for the real-time process data and processed simultaneously by a smart enough semantic HMI.

OPC Unified Architecture technology meets all the requirements, because:

  • It is a platform neutral standard allowing easy embedded implementation
  • It is designed to support complex data types and object models.
  • It is designed to achieve high speed data transfers using efficient binary protocols.
  • It has broad industry support beyond just process automation and is being used in support of other industry standards such as S95, S88, EDDL, MIMOSA, OAGiS.

Connection between HMI, as the decision entrance device, and process control device, as the decision execution device, may engage many technologies (e.g. RS232 serial bus located inside the box containing both, Internet, wireless connection, etc …). Unfortunately, vulnerability of the communication medium is only one measure of the security issues severity. Directly related decision cost and its consequence makes together another measure that must scale the required security robustness. In other words, without authentication of the transferred data, data sources and users we cannot expect and rely on the responsibility. Even in the completely shielded control room of a nuclear power plant, at the end of the day we must know who is responsible for pressing the virtual “ACCEPT” button if any problems occur. On the other hand, can you imagine a message on the screen saying “you must login to continue…” in a really critical situation in places like that.

There are more and more modern solutions of HMIs: advanced graphics, with high resolutions and touch screen, high IPs for front panels, faster CPUs, integration with modern operating systems, etc. However, they must offer much more to be used as a decision entrance device in applications like process control of municipal-wide heat distribution network located in the city of Lodz Poland (750k citizens), supplied from three plants with total thermal output power of 2560MW producing hot water distributed using ~800km of pipes interconnected by ~8000 nodes. In application like that, the most important features are openness to be seamlessly pluggable, visualization flexibility to expose process data in the context of process metadata, and appropriate security precaution to provide selective availability to control functions. It seems that using new standards, like OPC UA and new technologies, mentioned above could cause synergy effect leading to reusable on-the-shelf products withstanding even most demanded requirements.