Unlocking Agile Manufacturing: Embracing Service-based Production with Eclipse BaSyx (Part 1)

Service-based production promises a plethora of benefits, such as higher revenues, by providing custom-tailored products or a significant reduction of the time between the placement of a customer order and its fulfillment. However, how can service-based production be realized? Delve into the transformation of manufacturing processes with our comprehensive guide. This investigation encompasses concepts such as Digital Twins, process orchestration, and Programmable Logic Controllers (PLCs) and establishes the foundation for implementing service-based production and achieving changeable production.

Service-oriented architecture (SOA) is a proven architecture pattern from the domain of IT systems where software components are created as autonomous services capable of functioning independent of their environments. These services are exposed to other applications, promoting loose coupling and high flexibility [1]. Applying SOA to production removes side effects when modifying manufacturing processes and ensures a clear separation between service providers and consumers [2].

In the first part of this blog series, we will explore how service-based production systems can be realized in practical applications in the context of a reference architecture. To do so, we use C4 diagrams to illustrate the interconnection of the components, thereby bridging the gap between theoretical considerations about the benefits of service-based production and its real-world implementation.

The diagram in Fig. 1 depicts the context where our reference architecture is deployed. The arrows indicate a dependency between components. The Service-Based Production System (in blue) can control field devices (e.g., actuators, sensors) and execute a production recipe based on the input of the Production Recipe Provider. This component uses the capabilities offered by the production system to generate a recipe that corresponds to the product to be produced. This approach helps realize a central goal of Industry 4.0, namely changeable production, where changes in the production requirements are addressed by the production system. For example, a new device connected to the production cell should be able to broadcast its capabilities and production capacity to the rest of the network and be autonomously integrated by the cell [3].

The architecture ensures that monitoring and supervision systems, such as dashboards or Human-Machine Interfaces (HMI), are effectively integrated. These systems play a critical role in providing real-time data and visualizations that support decision-making processes and operational efficiency. By connecting these systems to the Service-Based Production System, it becomes possible to monitor the production process in real time, identify any deviations from the expected performance, and implement corrective actions swiftly.

Figure 1: C4 context diagram of the Service-based Production System

The system’s internal structure (Fig. 2) reveals how different applications such as the Orchestrator, the Digital Twins (DTs) Infrastructure, and the Programmable Logic Controller (PLC) Environment interact within the system.

Before we proceed with the explanation of these components, it is important to distinguish capabilities from skills in the context of industrial production and automation. These terms refine the broader definition of service and come from the Capablity-Service-Skills (CSS) model. Capabilities refer to the general functionalities that a system can perform, often described in terms of the potential to execute a specific process step, such as drilling, with defined properties and constraints, like hole depth and diameter. They outline what can be done, without specifying how it is done on a particular machine. Skills, on the other hand, represent the actual implementation of these capabilities on specific equipment or software, providing a practical interface for other systems to invoke these functions. While capabilities define the possible actions in abstract terms, skills translate these into executable commands, complete with input and output parameters to control and monitor the execution process [4].

On the right side of Fig. 2, the Orchestrator is responsible for executing the production recipe. These can be described as Business Process Model Notation (BPMN), which has proven feasible for describing the interdependence of manufacturing steps [2].

Figure 2: C4 system diagram of the Service-based Production System

Each BPMN node details one needed skill in combination with process parameters. Fig. 3 illustrates a simplified production recipe for a precision gear. Initially, a solid metal block is shaped into a basic gear form by cutting the outer diameter and removing excess material to create a rough gear blank. Subsequently, the gear teeth are precision-machined using a hobbing process. Following this, heat treatment is applied to enhance the gear’s strength and durability. Additionally, the figure demonstrates the orchestration of the abstract recipe into an executable plan by integrating the plant topology and individual process parameters.

Figure 3: Abstract production recipe for a precision gear and the corresponding BPMN model

Let us now investigate the internal structure of the other two components.

Understanding the PLC environment

The PLC is an industrial computer control system that continuously watches the state of input devices and makes decisions based on a custom program to control the state of output devices. The entire PLC Environment acts as a bridge between a controlled device and a service consumer of the field devices, e.g., the Orchestrator. In the proposed reference architecture, a distinction is made between high-level skills and low-level skills [5]. High-level skills provide a higher level of abstraction and are easier to integrate into production recipes, whereas low-level skills explicitly implement the control logic to interact with a device.

To illustrate: an industrial robot could contain a high-level skill moveTo in its control component, which expects a position to move. However, its actual implementation depends on the coordination of several low-level skills implemented in the control logic; for instance, the actuation of the individual motors (e.g., sending pulse-width modulation (PWM) signals) and input from sensors (e.g., encoders). This clear separation frees the production recipe from unnecessary complexity while increasing consistency and readability.

In the proposed architecture (Fig. 4), the Control Logic is responsible for low-level skills and typically adheres to established standards in the automation domain, such as IEC61131 and IEC61499. Meanwhile, the Control Component offers high-level skills and can be implemented as a separate component utilizing higher-level programming languages (e.g. Java, Python, or even no-code development platforms such as NodeRed) or the same standards.

Both components, Control Logic and Control Component, provide an interface for accessing their skills and relevant operational parameters. The proposed reference architecture is based on OPC UA. The IT Infrastructure for DTs can consume data directly from the control logic and keep it synchronized with the current plant’s state. In the same way, the Orchestrator can execute skills in the control components.

Figure 4: C4 container diagram of the PLC Environment

Implementing the IT Infrastructure for Digital Twins with BaSyx and the AAS

Eclipse BaSyx is an open-source middleware that facilitates the integration of Industry 4.0 components. It provides a Software Development Kit (SDK) and off-the-shelf (OTS) components for quickly deploying services in the IT Infrastructure for DTs (Fig. 5). It is used to implement the DT’s virtual representation, encapsulating metadata, and operational data of an asset.

In this reference architecture’s context, it provides information on the current capabilities found in the plant and the description of the skills available to skill consumers, e.g., orchestrators.

Furthermore, another part of the system is the BaSyx OTS component DataBridge. It connects different data sources to the infrastructure and realizes common integration scenarios in production systems. Here it is used to update the state of the DTs by polling data from the PLC Environment via OPC UA.

It can be easily integrated into an IT Infrastructure for DTs implemented with BaSyx due to its use of a standardized interface. This enables easy integration into other platforms, for example, MATLAB/Simulink, to provide simulation as a service.

If you want to know more about BaSyx and what it enables, please also check how it helps build the Industry 4.0 IT Infrastructure for DTs and can improve changeability in the process industry.

C4 container diagram of the IT nfrastructure for DTs — Figure 5: C4 container diagram of the IT infrastructure for DTs

Shaping the future of manufacturing

The transition towards service-based production is not merely a technological shift but a strategic realignment of manufacturing processes. By adopting a service-oriented architecture, manufacturers can realize the vision of Industry 4.0, which is characterized by agile, flexible, and intelligent production systems capable of responding to evolving market demands and technological advancements. Our reference architecture offers a blueprint for integrating DTs, orchestration logic, and PLCs into a cohesive system that leverages the full potential of SOA in manufacturing. This framework not only enhances operational efficiency and adaptability but also paves the way for future innovations in the domain of smart manufacturing.

Would you like to learn more about the potential of digitalization in your production systems?

Feel free to contact Fraunhofer IESE by email. We will be happy to assist you with further information and discuss new applications in your industrial operations.

Understanding the PLC environment

Implementing the IT Infrastructure for Digital Twins with BaSyx and the AAS

Shaping the future of manufacturing

Further reading