Keywords

1 Motivation and Challenge

Information technology (IT) aspects are addressed still quite late in the design and planning process of manufacturing systems in industry. Usually the IT infrastructure for manufacturing systems is implemented in a permanent way for a specific production line or factory. It creates difficulties regarding setup-time and flexibility.

Flexible and resilient manufacturing systems require a dynamic adaptability of the IT configurations along with the dynamic reconfiguration of the shop-floor related to demands such as:

  • New products or services.

  • Events of failure and change.

  • Robust and secure IT realizations.

  • Management of customer orientation.

This requirement even already arises in “mass production”. Thereby a large number of new variants appear and the repetition number of the same product can be easily lower than 1.4 products per year. This has been identified from different industry sectors during several projects in the last 5 years. Therefore, approaches are required to increase the flexibility as well as to move the development of the information management for the shop-floor into earlier planning phases. This information management is also called shop-floor IT.

The shop-floor IT is directly involved in the production. It is responsible for the control, management and monitor of the production facilities in real time. Shop-floor IT functions (IEC62264) are for example “specification management”, “execution management”, “data acquisition” and tracing.

The approach for the development and maintenance of the shop-floor IT is at the moment usually sequential. The shop-floor architecture and infrastructure is developed after the final definition of the machinery. This final step connects the embedded IT of the machinery with the shop-floor IT by adaptation of the communication and the implementation of the manufacturing processes. This approach creates a close dependency between the machinery and the shop-floor IT.

New manufacturing approaches arise and the number of product variances increases and becomes more complex. These would lead to an increase of manufacturing functions. It goes along with continues automation processes within industrial digitalization and industry 4.0. Currently the high number of manufacturing steps results in a high number of IT‐functions for control, management and monitor of the machinery. This easily extends the complexity and resource costs for the shop‐floor IT planning. Furthermore, the high number of functions and devices increase the risk of failures.

At the same time, the demand of rapid changes in the production is growing and additional to that the information management during the manufacturing execution needs to be adapted in short term.

To insure continuous production, new configurations needs to be applied during the manufacturing process online without stopping the process. But also if failures appear alternative machinery should easily be put in place. This is currently very difficult and challenging to realize within the current shop‐floor IT setups because of interoperability issues such as:

  • Control devices are different with different communication mechanism and openness.

  • The plug-in of new devices or services into a network of manufacturing systems requires effort in adaptation of the communication mechanism. This relates to the diversity of controllers for physical devices as well as different implementation on top of the controllers.

  • Differences between shop-floor IT relations even within the same organization [1].

Within the current automation pyramid the shop-floor IT is located between the machinery and low level Manufacturing Execution System (MES) functions [2, 3]. This covers Programmable Logic Controller (PLC) [4], Supervisory Control and Data Acquisition (SCADA) [3] and the production data acquisition and monitoring of the MES.

Currently, setup and work sequences are derived from the product structure and the structure of the manufacturing system. The shop-floor IT is not considered here. In future, predefined services should be used which already contain interfaces in a standardized form.

The approach developed in cooperation with industrial stakeholders focuses on a modular solution and the representation of IT functions of manufacturing facilities in terms of services provided by cyber physical systems so called “modular shop-floor IT”. Indeed modular concepts are developed since decades also for manufacturing. The paper focuses on the use of such concepts to improve the reusability of the design of the information management for manufacturing.

The assumption is that the IT functions required by the shop‐floor are quite often similar. Therefore, manufacturing functions can be represented by a small set of normalized services which can be grouped into modules. This has been analyzed, specified, grouped and categorized in previous industrial research projects. It can reduce the effort for development, implementation and maintenance by using these generic functions for the shop‐floor IT architecture. It also forces a harmonization of functions across factories and interfaces to the machinery [5]. Details of the approach and the technical concept are described in Sect. 3.

2 Related Technologies

With industry 4.0 the focus on cyber physical systems and internet of things in industry becomes more prominent. Technologies such as OPC-UA [6], DDS [7], IIRA [8], RAMI4.0 [9], CoAP [10] and MQTT [11] support the connection of physical components with the cyber world. They also provide frameworks to create smart networks via intranet and internet.

Taken OPC-UA it provides a standardized architecture and protocols to access physical systems. However, the specific interface still needs to be developed. This covers the functionalities as well as the security level [12, 13]. Furthermore, OPC-UA is only one possibility for a standardized access to the physical world. Currently, each machinery provider developed their own control software. Therefore, the problem of the plug and produce into the shop-floor IT without programming effort is still a challenge.

Ontology approaches exist, such as the “method for connecting automatic functional unit in hierarchically structured manufacturing system, involves providing connecting functional unit with readable data, and transforming and enriching data with semantic information” [14]. It does not address explicitly modularity and a model based approach. It also focuses especially on OPC-UA whereas the shop-floor IT concept presented in the paper addresses openness for protocols and architectures. It proposes a normalized service interface for each physical component which hides the used access to the physical system.

In the described reference, architecture parts and ideas are implemented related to RAMI4.0 and industrial internet reference architecture (IIRA) [8]. This simplifies compliance to RAMI4.0 and IIRA in the future.

3 Architecture

For the modular shop-floor IT, three layers has been identified from a physical system to the network of systems to a representation layer (see Fig. 1):

Fig. 1.
figure 1figure 1

Components of IoT infrastructures for flexible manufacturing systems

Full size image

  • Cyber Physical System: The “shop-floor IT enablers” provide a set of services related to a cyber physical system. It delivers for each physical component in the shop-floor related services to establish a common service interface for each of these components.

  • Network: The execution engine benefits from the services are provided by the shop-floor IT enabler and establish the workflow between the different cyber physical systems. Using the provided services, it can start and stop the manufacturing process on the cyber physical system as well as stepwise progress and manage the feedback from the cyber physical system. The information is sent to the information management monitor “IM monitor” in terms of user interface.

  • Representation/Event detecting and debugging: The “IM monitor” provides a view on the actual progress on orders in the shop-floor. It also allows a kind of debugging within the shop-floor process.

An enterprise model of the shop-floor processes and related data provides common information for the configuration of the shop-floor IT. It is built by applying a library of modules. The modules consist of service descriptions relevant for the shop-floor IT execution. The service descriptions are based on the “Unified Service Description Language” (USDL) [16] and the “Web Services Description Language” (WSDL) [15]. USDL is used to carry data such costs of the service, responsibilities etc. whereas the executable service is described by WSDL. The model includes the relation between the shop-floor IT enablers and the manufacturing processes. The shop-floor IT enablers represents a virtualization of a machinery in terms of services to control the machinery.

The main objective of the “shop-floor-IT enablers” is the harmonization of the interface to the devices on the shop-floor. The assumption is that it is possible to define a set of services which provides a common interface to manage the devices. Currently each device has its own specific interface. Standardized interfaces are sometimes provided but they differ in terms of specific semantics such as possibilities to start and stop a device or to get feedback.

Therefore, an adapter is proposed to provide a minimum set of services for each device. The initial set is just start, stop and step forward. Each of these services is parameterized with information about the expected work of the device such as for the start service. In fact, the adapter does an abstraction of the real functionality of the device and transfers the specific work as well as order and product information directly to the device.

This is possible because the realization of the information management does not take care of the specific service of the device. But it is required to get feedbacks such as status information e.g. ready, stopped, error, shutdown, and alive as well as potential service data. The data which provided from the device for other services is also managed like a black box. An example could be a camera which provides a figure to identify a product. This information will be directly forwarded by the information management of the shop-floor to identification services which provides the information to the next device. Each device requires its own adapter and in the future theses adapters should be provided by the suppliers of industrial services and devices.

To know which services are available, they are grouped into a service registry. The execution engine uses the services from the service registry to process and manage the information about the shop-floor (see Fig. 2). The details about the devices and their possible connections are derived from the same enterprise model which contains process information and also data about the services, products and orders (see also Sect. 4).

Fig. 2.
figure 2figure 2

Shop-floor IT enablers and execution engine service interfaces

Full size image

The shop-floor IT enablers target the development of a harmonised interface to access devices and services. Therefore, every device is also represented in terms of services. This provides a unique strategy independent from if it is a physical device or a service.

The diversity of controllers for physical devices as well as different implementation on top of the controllers are the major challenge. Therefore, the approach proposes an adaptor which hides the real implementation of the controllers, protocols and even architectures to access the physical devises or sensors because even using OPC-UA different implementations are possible. The initial implementation of the “shop-floor IT enablers” uses OPC-UA but it is not mandatory and other architectures are also possible.

In detail, the shop-floor IT enablers are implemented as Shopfloor IT Service Systems. Together they build an IoT infrastructure, in which every Shopfloor IT Service System represents a CPS and publishes its services. A Shopfloor IT Service System controls the execution of a service, ensures safety measures and handles behavior in case of errors. Access to the Shopfloor IT Service Systems is realized through service interfaces.

4 System Network and Service Execution

The overall objective of the Execution Engine is the realisation of a path within a network of CPSs. The network together with the related date is stored within an enterprise model. The Execution Engine consists of different services and files. The Index File Service and the Execution Manager Service are the main software components. These components are supported by different templates and configuration files. Each component is represented at Fig. 3.

Fig. 3.
figure 3figure 3

Execution engine architecture

Full size image

The enterprise modelling system MO2GO [17] has been used to design required information model as well as the process descriptions. The method used is the integrated enterprise modelling (IEM) [18]. It provides input/output relation and actions to model object transformations as well as the related resources required for the transformation. The resources are connected by a dotted line to the action. Within MO2GO NG the user has the possibility to create a process model. This process model has to consist of the modules of the modular Shop-floor IT stored in a MO2GO model library.

The model based view of a production process simplifies the understanding of the product lifecycle and planning. The production process is divided into modules similar to building blocks. Every module represents a single production step and consists of three parts, such as:

  • standardized interaction function

  • standardized basic information function

  • generic operation module

Generic operation modules combine execution functions on the field level. The standardized interaction functions are IT modules which are used for the in- and output parameters from the module. Standardized basic information functions are used for other data processing, e.g. data synchronization.

In Fig. 4 “signal setting” and “handle feedback” are standardized interaction functions. The part “data processing” is a standardized basic information function. An example for a generic operation module is “mating”. By combining and rearranging modular shop-floor IT modules, different production processes are enabled. This enables a flexible reconfiguration for customized products and variants as well as a faster setup of new production processes.

Fig. 4.
figure 4figure 4

Module of the modular shop-floor IT

Full size image

In order to be able to produce a product later, a process model must be created first. This process model has to consist of predefined modules of the modular shop-floor IT. Next the Index file service has to evaluate the process model. With the information of the evaluation the execution engine can control the connected components. Every of these components have to send a feedback to the execution engine. On the basis of the feedback, the execution engine stops the whole production process or can start the next module to complete the production.

The second step is the connection between the execution engine and the shop-floor. To control all machines and measure related production data, the IoT technology can be used here. It means all production objects should be (building) up as IoT components in a virtual network as an infrastructure. Those production objects could be physical things like a machine with its controller or virtual things like a software component. To transform the physical production objects into IoT components cyber physical systems (CPS) concepts are used.

Finally, Fig. 5 illustrates the components involved in the realization of the approach. The execution engine works with the stored model information. The execution engine uses a range of messages to communicate with the connected components. These components are on the one hand the IM monitor and on the other hand various OPC UA servers.

Fig. 5.
figure 5figure 5

Main components for the execution of the shop-floor information management

Full size image

5 Conclusion

Tests of the concept and related prototypes have been applied. The initial tests were on an artificial manufacturing line and illustrated the potentials in terms of modularity and flexibility. Now two industrial related cases are established. Whereas the first uses a traditional intranet implementation, the second uses a cloud infrastructure and has a little modified setup. It shows already the flexibility in terms of infrastructure as in both cases the previous described IT system is used. The setup of the demonstrator consists basically of two incorporating commercial robots, a visual detection for the availability of various parts as well as hard- and software components, which is an usual configuration in industry. A visualisation and interface for user offers a Monitor next to the robot cage.

A current case is where the two robots assemble three gears into a planetary gear. The demonstrators are an important indicator of the feasibility of the approach. It was possible to show that different devices could be networked via different network protocols in order to produce a product. Therefore, modular approach allows users a quick and easy change of the process model. Next steps are the implementation of the concept and prototypes within productive environments. But a major objective for the future is test concepts to ensure security, robustness and interoperability. This is currently under development as part of a national project called IoT-T (http://www.iot-t.de/en/).