Keywords

1 Introduction

Today, the environment in which manufacturing companies operate is characterized by volatility, uncertainty, complexity and ambiguity (VUCA world) [1, 2]. The requirements which arise in this environment are decisive for the success of companies. Flexibility and adaptability are enablers to cope with these requirements and crucial success factors that can ensure competitiveness [3].

Progressive digitization has evolved from a trend to an enabler in the global production network and offers companies the opportunity to deal with growing demands in the VUCA-world [4]. A new paradigm that offers potential to exploit the full scope of digitization and remove the existing barriers is Software-defined Manufacturing (SDM) [5, 6]. Inspired by software-defined networking, SDM aims to decouple hardware from software, with the goal of increasing flexibility and changeability of both hardware and software. Therefore, SDM empowers increasing efficiency in planning and operating and reduces the complexity of the systems at the same time [5,6,7]. The full potential of SDM can be realized when it is used across all levels of production [3]. Starting from machines, through the production system, and up to the global production network, a continuity can be created by implementing standards and by using the same technologies as well as the same mindset. However, SDM should not only be applicable across all levels, but also along the entire production life cycle. The production life cycle is oriented on the product life cycle (Introduction, Growth, Maturity and Decline) [8]. During the life cycle of a production, requirements change and adjustments must be made which can be supported by SDM through a continuous adaption process which includes the development, planning and operation of a production [3, 6].

Based on existing approaches and technologies, it is now necessary to establish SDM across all levels and along the entire life cycle of a production in order to counteract the VUCA world effects. The remainder of this paper addresses existing approaches (Sect. 2), presents an architecture that aims to realize SDM over all layers of production (Sect. 3) which is illustrated in an exemplary use case (Sect. 4). Finally, the presented architecture is discussed and the paper concluded (Sect. 5).

2 State of the Art

The SDM paradigm aims at “adapting an entire production purely via software” [9]. Similar to other software-defined approaches such as software-defined networking [10], SDM pursues its goal by utilizing abstraction layers to decouple control software from production hardware [5]. SDM promises to increase flexibility and changeability of production and allows to handle the complexity of modern, digitized production sites [7]. Currently, different concepts for SDM architectures are discussed in the literature, that can be differentiated in modular service-oriented approaches [6, 7, 9] and centralized control approaches [11, 12]. Since modular service-oriented approaches suit the idea of abstraction, these approaches are presented in the following.

An essential foundation for the realization of SDM is a digitized production, where different assets in the production are cyber physical systems (CPS). A CPS refers to a system with integrated digital and physical capabilities that collects data and allows to control its physical components by software [13]. There exists a multitude of communication protocols with service-oriented architectures that can interact with and control CPS, such as OPC UA [14] or MQTT [15]. Both provide a basis for standardized communication across all levels of an enterprise. In their basic form, however, they do not consider the specific changes in a CPS over the life cycle. A promising concept that allows to create standardized data models that comprise all data to describe a CPS and allow for communication with the physical part of the CPS is the asset administration shell (AAS) [16, 17]. The AAS is promoted as a basis for a digital twin (DT) [16].

Despite multiple, sometimes contradictory definitions of a DT in the literature [18], most researchers agree that a DT is the virtual representation of a physical asset that synchronizes with the real system [19]. In most cases, a DT incorporates models that allow making predictions about the real system [20]. Stark et al. [21] state that a DT consists of data and models that utilize this data to mimic the behavior of the real system. A definition relevant in regard of SDM is presented by Kritzinger et al. [18] who states that a DT must support automatic information flow from and to the real system. Thus, a DT needs to be able to control the physical system.

Besides SDM, there exists a plethora of approaches that aim to improve production by using CPS or digitization in general. The concept of cyber-physical production systems, which is proposed in [22], aims at a production with autonomous, interconnected and cooperative CPS. The concept targets a self-organized and highly flexible production. Similar approaches that aim for an intelligent, flexible and changeable production are biological [23], reconfigurable [24], fractal [25] or holonic [26] manufacturing systems. However, the above-mentioned concepts lack a conceptual software architecture that allows to use the CPS as proposed. This paper aims to close this gap by introducing an SDM architecture that allows for abstraction to reduce the complexity in production and enabling service-oriented manufacturing.

3 Approach

Realizing the SDM paradigm promises to improve the efficiency in planning and operation of production systems. The main enablers that are exploited to realize a software-defined production are virtualization and abstraction. As a result, operation and planning can be fully adopted by virtual representations of the production and interaction with the production is simplified by realizing abstraction with offered services.

In regard of SDM, virtualization describes the digital replication of a physical asset in production [7]. However, different requirements need to be fulfilled to achieve virtualization of the production system. The production assets, i.e. production resources such as machines, need to be CPS with virtual counterparts, i.e. DTs [27]. By combining these individual virtual counterparts of the assets in a model that also contains the connections of the assets, a virtual representation of the production system can be created. Similarly, virtual production systems can be combined to virtual production networks. Besides production resources, production systems and global production networks are also referred to as assets in the following.

In order to realize a virtually operated production, it is crucial that assets allow for a bidirectional information flow between physical and virtual world. Thus, assets need DTs that suit the definition of Kritzinger [18]. The two components of the DTs, i.e. data and behavioral models, need to be separated to realize abstraction.

Abstraction refers in this context to the idea that interactions with the production are separated from the production’s technical infrastructure. Thus, abstraction implements the concept of separation of concerns [7]. Abstraction can be achieved by a reference model that contains references to the data of the DT and the real production resources in a standardized form [6].

We propose a service-oriented, modular architecture for planning and operation of production that allows to realize the SDM paradigm with virtualization and abstraction.

Fig. 1.
figure 1

Visualization of the proposed service-oriented architecture with the possible connections between application, reference and infrastructure layers of two exemplary assets.

Full size image

The architecture of an individual asset, as depicted in Fig. 1, contains three distinct layers: an application layer, reference layer and infrastructure layer. The application layer provides services and applications for operation and planning of the asset, such as a service to produce a product or a simulation model of the asset as an application. The infrastructure layer contains all data to describe the asset and functions that can be performed by the asset. Application layer and infrastructure layer are connected through the reference layer. A reference is thereby a connection of a standardized key to infrastructure components that relate to this key. For example, the key processing time of a machine allows a standardized reference to all processing time data values of this machine. The reference model defines thereby the keys of each asset. References can either be requests for data or requests to perform a function. Besides references to infrastructure components, references to the application layer of other assets are also possible. This allows the creation of an architecture where hierarchical levels of the production can be represented, as shown in Fig. 2. The advantage of this architecture is that the interaction of humans or machines with the production is limited to the application layer and the technical infrastructure is not necessary to be considered. Moreover, production layers are decoupled so that interactions on a certain production level do not directly depend on other production levels. This approach makes it possible, for example, to trigger successive simulations from the upper levels to the levels below, thus extending the functionality of communication protocols such as OPC UA. Moreover, it is possible to use different communication protocols concurrently.

Fig. 2.
figure 2

Visualization of the proposed service-oriented architecture in context of the three production levels machine, production system and production network with three exemplary requests

Full size image

Subsequently, the specific characteristics of the production levels machine, production system and production network are described with respect to the SDM architecture.

3.1 Machine

Due to a continuous standardization of interfaces and information models, the connection of new machines to the SDM architecture will become increasingly easy. As shown in [28] by a survey of representative companies in the mechanical and plant engineering sector, almost all companies work with machines and machine controls from at least two manufacturers and 81% of the machines in operation are older than six years. Therefore, brownfield machines with varying standards, interfaces and ages must be considered for a consistent integration in production systems. Since these machines have an advanced degree of wear and tear, the machine life cycle plays an important role. For connection of these machines, programmable logic controller (PLC) data, as well as additionally retrofitted sensors, must be considered. These sources can be accessed via various edge devices and nodes leading to an inhomogeneous data landscape. Multiple protocols and data formats, as mentioned in Sect. 2, must be considered. To deal with this complexity and, thus, be able to introduce retrofitted brownfield machines to SDM, relevant data sources should be made accessible to the reference layer with the help of a data-grabber [29]. Furthermore, to add the data sources to an information model, their signal types must be determined. This can be done by intelligent signal identification algorithms [30], which can be integrated into crawler tools for production communication networks. Furthermore, it can be assumed that there is no axis model available for brownfield machines, which is required to represent the machine using a DT. Based on this, a holistic integration of brownfield machines only unfolds its full potential when the system parameters of all machine axes are known. Therefore, reference runs with high information content as presented in [31] can be used to generate data for the determination of axis components. If both new and existing machines have been enabled for integration into the SDM architecture, they are available to host services and applications that utilize the machine’s infrastructure layer.

3.2 Production System

Operating a production system efficiently demands a high effort in planning due to the complexity of the systems [32]. This is caused by the necessary consideration of technical details of the used production resources and by changing requirements to the production system over its life cycle [3, 24]. With SDM and the presented architecture, these limitations can be overcome.

Since the SDM architecture allows for abstraction, production resources can be treated as black boxes with certain capabilities offered by services. Thereby, technical details of these resources can be neglected. This simplifies the management of the resources in a production system as planners only need to consider a subset of information.

Pairing abstraction with virtualization simplifies the production planning task for production systems even more. The DTs of production systems, mostly modelled as material flow simulations [18, 20], allow for detailed forecasting, optimization and autonomous control. The reference layer simplifies the generation of DTs as the access to required data is improved by standardized interfaces. Moreover, data analysis services can be combined with real time data sources, as e.g. MES systems, by the reference layer to synchronize DT and real production system.

The implementation of this approach into existing production systems requires three steps. At first, the requirements for virtualization of the production system and its resources need to be satisfied. Hence, the assets need to be digitized to gather data and to allow for virtual control. Next, the reference model can be created with references to the data and the production resources. At last, services and applications can be built upon the reference layer by using existing architectures such as REST. Possible services for a production system are the production of products or the analysis of the production system. Moreover, applications could range from simulation tools to data dashboards presenting the performance of the production system.

3.3 Production Network

By using the SDM paradigm also across companies in the global production network, new opportunities for interaction and collaboration in production networks as well as the design of production networks become possible. Production networks are systems that usually have grown over years and combine different locations and production systems [33]. For this reason, the focus on the global production network level is on brownfield planning.

The starting point for using SDM on the production network level is as well a reference model that provides the necessary information and enables abstraction and virtualization. Accordingly, the first requirement for SDM from the production network perspective is a unique reference between the reference models at the different levels, given by the reference layer. While the various sites, systems and machines represent internal company information, the production network level also requires information on suppliers, customers, service providers, etc. In the future, this data can also be provided via information models with an external interface. If suppliers do not yet provide information models, the data must be collected from the company's own databases in a transitional phase. Here, ERP and MES systems can be used. This allows, for example, to import customer and order data into the information model to perform order allocation or aggregate production planning tasks. In summary, the application layer for the production network receives information from the underlying levels (linked via the reference layer), information models of external parties and the company's own systems (ERP, MES, etc.). Since production networks are complex structures with high variety, the reference layer needs a detailed logic which can be modeled by asset administration shells and enhanced semantically through ontologies [16].

The infrastructure layer is contrasted with the application layer. Like the production system, the production network also focuses on a DT. However, this requires the right level of abstraction to be able to fulfill necessary tasks, on the one hand, and to keep the computing time and the effort required as low as possible, on the other hand. Since the use cases can be very diverse, it is important to define as precisely as possible which information is required for each individual application. If there are continuous reference models across all levels, only the corresponding one must be referenced.

4 Exemplary Use Case

In the following a specific use case for the service-oriented architecture in the context of the three production layers is introduced. In detail, the architecture aims to realize a changeable production environment. This goal is enabled by the architecture because it can facilitate the planning and operation of today's digitalized production.

The use case comprises of the introduction of a new product variant in an existing production which is a common but still challenging scenario in production. Parallel to the introduction, the quantity of requested products by the customers changes as well. To react to these drivers of change, the existing production needs to be optimized and reconfigured for the new product und quantities. The use case shows how the service-oriented architecture is used in production planning on different levels of production.

First, a service is used on the production network level to find the optimal locations to produce the new product variant. To do so, historic production data of the different locations and production systems is needed. With the architecture, the data can be quickly gathered from information models. Heterogeneous data standards at different sites (identification, addresses, format, etc.) can be used in a unified service via the reference layer, thus supporting interoperability. The data is then analyzed and compared to the production capabilities needed to produce the new product variant. Out of this, planning algorithms can find a suitable match of production plant capabilities and product requirements and recommend it to the user. Allocation planning can thus be automated by using data directly from the information models.

Thereafter, production planning on a production system level needs to be performed. At first, material flow simulations are performed to analyze the performance of the production system under the new circumstances. The proposed architecture allows to create a service to retrieve a data-based description of the production system from the information model and automatically create a simulation model based on this data. As the structure of the obtained data is standardized by the reference layer, this service is applicable for different production systems and allows to reduce simulation modeling time dramatically. Similar services are also possible for other production planning tasks, such as scheduling of orders or reconfiguration planning. If the result of the simulation shows an acceptable performance, the architecture can be used to request the production system to produce the new product variant in the demanded quantity. The reference layer should link this request to the ERP system of the production to automatically trigger the production process. Again, this request could be standardized to allow the connection of different ERP systems to simplify the interaction of production planners with the IT infrastructure of the production.

If the production of the new variant requires a changeover of some machines, the architecture can also be used to support this process. A service can be imagined, that allows to request a changeover of a machine. Depending on the capability of the machine for automated changeover, the service either requests maintenance personal to perform the changeover or directly communicates the needed changeover to the machine via suitable communication protocols. Ideally, the interface of this service is standardized for all machines and the reference layer distinguishes the associated requests to suit the needs of the machine.

The use case illustrates how the architecture can be used for production planning and operation on different levels of production. The possibility to create standardized services and requests with the architecture does not only simplify but also reduces the required time for production planning as these services can be reused in other scenarios. Moreover, interoperability of different tools, such as simulation or data analysis, is enhanced since it enables a standardized representation of a consistent data base.

5 Discussion and Conclusion

The presented SDM approach promises various advantages and opportunities by extending the SDM concept with consideration of the production life cycle on different levels of production. By decoupling the physical production and associated software with abstraction, a clear application layer can be implemented leading to simplified supply chain and production planning. In turn, this helps to reduce the complexity in production planning and control and, thus, promises to increase the efficiency in production. Consistent matching of product requirements and currently available production capabilities can be achieved even before the production of initial samples. Furthermore, the architecture promotes the use of virtualization that also reduces the required time for production analyses and forecasts. Lastly, interoperability in planning and operation of production is enabled by services and the use of a reference layer.

However, the presented SDM architecture and SDM in general still face various challenges in the implementation. For example, depending on the requested services, there are specific minimum requirements for the required data quality. Thus, standardization and digitization of production assets is required. In order to be able to map the entire global production network, end-to-end networking between all layers and models must be ensured. Furthermore, isolated use of individual models must be made possible at every level. For this purpose, it has to be possible to abstract individual layers so that individual models can be used. This should be possible, even if there is no reference to one of the other layers. In summary, the management of the reference layer must be simple to avoid additional administrative work. Moreover, existing implementations need to be extended to allow an integration into a unifying architecture. Future research shall implement the introduced architecture with various layers and demonstrate its applicability to address the presented challenges.