1 Introduction

Modern production environments are required to cope with changing market demand, mass customization of products, and shorter product lifecycles. Reconfigurable Manufacturing Systems (RMS), characterized by their ease of adaptation to changes in product design and production requirements, surpass other manufacturing systems in throughput, cost-effectiveness, and the ability to accommodate product variety [1]. The concept of Plug & Produce is within the topic area of RMS, and it is centered around the automatic addition and removal of manufacturing devices with minimal intervention [2]. Furthermore, Plug & Produce systems adapt to a variety of new or modified products through in-house competencies that prioritize manufacturing processes rather than machine function programming [3]. The reconfiguration ability of the Plug & Produce system requires autonomy among the system’s components, which is realized with multi-agent control [4]. In multi-agent control, each piece of equipment is controlled by an agent. These autonomous agents negotiate and decide the allocation of tasks automatically without manual intervention, achieving flexibility in job-shop task allocation through autonomy [5]. The multi-agent controller approach proved valid to support the concept of Plug & Produce [6, 7]. Notably, the IDEA project validated with industrial experiments the effectiveness of multi-agent control in achieving seamless shop-floor reconfiguration [8]. A more recent advancement in multi-agent control of Plug & Produce is the Configurable Multi-Agent System (C-MAS), which implies that all agents are configured rather than programmed, as in many other similar concepts. C-MAS shortens engineering time and reduces the level of needed competencies [9]. Indeed, autonomous decision-making improves efficiency by automating task distribution and execution and providing optimization possibilities during runtime. However, the autonomous feature complicates the implementation of safety measures. The complexity is twofold: (I) after a system reconfiguration, the system must be examined to identify possible new risks, and new safety measures must be implemented if needed. This requirement adds to the time needed for the system to reach full operational capacity which opposes the advantages of the Plug & Produce concept of flexibility [10]. (II) The risk assessment must be performed in a way that perceives every possible task distribution and plan execution, and the consequent safety measures must cover all these possibilities. The difficulty of perceiving the exact behavior of the system leads to the implementation of overly restrictive safety measures. This in turn limits the system’s flexibility and ability to make decisions for efficient production. There is a gap in the scientific literature and the current practices regarding addressing these safety-related issues. Traditional industrial safety solutions in manufacturing often deal with predefined scenarios and perceived flexibility, which are insufficient for the unforeseen changes characteristic of Plug & Produce systems. In Plug & Produce systems, manufacturing equipment and produced parts are not always known during the design stage, making traditional safety approaches inadequate. Furthermore, the review of related works provided in this paper shows that there is a need for proactive safety methods, within the smart controller of Plug & Produce to dynamically adapt to new configurations without compromising system flexibility. This research is motivated by the need to address the gap in ensuring the safe operation of RMS, specifically Plug & Produce systems, while preserving their inherent flexibility. The objective is to propose a method that enables the realization of the Plug & Produce concept in modern manufacturing environments. As automated manufacturing moves towards more human integration, this research aligns with the goals of Industry 5.0, which focuses on designing human-centric manufacturing systems. This paper addresses the issue of safety assurance after reconfiguration and the safety challenges coming from the autonomous nature of the Plug & Produce system. It presents a control method within the Plug & Produce multi-agent controller, realized through an algorithm that forms an integral component of the strategy utilized by individual agents. The paper has implications for human-centric and reconfigurable manufacturing as the proposed method is an enabler for safe and flexible Plug & Produce systems and it is essential for their practical implementation and realization. The proposed control strategy ensures safety after reconfiguration without the need for manual modification of the control logic, and it copes with the autonomous decision-making by planning safe operations without limiting flexibility or reliance on overly restrictive measures. The contribution of this work is twofold: (I) a control method that enables the Plug & Produce multi-agent controller to automatically generate the runtime safety requirements and autonomously distribute the shop-floor tasks in a way that satisfies the safety requirements. The proposed method makes safety more proactive rather than reactive, and it complements the safety-related part of the control system by incorporating within the multi-agent controller the capability to predict risk events. Accordingly, the method enables the control system to autonomously schedule operations in a way that avoids safety stops. (II) The method prevents risk situations by specifically avoiding combinations of equipment that could potentially lead to risk. However, it does not impose a complete restriction on equipment operation. Instead, the method allows the equipment to participate in other processes that are considered safe and do not pose a risk of harm. This flexibility allows for more effective utilization of equipment while maintaining safety requirements. There are limitations to the scenarios where the methodology proposed in this paper can be applied. This paper focuses on the operational safety of RMS, specifically Plug & Produce systems at the system control level. It does not address the safe design of individual components, physical safety barriers, or emergency stops within a manufacturing system. Additionally, ergonomics and hazards from unintended resource use are beyond this paper’s scope, as these topics are covered by established safety assurance methods and engineering practices. The proposed method does not involve altering or bypassing the safety PLC, which remains an essential component of the safety infrastructure. Instead, our method complements the safety PLC by providing an automatic safety assessment method that is integrated into the operational planning, ensuring that the system can adapt dynamically to new configurations while maintaining stringent safety. The proposed method is specifically for reconfigurable and discrete manufacturing cells and may not apply to process manufacturing environments. Industries like chemical processing or food and beverage manufacturing, which rely on continuous processes, have different safety requirements that this methodology may not adequately address. This paper is organized into five sections; Sect. 1 introduces the topic area, the research problem and the contribution of this paper. Section 2 presents the related work and the theoretical framework of the proposed approach. Section 3 describes the proposed method for safety reasoning in MAS control Plug & Produce. Section 4 describes a manufacturing scenario, the results, and the discussion, and Sect. 5 describes the conclusion and future work.

2 Related work

Despite the wealth of literature on the design and management of RMS, the topic of safety assurance and risk management remains limited. Recent studies have recognized the importance of human integration and are now addressing safety assurance in RMS. One line of research advocates for incorporating safety considerations at the layout design stage of RMS [11]. This approach is complemented by efforts aimed at optimizing ergonomics to enhance the safety and efficiency of operations [12]. Tools have been developed to aid safety managers in conducting safety analyses and in the ergonomic design of system layouts [13]. The design of the safety-related part of the control system has also been addressed, with an approach to functional safety that revolves around the dynamic and rapid reconfiguration of the safety system to adapt to changes within the manufacturing setup [14]. These design approaches emphasize adjusting the safety measures rather than planning the distribution of tasks to avoid potential risks. There is a need for proactive risk management techniques that can as well retain system flexibility without imposing restrictive safety measures [15]. The second line of research focuses on the incorporation of advanced sensors and monitoring to improve safety. Recently, the main application of advanced sensor technology has been improving the health and safety of workers [16]. Integrating sensing and prediction into robot controllers allows robots to dynamically adapt their actions based on human interactions and predefined task execution plans [17]. Also, advanced sensors enable robots to determine the best control strategies for various levels of human–robot interaction. They can switch to an appropriate collaborative mode based on sensor data, such as stopping the robot if a human is detected too close or replanning the robot’s path to avoid collisions [18]. While these technologies are crucial in robotics, their application is currently limited to robotic systems and has not been extended to other machines and processes in manufacturing settings. Additionally, hazards in Plug & Produce systems are not confined to a single process or device; they emerge when several components are configured together in the system [19]. This necessitates methods for planning on the system controller level. Furthermore, integrating sensor data with existing manufacturing systems can be complex and costly, requiring significant upfront investment in technology [20]. In this work, the objective is to address the risks within the multi-agent control of the RMS proactively. Multi-agent control is advantageous in RMS as agents autonomously accommodate new scenarios through collaborative decision-making among human workers, machines, and robotic systems [21]. It enables optimization of manufacturing processes and addresses the challenges posed by dynamic production environments and customer demands [22, 23]. In the topic of safety, scheduling in multi-agent control is employed for collision avoidance. Key concepts include path planning, where algorithms determine the routes, agents should take to reach their destinations without collisions [24]. Temporal aspects are crucial to avoid collisions, especially in dynamic environments, by scheduling the timing of movements to ensure that two agents do not occupy the same space at the same time [25]. This has been applied in autonomous vehicles to ensure that self-driving cars do not collide with each other or with human-driven vehicles [26] and in robotic swarms to coordinate large numbers of robots and avoid collisions [27]. Despite the advancements in MAS and dynamic scheduling, the application of these technologies has had a limited focus in the domain of safety of manufacturing, primarily concentrating on collision avoidance in autonomous vehicle contexts, rather than comprehensive manufacturing systems. Additionally, the literature review reveals a gap in proactive safety management strategies within RMS. Most existing research emphasizes reactive or immediate solutions rather than ongoing, dynamic risk management strategies. Notably, existing agent architectures in manufacturing propose a part agent that is responsible for scheduling and resource allocation, utilizing model-based reasoning for production goals and cooperative scheduling [28, 29]. In this work, a model-based approach is chosen for safety reasoning in multi-agent control of Plug & Produce and the theoretical framework is further described in the next subsection.

2.1 Theoretical framework

The model-based approach in MAS leverages the use of computational models to represent the system, its components, and the interactions among agents. Model-based reasoning is the agents using computational models to reason and collaborate on decision-making. This approach typically relies on creating a formalized representation of the agents’ goals and the available resources to achieve these goals [30]. Within this framework, agents utilize their internal models to reason about the environment, predict the consequences of their actions, and make informed decisions to achieve their goals [31, 32]. On the other hand, the model-based safety approaches are centered on a formalism model of the control system and the safety-related information, followed by a safety analysis of the formal system model [33]. It offers automation opportunities for safety analysis in complex systems [34]. These methods enable automation of the traditional safety analysis [35,36,37] and allow quicker design processes that integrate safety considerations [38]. In addition, model-based approaches closely integrate safety and the design models which enables the reusability of the safety-related information. This is particularly important in a changing environment such as a Plug & Produce as safety models can be traced and reused after a change in the system [39]. Furthermore, model-based techniques enhance interoperability and reusability of safety knowledge contributing to the automatic generation of safety requirements, which can be deployed manually with system support [40] or automatically to a safety PLC [41]. Also, model-based safety approaches enable verification of safety before production. Verification is a critical step in ensuring the efficacy of safety measures as the safety of manufacturing processes can be verified before the start of production on the factory floor. For verification of safety, model-based approaches leverage formal methods in traditional and autonomous control systems [30, 42, 43]. By adding safety models to the system model, agents can use these models to reason about safe behavior and adapt to the new manufacturing requirements. This enables adaptive safety measures that can dynamically adjust to changing conditions. This is commonly used in the control of autonomous vehicles, as it supports adaptive safety measures, enabling vehicles to dynamically adjust their behavior in response to changing traffic conditions [44,45,46].

The literature reviewed in this study provides a comprehensive overview of existing approaches to model-based reasoning for multi-agent control in reconfigurable manufacturing and its role in facilitating adaptability through collaborative decision-making. Previous research in the safety of RMS has predominantly focused on reactive functional safety measures aimed at minimizing risks associated with known scenarios or solutions that are limited to robot collision avoidance and individual processes. In contrast, the work presented in this paper extends beyond existing frameworks and introduces a novel solution to address safety in reconfigurable manufacturing on a system level, prioritizing proactive safety measures, through planning, to avert risk scenarios altogether.

3 Safety reasoning in MAS control Plug & Produce

This section describes the proposed method for safety reasoning in MAS control Plug & Produce. It includes three subsections; the first subsection describes the proposed control architecture, the second subsection describes the method for agent reasoning for risk scenarios, and the third subsection describes the proposed algorithm to implement the agent reasoning.

3.1 The MAS model for control of a Plug & Produce system

In the MAS model, there are two types of agents that are parts and resources. These agents have interfaces that are used to match and negotiate with each other. A part agent represents a product, and it is configured with goals that describe how the part is manufactured from the start until a finalized product is achieved. A resource agent represents a manufacturing asset. For instance, a robot, a machine, or a human operator is a resource in the Plug & Produce system. A resource agent is configured with skills that represent the capabilities of the corresponding physical manufacturing asset. Both part’s goals and resource’s skills utilize process plans which are data entities that include a structured text code. These codes include demands for skills on abstract interfaces. Meaning that a certain skill is demanded to be executed without specifying the resource that owns the skill. This non-restrictive design of process plans enables a flexibility aspect, in which a part autonomously determines the execution of an abstract plan based on its strategy. Another aspect of flexibility enabled by this design is that skills can also be abstract. This is typical for a skill that requires other skills to be able to complete its task. An example is a robotic gripper tool that has the skill “\(load\).” This skill will include a process plan that demands another skill “\(moveTool\)” that can be offered by a robot.

In this model, the part agent has a strategy that constitutes the methods to reach its goals. This strategy includes choosing a process plan that solves the goal with the lowest cost and allocating tasks/skills to resources. Also, the goals have preconditions that describe the criteria that must be fulfilled before running the goal. The preconditions are generated automatically based on the manually created sequence of goals. If several goals have fulfilled preconditions, the goals are allowed to run in parallel if enough resources are available for a parallel behavior. Indeed, the resource agents communicate to their corresponding physical entities through the instructions in the structured text code in the process plans. For the human operator, its resource agent negotiates with other agents to include the operator within the production plans, and it controls the human-system interaction by delivering instructions and receiving input from the operator.

This paper proposes a formalism to incorporate and model safety-related information within MAS. This is a generic model that can be applied to versatile applications within Plug & Produce. In this proposal, agents use the safety models to perform automatic risk assessments of their goals’ process plans. Based on the risk assessment, the agents decide a behavior that avert risks in the production of parts. Hazard-related information is integral to the risk assessment process. Hazard identification, according to the safety standard ISO 12100, is to list all hazards within the determined machine limitation. This includes investigating the intended use of the machine and identifying any source of harm within the associated task. In a Plug & Produce environment, this corresponds to hazard identification of resources. Hazard identification of a single resource includes determining the set of skills that the resource can perform and identifying the hazards associated with each of the skills. When a process plan of a skill is composed in a way that only includes the agent logic that instructs the physical resource, the hazards can be easily identified and fetched from the hazard information identified in the design phase. However, when the process plan includes other skills to be achieved by other resources, then it is required to fetch the hazards related to these remote skills. Modeling the hazards associated with a skill allows for including this safety-related information within the system’s logical configuration and allows for the reusability of this information when the skill is demanded for the execution of a process plan.

Within the context of the proposed formalism, an agent interface is denoted as \(if\) and is defined as the tuple\(, if=\langle {S}_{if},{V}_{if}\rangle\), where \({S}_{if}\) is a set of skills of the interface and \({V}_{if}\) is a set of variables. A skill \(s\in {S}_{if}\) is defined as the tuple:\(s=\langle {\pi }_{s},{\tau }_{s},{H}_{s},{o}_{s}\rangle\), where \({\pi }_{s}\) is the process plan of skill\(s\), \({\tau }_{s}\) is the type of skill, \({H}_{s}\) is a set of hazards, and \({o}_{s}\) is operational space. A single hazard denoted \(h\in {H}_{s}\) is defined with the tuple,\(h=\langle {k}_{h},{\tau }_{h} \rangle\), where \({k}_{h}\) is risk level and \({\tau }_{h}\) is the type of target skill by the hazard\(h\). The operating space \({o}_{s}\) is the space in which a resource performs the skill \(s\) according to its configuration, and this attribute is used to detect the unsafe situations in a certain space. The term is adopted from the standard ISO 10218 and is used to represent the occupied space by a resource while it performs the skill\(s\). The operating space is defined by its shape, and it has a coordinate system that is relative to the resource coordinate system. The tuples defined for a MAS control Plug & Produce are summarized in a UML diagram as shown in Fig. 1, which defines the complete model of MAS control Plug & Produce and incorporates the safety models within the system control architecture.

Fig. 1
figure 1

The complete model of MAS control Plug & Produce, incorporating the safety models within the system control architecture

Full size image

3.2 The agent’s reasoning for risk scenarios

Agent’s reasoning on risk scenarios uses the information in the proposed safety models. To explain this process, an example is visualized in Fig. 2 and described as follows. Assume process plan \({\pi }_{load}\) for the skill “\(load\)” on a gripper tool. The process plan includes three skills, “\(pick\),” “\(moveTool\),” and “\(place\).” It is sufficient to choose the skill “\(moveTool\)” to further describe the part strategy.

Fig. 2
figure 2

The discovery of a risk scenario that includes a robot and an operator

Full size image

The skill “\(moveTool\),” which is achieved by a robot, generates a high-risk hazard \({h}_{moveTool}\). In addition, \({h}_{moveTool}\) is harmful to the operator. Based on this, the hazard of the skill “\(moveTool\)” is configured as \({h}_{moveTool}=\langle {high}_{{h}_{moveTool}},{opSkill}_{{h}_{moveTool}}\rangle\). To discover the risk scenario, the proposed part’s strategy instructs to check the risk level of the hazard, and in this case, it finds it is a high-risk hazard. Then, the strategy checks if there is any other skill in the system that overlaps with the operational space of skill “\(moveTool\).” Assuming the system is designed in a way that the operator’s skill “\(load\)” has operational space that overlaps with the skill “\(moveTool\)” of the robot. In this case, the part strategy instructs to check if the skill “\(moveTool\)” harms the operator while performing the skill “\(load\).” The part finds that the skill “\(load\)” that is owned by the operator resource and has the type ‘‘\(opSkill\)’’ is targeted by the skill “\(lmoveTool\) ”that is owned by the robot. Based on this information, the part books both skills “\(load\)” and “\(moveTool\).” This means that the part not only uses the robot to achieve its plan but also prevents the operator from being demanded, by another plan execution, to perform the skill load. Note that the operator is only prevented from doing a load and remains unrestricted in executing other skills.

3.3 The part agent method for goal scheduling according to the safety analysis

The purpose of a part is to achieve its goals, and the part’s strategy instructs the planning of goals. The part strategy includes methods of finding matching interfaces for the abstract plans [47]. Also, the part strategy includes methods for planning the execution of concurrent goals [9]. This section describes further development to the part strategy and includes a method for executing the goals safely with the lowest production cost. The proposed method runs on each part, and when several parts are added to the system, to avoid conflict over resources, one part at a time can plan.

A part plans its goals to avoid the violation of the safety requirements which are derived from automatic risk assessment of the parts plans. In line with the guidelines described in the standard ISO 12100, the risk assessment method consists of three steps. First, detect runtime hazards in the process plan; second, evaluate the risk level of the detected hazards; and third, perform risk prevention using control actions. The runtime hazard detection finds the hazard associated with the skill, considering that the skill’s process plan also may include other skills on other resources. This can only be done in runtime when all process plans are made executable. To achieve this, Algorithm 1 is proposed to be included in the part strategy for planning the safe execution of goals.

To achieve the part’s strategy, the algorithm generates runtime variables that include, for a given interface \(if\), an interface schedule denoted as \(s{c}_{if}\). The interface schedule has states included in a set \(St\) and it registers at each state \(st\in St\), the skills \({S}_{if}\) that are used in the parts’ plans.

The algorithm can be summarized by the following steps:

  1. 1.

    Get the next goal from the ordered set of goals \({G}_{p}\).

  2. 2.

    Get all executable process plans for the selected goal.

  3. 3.

    Select the plan with the least cost among the alternatives.

  4. 4.

    For each skill \(s\) in the selected plan, assess the risks associated with the skill using the risk assessment function.

  5. 5.

    Book the skill \(s\) and the skills in \({S}^{\tau }\) that are targeted by the hazards of the skill.

The outermost loop iterates through the goals \({G}_{p}\) and performs steps 2 to 5 for each goal in order. The function \(getAllExecutableProcessplans()\) returns all the possible combinations of resources within alternative executions of part’s \(p\) goal \({g}_{p},\) and they are stored in the set \({\Pi }_{g}^{alt}\). Then, the function \(selectPlanWithLeastCost()\) returns the least cost executable process plan. The inner loop iterates through the skills of the selected process plan and includes risk assessment and booking of the skills.

Algorithm 1
figure a

imposes the safety requirements in the planning of a part agent goals.

Full size image

The function \(riskAssessment(skill: s)\) takes a skill, \(s\), as an input and returns a set of pairs of interfaces and skills, \(I{F}^{\tau }\) and \({S}^{\tau }\), that are targeted by the input skill. The function uses the \(getSkillHazards()\) function to get the hazards that are locally on skill \(s\) and hazards that are on the remote skills used by the skill’s process plan \({\pi }_{s}\). The skill’s hazards are stored in the set \({H}_{s}\). Next, for each \(h\in {H}_{s}\), the risk \({k}_{h}\) is checked, and if the risk is “high,” all skills that have operational space that overlaps with the operational space \({o}_{s}\) of skill \(s\) are collected. The function \(getAllOverlappingSkills()\) returns the overlapping skills and their interfaces. The returned list of skills and interfaces is stored in the set \([\langle I{F}^{o},{S}^{o}\rangle ]\). For each overlapping skill \({s}^{o}\), which shares the same hazard type \({\tau }_{{s}^{o}}={\tau }_{h}\), the function adds the skill and its interface to the \({S}^{\tau }\) and \(I{F}^{\tau }\) lists. Finally, the function \(riskAssessment(skill:s)\) returns the \(I{F}^{\tau }\) and \({S}^{\tau }\) list as output.

The function \(book\left(skill:s,interfaces:IF, skills:S, state:st\right)\) takes a skill \(s\), a list of interfaces \(IF\), a list of skills \(S\), and a state \(st\), as input parameters. The function first gets the interface associated with the input skill \(s,\) using the \(getInterfaceForSkill()\) function. It then retrieves the current schedule \(sc\), associated with that interface using the \(getSchedule()\) function. For each interface and skill in the \(IF\) and \(S\) lists, the schedule of each interface is added to \(sc\), which makes \(sc\) a total schedule for all the involved interfaces. The function \(findAvailableState(\text{s},S,st,sc)\) returns the first state in which the skill \(s\) and all the skills of set \(S\) are available in the schedule \(sc\). Then, the returned state \(st\) is passed to the function \(addToSt(\text{s},S,st,Sc)\), which schedules the skill \(s\) and the skills in the set \(S\) in \(sc\), at the available state \(st\). Finally, the function \(addToSt(\text{s},S,st,Sc)\) returns the updated state \(st\), as output.

The booking function books the targeted skills only and not the whole interface that it belongs to. This prevents the targeted skill from being scheduled by other parts at state \(st\) and at the same time allows the other skills on the same interface to be scheduled by other parts. There is here an expected benefit by preventing a resource from being allocated to an unsafe task, while the resource remains available for allocation to other safe tasks. This ensures that the resource is efficiently utilized.

The logic of the algorithm has been formally verified by modeling the part behavior using Extended Finite State Machines (EFSM) [48]. The model is checked if it satisfies the safety requirements that are formalized from the model-based analysis performed by the function \(riskAssesment()\). The NuSMV solver [49] is used to check if the parts strategy and the proposed method satisfy the safety requirements, which are described in more detail in the next section.

4 Formal verification of a manufacturing scenario

In this section, to validate the efficacy of the suggested method, a Plug & Produce manufacturing scenario is formalized. Model checking is employed for formal verification of the strategy [35]. This section is divided into five subsections. The first subsection describes the manufacturing scenario, the second subsection describes the resource models, the third subsection describes the part models, the fourth subsection resents the safety requirements in this scenario, and the fifth subsection presents the verification result and discusses the satisfaction of the safety requirements.

4.1 Description of the manufacturing scenario

The manufacturing scenario includes a part type \(p\) which has three goals: goal \({g}_{1}\) to be prepared, goal \({g}_{2}\) to be loaded into a machine, and goal \({g}_{3}\) to be machined. For simplicity, each goal has one process plan, and each process plan has one skill. Also, the scenario includes four resources, two machines, a robot, and an operator. Each resource has one interface, and each interface has one skill. The robot interface has the “\(load\)” skill that loads the part into a machine, and the machines’ interfaces have the “\(machine\)” skill that processes the part, and the operator agent interface has the “\(prepare\)” skill. For simplification of description and as each interface has one skill, the whole resource is considered booked if its skill is booked for a part. The abstract layout of the manufacturing scenario is shown in Fig. 3.

Fig. 3
figure 3

The abstract layout of the manufacturing scenario

Full size image

The operational spaces of each of the different resources’ skills are represented with different dotted rectangles and all operational spaces overlap. To count for unplanned operator actions, the operational spaces are monitored by safety sensors, and in case the operator, in an unplanned manner, enters another resource’s space, the safety control logic enforces a safety stop.

The scenario includes two configurations, each with a different machine. In the first configuration, the robot skill and the first machine skill are hazardous to the operator and therefore have high risk levels. In the second configuration, only the robot skill has a hazard that targets the operator and the second machine, which has a low-risk level, replaces the first machine.

4.2 Resource models

Based on the description of the scenario, the resources are defined by the following tuples.

The robot resource has the interface \(i{f}_{R}\) with the skill \(load\) and is defined as \(i{f}_{R}=\langle \{loa{d}_{R}\},{V}_{R}\rangle\), where \(loa{d}_{R}=\langle {\pi }_{load},robotSkill,{h}_{load},{o}_{load}\rangle\) and \({h}_{load}=\langle high,operatorSkill\rangle\). The skill \(load\) has operational space \({o}_{load}\), and it has a hazard \({h}_{load}\) which is a high-risk hazard, i.e., \({k}_{{h}_{load}}=high\), and it targets the operator skill meaning that \({\tau }_{{h}_{load }}=operatorSkill\).

Similarly, the first machine resource has interface \(i{f}_{M1}\) with the skill \(machine\) and is defined as \(i{f}_{M1}=\langle \{machin{e}_{M1}\},{V}_{M1}\rangle\), where \({machine}_{M1}=\langle {\pi }_{machin{e}_{M1}},machineSkill,{h}_{machin{e}_{M1}},{o}_{machin{e}_{M1}}\rangle\) and \({h}_{machin{eSkill}_{M1}}=\langle high,operatorSkill\rangle\).

Likewise, the second machine resource has interface \(i{f}_{M2}\) with the skill \(machine\) and is defined as \(i{f}_{M2}=\langle \{machin{e}_{M2}\},{V}_{M2}\rangle\), where \({machine}_{M2}=\langle {\pi }_{machin{e}_{M2}},machineSkill,{h}_{machin{eSkill}_{M2}},{o}_{machin{e}_{M2}}\rangle\) and \({h}_{machineSkil{{l}_{M}}_{2}}=\langle low,operatorSkill\rangle\).

The skill \(machineSkill\) of the second machine resource has a low-risk hazard to the operator. Therefore, it has a different hazard model than the first machine and the risk level of the hazard \({k}_{h}=low\). Finally, the operator resource agent has interface \(i{f}_{op}\) that has the operator skill \(prepare\), defined as \(i{f}_{Op}=\langle \{prepar{e}_{Op}\},{V}_{op}\rangle\), where \(prepar{e}_{Op}=\langle {\pi }_{prepare},operatorSkill,\varnothing ,{o}_{prepare}\rangle\). The skill \(prepare\) has no hazard as this skill does not generate any harm to the operator or the other resources.

4.3 Part model

Consider a set \(P\) of parts, where each part \(p\in P\) is assumed to be modeled by an EFSM [48]. An EFSM is an ordinary Finite State Machine (FSM), also called an automaton, where a set of variables \(V\) is also included. The total discrete state space of an EFSM is the combination of the locations (the states in an ordinary FSM) and the values of the involved variables. The variables are used to determine conditions (guards) that must hold before a transition from one location to another may occur. When a transition occurs, the values of some variables can also be updated, also called actions, and the updated variables are determined by adding a prime on the variables resulting in the updated variable set \(V{\prime}\). As an illustration, assume that a variable \(v=1\) is a guard and after the transition the updated value is \(v{\prime}=0\). This is then expressed by the formula \(v=1 \wedge v{\prime}=0\) as a transition condition. All such possible transition conditions including the variables in \(V\) and \(V{\prime}\) are included in set denoted \({F}_{V}\), and a complete EFSM is defined by the tuple \(ES\) = \(\langle \Sigma ,Q,\to ,{Q}^{o},{Q}^{w}\rangle\). The EFSM for a part \(p\) is defined by the tuple \({ES}_{p}=\langle \Sigma ,Q,\to ,{Q}^{o},{Q}^{w}\rangle\), where \(\Sigma\) is a set of events including the completed skill event, \(Q\) is a finite set of locations, \(\to \subseteq Q\times \Sigma \times {F}_{V}\times Q\) is conditional transition relation including the set \({F}_{V}\) of all possible expressions on variables and their transition updates, \({Q}^{o}\subseteq Q\) is a set of initial locations, and \({Q}^{w}\) is a set of marked locations. There are three part model variables controlled by Algorithm 1, which are involved in transition guards. The variables are \({V}_{p}\in \{R,Op,M\}\) and \({V}_{p}{\prime}\in \{R{\prime},Op{\prime},M\}\), where \(R\), \(Op\), and \(M\) are the variables representing robot, operator, and a machine, in a specific configuration. The domain of each variable is \(\{A,B\}\) where \(A\) means that the resource is available and \(B\) that it is booked. Figure 4 shows the EFSM of a part \(p\) in the first configuration in which the first machine is used. In this model, \({q}_{0}\) is the initial location and the conditional transition from \({q}_{0}\) to \({q}_{1}\) makes the variable \(Op=B\) as the operator skill “\(prepare\)” is used to achieve the plan of the first goal \({g}_{1}\). The operator is made unavailable (booked) for goals \({g}_{2}\) and \({g}_{3}\) to not be able to interact with the hazardous skills of the robot and the machine. The model shows four conditional transitions and the final one is to the marked location \({q}_{4}\) at which the event “\(mc\)” represents the completion of the skill “\(machineSkill\).” This skill is performed by the first machine resource that is included in the plan of the third goal \({g}_{3}\).

Fig. 4
figure 4

EFSM for a part p in Configuration 1

Full size image

Figure 5 shows the EFSM, of a part \(p\) in the second configuration, in which the second machine is used. In this EFSM, it is shown that the operator skill.“\(prepare\) ”is available at location \({q}_{3}\) and this is because the “\(machineSkill\),” in contrary with the first configuration, is not hazardous to the operator and the operator can interact with the machine. The event “\(mc\)” represent that the second machine has completed“ \(machineSkill\)” and the part life cycle is completed.

Fig. 5
figure 5

EFSM for a part p in Configuration 2

Full size image

4.4 Safety requirements: first and second configuration

Consider a part \({p}_{i}\) and any other part \({p}_{j}\). Now assume that the system includes \(n\) parts, meaning that \(|P|=n\). The resulting EFSM from the parallel composition of all parts \({\text{ES}}_{{p}_{1}}\parallel \dots \parallel {\text{ES}}_{{p}_{n}}\) models the instantiation of \(n\) part agents concurrently. Algorithm 1 generates a part behavior described by the ESFM in the previous subsection. To prove that the total behavior of all parts is safe, the safety requirements are derived and then the parallel composition of all parts \({\text{ES}}_{{p}_{1}}\parallel \dots \parallel {\text{ES}}_{{p}_{n}}\) is checked such that it satisfies the safety requirements. The safety requirement that concerns the reachability of the forbidden location \(\left({q}_{ik},{q}_{jm}\right)\) is described as \({q}_{ik}\in {Q}_{i}\) and \({q}_{jm}\in {Q}_{j}\) and \(\text{G }\neg \left({q}_{ik}\wedge {q}_{jm}\right)\), where \(\text{G}\) is the temporal logical modal operator globally, and this property must be satisfied in every globally reachable state. The forbidden state describes that part \({p}_{i}\) is not allowed to be in the location \({q}_{k}\) at the same time as part \({p}_{j}\) is in location \({q}_{m}\).

In the presented scenario, the operator and the robot are working concurrently in the locations \(\left({q}_{i2} ,{q}_{j1}\right)\) and \(({q}_{i1},{q}_{j2})\). Also, the operator and the machine are working concurrently in the locations \(\left({q}_{i3},{q}_{j1}\right)\) and \(({q}_{i1},{q}_{j3})\) and in the first machine configuration this is not allowed. Thus, the safety requirements in the first machine configuration are \(G \neg \left(\left(\left({q}_{i2}\wedge {q}_{j1}\right)\vee \left({q}_{i3}\wedge {q}_{j1}\right)\right)\wedge \left(\left({q}_{i1}\wedge {q}_{j2}\right)\vee \left({q}_{i1}\wedge {q}_{j3}\right)\right)\right)\). \(G\neg ()\) means that the statement within parenthesis is not true at any time. In the second configuration where the second machine is used, the safety requirement is \(G \neg \left(\left({q}_{i2}\wedge {q}_{j1}\right)\wedge \left({q}_{i1}\wedge {q}_{j2}\right)\right)\). This only forbids the operator and the robot to work concurrently, while the machine and the operator now can perform their skills in the same area.

4.5 Test results and discussion

The EFSM models were built using the formal model-checking software NuSMV [49], and the results were obtained from the simulation of the part agents’ strategy including resource scheduling and safety analysis. The models used for the simulation are presented in the Appendix. It is noticed that with the first configuration that involves the first unsafe machine, the composition of the parts’ schedules achieves risk reduction by only scheduling the safe states as shown in the reachability graph in Fig. 6, including 16 reachable states, while the total global state space has \(200\) states. The unsafe locations are never reached, which are \(\left({q}_{i2},{q}_{j1}\right)\) and \(({q}_{i1},{q}_{j2})\) which include the operator and the robot working concurrently or the locations \(\left({q}_{i3},{q}_{j1}\right)\) and \(({q}_{i1},{q}_{j3})\) in which the operator and the machine are working concurrently. In the first configuration, the reachability graph shows that parts are produced sequentially as expected and that is because the operator skill \(prepare\) which is the first skill in the part plan cannot be initiated if any other machine is working.

Fig. 6
figure 6

Reachability graph for two parts’ composition applying Configuration 1. The dashed states are unsafe states. mc is the event of “machineSkill” completed and \({q}_{i4}\),\({q}_{j4}\) is the final location where the production of parts is completed

Full size image

In the second configuration that includes the second safer machine, it is noticed that the composition of parts schedules achieves risk reduction by only scheduling the safe states as shown in the reachability graph in Fig. 7, but now with 20 reachable states within the same number of global states as in the first configuration with 200 states. This is understandable as more restrictions are implemented by the controller in the first configuration due to the presence of more risks. In the second configuration, as it is safe for the operator to work concurrently with the machine, a part plan may be scheduled to be parallel to another part. Also, the reachability graph shows that the final event for a part \({p}_{i}\), \(m{c}_{i}\) (machine completed for part \(i)\), can happen before the start of the first skill \(prepare\) in a part \({p}_{j}\) plan, as in the first configuration, but also later when skill \(load\) is scheduled for part \({p}_{j}\).

Fig. 7
figure 7

Reachability graph for the composition of two parts applying Configuration 2. The dashed states are unsafe states. mc is the event of “machineSkill” completed and \({q}_{i4}\),\({q}_{j4}\) is the final location where the production of parts is completed

Full size image

The safety requirements for each of the configurations were checked, and the results showed that the model of the parts’ joint schedules satisfies the requirements. This means that safety requirements are always met based on each part’s self-scheduling of its goals, without the need for manual risk assessment and modification of the safety-related part of the controller.

5 Conclusion

The Plug & Produce concept, facilitated by MAS, offers seamless machine integration and rapid production ramp-up times after reconfiguration. This paper proposes a novel method for employing the MAS control of Plug & Produce systems to perform model-based safety analysis and generate control actions that ensure compliance with safety requirements during production. This method removes the need to manually modify the safety-related part of the control logic after reconfiguration. The proposed method includes automatic risk assessment performed by agents in line with the safety regulations, and it enables foreseeing risk events and scheduling the operation pre-emptively to avert risk scenarios rather than reactively responding to them. This significantly reduces the reliance on physical barriers and emergency stop mechanisms. The formal verification of the method demonstrated that safety requirements are consistently satisfied in two different configurations, validating the method’s efficacy. Quantitative results from the formal validation further underscore the effectiveness of the method. The manufacturing scenario tested involved two configurations with different levels of risk. In the first configuration, where a hazardous machine was used, the reachability graph showed 16 safe states out of a possible 200 global states, effectively avoiding unsafe states where concurrent operations could lead to hazards. In contrast, the second configuration, featuring a safer machine, resulted in 20 safe states within the same global state space. This increase in reachable safe states demonstrates the method’s ability to maintain safety while allowing for greater flexibility and parallel operations. In comparing our approach with existing methods, several distinctions stand out. Traditional safety solutions often rely on predefined scenarios and fixed safety measures, which limit flexibility and responsiveness to unforeseen changes characteristic of Plug & Produce systems. Our method contrasts by offering proactive safety through dynamic planning, significantly enhancing system flexibility without compromising safety. Advanced sensor-based safety methods, while improving human–robot interaction safety, often involve high costs and complex integration processes. Our approach leverages MAS reasoning capabilities to cover the entire manufacturing system more comprehensively and cost-effectively. Furthermore, while MAS has been primarily focused on collision avoidance in autonomous vehicle contexts, our method extends these technologies to provide a comprehensive safety solution for RMS. The implications of this work are profound for human-centric and reconfigurable manufacturing environments. By ensuring safe operations after reconfiguration without manual intervention, our method supports the practical implementation and realization of flexible Plug & Produce systems. It allows for more effective utilization of equipment, maintaining safety without overly restrictive measures, thereby fostering a safer, more adaptable production environment. Future work will consider achieving global lowest-cost schedules for all parts. This must include a dynamic cost that is negotiated between parts based on their schedules. Additionally, it is important to develop a method for rescheduling part’s plan when failures occur which includes considering adjusting schedules accordingly. The continuous optimization of safety assurance methods within Plug & Produce contributes to the feasibility and implementation of this solution for manufacturing.