We have seen a flood of innovations in the field of digitization in recent years. The one with by far the greatest impact is the OPC UA communication technology. After years of proprietary fieldbus communication, the way is now clear for the seamless connection of different machines and production networks in the world of information technology.
If we think back about a decade, it was only possible to read out any machine data with increased effort. There was still no talk of networking machines and systems on a large scale. But with the changed requirements for the production networks, the requirements of each individual machine have also changed. What has changed?
Today every machine, every product is automated in some way.
Set-up times as non-value-adding activities disrupt the flow of production more than ever.
Mass production gives way to individual product design with a quantity of "1".
Remote maintenance is the non-plus-ultra that should not be missing for the sustainable operation of the system.
The motto is: make performance measurable in order to survive in global competition
Today everyone is talking about OPC UA. But what exactly is behind it? How can you implement OPC UA and incorporate it into the automation of the machine? And are there best practice approaches?
Hardware becomes a commodity; but the manufacturers remain proprietary when it comes to software
All leading manufacturers of components for industrial automation today offer the availability of OPC UA. It belongs to the new standard to enable interoperability and communication in the sense of Industry 4.0. This makes hardware a commodity today - features for differentiating between manufacturers can only be made out insignificantly.
A horizontal and also vertical networking is therefore a prerequisite - but at the end of the day, a consistent engineering solution is also necessary. But due to the different hardware manufacturers, there are also different engineering platforms - not much has happened here with regard to an open source approach. It is inevitable for the customer to use paid access to work in one of the engineering platforms.
In addition, the platforms themselves are disappointing in that they have so far only insufficiently opened up to the IT world. The majority of them are primarily characterized by their performance in industrial automation (OT). They offer few features to serve the IT aspects of modern Industry 4.0 solutions. But more on that later.
The essential aspects of OPC UA: asset administration shell, security, semantic self-description
One thing becomes immediately clear - OPC UA offers more than just seamless communication between network partners and is therefore not considered a "technology" for nothing. With meta information on each data point or on the machine itself, OPC UA gives you much greater opportunities to share details in a smart network. Above all the so-called administration shell.
The administration shell is the digital image of an object and provides the interface for I4.0 communication. The goal is to describe the asset minimally but adequately over its life cycle. Content-related, descriptive or functional aspects are described in partial models. These can be, for example, aspects such as identification, security, energy management or various process capabilities such as drilling. In the case of intelligent products, the asset administration shell can be part of the asset; in the case of non-intelligent products, it can only be located in a cloud application or on an edge component.
For the secure exchange of data, OPC UA offers comprehensive security features, which is not the last thing an optimal prerequisite for the horizontal and vertical. The security features are mapped on the "Application Layer" and "Transport Layer" levels.
There are several security mechanisms at the application layer. The user can be identified by a username / password combination or a user certificate.
On the transport layer, TLS (Transport Layer Security) makes data exchange secure. WS Secure Conversation is used for web services to ensure compatibility with .NET and other SOAP implementations. For the binary variant, the so-called UA Secure Conversation is used. The authentication uses only x509 certificates.
In semantic self-description, there is a distinction between "objects", "variables", "methods" and "events". What this means can be seen quickly using a specific example. For example, the following information can be exchanged at the interface of a robot: "I am a robot (object), with tools (variables) for turning and welding (methods) and am currently welding (events)." Every other network participant immediately recognizes the type and status of a machine.
In the extension, the semantic self-description is then further standardized by means of a companion sepcification. Machine manufacturers and industrial associations have agreed to standardize the type of semantic self-description via the OPC Foundation. Uniform specifications are already available for the area of machine tools and plastics processing machines.
The challenges in engineering
As plausible as the individual features mentioned above are - they also need appropriate engineering to implement them. However, inadequate standardization and commenting in the programming often lead to time-consuming research. You can only meet this dilemma if you choose the right strategic path for OPC UA. Last but not least, the strategic approach can also be linked with possible future business field developments.
A question to consider in this context: What are customers asking for? Can the aftermarket service generate added value in maintenance and repair through an interface? How can I provide additional features on the machine?
The introduction of a new information system requires not only an overarching objective but also suitable detailing and subdivision. The basic dimensions are: the concept, the interfaces, the productivity, the future security and the costs of the solution. One possibility for orientation is provided by so-called user stories, i.e. a requirements analysis based specifically on customer needs.
Edge IoT: solutions for implementation
Precisely because customers often want the opportunity to work with a machine interface themselves, direct access to the control, the heart of every machine, does not make sense. In order to prevent damage caused by insufficient knowledge of the machine, it is advisable to set up an Edge IoT solution. This is how I separate real-time automation (OT) with that of IT networking. Such a solution is user-friendly and can also be developed into a comprehensive administration platform in just a few steps using intuitive GUIs.
Two approaches that stand for a different form of this solution architecture and are available via the Lean.IQ marketplace:
Thin Edge: A simply designed edge client runs on a gateway on the machine. This can be managed individually by a cloud platform and gives immediate access to all relevant data. Simplified logic can be taken into account as well as the interval with which the data is made available.
Edge software framework: If there are greater requirements for data preprocessing or possibly also visualization on the machine, an extensive software framework offers numerous design options. Especially if no internet connection can be provided for the machine, there is also the possibility of providing additional features. In interaction with a cloud platform, these features can also complement each other.
In both cases, in the Lean.IQ approach, we attached great importance to an open source approach. In addition, we also ensure that we can map all of the requirements of OPC UA. In particular, the Edge Software Framework offers a comprehensive toolset for mapping any Companion Specifications - an information model can be put together in a short time using a no-code approach.