The Industry 4.0 concept includes intelligent equipment that enables a fully digitalized and highly flexible production process in manufacturing and assembly using a wide range of sensors and communication technologies. This is expressed in terms such as 'batch size 1' or 'one-piece flow'. This refers to products that can be configured in a highly customized manner and where the customer can still influence the order and make changes for as long as possible. This demand for maximum flexibility can only be realized through sophisticated variant and configuration management on the product development side.

The Y model according to Scheer: The demand for individualization can be found in all areas. Anyone who wants to manufacture customized products in the 'factory' process area must also apply this standard of flexibility to product development.

© XPLM

It is worth taking a look at company processes. Professor Scheer from Saarbrücken shows the connections between production/assembly, order processing and product development in his Y-model. It describes the two main process chains in an industrial company. The business process chain on the left and the technical process chain on the right. Three process areas can also be identified:

• The factory process area, around which much of the German discussion on I4.0 revolves.
• The product development process area, where product data is managed using PLM systems.
• The logistics process area, where orders are processed and supply chain data is managed.

In contrast to the logistics process area, where a high degree of end-to-end information flows and data consistency is achieved with sophisticated ERP systems, the product development area is characterized by a large number of isolated solutions in terms of the tools and processes used. Each engineering discipline has its own product models and development methods. These are referred to as discipline-specific models: Mechanical CAD systems for the design engineer, electrical/electronic CAD systems in electrical engineering or Application Lifecycle Management (ALM) applications in software development.

There is a lack of a comprehensible model of the product to be developed on which everyone can work together. If product development is divided into an early and a late phase, CAD models, for example, are classified in the late phase. An exchange between the disciplines is often no longer possible in the late phase, as there are no common models, let alone common vocabulary to describe (partial) products. This not only affects the speed with which a product can be brought to market, but also its quality.

System engineering

The integrated system model: The system model is the 'glue', so to speak, that holds the discipline-specific models together - the sum of the system model and discipline-specific models can be described as an integrated system model.

© XPLM

Model Based Systems Engineering (MBSE) provides a remedy. Here, machine-readable models are used instead of documents - with the advantage that individual pieces of information can also be addressed individually. This makes it possible to create a system model that allows you to link your own information content with discipline-specific models from later phases of product development and keep it consistent. Information from the integrated system model of product development can be used and synchronized for much later phases of the product life cycle. In this way, information between product and production system development can be structured and exchanged in a machine-readable form at a very early stage.

Modelling languages that allow formalized, machine-readable modelling are used to model a system model. These are usually languages with graphical notation that allow the engineer intuitive access to the system model. One example of this is the Systems Modeling Language (SysML) standardized by the Object Management Group (OMG), which is based on the Unified Modeling Language (UML) known from software development. The creation of a system model of the product to be developed makes an important contribution to the necessary digitalization in the company. MBSE tools that are now available support engineers in creating a system model - however, these tools lack any process support. This means that there is neither sophisticated version control nor practical support for collaborative work on a system model.

The role of the PLM system

This is where PLM systems come into play, as they have been supporting precisely this for many years. In order for PLM systems to support the management of data originating from the MBSE, they must be able to map other interdisciplinary data on the requirements and behavior of the system in addition to pure structural data. The main objective pursued with PLM systems in this respect: To establish the traceability and transparency of all decisions about the development process as well as the entire life cycle. This guarantees the traceability of valid combinations of requirements, functional descriptions and physical components at all times. In the operational phase, the data from the field and the current configuration of the system are important. Although the idea of the integrated system model originates from product development, the information it contains is relevant for all phases of the product life cycle.

One obvious use of the integrated system model is to generate a digital image for each unit to be produced. This is often referred to as a digital twin. The concept of the digital twin comes very close to what is described as a virtual representation in the Industry 4.0 implementation strategy. Together with the technical functionality, the virtual representation forms the administration shell. This administration shell can be hosted within the Industrie 4.0 component or mapped in a higher-level IT system.

From a product perspective, this administration shell must be mapped in the PLM system, as this is where the product data is managed over the entire life cycle. The integrated system model must be an essential part of the asset administration shell - until now, only CAD data, connection diagrams and manuals have been mentioned as exemplary components.

Maintaining contact

Another wish of many manufacturers is not to completely lose contact with their product when it is in operation. A lot of field data can be used for downstream optimization, maintenance or usage data collection. To do this, each unit produced must communicate with its manufacturer. To ensure that the data collected from the units can also be understood in terms of its meaning, it makes sense to mirror this operating data from reality against the integrated system model.

The system model definition made during product development provides the necessary contextual information for field data collection in the later phases of the life cycle. This means that in addition to the pure values that are measured, the system model can be used to make the context and meaning of the data clear to an analysis tool or the user. Simply transmitting a value, for example 290 for a temperature sensor, requires implicit contextual knowledge from the user. It would be better to transmit a value of 290 K (for Kelvin) together with a unique identification number (UID) of the sensor. With this UID, the reference to the system model can be established and the explicit contextual knowledge contained therein can be made available to the user. This means: What does this value mean in the context of the system? Why was it measured?

Condition-based maintenance

Another use case could be the concept of condition-based maintenance. Using statistical methods and the ability to record field data via the Internet in near real time, it is possible to predict component failures much more efficiently and provide the customer with a replacement as a precautionary measure. As the system model can also be linked to simulation models (e.g. VHDL, Matlab, Modelica) or simulation models can be derived from the system model, virtual simulations can be carried out based on the information from the integrated system model and the real parameters of the system in operation. For example, it is possible to anticipate the future behavior of the system and validate it in advance before a new firmware is rolled out.

The 150% system model depicts all variants of structure and behavior.

© XPLM

One way to use the digital twin: The virtual world maps the digital twin - first at type level (part number basis) and then with production at instance level. Instead of a 150% parts list that maps all variants, in the context of MBSE we speak of a 150% system model that contains not only structural but also behavioral information as described. Together with the production in the real world, the digital twin is instantiated from the 150% system model in the virtual world. Just like its real twin, it is given a unique identifier (serial number or UID). In the operating phase, field data can then be recorded online via the network and firmware updates can also be rolled out, the influence of which on the behavior can be verified beforehand, as already described.

The path to realization

With regard to Industry 4.0, it can be said for engineering that the management of system models cannot yet be fully supported. Both the MBSE (modeling) and PLM sides must continue to develop their solutions and concepts. This also means driving forward the creation and further development of standards. Work on the integration of modeling, discipline-specific models, management and simulation must continue - the individual technologies are there, but the bridging of isolated solutions is still pending. The use of mature management systems and the replacement of legacy systems are necessary to ensure future-proofing. Individual developments and proprietary solutions no longer have a place if Industry 4.0 is to become a reality.

Authors:
Christian Muggeo is a research assistant at the Chair of Virtual Product Development at TU Kaiserslautern;
Michael Pfenning is PLM Consultant at XPLM Solution .