New ways of communication

Figure 2: The new communication within a modern production line

© PLCopen

Mapping the OPC UA information model to the PLCopen/IEC 61131-3 software model results in a uniform 'look and feel' of the OPC UA server technology, even on different controllers. This is the basis for 'out-of-the-box' communication, which can also include safety. Users can also link a template in the HMI with the applicable data (structure) in the controllers, regardless of brand, provided they support PLCopen OPC UA mapping. An example of these naming conventions are the PackTags and the state machine, as defined in the OMAC-for-Packaging specification PackML as part of the "ISA 88 Technical Report on Machine and Unit States". By consistently applying these conventions, a controller can be integrated 'out-of-the-box' into the PLCopen environment via the OPC UA client mapping.

The client contained in the controller can be used to initiate communication at the lower level and completely new hierarchies and architectures can be created. Controller-controller communication is also easy to implement, regardless of the communication architecture used. This makes it possible to initiate a new controller architecture in which communication follows the various phases of product completion(Fig. 2).

Figure 3: Extended client-server communication

© PLCopen

For example, if a controller sets a certain speed for a transport system (such as a conveyor belt) on which a product is moving that needs to be picked up by a robot arm. The controller can make a method call to the robot controller to pick up the product and transfer the speed of the belt at the same time. The robot, in turn, can make a method call to the intelligent camera to obtain the rotation and translation values of the product. With these values, the robot can calculate the trajectory to pick up the product smoothly and correctly. The controller can also initiate communication with the ERP/MES system to query recipe information and for product tracking(Fig. 3).

Figure 4: An Industry 4.0 scenario that can already be implemented today.

© PLCopen

This opens up completely new possibilities. For example, communication can also be initiated at the lowest level - by a sensor, for example. This means that a product (such as a yoghurt pot) can have an RFID that contains all the relevant information for its production. This information can be read by the control system and the various work stations can perform the corresponding actions, such as adding 98 grams of yogurt at the first station. At the end, the check station can write back the checked actions and initiate a method call to the ERP system to deliver the results of the processing to the track and trace system - even if this may be outsourced to a cloud. These are all communication features that can already be implemented today(Figure 4).

Industry 4.0 - AAS and PLCopen

Figure 5: The AAS can ...

© PLCopen

... build on each other.

© PLCopen

An important new concept for production machines in the digital age is defined by the Asset Administration Shell (AAS for short) in Industry 4.0. In future, every plant, machine or component must be equipped with an AAS in order to be 'I.4.0 ready'. In the case of a machine, the AAS - as perceived from another higher-level instance (the cloud) - should be the start page or resource directory that lists all the services that the machine can provide.

The basic idea of the I4.0 components: Each Industrie 4.0 asset should have an Asset Administration Shell (AAS) that contains a minimal but sufficient description according to Industrie 4.0 use cases. Asset administration thus consists of a series of 'sub-models'. These represent different aspects of the asset in question; for example, they can contain a description of safety, but also describe different process capabilities such as movement or synchronization. In this way, a machine (the 'asset') can be viewed as being constructed from different subsets, which in turn represent assets(Figure 5).

Figure 6: Example admin shell function block

© PLCopen

Broken down to a real system, this could look as follows: At the lowest level, there is a combination of the drive and motor assets with an encoder, which are linked to the functionalities defined in PLCopen Motion Control such as MC_Move_Absolute and MC_Power. At the next higher level, several of these combined assets are combined again and another asset - such as a controller - is added. In this case, functionalities such as synchronization between the axes or even a virtual axis can be added. At the next level up, the asset represents the machine, including the application software that runs in the controller. Safety aspects can also be taken into account in this way.

Figure 8: The exemplary instantiation of properties

© PLCopen

In order to access the AAS, PLCopen is working with its members to define a series of function blocks. At the top level, this could look like this, for example: The 'AasTypeId' refers to the identifier of a type-specific administration shell(Figure 6). By describing such an AAS, the system integrator or machine builder can describe a series of machines and specify which submodels and information are implemented by each machine in the series. The attribute can be left empty if no such description is available. The 'AasInstanceId' can be used to specify an instance ID for the AAS. The implementer should ensure that each individual machine is provided with a unique ID. The 'AssetId1' refers to the serialized ID of the machine, production station or similar. As with the 'AasInstanceId', it is necessary to ensure individuality on the one hand, but also simple implementation on the other.

The information and also the functionalities of an AAS are organized in 'submodels'. The content of a submodel can be standardized by Industrie 4.0 or freely introduced by a system integrator. Many submodels can be managed by the AAS(Figure 7).

At the next level, function blocks are proposed for properties of different data types (Boolean, DateTime, Enumerations, Integers, Real numbers, Strings). Each of these blocks has almost the same attributes(Fig. 8).

Industry 4.0, AAS and PackML

Figure 9: Models such as PackML in the AAS will help to combine IT and OT engineering expertise.

© PLCopen

Automation information models that have been tried and tested in production can serve as sub-models. One of these models is PackML, which defines machine operation, a standardized human-machine interface and predefined OEE (Overall Equipment Efficiency) key figures. A PackML submodel can be used as part of the AAS for a semantic model of machine behavior(Figure 9).

PLCopen, PackML and OPC UA

The standardization of machine information models is a key element when it comes to machine interoperability and connectivity. It is important to agree on a valid model of internal control software to ensure the efficiency and scalability of machine code programming. For more than 25 years, PLCopen, as an independent association of technology providers, has been working on these principles and actively promoting the IEC 61131-3 programming standards. PLCopen has also worked to introduce the use of IEC 61131-3 as the programming basis for the creation of ANSI/ISA-TR88.00, 'Machine and Aggregate States'.

Figure 10: Software layers and PLCopen encapsulation levels

© PLCopen

In turn, the OMAC (Organization for Machine Automation and Control), which brings together various stakeholders such as OEMs, system integrators, technology suppliers and end users, has successfully promoted and established the PackML name worldwide, with a particular focus on the packaging machinery market. Everyone who uses PackML knows that these standards and guidelines are applicable to every single production machine.

In terms of interoperability and software efficiency, a modern 'open' packaging machine is now based on a layer of scalable software based on the principles promoted by PLCopen and OMAC-PackML. This relationship can be described as a multi-layered solution(Figure 10).

PLCopen-standardized function blocks - placed at Level 1 - provide platform-independent reliability and industry-specific know-how as a solid foundation for the control pyramid. These proven APIs are essential for the development of sustainable, reliable and distributable machine control software. At levels 2 and 3, vendors, system integrators, OEMs and users are encouraged to write and maintain their own application libraries and tools. In this way, competitive innovation and product differentiation can be realized and intellectual property protection ensured - the OEM's intellectual property is encapsulated and protected at this level.

By calling higher-level function blocks, programs can be executed efficiently at level 4. At the top level 5, PackML appears as a higher level of control, offering standardized machine states and operations, Overall Equipment Effectiveness (OEE) KPIs, Root Cause Analysis (RCA), flexible recipe schemes and common SCADA or MES inputs. All of these possible interactions with the human operator have been well defined and refined over the years in many production scenarios around the globe.

Both PLCopen and OMAC have worked with the OPC Foundation to bring their respective models into the OPC UA address space. Among other things, the IEC-61131-3 software model has been mapped to an OPC UA information model, which enables the creation of complex data structures such as a PackML Unit Control Data Structure.

OPC UA also allows automatic detection and exploration of servers and their complex data structures. This means that if the client-server installation were to use PLCopen and PackML, these machine types would have the same information model and could understand each other almost automatically. An OPC UA client could explore the available PackML partners and search for the desired 'PackML services'.

Author:
Eelco van der Wal is Managing Director of PLCopen e.V..