A Basic Description Logic for Service-Oriented Architecture in Factory Planning and Operational Control in the Age of Industry 4.0

Abstract

Manufacturing companies across multiple industries face an increasingly dynamic and unpredictable environment. This development can be seen on both the market and supply side. To respond to these challenges, manufacturing companies must implement smart manufacturing systems and become more flexible and agile. The flexibility in operational planning regarding the scheduling and sequencing of customer orders needs to be increased and new structures must be implemented in manufacturing systems’ fundamental design as they constitute much of the operational flexibility available. To this end, smart and more flexible solutions for production planning and control (PPC) are developed. However, scheduling or sequencing is often only considered isolated in a predefined stable environment. Moreover, their orientation on the fundamental logic of the existing IT solutions and their applicability in a dynamic environment is limited. This paper presents a conceptual model for a task-based description logic that can be applied to factory planning, technology planning, and operational control. By using service-oriented architectures, the goal is to generate smart manufacturing systems. The logic is designed to allow for easy and automated maintenance. It is compatible with the existing resource and process allocation logic across operational and strategic factory and production planning.

1. Introduction

Manufacturing companies across all industries are facing new challenges from multiple sides. On the one hand, the various consumer markets are behaving more and more dynamically and unpredictably. This is forcing companies to design their business models and production systems to be more flexible and resilient than ever [1,2,3,4]. On the other hand, various technologies like artificial intelligence (AI), additive manufacturing (AM), collaborative robotics, cloud computing, and advanced assistance systems like augmented reality have made huge improvements regarding price, performance, and usability. This offers the potential to substantially improve the efficiency and effectiveness of production systems [4,5,6]. This advancement in various technologies to a technological readiness level that allows for broad industrial application has often been referred to as the fourth industrial revolution of “Industry 4.0” [6,7]. Industry 4.0 is generally seen as a new generation of industry: one that is characterized by more comprehensible, digital, and flexible manufacturing systems [4]. Network communications, computer technologies, autonomous systems, and other technologies are incorporated and connected within the smart and intelligent production system (the so-called smart factory) [8]. One of the key enablers of these connected factories is the Industrial Internet of Things (IIoT) [9]. The IIoT is a subset of the much larger IoT (Internet of Things). It encompasses all of human society and entails many connected smart devices. This happens all across the globe, connecting every aspect of human life across all industries, continents, and societies, sensing, transmitting, processing, and relaying data and information from and to every point in the network. The IIoT, as a subset of the Internet of Things, focuses on industrial applications. It is a key element of the smart factory of the future [10]. It is constituted by cyber-physical systems (CPSs) or industrial-CPSs, networked devices, and systems. These systems consist of a digital (virtual) and a physical component. Both components interact with one another [11,12]. With their ability to perform physical tasks and provide interconnectedness, a CPS is a key component for enhancing the flexibility of manufacturing systems.

Despite these potentials, the overall adaptation of Industry 4.0 is not happening as quickly as many anticipated [6]. The reasons for this are manifold. The obstacles or challenges holding companies back can be found in various dimensions, both within the companies and their environment or the context of society. In a 2022 survey by BPM in the German-speaking world, only 41% agreed to have a digital strategy for the company. In total, 59% percent either had no strategy (29%) or were in the process of preparing one (30%) [13]. Furthermore, many companies reported a lack of skilled personal [14].

In the domain of manufacturing, the challenges are not limited to the availability of skilled employees that can implement Industry 4.0 technologies. The manufacturing systems and their elements, the machines, and the equipment available are often incompatible with the ideas associated with Industry 4.0. Many companies have a machinery and equipment park that dates back many decades. Back when machines were not fitted with sensors and powerful PLC, they were fitted to gather a host of different data which were then analyzed and interpreted within the cloud. These machines were purchased and depreciated decades back and still manufacture precise, high-quality products if maintained properly [6]. The overall configuration of the production system in many companies is a collection assembled over time. Today, production systems often contain equipment from each of the last few decades. This means there are machines that do contain the necessary sensors and computing power to facilitate the overall concept of Industry 4.0. They are, however, usually surrounded by equipment that completely and partially lacks those abilities [6,8,15]. The same is often true for the processes within the manufacturing systems. These were usually not designed for information sharing and collaborative production. The idea that a machine performing a specific process within a chain of processes might have to change its working parameters during operations based on another machine’s condition/performance was not part of the design of these processes and, in fact, the overall systems. This legacy aspect of most manufacturing systems is also reflected in the overall composition of the systems. Usually, companies possess equipment from various suppliers [6,15]. Often, these machines come with interfaces and programming, which makes connecting them and retrieving necessary information more difficult. It also complicates the implementation of decentralized steering and control. The approaches to address these challenges are, e.g., OPC-UA (Oper Platform Communications–Unified Architecture) or ROS (Robot Operating System). While ROS is a set of open-source libraries and tools for building tobot applications, OPC-UA offers platform-independent communication in a multi-layer approach. OPC-UA contains integrated encryption, authentication, and auditing and offers expandability by integrating new features without compromising existing applications and comprehensive information modeling. It further allows for event management, enabling the definition and notification of important data and information, and supports numerous protocols JSON over websockets [16,17]. Even though OPC-UA offers a reliable transportation and communication solution that enables a much easier connection of machines and various outer systems, it only addresses a small (but important) part of the greater picture.

In order to offer a holistic model for the entire concept of Industry 4.0, the Reference Architecture Model for Industry 4.0 (RAMI 4.0) was developed. It is a three-dimensional model aimed at systematizing, structuring, and mapping the complex relationships and functionalities required for Industry 4.0 application. [18].

The RAMI 4.0 model is composed of three dimensions (see Figure 1).

These are life cycles and value streams, hierarchy levels, and multiple IT layers (information technologies), ranging from the asset layer at the bottom to the business layer at the top. Each layer represents different tasks and processes. The lowest layer represents physical objects like machines, sensors, actuators, or technological documentation [18]. On this level, the CPSs are located. The information generated within the asset layer is then provided to higher layers in a structured way via an administrative shell that organizes the asset information. This takes place in the integration layer. Functions in this layer further integrate information from products and processes and other logistical information relevant to the identification of objects within the system [18]. The communication layer connects the two basic layers with the upper layers and all elements within the IIoT network. This is where communication protocols like OPC-UA are located. The information layer processes the upcoming information, checks it for integrity, and then summarizes and repackages it in a new information model. It thus provides a standard interface or communication model for the functional and business layer. The functional layer hosts’ aspects, like production planning rule generation, represent the runtime environment for the manufacturing system.

RAMI 4.0 provides a solid framework for the hierarchical classification of objects, functions, and tasks across the Industry 4.0 vision. It gives companies a guideline for where specific tasks occur, how information is provided, and how additional assets might be integrated.

However, in the context of this work, there are two aspects worth mentioning. The first aspect is in the context of production planning and control, located on the functional layer. Algorithms on this layer, in the context of manufacturing, will decide what machines will manufacture what products and perform which tasks. This will take place centralized in the cloud or decentralized among the different machines within the production system. A question that has not been answered so far is: how is the information about what machine is capable of performing what process on what object/part generated? The static process of allocation used in the Industry 3.0 world will not be sufficient since it captures only a fraction of the actual manufacturing potential and flexibility (this is explained in more detail in Section 2.2). This is also where the model presented in this paper can contribute.

The second aspect is that in the current situation most companies find themselves in, this idealized hierarchical structure represented by the RAMI 4.0 model is still a long way coming. The RAMI 4.0 model has a clear and distinct layout. The main point is the possibility of establishing decentralized control systems to steer production [4]. However, this vision runs very much against how most existing IT management systems are fundamentally designed.

As a baseline, the difference both in design as well as structural organization and operational management needs to be understood. Therefore, the conventional hierarchy within a company’s IT infrastructure, the automation pyramid, serves as a reference point. The automation pyramid represents the general hierarchical layout of the different IT systems used by manufacturing companies to manage their production and all other operations [20]. This hierarchical structure is also known as the ISA-95 architecture or the ISA-95 framework. Figure 2 shows the automation pyramid.

The physical processes are at the lowest level of the pyramid (level 0). These are the actual physical transformation processes within the production system. On this level, RFID Chips or Barcodes can be named as relevant objects. They provide information about product features, processing states, or the object’s current status in the overall process chain to the next layer, level 1. In the overall ISA-95 framework, level 1 represents the shop floor or production layer, with sensors (e.g., temperature or pressure) and actuators (e.g., electrical regulators). These process relevant information for the production system in the form of input and output signals [21]. Level 1 is the level of operational control, where the sensor data are processed via a PLC (programmable logic controller). The information is then sent back to the shop floor or upwards for further analytics and storage. This level is of great importance when it comes to decentralized control [21,22]. Monitoring, supervising, and operational control are located on the third level. Software and tools are often SCADA (Supervisory Control And Data Acquisition) and HMI (human–machine interface) solutions, serving as a display of operational data and operating systems. On level 3, the actual operational management of the production system takes place, usually supported by an MES (Manufacturing Execution System). On this level, the actual steering and management of the production system take place. The information comes from data from the lower levels, such as machine, logistical, and operational data. This level links the strategic and tactical planning, which then takes place on the company level (level 4) to the actual situation on the shop floor. One of the main tasks of the MES is the operationalization and detailed planning of the rough production program, which is planned in the ERP (Enterprise-Resource-Planning) system (level 4). The ERP system on the fourth level encompasses all corporate management tasks and functions and includes all relevant data for this purpose [23,24,25].

The distribution of task-respective functions across the different levels of the automation pyramid is very strict and not designed for flexibility [25]. Its structure and configuration are the result of a decades-long incremental development process stretching back to the 1960s. Different systems were developed for different tasks and varying functionalities. The systems were then connected via interfaces to move information between them. Each system contains its own set of data, often inconsistent with the data sets in other systems. This makes achieving high operational performance, efficient processes, and quick operational control hard. Furthermore, all of these systems on various levels operate within different timeframes. While data and information on the lower levels are acquired, analyzed, processed, and distributed within seconds or minutes, systems on levels 3 and 4 often operate within hours or even days. This further complicates the efficient and effective operational as well as strategic management of a manufacturing company.

Due to the shortcomings of these traditional systems, new approaches to operational management or production systems have been developed over the last decade, especially for operational activities like scheduling, sequencing, monitoring, and controlling. In most systems, these tasks take place on the level of the ERP systems or the MES (levels 3 and 4) [26]. Modern MESs (as well as systems for advanced planning and scheduling APS) do a better job concerning the operationalization of the rough capacity plan generated in the ERP system and the operational steering of the production. However, the obstacles associated with their implementation and seamless integration often render the benefits far from achievable [27]. Despite their shortcomings, ERP systems and MESs offer a good foundation for future concepts since they already contain most of the relevant data upon which future solutions can be built. Furthermore, they are the IT backbone of most companies across which all operations are conducted. Any transition towards a new paradigm or operational system/logic has to consider this and offer appropriate compatibility and interoperability within the transition phase.

Regarding the increasing need for more flexible, smarter, and faster production control, especially against the abovementioned challenges, decentralized production steering and control have been proposed as one possible solution. Today, cost-effective and powerful CPSs that can easily be connected via communication protocols are widely available. With those, OPC-UA, SOAs (service-oriented architectures), and other agent-based solutions appear more realistic than ever and have received growing attention [28,29,30]. In order to differentiate the advantages and challenges, the current developments toward more agile and flexible solutions for production planning and control (PPC) will be discussed in Section 2.2.

It would, however, be wrong to put all the blame for the inflexibility and lack of operational control on the different software systems and their inherent limitations. These systems were developed to help with the operational management and control of then-existing production systems. These systems were often decades old, containing machines and processes predating the lunar landing and within even older buildings. Neither the software systems nor the factories were designed on a blank slate for the current economic challenges. However, manufacturing companies must compete and survive in ever-shifting markets with high volatility and unpredictability and new, ever-faster-emerging technologies and improved old ones. Against these challenges, factory planning, operational management, and existing IT infrastructure must be viewed together. This combined view is needed, especially from a data and design point of view.

By offering a potential solution for this challenge, the authors hope to contribute to further developing integrated Industry-4.0-level production systems. The task-based description logic presented in Section 2.4 can be used for the strategic factory planning process at the beginning of the factory lifecycle and for operational steering and control during a factory’s operational phases. Furthermore, the database can be easily maintained and expanded due to the lack of fixed connections between machines and products. Furthermore, due to the feature and competence-based allocation principle, identifying potential matches between machines and products can be partly automated, saving both money and time. If connected with smart machines and CPSs, the logic also holds the possibility to update itself automatically, should improvements or deteriorations in machines within the production system occur. However, to present the logic and potential benefits, it is first necessary to examine the relevant literature in the relevant fields of research. Following this argument, the next chapter will explore the factory planning process (Section 2.1) and the dependencies between factory planning and operation control (Section 2.2). In Section 2.3, we will discuss the idea of service-oriented architectures (SOAs) as a means for a more decentralized and flexible production planning solution. Section 2.4 will bring these elaborations together and present a task-based view both on factory planning and flexible operational management. This aims at helping to facilitate a better and more efficient design of both factories and production management systems. Section 2.5 will summarize the potential benefits of the proposed basic task logic and highlight the contributions. The main contributions of this paper can be considered as follows:

• The proposed design of a task-based allocation principle for machines and products in manufacturing systems;
• The implications of how such a new way of allocation can impact both factory and technology planning as well as operational control;
• The implications of such a design on manufacturing data consistency and maintenance compared to conventional work plans.

Furthermore, examples and potentials for applying the task-based logic will be presented in Section 3 and discussed in Section 4.

2. Methodology—Related Works

This section describes the factory planning process’s general logic and the history, general idea, and design of service-oriented architectures. The presentation and discussion of SOA will, following the paper’s general direction, focus on the area of manufacturing and operational production control. The interdependencies between the factory design process and its results are considered. Also, operational production control is considered, as well as how both tasks (factory design processes and operational production control) affect the other. This analysis will take place against the backdrop of the arguments and developments regarding Industry 4.0 and the smart factory presented in Section 1.

2.1. Factory Planning

The factory planning process involves a structured and multi-step approach, utilizing various tools and methods to design and dimension manufacturing systems [1,2,31,32,33]. The process of planning a factory is subject to constant improvement. The reason for this is the constant evolution and increase in computing power, cloud computing, and other technological advancements. Three-dimensional scanning, BIM (Building Information Management), or augmented and virtual reality can be named in this context. Even though the tools and methodologies are subject to constant innovation, the fundamental planning process is still the same. It can be categorized into distinct successive phases. Each phase focuses on different aspects and levels of detail. Figure 3 offers a cross-section of a number of factory planning guidelines. The various phases and their content, as outlined by the respective authors, are displayed [1,34,35,36,37,38,39].

According to most guidelines, the planning process begins with Phase I. This phase entails defining project objectives and factory goals. Phase II follows it, involving gathering the necessary information and conducting preliminary planning. Phase III involves the development of a general factory concept. Factors such as structures, layout planning, and identifying an ideal solution are considered. Phase IV subsequently builds upon the ideal solution by incorporating real-world constraints, integrating existing limitations, and further refining the detailed planning.

Given the context of this paper, Phase II holds significant importance. In this phase, generally known as general or rough planning, factory planners face crucial decisions regarding the choice of technology [1,39,40]. Equally important, planners at this stage determine the level and type of flexibility to be incorporated into the production systems. Also, the specific technologies that will contribute to this flexibility are defined [41,42]. These decisions establish the framework that subsequent planning steps must adhere to. Furthermore, specific design choices are determined based on the selected technologies at this stage. These determine the factory’s layout and the fundamental operating logic in the later day-to-day business of the production system.

Regarding the technology planning process, it must be considered that the choice of specific technologies strongly depends on material and workpiece geometry. It also depends on the amount and nature of features that have to be produced. These challenges have led to the development of approaches based on a classification of workpiece geometries and an automated generation of process chain alternatives for manufacturing [43]. Any such methodology must be built upon a comprehensive, quantifiable, and, whenever possible, automatable approach to characterizing workpieces. The workpiece’s geometry plays a crucial role in identifying a set of possible manufacturing processes capable of realizing the required workpiece properties. Metrics independent of specific features, such as volume, volume–surface ratio, and aspect ratio, provide a general description of the workpiece. They yield specific insights into its geometric complexity. Such metrics can be calculated using existing 3D CAD files as an example. Feature-related metrics must also be considered to account for each manufacturing technology’s unique opportunities and limitations [44]. Established software approaches for feature recognition enable automated metrics analysis based on CAD formats such as the STL format. Nevertheless, the effort needed to determine these features has been extremely high in the past, which led to its utilization being strongly restricted [45].

In other words, the design choices made at this stage determine the later flexibility, responsiveness, robustness, and latency of the entire production system to a major degree. They dictate the fundamental workings of how productions will be manufactured in the factory in question. They thereby also determine the requirements of the software systems responsible for the day-to-day operations, like scheduling, sequencing, monitoring, and controlling.

2.2. Interactions and Dependencies between Factory Planning and Operational Control

Based on the elaborations in the previous two chapters, both areas, the planning and design of the production system and the IT systems for operational control, play important roles concerning the vision of the future’s self-controlled, flexible, and agile factory. Of course, the technological advancements in the fourth industrial revolution and the technologies encapsulated within it must be and are intended to be capitalized on. Therefore, it is necessary to rethink a core element of the factory planning process and the operational production control of the production system. This core element is the work or process plan. The work plan serves different purposes within the organization and management of the production system. Primarily, it is the core element connecting products and machines. In the work plan, the precise order of necessary processes for manufacturing any given product is specified, together with the respective processing times, changeover times, and other relevant information. The logic of the work plan is decades old. It is used in the general planning phase of the factory design process as a means to structure the manufacturing process and connect it with the favored technologies. Once the factory has been built, the same work plans are then used to steer and control the production system on a day-to-day basis (see Figure 4 as an example).

The main problem with the concept of the work plan is its lack of flexibility. Alternative means to perform certain tasks are cumbersome to integrate in a way that allows for flexible and dynamic management of the production system. Furthermore, once a production order has been started, it is substantial and often manual additional effort to alternate the path of a product through the production system (e.g., because of a machine breakdown). Workers have to manually adjust the work plan and override specific parts to assign a specific order to a different machine than previously planned. This, of course, disturbs the resource utilization within the production system. It also creates potential new bottlenecks. Even though modern MESs can work with some challenges, they are still designed to work with different work plans and, thus, different predetermined sequences of machines for manufacturing a certain product. This problem is further enhanced by the fact that often, not all potential options for the transformation of a product at a certain stage in the process are known to the MES or ERP system. Often, this kind of knowledge exists in the minds of the workers. They will then reroute the production order to a different machine. In doing so, it is taken off the radar of the centralized planning system. Using the concept of the work plan to utilize this knowledge would require the creation of various work plans, each containing a specific route through the production system. If implemented consistently, the number of available work plans for most productions in a conventional SME would increase dramatically. It would make actual planning nearly impossible due to the number of available options, and IT system algorithms would continuously have to calculate and evaluate.

In order to solve this problem, many authors have presented ideas for more decentralized and agile planning approaches [46,47,48]. Until recently, these approaches seemed impossible. The reason was the lack of operational real-time data and computing power. However, with the emergence of the IIoT, together with cloud computing, artificial intelligence, and the improvements in the computing power of PLCs, more and more authors deem this concept of decentralized autonomous production planning and control feasible, even for SMEs.

2.3. Smart Production Control and Service-Oriented Architectures

Due to the deficits of the existing IT solutions cited above, the rapid increase in the affordability and availability of computing power (especially on the Edge), and the rise of the IIoT, more agile and decentralized approaches have seen a tremendous increase over the last decade [28,49]. In particular, the rise and ubiquity of CPSs in the wake of the IIoT is a crucial component. The trend towards transparent production and logistical systems based on the availability of real-time information would not be possible without these CPSs. The combination of computing power with sensors and network connectivity allows for the gapless tracking and tracing of almost all material and production/customer orders throughout the entire production system. This counts across company borders and the supply chain [28]. Based on these technological trends and improvements, various concepts for enhanced planning and control of production systems were developed [50,51,52]. Another approach that has received a lot of interest and attention in Industry 4.0, in general, is concepts tied to utilizing artificial intelligence (AI). The idea of applying AI to the domain of manufacturing (e.g., for scheduling problems) is not new. The first concepts go back to the year 1999 [53]. Following the initial attempts, various concepts in different application areas were developed. They ranged from the prediction of production costs and the evaluation of different layout/organizational concepts to the domain of predictive maintenance to real-time scheduling on the shop floor [54,55,56,57,58,59]. The approaches, depending on the application and the area of consideration, encompassed methodologies ranging from supervised and unsupervised learning to algorithms from the domain of reinforced learning. For a more extensive and detailed review and analysis of these concepts and studies, please see [28] and the literature cited there.

Even though the algorithms and concepts often produced tangible results in many of the abovementioned cases, almost all these developments suffer from the same fundamental problem. This problem is described by [28,60] as the solution linearity problem. Almost all studies analyzed (that the authors are aware of) used specifically designed or pre-processed data. These data had been cleaned, explored, and further processed in a linear process until the results were generated. The problem is that real-life manufacturing is dynamic. Relevant parameters like processing times, setup times, available machines, maintenance intervals, and many more constantly change. Often, these changes are not documented in the company’s IT systems. This leads to a phenomenon called conceptual drift [60,61]. Since inconsistent data undercut all results generated, a linear approach would be only sustainable with massive and constant human support, if ever.

Following these lines of argument and considering the presented challenges, various authors suggest the concept or approach of service-oriented or microservice architecture. This suggestion is a counter design to the monolithic conventional production planning systems. The concept is easily scalable and highly adaptable. Also, past research has indicated that these self-adapting and self-optimizing multi-agent distributed control systems perform better and are more flexible compared to conventional systems [28,62].

The origins of the SOA concept emerged in the IT world as a model for infrastructure architecture in the early 2000s [63]. The general idea was to provide a solution to a typical problem with the automation pyramid (cf. Figure 1): various functionalities existing in multiple applications at the same time, increasing (among other things) maintenance costs, adding unnecessary complexity to the infrastructure, and, due to missing interfaces and consistency checks, posing the risk of different data sets for the same indicator in different systems (e.g., a credit check). The fundamental idea of SOA was to design infrastructure around services rather than applications. Instead of designing and building entire software applications, programmers focus on the orchestration and the allocation of services. Services are small units of software that contain a certain functionality [63].

Since its emergence, SOA has been adopted by numerous other disciplines. In the context of this paper, the business context is the most important. Here, SOA can be understood as a set of services businesses offer partners, customers, or other members of the same organization [64]. In terms of a manufacturing system, this can be understood as follows: machines offer services (the transformation of goods/materials) according to the customer’s needs. The customer (depending on the chosen granularity) can be the company’s customer, a specific department, or a piece of material that needs to be transformed to become the desired product. The interaction between machines and material/customer orders can then be decided decentralized and situationally, depending on various factors like processing state, capacity utilization, or the setup of the machines. The allocation of machines and material/customer orders is consequently not planned in a centralized manner but rather decided situationally. Figure 5 illustrates the concept in the context of a completely digitized factory shop floor.

After the customer order has been placed and processed, a manufacturing order is generated in the cloud. The specific order is then connected to the material (or rather, its digital twin) and a CPPS component is created. This component contains all necessary information about what transformations (services) are necessary and in what sequence. After the production order has been released, the part will “negotiate” its way through the production system. This happens by constantly communicating with the entire system or a subset of the machines regarding who can perform the next necessary task. Depending on the current state of affairs, the machines will estimate how much the transformation would cost. Based on this, the selection will be made until all necessary transformations have been performed.

Following these explanations, the following requirements arise for a basic description logic for data within manufacturing companies about their use in production:

• In order to be applicable in a real-life environment, existing data from ERP or MES systems must be integrated without too much effort.
• New or altered data from a digitized shop floor (in part or fully) should be easily integrable (e.g., changed process times and altered maintenance intervals).
• Changes in the manufacturing system (e.g., new machines and other resources) must be integrable without much effort.
• The same applies to changes in the production program: adding new products or materials to the production system or removing expired ones must be easy and carried out with low effort.
• The logic must be applicable in and support the factory and technology planning processes. It must also work when it comes to operational production planning and control.
• The logic or programs applying this logic must provide a low hurdle threshold for integrating implicit worker knowledge (e.g., the integration of new allocations of production resources and materials or manufacturing tasks).

Independent of the supposed solution, none of the concepts and methodologies mentioned above offer a realistic solution for the abovementioned requirements. The question of how to design a system or a methodology in which the relevant pieces of data and information can be stored, used, and presented in a way that allows for self-sustainability but also uses the existing data sets has not been found so far. This is where the authors propose the following basic task logic to make a difference.

2.4. Basic Task Logic

In order to provide a solution that meets the requirements listed in the previous chapter, the authors decided to use a task-based approach created by [65,66]. This approach is based on a process-centered logic that was created by [67,68,69,70] for the planning and design of production and logistics systems. The investigation, evaluation, and development of manufacturing flexibility in conventional production systems were also addressed by [42] using this task-based methodology. Due to the fundamental process logic at the model’s core and the resulting self-similarity, the level of granularity in the analysis and evaluation can be easily and smoothly adjusted.

The separation, or rather, the distinct response of two questions, which in manufacturing are typically answered in one step, is the core tenet of the basic task logic. The how and what of each transformation during the creation process of a product within the manufacturing system are the subjects of these queries [65,66,71]. Creating a work plan that directly connects each necessary transformation (what) to a particular machine (how) provides a general solution to these concerns. A fundamental explanation for the growing complexity in manufacturing is established by directly responding to these two queries in one motion. Every choice for how the transformation might be accomplished has to be documented in a different document because the transformation and means are directly linked in the work plan. Additionally, because the same limitations apply here, it greatly restricts the adaptability of models for flexibility analysis and evaluation [42].

As mentioned in different sections of this paper, such limitations are particularly difficult in the context of strategic factory planning. This is because, with the definition of the work plans, many technological questions are addressed. Subsequently, design options are eliminated at a time when greater flexibility and alternative design options would be highly advantageous [72,73].

The same does also apply in the domain of the operational control of the production system, as has also been stated in various instances in this paper. Separating the task from the means of the transformation would allow for a more flexible allocation of processes and resources. Also, it allows for a much more decentralized steering and control approach.

Work plans do not distinguish between tasks and processes; task-based approaches do. Both an internal and an outward perspective are present in tasks. The external perspective includes relevant objectives (such as costs, performance, or efficiency) and materials (such as information and materials). In the domain of operational control, the main objective would be the timely completion of a specific production program (with specific volumes and variants for a defined number of products). The material (parts and components) required for the manufacturing of the production program across all intermediate stages, as well as the initial and final states of these objects related to each specific task, would be the most pertinent features of the objects.

Thus, the external view of tasks defines two things through the precise specification of the respective initial and final states of the task objects along the respective task chain: First, the logical sequence of the subtasks (pre- and post-events) is defined. Second, the objectives to which the activities for the fulfillment of the task must be designed towards are defined. These traits, which represent the internal view of the task [42,65,66], are used to characterize the activities whose proper execution leads to the completion of the associated task.

The entities transforming the objects are resources and methods, specifically. The productive performance capacity of people and machines within a given manufacturing system constitutes the resources. On the other hand, methods define how a task’s objectives may be accomplished. In this regard, also, the regulations that must be followed and the fundamental principles that must be adhered to must be named. The work step sequences and the related work instructions are of major interest to this study. They specify the order in which transformation tasks must be completed to create a final task object effectively. They also define process structures that dictate how production systems are divided into organizational units. This has a big impact on how production systems are structured and, consequently, how much system flexibility should be taken into account [42].

A process [74] or an operation [71] is the actual performance of the actions required to complete the task. Tasks have more degrees of freedom than processes because they can be completed in numerous ways depending on previous events and input items [65]. As a result, different activities may be used to complete a task. Concerning the desired logic of SOA, this concept provides the flexibility needed in operational scheduling and control.

The following Figure 6 graphically exemplifies the basic task logic.

Within the basic task logic, the central linking element—just as in the case of the work plan-based linking of the products with the system resources—are the transformation tasks to be performed. In order to provide a fundamental description framework that allows not only for the allocation of production resources and necessary transformation but also supports the answering of the question of what resource can perform what task, further aspects need to be considered. Due to the focus of this study being on production systems (operational and strategic), only value-adding manufacturing and assembly tasks, as well as the overall production program, will be considered in more detail below. However, a transfer of the logic is also possible for assistive tasks such as logistics and the like. For this paper, a limited focus on operational control and factory/technology planning was deemed sufficient.

The overall transformation task to be performed by a production system can be broken down into individual, defined subtasks. Their (the subtasks’) sequential execution in accordance with the process organization generates the task chains underlying the overall transformation task [42]. These elementary transformations represent the most detailed consideration level for this work. Following the limitedness of the production program in extent and composition, the elementary transformation tasks to be accomplished within the production system for the production of this production program are also limited in their number.

According to the above explanations, a basic task describes the transformation of a defined input (task object) into a defined output (transformed task object). These individual basic tasks and the then transformed task objects are product-neutral and can be assigned to any product to be manufactured and, thus, to any task chain. This logic is displayed in Figure 7.

The individual basic tasks need to be linked with the primary resources of production systems, the work equipment, and the personnel in a product-neutral manner. Therefore, certain competencies must be assigned to these resources. In order to be able to take cost and performance aspects into account as well, performance factors also need to be considered. The basic assumption is that a work resource and an employee are always required to perform a basic task. This connection exists for all tasks to be executed within a production system. In the following, only the granularity level of the basic tasks is considered further, according to the preceding remarks.

Following the basic logic of tasks and processes described at the beginning of this chapter, several basic processes can arise from a basic task. This depends on the resources potentially allocated to the task in the context of production factor allocation. Each resource capable of transforming the initial object into the desired final state using different processes and thus fulfilling the task objectives will generate a new basic task. The number of basic processes arising from a basic task thus depends on the number of different production resources that are capable of performing the required transformation service on the task objects concerned (see Figure 8). For further explanations, the focus will be on the machine side of the allocation. This is not to neglect the operator’s role in the value creation process but rather to keep the model as lean as possible at this stage. Furthermore, the fundamental logic operates in a way that allows the subsequent allocation of personal [42].

The goal is to automate the connection of basic tasks and production resources and design the creation and maintenance of the database to be as lean as possible with as little labor as possible. Therefore, it is necessary to allocate tasks and resources based on parameters [42].

The extended parameterization of basic tasks and production resources follows the guiding principle of a largely automated selection of the resources that come into question for a defined transformation task (basic tasks). This requires the definition of additional parameters common to all basic tasks in a production system, which can be used to determine the principal capability of the respective resource to perform the transformation required within the individual basic tasks within the framework of pairwise comparison. Only if the work equipment possesses the appropriate characteristics for all basis-task-describing parameters can the appropriate basis task capability be assigned to it. These additional description parameters are thus to be understood as filters. They reduce the quantity of the objects, which can be parameterized manually during the admission of new system objects (work equipment, personnel resources, or basic tasks).

These additional description parameters result from the properties of the task objects to be transformed within the scope of a basic task, the properties of the transformed task objects, and the transformation task itself. The following description parameters are only to be understood as suggestions for task parameterization. They do not raise in any way the requirement of completeness or applicability for each production system [42]. They rather serve the execution and visualization of the underlying logic. An excerpt of the potentially relevant parameters is as follows:

• Geometric dimensions;
• Weight;
• Material;
• Shape and position tolerances.

In addition to the criteria listed above, companies can substitute these description parameters with others or add additional ones, depending on the transformation task to be performed. The only decisive factor is that all parameters which would disqualify a work tool or an employee for the execution of a basic process are considered.

In addition to these criteria regarding the selection process of whether a machine is capable of performing a certain task, it is also necessary to specify the following aspects:

• The performance capability of the machine for a specific task;
• The available capacity in a given timeframe (e.g., shift model or hours per day);
• The fix cost of the machine;
• Variable costs for the basic process.

An example of the selection of relevant criteria could be [75]. This is, however, without claim to completeness.

Figure 9 shows an exemplary parametrization of basic tasks and machines.

The following chapter shows different areas to which the concept of the basic task logic has been applied. This includes strategic technology and flexibility planning, as well as the use of CPSs for semi-automatic data extraction and operational scheduling.

2.5. Advantages of the Basic Task Logic Compared to Conventional Work Plans

The basic task logic presented above offers numerous advantages compared to conventional work plans across all factory lifecycle phases and the development of dynamic, decentralized production system configurations. Within Phase Two of the factory planning process, work plans are used to determine different and often alternative manufacturing alternatives for given products. The connections made at these stages within the process chains of the respective products by the definition of work plans are seldom questioned in the further processes. This substantially limits the flexibility of the planner in the design phase. Not all potential connections and feasible ways of making a product are often established and considered, since this would lead to too many different work plans to design and consider. With the definition of task chains on the product side and competencies on the side of the machines, it is possible to almost automatically generate different options at each stage of the manufacturing process, thus offering the planner way more flexibility later in the factory and technology planning process.

The same task chains used in the planning stage can also be used in the operational phase of the production system. As explained in Section 2.2, work plans connect machines and products. They are inflexible and have a large maintenance requirement. Whenever a machine leaves the production system, it must be removed from all the workplaces it is part of and replaced with alternative machines with the relevant capabilities. By applying the basic task logic, it would only be necessary to eliminate the machine from the system, and all basic processes connected to it (or rather constituted by it) would disappear. Whenever a new product is to be included in the production program and thus the production system, it is necessary to (mostly) manually draw up work plans and alternative work plans. By parameterizing the object (product), it is possible to eliminate most of the machines within the production system at every stage of the process chain, leaving the relevant ones for the planner to sort through and then parameterize. This also allows all possible options to be parameterized, not only the two most prominent ones. This will also enhance operational flexibility due to having more options per manufacturing stage.

These advantages become more obvious when considering factory planning in a brownfield scenario. Redesigning an existing factory usually does not result in creating a completely new production system. Usually, some new equipment is added while some existing equipment is sorted out. With the basic task logic in place, the analysis of an existing machine park against various production programs can be carried out with much less effort, and new equipment can be tested/considered with less effort and can be more easily integrated.

Suppose all machines within a production system are CPSs capable of communicating with each other, and the same is true for the parts and components that have to be manufactured. In that case, the basic task logic offers the opportunity for decentralized control without previous database adaptation. Since all the machines “know” what they are capable of and all products “know” what task needs to be performed in what order, service-oriented architectures can be implemented that allow for a decentralized allocation of products and resources that would be impossible to achieve with conventional work plans.

In an Industry 4.0 production system composed of CPSs and operating within the RAMI 4.0 framework, the basic task logic would offer a further advantage regarding the maintenance and actuality of production data. If all machines are connected and report real-time data via the integration and connection layer towards the higher applications, this can be used to constantly check the process and setup times within the machine profiles for accuracy. If machines run slower or processes have been optimized, this will automatically be noted, and the parameters can be adjusted. This will then be considered in the resource-product allocation process, potentially leading to different allocations that would not happen with conventional work plans due to the lack of feedback. It would also be possible to implement this automated data update loop with work plans. However, due to the logic of the automation pyramid discussed in Section 1 (see Figure 2) and the priority of the work plans set therein, this would not affect the operational allocation, thus losing efficiency in the manufacturing process.

3. Results

In order to demonstrate the potential of the basic task logic as a foundation for factory planning and also operational planning and control in the era of Industry 4.0, different application scenarios will be presented.

3.1. Strategic Flexibility Planning

One of the biggest challenges for manufacturing companies in various industries is the design of flexible yet efficient and cost-effective manufacturing systems [1,41,76]. Usually, creating flexibility means additional machines to compensate for fluctuations that cannot be met by resource allocations or additional shifts alone. The strategic decision to purchase new equipment and machinery is often based on the strategic capacity evaluations carried out with the data available in the existing IT infrastructure, mostly the ERP systems. However, the dependability of these results is questionable at best. This is given the fact that a substantial amount of the data in these IT systems do not necessarily represent the actual state of affairs within the production [28], and the true capabilities of the production system to manufacture certain volumes are often unknown.

Against this backdrop, the fundamentals of the basic task, in combination with the process-oriented factory planning approach by [67], were used by [42] to quantify different types of flexibility across various production scenarios for a manufacturing company. In this project, the basic task logic allowed for the very flexible analysis and evaluation of individual process chains across multiple system configurations and production programs. Due to the fact that it was very easy to generate new basic processes by simply assigning certain machines basic task capabilities, the true potential of the production system was extracted from the minds of the workforce.

As a result of this analysis as well as the subsequent redesign of the production systems’ general structure, the company did not need to purchase new equipment but was rather able to restructure its shop floor based on a more flexible and agile philosophy. Key to this success was the task-based analysis of the production resources and the production system’s inherent volume and mix flexibility.

3.2. Operational Data Cleansing and Job-Shop Scheduling

The key to the previously described success in the factory planning project was the thorough analysis, evaluation, cleansing, and enhancement of the production data. The initial data were (as is often the case in these kinds of projects) redundant (ERP and MES), inconsistent, incomplete, or simply false. Using the basic task logic made it possible to use one work plan as an initial representation of the basic task chain. This expression of the necessary chain of transformations was then used to deduct the number of necessary transformations and their content, as well as the desired input and output. This was cross-referenced with machines with comparable properties and manufacturing technologies to generate additional basic processes. This list was then cross-referenced with past production programs and their respective resource allocation. Even though the system was only partly digitized at the time, the actual pairings (machine–customer order) were visible in the data, and thus, more basic processes were defined and basic task capabilities distributed. As a final check, the list was given to the employees within the production system to fill in the machines that were missed thus far.

Even though the process was long and sometimes painful, the results were astonishing. Due to the heightened transparency, various types of flexibility were much higher than previously anticipated. The biggest effect, however, was on operational scheduling and short-term flexibility. With the additional manufacturing options identified at various stages in almost all supply chains, the strategic and tactical capacity planning within the ERP system became much better, leading to fewer inconsistencies and to a better and more realistic production program for the MES to refine.

The biggest impact with regard to this paper, however, is the potential for automated data enhancement with the help of CPSs. In production systems, every machine is at least loosely connected and at least capable of tracking process times and numbers. It is thus possible to use these data in combination with the information in the production order regarding material or product and targeted transformation. With that, suggestions for what machines have which basic task capabilities and how they perform can be derived automatically. Also, if machines are removed from the production system, they can be erased from the system, and automatically, all basic processes related to these machines will disappear as well. This happens without any additional search effort with work plans. These examples show that the task-based logic can provide a dependable foundation for manufacturing systems in a dynamic environment.

3.3. Technology Planning

The tooling industry provides an intriguing case study for exploring flexible models, as it faces two significant challenges in technology planning. Firstly, workpieces in this industry are unique, with specific geometries directly tied to the final product they are intended for. Secondly, the tool-making process is complex, both in achieving high-quality results and dealing with intricate geometries. Moreover, the involvement of complex process chains adds to the complexity. To ensure efficient production, industrial tooling often relies on a high degree of standardization for both products and processes [2]. A workshop-oriented approach, which lacks an application-oriented process flow, leads to diverse and inefficient production processes. Dealing with one-off production and the absence of learning effects pose particular challenges, requiring flexibility in tool production and associated departments [12]. Additionally, producing parts with strict tolerances, free-form surfaces, and high surface requirements necessitates using advanced manufacturing processes and high-quality machine tools. However, cost-effectiveness also demands efficient production methods.

In light of these challenges, the planning process in the tooling industry needs greater flexibility during both the planning and implementation phases. One way to enhance planning flexibility is by generating technology bundles based on key metrics derived from workpiece characteristics and the capabilities of available technologies within a specific shop floor. A technology bundle comprises various manufacturing technologies required for producing a workpiece. While selecting technologies within a bundle is company-specific, certain relationships and technology usages for specific parts can be considered universal and are described in available data sets.

Technology bundling serves as the foundation for developing technology chains, as the bundles contain the necessary technologies but not their sequencing. The sequencing of technologies within a bundle leads to the formation of a technology chain. Technology bundling must incorporate workpiece requirements and manufacturing technology capabilities. The technologies within a bundle for a specific workpiece must fulfill all its requirements for successful manufacturing. To achieve this, it is crucial to identify the key workpiece characteristics or requirements that guide technology selection for creating a bundle. Existing criteria in this research field have primarily focused on standardized and recurring processes for serial production.

As the number of applied technologies increases, production complexity also rises disproportionately. Hence, it is desirable to identify lean and standardized technology chains that minimize the use of diverse technologies for each workpiece. However, before implementing the identified technology bundles in production, the sequencing of bundled technologies must be determined to create a technology chain. A technology chain represents the sequential combination of manufacturing technologies that transform a workpiece from its initial condition to its final state with defined characteristics. Throughout the manufacturing process, the workpiece may undergo various temporary conditions facilitated by the technology chain. Retrospective analysis of technology sequences helps derive the sequence of manufacturing technologies within the technology bundles to generate technology chains.

Applying the generative design of technology chains to technology planning presents numerous possibilities. By integrating these options into the basic task logic mentioned earlier, production can be made significantly more flexible. Unlike traditional approaches, it becomes conceivable to make changes to the planned technological process chain even during ongoing production. This newfound flexibility allows for the agile rescheduling of subsequent technological steps in response to disruptions or changes, complementing logistical and organizational measures.

It is important to note that the use of alternative manufacturing processes requires additional operational planning steps, such as CAM programming for milling or producing electrodes for electrical discharge machining. Future research activities should focus on advancing the integration of planning systems, especially along the CAx (Computer-Aided Technologies) process chain.

4. Discussion and Conclusions

This article presented a task-based allocation logic for products and machines within manufacturing systems. The basic task logic offers distinct advantages compared to conventional work plans and can act as an enabler for SOA in manufacturing systems. To show the advantages of this logic compared to the conventional work plan approach, we discussed the most prominent fields affected, factory planning and operational planning and control, and the existing and future IT infrastructure by looking at ISA-95 and RAMI 4.0. The basic task logic approach offers a new level of flexibility from factory and technology planning to operational production planning and control. By incorporating those disciplines which have ever been separated from each other in classical production environments, the new approach can overcome classical barriers and lead to a new level of agility and responsiveness.

Industry 4.0 is revolutionizing manufacturing processes by integrating cyber-physical systems, advanced automation, and data-driven decision making. In this context, service-oriented architecture (SOA) is a promising framework for enhancing the interoperability and agility of Industry 4.0 systems. This paper explored the integration of the SOA approach within Industry 4.0 and its contributions to networked systems, new data protocols, and digital twin solutions.

However, the conventional allocation of products and manufacturing equipment through work plans, as is standard in the IT infrastructure of Industry 3.X, does not serve as part of the future of manufacturing. The restrictions and limited flexibility associated with this concept do not allow for the flexible, situational allocation of products and machines, nor support the automated updating of information in higher layers of the RAMI 4.0 framework when it comes to aspects like process improvement on machines of changes in machine availability. The basic task approach presented in this paper offers a potential solution. Separating the what (tasks or transformation) from the how (machine) allows for a dynamic and situational allocation. This lays the groundwork for the potential implementation of SOA in manufacturing systems as a means of decentralized control. The same applies to data consistency and data maintenance in connected factories. The integration of the SOA approach in Industry 4.0 could enable the creation of networked systems that facilitate seamless communication and collaboration among various components, including machines, devices, and software systems. When incorporating the SOA approach in Industry 4.0, new data protocols that enable effective data management and analysis have to be developed. Leveraging the principles of service orientation, these protocols have to facilitate the capture, processing, and transmission of data throughout the industrial network, ensuring real-time access to accurate and relevant information.

Furthermore, utilizing the SOA approach in Industry 4.0 contributes to implementing digital twin solutions. Digital twins, virtual replicas of physical assets and processes, enable the simulation, monitoring, and analysis of industrial systems in a virtual environment. By integrating the SOA approach, digital twin solutions should be enabled to seamlessly interact with other components of the Industry 4.0 ecosystem, allowing for real-time data exchange, performance monitoring, and remote control, thereby facilitating improved operational efficiency, predictive maintenance, and product lifecycle management.

It has to be emphasized that the presented work consists of a theoretical framework aiming at contributing to a solution for a classical dilemma in production and factory planning. In order to be able to determine the necessary investments in industrial implementation with sufficient lead time, a significant part of the factory planning in classical approaches is based on well-founded assumptions. The rigid allocation of work plans to resources and machines means that decisions, once made, cannot be adapted or can only be adopted with great effort. The depiction of work tasks as necessary transformations on the product, to which specific resources are only allocated subsequently, now makes it possible for the first time to make simple and thus late changes in the production process. This means that technology and factory planning are much more closely networked, and the system as a whole is more agile and flexible. In the operational implementation, this results in another advantage: if data are recorded in production, it can now be directly assigned to the described transformation. These data are also directly available in the event of a change in the existing process chain or future replanning.

Further research needs to be carried out to evaluate the presented framework. Above all, this future work must aim to realize application examples in pilot plants and real industrial environments. When evaluating the presented framework in industrial applications, the main focus has to be on measuring the effects of planning agility and speed, the achievable flexibility increase, and the impact on productivity. Choosing an environment where classical technology and factory planning methods are already in use offers a chance to directly compare the results and identify potentials and further needs of the proposed methods.

Further integration aspects could address the area of humans in the manufacturing system and environmental aspects. Parameterizing basic tasks and machines to incorporate aspects that are harmful to humans, as well as aspects like energy consumption or other sustainability-related aspects, could enable production planning and control that optimizes these methods towards several goals.

In conclusion, the main contribution of this paper is the task-based description logic which offers a different fundamental logic for connecting machines and products dynamically and flexibly. By offering a content- (task) and competence (equipment)-based allocation approach for the connection of material and machines within production system design and steering and control, an initial challenge for implementing service-oriented architectures can be solved. The basic task logic described is compatible with the existing allocation logic within the old Industry 3.X era IT systems while simultaneously being compatible with the anticipated decentralized structure of the next generation of production systems. This future structure will be based on the RAMI 4.0 framework. Furthermore, the applicability of the basic task logic both in the domain of factory and technology planning and later during the operational phase within a factory’s lifecycle offers less data inconsistency and fewer media breaks and interface challenges than is the case in the current IT environment.