{"id":7218,"date":"2020-12-22T09:53:18","date_gmt":"2020-12-22T07:53:18","guid":{"rendered":"https:\/\/www.iese.fraunhofer.de\/blog\/?p=7218"},"modified":"2024-01-22T11:53:27","modified_gmt":"2024-01-22T10:53:27","slug":"continuous-engineering-industrie-40","status":"publish","type":"post","link":"https:\/\/www.iese.fraunhofer.de\/blog\/continuous-engineering-industrie-40\/","title":{"rendered":"Continuous Engineering for Industrie 4.0 (Part 1)"},"content":{"rendered":"

Rolling out changes in complex systems is always a challenge. Regardless of whether a software component needs to be modified or whether a change in the communication network needs to be made, any change may lead to unexpected behavior. Continuous Engineering of Industrie 4.0<\/a> promises to alleviate these issues by enabling continuous assessment and continuous change of the system. Today, we start a series of blog articles in which we will explore how continuous engineering practices should be instantiated to the automation domain to support Industrie 4.0 principles.<\/p>\n

Continous Engineering in the context of Industrie 4.0<\/strong><\/h3>\n

Continuous Engineering (CE) for Industrie 4.0 refers to orchestrations of practices like Continuous Integration (CI) and Continuous Deployment (CD) and aims at improving Time-to-Market (TTM) by reacting faster to demands that might range from a mobile phone software update to the incorporation of a new feature in a vehicle. Automated testsuites evaluate the quality and the impact of a change before this chain is rolled out into the field. This enables short release cycles even for complex software systems, such as the Amazon platform. Continuous Engineering practices were first successfully implemented in the course of the development of traditional information systems. Recently, players from the automotive sector like Tesla [1]<\/a> and BMW [2]<\/a> have also reported successful adoption of Continuous Engineering practices in the development of critical embedded systems. They use simulations to implement the testing environment for their systems.<\/p>\n

The adoption of CE practices in the industrial production automation domain<\/strong> is still slow. One key reason for this is the lack of understanding of how to instantiate CE aspects for the particularities of the industrial production automation domain. However, this adoption is particularly important due to the advent of Industrie 4.0 and all the agile and continuous dynamics expected of smart industries. CE practices can enable quick assessment of changes to be made in the system. Thus, the impact of changes is already known beforehand and, as a consequence, uncertainties are eliminated.<\/p>\n

The first four posts of our blog article series will discuss common challenges encountered when changing manufacturing processes or process automation. We will describe instantiations of CE practices aimed at dealing with the following situations:<\/p>\n

\"Industrie
Figure 1: Typical scenarios in production plants<\/figcaption><\/figure>\n

These four posts will be followed by two posts discussing how the BaSyx middleware and the FERAL simulator support the technical realization of continuous engineering practices to the industrial production automation domain, and how both enable the realization even of complex Industrie 4.0 solutions.<\/p>\n

The remainder of this first post focuses in the instantiations of CE practices to deal with the first scenario depicted in Figure 1: rescheduling\/reassignment of tasks to a redundant device due to hardware malfunction.<\/p>\n

Continuous Engineering: Rescheduling\/reassignment of tasks due to hardware difficulties<\/strong><\/h3>\n

The first scenario assumes that (i) the production plant is operating, (ii) a production device or a cell is faulty, produces bad quality, or has become fully unresponsive, and (iii) a redundant piece of hardware is available to replace the failing one. However, this hardware might not be a full equivalent of the failing hardware, but an available substitute. Engineers therefore have to evaluate whether the new hardware will work in the context of the manufacturing line.<\/p>\n

Hardware misbehavior\/unresponsiveness<\/em> is identified by the Continuous Runtime Monitoring<\/strong> (cf. Operations<\/em> in Fig. 2) of the production plant. In the event of hardware misbehavior\/unresponsiveness<\/em>, technical staff should perform onsite tests and minor maintenance at the operation site (e.g., restart, clean, or change tools).<\/p>\n

\"Continuous
Figure 2: Continuous Engineering cycle for rescheduling\/reassignment of tasks to a redundant device due to hardware malfunction<\/figcaption><\/figure>\n

If the hardware misbehavior\/unresponsiveness <\/em>persists, it is necessary to analyze the impact of the failing hardware <\/em>on the overall production and plan the reassignment of the tasks of the failing hardware<\/em> to available redundant manufacturing lines. Efficient and effective Continuous Planning <\/strong>(cf. Business Strategy<\/em> in Fig. 2) will minimize the impact of such failures and mitigate the impact on the Business Strategy.<\/em> The implementation of continuous planning requires the ability to predict the outcome of changes. Usually, this is realized with simulations. Transferring this principle to the Industrie 4.0 world, continuous planning requires a digital model of every asset, of the manufacturing plant, and of the manufacturing line in question: the Digital Twin<\/a>.<\/p>\n

Continuous Engineering for Industrie 4.0: The Asset Administration Shell<\/strong><\/h3>\n

Today, a technology called the Asset Administration Shell<\/a> (AAS) is being developed by a large group of players from industry and academia to support digitally harmonized representations of production assets. This includes, for instance, devices, manufacturing lines, processes, products, and everything else that is relevant for production. The AAS therefore integrates all relevant production data into one digital model. For this reason, Asset Administration Shells contain numerous sub-models that provide access to different kinds of information.<\/p>\n

A very important AAS sub-model that is currently being defined by a sub working group is the simulation sub-model. It will support the Functional Mockup Interface standard and provide a re-usable simulation model of the asset that is represented by the AAS. By coupling these simulation models, a virtual representation of a plant is created. This is the foundation for Continuous Planning processes. The virtual representation of the plant evaluates whether the rescheduling\/reassignment is going to meet the expected Quality of Services (QoS) and\u00a0 comply with internal industrial processes (cf. Development<\/em> in Fig. 2).<\/p>\n

The simulation results are processed in the Continuous Planning stage, where decisions regarding changes are made\u00a0 according to the simulation results. The cycle between Continuous Planning and Continuous Simulation continues until adequate parameter values are reached. When this QoS is confirmed by the simulation, the deployment of the redundant misbehaving\/unresponsive device is triggered and executed. After this, Continuous Runtime Monitoring is used to monitor whether the rescheduling is working in production as expected. If a parameter is violated due to the rescheduling, the continuous cycle restarts.<\/p>\n

This automated continuous cycle for dealing with the rescheduling\/reassignment of tasks to a redundant device due to hardware malfunction is made possible because of the orchestration performed by Continuous Engineering tools like GIT, Jenkins, and Docker, as well as the Industrie 4.0 middleware BaSyx [3]<\/a>, and the simulator FERAL [4]<\/a>. The technical implementation of this will be presented in the next posts in this series, so stay tuned!<\/p>\n

\n

For further information concerning the topic of „Continuous Engineering for
\nIndustrie 4.0“, please check the following links:<\/p>\n

 <\/p>\n