Graphic Model for Shop Floor Simulation and Control in the Context of Industry 5.0

Abstract

Industry 5.0 changes the paradigm of the current production model, with repercussions throughout the value chain, and opens up opportunities for new approaches that include reducing waste to optimize the use of the planet’s resources. This paper proposes a functional and executable model that implements a Holonic Manufacturing System (HMS) architecture inspired by the I5.0 guidelines. This architecture presents the factory floor as a service provider for the product to be built, intending to make the manufacturing process adaptable to changes. The model uses Reference nets as the modeling language, a high-level class of Petri nets, Java programming language as the annotation language, and free tool support. The model can be used to perform software-level simulations and can also be interconnected to existing physical devices using Internet of things technologies, enabling interactions between Cyber–Physical Systems (CPSs). It thus allows for the control of the shop floor and the reuse of the current machine park to make its adoption more sustainable. The model was used to generate several simulation results, which are presented and analyzed, thus demonstrating the model’s usefulness.

1. Introduction

Industrial development has had an enormous impact on European society [1]. Since the first industrial revolution, industry has been the engine of European prosperity.

The concept Industry 4.0 (i4.0), coined in Germany in 2011 [2], describes how the industry will use technology to better cope with a changing world and economy. The special requirements for a “green production” and carbon-neutral and energy-efficient industry are part of the i4.0 concept.

China has identified how to apply the concept in its context. The government initiative “Made in China 2025” is directly inspired by i4.0, focusing on revitalizing China’s manufacturing industry in the process of soft change.

A survey presented by Deutsche Bank in 2014 [3] suggested the adoption of i4.0 as the “factory manufacturer of the world”. Professor Klaus Schwab describes in [4,5] how i4.0 fundamentally differs from previous industrial concepts, characterized primarily by technological advances.

The European Commission presented the Industry 5.0 (i5.0) [6] concept in which the ability of the industry to achieve social goals beyond employment and growth is recognized as a resilient source of prosperity. Production respects our planet’s limits, and the workers’ well-being is now at the heart of the production process. It complements the existing i4.0 paradigm, where research and innovation will drive the transition to a sustainable, human-centered model and a resilient European industry. There is a shift from an exclusive focus on shareholder value to stakeholder value.

As highlighted in the [6] document, adopting i5.0 requires new technologies. However, the replacement of equipment has repercussions in the volume of investment and, consequently, in the consumption of natural resources.

The use of Business Process Model and Notation (BPMN)-based [7] models (e.g., [8,9,10]) or Petri-nets-based ones (e.g., [11,12,13,14]) has been proposed for performing simulations and for integration with the physical equipment in the industry.

This paper contributes an architecture and a presentation of a functional model that implements a Holonic Manufacturing System (HMS) architecture. The I5.0 guidelines inspire the architecture. The model is intended to be used to perform simulations or connect with existing equipment and enable, enabling Cyber–Physical System (CPS) interactions. It thus allows for the reuse of the current machine park to make the adoption more sustainable. Simulations were performed and their results are presented to demonstrate the model’s usefulness.

The structure of this paper is as follows: in Section 2, related work is presented, namely holononic architectures and technologies for CPS modeling. The proposed architecture is described in Section 3, which is followed by Section 4, presenting the use case and the technologies used in the proposed model. Section 5 provides a detailed explanation of the model components. The model execution is described in Section 6. The simulations are described in Section 7, followed by their result and discussions presented in Section 8. The final Section 9 presents the conclusion.

2. Related Work

Holonic Manufacturing Systems (HMSs) are proposed in IMT Test Case 5 [15]. These systems are an adaptation of the social concepts proposed by [16], which describe the concept of holons. The holon is based on the observation, in nature, that something that is simultaneously a whole and a part, e.g., atom, are a whole but also part of cells.

In the same year, 1994, Valckenaers presented the results of a test [17], concluding that adopting the HMS architecture has advantages for manufacturing processes. The same article highlighted the high adoption costs due to the lack of suitable technologies.

Van Brussel, in 1997, proposed the Product-Resource-Order-Staff Architecture (PROSA) [18], which introduced significant innovations, naming the decoupling of the system structure from the control algorithm and disassociation of logistical aspects from technical ones. In the same document, we identify three basic types of holons, represented in Figure 1 as the building blocks for an HMS architecture. The relationships between holons identifies the type of knowledge exchanged between them.

PROSA introduces the staff holon as an optional element that can assist basic holons in the performance of tasks and allow for the incorporation of centralized solutions. Thus, staff holons are useful for problems that do not use a distributed solution, allowing for an easy migration of current hierarchical systems to holonical solutions. Finally, staff holons do not introduce hierarchical rigidity into the system since they only advise basic holons.

Subsequently, Ounnar presented the Product, Resource, Order and Simulation Isoarchic System (PROSIS) [19]. This architecture introduces significant differences in PROSA, namely (1) a new interpretation of the three basic concepts of holons, (2) the disappearance of the staff holon concept, unnecessary in the context of an isocratic system where all holons have equal access to the command, and (3) the addition of the concept of holon simulation in order to anticipate any failure.

It proposes a fully decentralized control system that optimizes resources and allows for real-time production system management. This is achieved by reducing failures and participating in increasing productivity. The PROSIS approach aims to obtain the “best” solution based on the actual state of all holons. The proposed self-organized and isocratic control system is based on the autonomous real-time control capability associated with each holon. Control decision making in PROSIS requires the participation of all entities (products, resources, and orders).

In recent years, more holonic architectures have been proposed, e.g., QHAR [20], ADACOR [21], ADACOR2 [22], and HCBA [23].

Reference Nets

Since Carl Adam Petri introduced Petri nets in 1962, they have been an object of study in works related to CPS modeling (e.g., [12,24,25]).

Reference nets are a colored Petri nets class that uses the Java programming language as the annotation language [26].

In addition, Reference nets also support the concept of nets within nets, where a token can be a reference to a net, and not just a value of some kind [27]. This concept means that nets can dynamically create, destroy, and encapsulate other nets. Each Reference net can be seen as a class used to create objects, also called net instances. These net instances fire their transitions when they run, creating or destroying other net instances, values, and variables.

As in other Petri nets, Reference nets contain places, transitions, and various types of arcs. In addition to the typical arc found in most Petri net classes, the model presented in this work used test arcs (no arrows), clear arcs (with a white double arrow), and inhibitory arcs (with a small black circle at each end). All information about arc types can be found in the Renew tool user manual, which provides a complete presentation of the Reference nets and the Renew tool [28].

The Renew tool can be extended with the plugins feature [28]. Hence, although it was developed primarily for Petri nets modeling, plugins provide support for different modeling techniques, i.e., Unified Modeling Language (UML) [29] or BPMN diagrams.

Next, we present the proposed PRESIB architecture.

3. Proposed Architecture

The PRESIB architecture, initially presented in [14], is inspired by the PROSIS architecture. PRESIB is also a distributed architecture but suppresses the order holon. Consequently, the features are distributed among the product holon (Ph), which becomes the holder of the production plan, and the resource holon (Rh) responsible for the task execution quality since it provides the service.

A holonic architecture has different planes of interaction. In PRESIB, each plane is called a Playground, which defines the interaction between holons, from which the system’s behavior emerges.

In Figure 2, different Playgrounds are represented at different levels. Reading Figure 2 top to bottom, we can see that we have the product distributed by sectors. Each sector distributes the corresponding part of the product through the factories. In turn, each factory distributes part of the products by its machines. At each of the different levels, the interaction takes place in a context, represented by the Playground. Each actor is an Rh, just as the product is a Ph. This is how the model’s applicability is carried out at different levels, highlighting the holonic characteristic of the architecture.

The Playground acts as the service provider for Ph, since it is the common element between the Ph holon and Rh holon. The Ph seeks the services the Rh provides in the Playground.

Thus, at different levels, the services provided by Rh are also different. Consequently, the Playground offers different services at different levels.

A holon is composed of two components, one logic and the other physical; this topic is covered in greater detail in Section 4 dedicated to the PRESIB model. It is from the integration of these two components that the Cyber–Physical Systems (CPSs) emerge as autonomous units that interact with each other to achieve a result.

4. Model

The model was inspired by the need to process different products on a hypothetical shop floor. This concept is shown in Figure 3. This shop floor (in this scenario, named Playground) is composed of machines A, B, C, D (Rh) with similar features and services. Transporters A, B, C are also machines whose services are limited to the transport of the product (Ph) to be produced between machines or to the warehouse after its completion.

Following the PRESIB architecture, the Playground is a service provider for the Ph. Simultaneously, the Ph is the holder of the production list composed of a sequence of services necessary for its execution.

Thus, the Ph informs the Playground that it needs to perform a particular service, and, in response, the Playground informs which available Rh will perform the requested service. Next, the Ph requests a transportation service from the Playground, which, in turn, provides the information of the Rh that will provide the transport service. The Ph then waits to be collected and transported to the Rh that will perform the service initially requested from the production list.

After running all of these services, the Ph again requests an available Rh to execute the next service according to the next step in the production list.

The Ph will perform this sequence as often as necessary until it is transported to the warehouse, which is the last step in the production list.

Based on the use case description, Figure 4 represents the sequence of actions between the main actors. In the sequence diagram, the Ph represents multiple instances of the Ph net, the Playground is the single instance of the Playground net, and the Rh transporter and Rh machine represent multiple instances of the Rh net.

In the beginning, steps 1, 2, and 3 occur without a predefined order, as this will depend on each net instantiation process.

As soon as step 3 receives a response, the sequence will be the one shown in the diagram.

From the Ph’s point of view, the execution of the set of steps will be repeated as often as services are required to execute the products’ production plan.

It is possible to identify three actions, as seen in the UML Use Case diagram shown in Figure 5, to be performed by the main nets of the model, represented as actors in the same figure.

The Register Services action is the act of the Rh registering the services that can run on the Playground. This action is performed in the Rh net startup process and whenever the service runs.

The Search Services action is performed by the Ph to run the production list. In this case, it was modeled on the Rh net where, whenever it gets the Rh to run the production service, it has to request a transport service. However, this can be changed by adapting the net modeling to the needs of the implementation.

Finally, the Service Execution action represents the execution of a service by an Rh in a given Ph.

For the implementation of this model, a series of components were used to perform the intended case study simulations. Figure 6 presents the various components used and the technologies to communicate between them. Next, the represented components are described:

• PRESIB Model – composed of Helios and Hermes packages.
• Transporter Micro Controller – Device (ESP32 Dev Kit) simulates a carrier.
• Machine Micro Controller – Device (Arduino Uno with hat ethernet) that simulates a machine.
• MQTT public server – Public server for asynchronous communication through MQTT protocol
• Virtual Microcontroller App–App developed to simulate responses from microcontrollers as a replacement for non-available physical equipment.

Except for the machine microcontroller and due to the limited availability of connectivity equipment, the system primarily communicates using WiFi technology.

The Message Queuing Telemetry Transport MQTT protocol was selected over other possibilities (e.g., the Open Platform Communications—Unified Architecture (OPC-UA) protocol) due to its popularity and consequent availability of public servers for test use scenarios.

Thus, the MQTT protocol enables asynchronous bidirectional communication between microcontrollers (physical or simulated in the application) and their Rh net instances, as represented in Figure 7. By creating this two-way communication between the digital element (the net) and its physical element (the microcontroller), we face a CPS.

This approach allows for the extension of existing equipment in the digital plane, provides new features or services, and reuses the current equipment.

5. Model Detail

The PRESIB architecture model is a functional executable model that applies the concepts presented in Section 3. It can be used to perform simulations and supports the creation of CPS. It was built using a high-level Petri nets class named Reference nets. This class of nets is supported by a freely available tool that uses a general-purpose programming language, allowing for more compact graphical models and multiple model extensions, including communication with other models and physical devices [26,28].

As represented in Figure 8, the model consists of two main packages, which have been given names of entities from Greek mythology, Helios and Hermes.

Helios represents the Reference nets that make up the model, and Hermes represents the Java classes developed to extend the functionality of the Helios nets. Both packages complement each other in order to create the PRESIB model.

The next subsections provide details about the Helios and Hermes packages.

5.1. Helios

Reflecting the PRESIB architecture, the Rh and Ph are represented in the model by the nets Resource Holon Net (Rh net) and Product Holon Net (Ph net), respectively. As presented in Figure 2, the interaction between the Ph and Rh takes place in a given context that is represented in the model by the Playground net. As stated in Section 3, one of the objectives of the PRESIB architecture is to enable the creation of CPS. For this purpose, the nets that correspond to holons use the package Hermes to create communication channels with the desired equipment.

The Helios package template is composed of the following nets:

• Resource Holon net—Net corresponding to resource holons.
• Product Holon net—Net corresponding to product holons.
• Communication net—Auxiliary net used for communication between Rh nets and their physical components.
• Auxiliary Net—For registering services in the Playground.
• Playground—Instantiates the Rh nets and the Ph nets; it is the catalog of available services.

All nets are available for consultation through the PRESIB website [30].

5.2. Hermes

The Renew tool is developed in Java and allows for the execution of Java classes; in essence, Renew nets are Java classes [28]. In the PRESIB model, the functionalities of the nets are extended by a Java package. This extension of the features is achieved not only by instantiating and using Java classes from within the nets but also by using nets from within Java classes. Hermes provides utility classes that are used in any model net and offers classes specific to certain nets, such as nets for holons.

6. Execution

Initially, the execution of the nets representing the holons is described, followed by an explanation of the execution of the Playground net. Although the nets interact with instances of Java classes and vice versa, this paper addresses the net model execution as a whole.

6.1. Resource Holon Net

The resource holon net (Rh net) is represented in Figure 9. At the time of instantiation, it is assigned a unique identifier that relates it to its physical counterpart.

After instantiation, the net performs a series of checks. It retrieves and publishes the list of services on the Playground net using the service_register; see Figure 10.

The end of this boot process is indicated by a token at the waiting for job place.

When the execution of a service is assigned to the net, the transitions following the waiting for job place are performed.

These transitions are composed of a series of commands that are sent to the physical part to indicate what operation to perform.

After executing the command, the net waits for the physical component response to proceed to the next step. By doing so, it completes the execution cycle, which is indicated by the token, again, in the place waiting for job.

In this implementation, all equipment that provides services, such as machines or transport, use this net.

6.1.1. Product Holon Net

At its instantiation, the product holon net (Ph net), presented in Figure 11, also receives a unique identifier that relates to the material to be processed. In its initial transition, the Java ProductHolon class is instantiated in the Ph variable that is used in various transitions throughout the model. It also provides the execution plan as a list of services to be executed. After its instantiation, the net requests the necessary service to the Playground net. By convention, it has been modeled that, after obtaining the reference of the instance of the Rh net that will provide the requested service, the Ph net will always request a transport service.

6.1.2. Communication Net

Figure 12 shows the holon_comunicator net. It handles the communication between the net model and the physical device and uses a Java class and the mqtt_message_receiver net, presented in Figure 13, to implement the observer partner, enabling the model to send and receive the MQTT messages between the holon net and its physical component.

6.1.3. Playground Net

The Playground net is responsible for instantiating all Rh nets and Ph nets that will be used during the execution of the model (see Figure 14). In this implementation, counters were implemented to control the instantiation of nets according to the desired number (identifier). The instances of Ph nets are referenced in the net by the variable Ph. Rh nets are used for transport, and machines are instantiated in different sites and referenced by different variables. In the model, the rht variable references the Rh nets for transport, and the rhm variable references the Rh nets for machines.

After being instantiated in the Playground, the Rh nets register their services and are placed in the service catalog place in the form of tuples. In those tuples, the service name is associated with the holonID of the instance that registers it.

After their instantiation, the Ph nets request the first desired service to the Playground. If the service is available in the service catalog place, then the Ph is informed of which rhm holonID will provide the service. The tuple [holonId, service] is removed from the service catalog place to prevent the service from that rhm being available to other Ph.

After a Ph orders the execution service (the ones provided by the machines), it returns to the request service place to order a transport service.

After a transport is assigned, the Ph is placed in the waiting for transport place to wait for the transport to perform its service. At the end of the transport service execution, the Ph is put in the waiting for machine place, waiting for the machine to start its service execution process. After execution, the service returns to the request service place to continue to the production plan.

The Ph will be in this cycle until transported to the warehouse, represented by the warehouse place, which indicates its completion.

The model provides a central log functionality. By adding an action in a transition, it is possible to write a log from any transition on the model, as represented in the Listing 1.

Listing 1. Command to produce a log in the transition.

The logs capability is important because it allows for adding custom logs that can be parsed after the execution of the simulation to perform an analysis on the results.

7. Simulations

The case study described in Section 4 inspired the model’s elaboration and simulations. The model was executed while connected to physical devices. The following analyses were carried out from the results of the simulations:

• Size of the infrastructure required to support communication between the physical and logical components of the CPSs;
• Analyze the actions of each simulation;
• Obtain execution and wait times by service and by simulation;
• Check the randomness of the execution of a given scenario.

Twenty-five simulations were performed, divided into two groups. One group represents simulations with a single service type and the same amount of services. The files generated by the simulations are presented in

Table 1. Simulations in which Ph have single service type and the same amount.

Fixed Number of Rh	Fixed Number of Ph
1ph_10xserv1_1ph_10xserv2_1ph_10xserv3__10rht_10rhm	100ph_10xserv1_5rht_10rhm
10ph_10xserv1_10ph_10xserv2_10ph_10xserv3__10rht_10rhm	100ph_10xserv1_10rht_10rhm
100ph_10xserv1_100ph_10xserv2_100ph_10xserv3__10rht_10rhm	100ph_10xserv1_10rht_20rhm
	100ph_10xserv2_5rht_10rhm
	100ph_10xserv2_10rht_10rhm
	100ph_10xserv2_10rht_20rhm
	100ph_10xserv3_5rht_10rhm
	100ph_10xserv3_10rht_10rhm
	100ph_10xserv3_10rht_20rhm

and divided into two subgroups. The table’s column with the tile “Fixed number of Rh” shows the filenames of the logs with the same amount of Rh but a variable amount of Ph. The column with the tile “Fixed number of Ph” represents the simulations performed with a variable amount of Rh.

The other group is composed of simulations where the service type and the amount of services per Ph are variable. The logs generated by those simulations are represented in

Table 2. Simulations in which Ph have multiple service types and different amounts.

Fixed Number of Rh	Same Simulation 10 Times
3diff_ph_10rht_10rhm	300diff_ph_10rht_10rhm_1
30diff_ph_10rht_10rhm	300diff_ph_10rht_10rhm_2
300diff_ph_10rht_10rhm	300diff_ph_10rht_10rhm_3
	300diff_ph_10rht_10rhm_4
	300diff_ph_10rht_10rhm_5
	300diff_ph_10rht_10rhm_6
	300diff_ph_10rht_10rhm_7
	300diff_ph_10rht_10rhm_8
	300diff_ph_10rht_10rhm_9
	300diff_ph_10rht_10rhm_10

. Also in this table, the logs are divided into two columns: one with the tile “Fixed number of Rh”, which shows the logs of the simulations with the same amount of Rh but different numbers of Ph between them, and another column with the title “Same simulation 10 times”, which shows the logs files of the same simulation executed 10 times.

The names of the simulations also describe the configuration used. In Table 1, the names follow the following convention:

amount of Ph_amount of services_rh carrier quantity_amount of Rh machine

In Table 2 the names follow the convention:

amount of Ph_rh carrier quantity_rh machine quantity

In the Same simulation column 10 times, the name of each file is preceded by _n, which represents the simulation number.

The full results list, with the corresponding links to the files, is available in [31].

Through a tool developed for this purpose, described in [32], the following files were generated for each simulation:

• procustion_steps_simulation_name.csv—The times of each action described in the stock sequence are displayed per line. Which instance of Rh machine and transport Rh performed the service is also displayed in each line.
• times_per_Service_simulation_name.csv—The name of the service, the sum of the runtime, and the sum of the request time are displayed per line.
• times_per_Service_simulation_name.svg—Representation on a bar chart of the values of the csv file with the same name.
• total_times_simulation_name.csv—Displays total simulation times
• total_times_simulation_name.svg—Representation on a bar chart of the values from the comma-separated values (CSVs) file with the same name.

8. Results and Discussion

The following analyses were carried out based on the results obtained from the simulations.

8.1. Scale the Infrastructure Needed to Support Communication between the Physical and Logical Components of the CPS

The total amount of messages sent during the simulation was analyzed to scale the infrastructure needed to support communications between the physical and logical components of the CPS; that is, between the Rh net and its microcontroller. Several simulations were performed in which only one change was made between each to identify how many messages correspond to this change.

A simulation was initially performed consisting of a Ph, an Rh transport, and an Rh machine. The Ph production list consisted of a service named “serv1” and transport to the warehouse. Rh transport offers two services: the shuttle service and the warehouse transport service. The Rh machine only made available the service with the name “serv1”. The total number of messages was 31.

Then, a series of simulations were performed, changing a single parameter in the reference simulation. For example, increasing the number of services in the Ph’s production list by one or adding another Ph or Rh.

The analysis of the results allowed us to identify that the set of 31 messages of the initial simulation is composed as follows:

• Eighteen messages per service in ph list;
• Two messages per Rh;
• Nine constant messages regardless of any change.

With this information, it is possible to estimate the infrastructure to accommodate the volume of messages generated during the execution of the model. For example, in a setup of 20 Rh with both machines and transporters, with the goal of producing 1000 Ph, and assuming that each Ph will need four services to be executed, it is possible to calculate the total messages using the following formula:

$$TotalPh\times AmountOfServices\times MessagesPerService+TotalRh\times MessagesPerRh+9$$

where:

$TotalPh$ = 1000;

$AmountOfServices$ = 3;

$MessagesPerService$ = 18;

$TotalRh$ = 20;

$MessagesPerRh$ = 2.

Replacing the variables is the formula, the result is the following:

$$1000\times 3\times 18+20\times 2+9=54,049$$

The average load of each service message depends on the amount of information needed in the communication between the physical machine and the logical counter part. However, if assumed that the average load is 300 Bytes, it is possible to calculate the total load using this formula:

$$TotalPh\times AmountOfServices\times MessagesPerService\times 300\mathrm{B}$$

Replacing the variables, the result is

$$1000\times 3\times 18\times 300\mathrm{B}=16,200,000\mathrm{B}\left(16,200\mathrm{KB}\right)$$

8.2. Analyze the Actions of Each Simulation

Files with the prefix procustion_steps_ display the steps performed for each service.

Table 3. Example of file content with simulation execution steps.

ph	Step	startServiceRequest	startTransportRequest	Service	transportService	isForWarehouse	endServiceRequest	endTransportRequest	rhtId	startTransport	endTransport	rhmId	startService	endService
productHolon[12]	2	2022-06-17 08:27:50,615	2022-06-17 08:27:51,794	serv1	transport	false	2022-06-17 08:27:51,729	2022-06-17 08:27:52,875	rht-005	2022-06-17 08:27:53,282	2022-06-17 08:27:53,516	rhm-008	2022-06-17 08:27:53,737	2022-06-17 08:27:53,908
productHolon[4]	3	2022-06-17 08:27:50,732	2022-06-17 08:27:52,789	serv3	transport	false	2022-06-17 08:27:52,461	2022-06-17 08:27:52,875	rht-010	2022-06-17 08:27:53,425	2022-06-17 08:27:53,811	rhm-009	2022-06-17 08:27:53,942	2022-06-17 08:27:54,315
productHolon[7]	1	2022-06-17 08:27:50,520	2022-06-17 08:27:52,914	serv2	transport	false	2022-06-17 08:27:52,797	2022-06-17 08:27:52,924	rht-004	2022-06-17 08:27:53,578	2022-06-17 08:27:53,812	rhm-009	2022-06-17 08:27:54,633	2022-06-17 08:27:54,822
productHolon[4]	5	2022-06-17 08:27:54,462	2022-06-17 08:27:54,483	serv3	transport	false	2022-06-17 08:27:54,464	2022-06-17 08:27:54,515	rht-006	2022-06-17 08:27:54,560	2022-06-17 08:27:54,713	rhm-004	2022-06-17 08:27:55,144	2022-06-17 08:27:55,286
productHolon[12]	4	2022-06-17 08:27:54,070	2022-06-17 08:27:54,149	serv1	transport	false	2022-06-17 08:27:54,086	2022-06-17 08:27:54,160	rht-007	2022-06-17 08:27:54,561	2022-06-17 08:27:54,632	rhm-006	2022-06-17 08:27:55,030	2022-06-17 08:27:55,287
productHolon[7]	6	2022-06-17 08:27:54,893	2022-06-17 08:27:55,011	serv2	transport	false	2022-06-17 08:27:54,895	2022-06-17 08:27:55,012	rht-009	2022-06-17 08:27:55,184	2022-06-17 08:27:55,555	rhm-010	2022-06-17 08:27:55,923	2022-06-17 08:27:55,951
productHolon[4]	8	2022-06-17 08:27:55,559	2022-06-17 08:27:55,644	serv3	transport	false	2022-06-17 08:27:55,576	2022-06-17 08:27:55,648	rht-004	2022-06-17 08:27:55,764	2022-06-17 08:27:55,883	rhm-006	2022-06-17 08:27:56,007	2022-06-17 08:27:56,360
productHolon[12]	7	2022-06-17 08:27:55,488	2022-06-17 08:27:55,620	serv1	transport	false	2022-06-17 08:27:55,494	2022-06-17 08:27:55,623	rht-005	2022-06-17 08:27:55,758	2022-06-17 08:27:55,916	rhm-008	2022-06-17 08:27:56,168	2022-06-17 08:27:56,459
productHolon[7]	9	2022-06-17 08:27:56,133	2022-06-17 08:27:56,240	serv2	transport	false	2022-06-17 08:27:56,137	2022-06-17 08:27:56,243	rht-005	2022-06-17 08:27:56,526	2022-06-17 08:27:56,722	rhm-006	2022-06-17 08:27:56,953	2022-06-17 08:27:57,203
productHolon[4]	10	2022-06-17 08:27:56,524	2022-06-17 08:27:56,554	serv3	transport	false	2022-06-17 08:27:56,550	2022-06-17 08:27:56,559	rht-010	2022-06-17 08:27:56,693	2022-06-17 08:27:56,721	rhm-002	2022-06-17 08:27:57,169	2022-06-17 08:27:57,203
productHolon[12]	11	2022-06-17 08:27:56,609	2022-06-17 08:27:56,744	serv1	transport	false	2022-06-17 08:27:56,643	2022-06-17 08:27:56,751	rht-006	2022-06-17 08:27:56,936	2022-06-17 08:27:57,205	rhm-003	2022-06-17 08:27:57,286	2022-06-17 08:27:57,640
productHolon[12]	14	2022-06-17 08:27:57,693	2022-06-17 08:27:57,698	serv1	transport	false	2022-06-17 08:27:57,695	2022-06-17 08:27:57,708	rht-003	2022-06-17 08:27:57,739	2022-06-17 08:27:57,798	rhm-003	2022-06-17 08:27:58,098	2022-06-17 08:27:58,127
productHolon[4]	13	2022-06-17 08:27:57,489	2022-06-17 08:27:57,496	serv3	transport	false	2022-06-17 08:27:57,493	2022-06-17 08:27:57,502	rht-001	2022-06-17 08:27:57,631	2022-06-17 08:27:57,798	rhm-001	2022-06-17 08:27:58,385	2022-06-17 08:27:58,522
productHolon[7]	12	2022-06-17 08:27:57,426	2022-06-17 08:27:57,538	serv2	transport	false	2022-06-17 08:27:57,491	2022-06-17 08:27:57,540	rht-010	2022-06-17 08:27:57,632	2022-06-17 08:27:57,869	rhm-003	2022-06-17 08:27:58,385	2022-06-17 08:27:58,522
productHolon[12]	15	2022-06-17 08:27:58,253	2022-06-17 08:27:58,259	serv1	transport	false	2022-06-17 08:27:58,256	2022-06-17 08:27:58,263	rht-004	2022-06-17 08:27:58,269	2022-06-17 08:27:58,473	rhm-006	2022-06-17 08:27:58,608	2022-06-17 08:27:58,794
productHolon[7]	16	2022-06-17 08:27:58,704	2022-06-17 08:27:58,723	serv2	transport	false	2022-06-17 08:27:58,709	2022-06-17 08:27:58,725	rht-010	2022-06-17 08:27:58,836	2022-06-17 08:27:59,077	rhm-003	2022-06-17 08:27:59,347	2022-06-17 08:27:59,378
productHolon[4]	17	2022-06-17 08:27:58,834	2022-06-17 08:27:58,948	serv3	transport	false	2022-06-17 08:27:58,879	2022-06-17 08:27:58,949	rht-001	2022-06-17 08:27:58,998	2022-06-17 08:27:59,310	rhm-005	2022-06-17 08:27:59,633	2022-06-17 08:27:59,809
productHolon[7]	19	2022-06-17 08:27:59,544	2022-06-17 08:27:59,614	serv2	transport	false	2022-06-17 08:27:59,547	2022-06-17 08:27:59,630	rht-003	2022-06-17 08:27:59,687	2022-06-17 08:27:59,801	rhm-004	2022-06-17 08:27:59,910	2022-06-17 08:28:00,046
productHolon[12]	18	2022-06-17 08:27:59,038	2022-06-17 08:27:59,080	serv1	transport	false	2022-06-17 08:27:59,075	2022-06-17 08:27:59,081	rht-008	2022-06-17 08:27:59,157	2022-06-17 08:27:59,311	rhm-003	2022-06-17 08:27:59,800	2022-06-17 08:28:00,047
productHolon[4]	20	2022-06-17 08:27:59,878	2022-06-17 08:27:59,914	serv3	transport	false	2022-06-17 08:27:59,881	2022-06-17 08:27:59,945	rht-003	2022-06-17 08:28:00,094	2022-06-17 08:28:00,246	rhm-004	2022-06-17 08:28:00,552	2022-06-17 08:28:00,575
productHolon[12]	21	2022-06-17 08:28:00,193	2022-06-17 08:28:00,282	serv1	transport	false	2022-06-17 08:28:00,232	2022-06-17 08:28:00,283	rht-007	2022-06-17 08:28:00,430	2022-06-17 08:28:00,581	rhm-001	2022-06-17 08:28:01,030	2022-06-17 08:28:01,208
productHolon[7]	22	2022-06-17 08:28:00,229	2022-06-17 08:28:00,281	serv2	transport	false	2022-06-17 08:28:00,243	2022-06-17 08:28:00,290	rht-001	2022-06-17 08:28:00,430	2022-06-17 08:28:00,697	rhm-005	2022-06-17 08:28:01,121	2022-06-17 08:28:01,209
productHolon[4]	23	2022-06-17 08:28:00,815	2022-06-17 08:28:00,821	serv3	transport	false	2022-06-17 08:28:00,817	2022-06-17 08:28:00,824	rht-005	2022-06-17 08:28:00,862	2022-06-17 08:28:01,152	rhm-002	2022-06-17 08:28:01,361	2022-06-17 08:28:01,477
productHolon[7]	24	2022-06-17 08:28:01,450	2022-06-17 08:28:01,520	serv2	transport	false	2022-06-17 08:28:01,486	2022-06-17 08:28:01,524	rht-007	2022-06-17 08:28:01,672	2022-06-17 08:28:01,865	rhm-010	2022-06-17 08:28:02,158	2022-06-17 08:28:02,336
productHolon[4]	26	2022-06-17 08:28:01,613	2022-06-17 08:28:01,668	serv3	in transport	false	2022-06-17 08:28:01,654	2022-06-17 08:28:01,669	rht-009	2022-06-17 08:28:01,817	2022-06-17 08:28:01,947	rhm-008	2022-06-17 08:28:02,369	2022-06-17 08:28:02,607
productHolon[12]	25	2022-06-17 08:28:01,525	2022-06-17 08:28:01,561	serv1	transport	false	2022-06-17 08:28:01,558	2022-06-17 08:28:01,566	rht-006	2022-06-17 08:28:01,671	2022-06-17 08:28:01,866	rhm-010	2022-06-17 08:28:02,564	2022-06-17 08:28:02,814
productHolon[7]	27	2022-06-17 08:28:02,370	2022-06-17 08:28:02,557	serv2	transport	false	2022-06-17 08:28:02,372	2022-06-17 08:28:02,566	rht-008	2022-06-17 08:28:02,727	2022-06-17 08:28:02,894	rhm-007	2022-06-17 08:28:02,941	2022-06-17 08:28:03,210
productHolon[4]	28	2022-06-17 08:28:02,643	2022-06-17 08:28:02,665	serv3	transport	false	2022-06-17 08:28:02,653	2022-06-17 08:28:02,667	rht-005	2022-06-17 08:28:02,727	2022-06-17 08:28:02,894	rhm-005	2022-06-17 08:28:03,098	2022-06-17 08:28:03,210
productHolon[12]	29	2022-06-17 08:28:02,858	2022-06-17 08:28:02,903	serv1	transport	false	2022-06-17 08:28:02,891	2022-06-17 08:28:02,909	rht-007	2022-06-17 08:28:03,137	2022-06-17 08:28:03,375	rhm-004	2022-06-17 08:28:03,554	2022-06-17 08:28:03,578
productHolon[4]	31	2022-06-17 08:28:03,386		tr.warehouse		true	2022-06-17 08:28:03,413		rht-007	2022-06-17 08:28:03,586	2022-06-17 08:28:03,767
productHolon[12]	32	2022-06-17 08:28:03,692	2022-06-17 08:28:03,764	tr.warehouse	transport	true	2022-06-17 08:28:03,717		rht-003	2022-06-17 08:28:03,797	2022-06-17 08:28:03,885
productHolon[7]	30	2022-06-17 08:28:03,344	2022-06-17 08:28:03,449	serv2	transport	false	2022-06-17 08:28:03,377	2022-06-17 08:28:03,489	rht-006	2022-06-17 08:28:03,652	2022-06-17 08:28:03,767	rhm-008	2022-06-17 08:28:04,020	2022-06-17 08:28:04,263
productHolon[7]	33	2022-06-17 08:28:04,368	2022-06-17 08:28:04,375	tr.warehouse	transport	true	2022-06-17 08:28:04,371		rht-008	2022-06-17 08:28:04,486	2022-06-17 08:28:04,656

displays a portion of the contents of one of those files with the CSV format. The sample file is available online [33].

Next, we present a description of each column:

• ph—Identification of the Ph net instance that requests to run a service;
• step—Execution order in model;
• startServiceRequest—Time information of when the service request was made;
• startTransportRequest—Time information of when the transport request was made;
• service—Production list service ordered;
• transportService—Name of the requested transport service;
• isForWarehouse—Identifies whether it is a shipping order for the warehouse;
• endServiceRequest—Time information of when the service request was answered;
• endTransportRequest—Time information of when the transport request was answered;
• rhtId—Rh net instance identifier that runs the requested transport service;
• startTransport—Time information on when the transport service starts;
• endTransport—Time information on when the transport service was completed;
• rhmId—Identifier of the Rh net instance that runs the requested service;
• startService—Time information on when production service execution starts;
• endService—Time information from when production service execution was completed.

The rows are sorted by the endService column in ascending order to provide the perspective of completing the execution of a given service.

By analyzing the sequence of the values of the step and endService columns, it is found that the order of completion is not identical to the order in which the service request happened. This characteristic can be checked in other files with this prefix and indicates no sequence or prioritization in the execution of services.

It is also possible to verify that the execution of the services by the Rh does not follow any pattern.

Although there is a sequence of actions for completing the execution of a service, the executing actors (the involved Rh) and the order of the start and end are both random. Hence, the system’s behavior is to perform the necessary actions in “the possible way”.

The information in each file is used to generate the remaining files and tables shown below.

8.3. Obtain Execution and Wait Times by Service and Simulation

These data are obtained from files with the prefix times_per_Service_1.

Table 4. Example of file content with run times per service.

serviceRequest	serviceExecution	Service
0.02195	0.0331166666666667	serv1
0.0232666666666667	0.0962	transport
0.0313166666666667	0.0284	serv3
0.0406833333333333	0.0258166666666667	serv2
0.000916666666666667	0.00731666666666667	tr.warehouse

displays the contents of one of these files, available through [33], whose columns are:

• serviceRequest—Sum of all service request times;
• serviceExecution—Sum of all service execution times;
• service—Service name.

The data in Table 4 are displayed as a graph in Figure 15.

The time values are displayed in minutes in both the table and chart.

In the chart in Figure 15, the red bar corresponds to the values of the serviceExecution column in Table 4. The orange bar matches the serviceRequest column of the same table.

Reading this data allows us to understand where most time is being consumed, in what service, and in what action.

In this case, most of the runtime refers to the execution of the transport service. According to the sequence of actions represented in Figure 4, it is verified that a transport service is executed for each production service. In this simulation, three production services were run ten times, so the transport service runs thirty times. Roughly speaking, the total execution time of each production service is one-third of the total execution of the transport service. This shows that the execution times between the various services are distributed in a homogeneous way.

8.4. Check the Randomness of Running a Given Scenario

To check the system’s randomness, the same simulation was performed ten times.

Table 5. Comparison of steps between simulations.

Simulation 1					Simulation 2					Simulation 3
ph	step	service	rhtId	rhmId	ph	step	service	rhtId	rhmId	ph	step	service	rhtId	rhmId
productHolon[248]	9	serv1	rht-008	rhm-010	productHolon[55]	2	serv1	rht-010	rhm-009	productHolon[935]	26	serv1	rht-008	rhm-002
productHolon[60]	2	serv1	rht-003	rhm-009	productHolon[876]	20	serv1	rht-001	rhm-005	productHolon[6]	8	serv1	rht-009	rhm-005
productHolon[901]	18	serv1	rht-008	rhm-008	productHolon[400]	46	serv1	rht-002	rhm-001	productHolon[115]	2	serv1	rht-005	rhm-009
productHolon[54]	6	serv1	rht-002	rhm-007	productHolon[48]	30	serv1	rht-008	rhm-002	productHolon[56]	17	serv1	rht-003	rhm-007
productHolon[790]	15	serv1	rht-005	rhm-006	productHolon[1003]	48	serv1	rht-006	rhm-008	productHolon[647]	29	serv1	rht-006	rhm-008
productHolon[1392]	43	serv1	rht-003	rhm-004	productHolon[219]	11	serv1	rht-001	rhm-005	productHolon[387]	25	serv1	rht-005	rhm-007
productHolon[949]	25	serv1	rht-004	rhm-001	productHolon[604]	17	serv1	rht-002	rhm-004	productHolon[104]	6	serv1	rht-007	rhm-009
productHolon[1771]	109	serv1	rht-007	rhm-004	productHolon[1158]	34	serv1	rht-007	rhm-003	productHolon[647]	191	serv2	rht-002	rhm-005
productHolon[463]	32	serv1	rht-002	rhm-002	productHolon[228]	16	serv1	rht-005	rhm-002	productHolon[14]	27	serv1	rht-004	rhm-004
productHolon[318]	19	serv1	rht-009	rhm-007	productHolon[1347]	118	serv1	rht-004	rhm-008	productHolon[2025]	76	serv1	rht-001	rhm-007
productHolon[1732]	90	serv1	rht-008	rhm-001	productHolon[616]	19	serv1	rht-006	rhm-001	productHolon[471]	38	serv1	rht-009	rhm-005
productHolon[1331]	58	serv1	rht-005	rhm-009	productHolon[140]	5	serv1	rht-005	rhm-006	productHolon[229]	28	serv1	rht-010	rhm-002
productHolon[790]	136	serv2	rht-007	rhm-009	productHolon[1532]	143	serv1	rht-008	rhm-004	productHolon[43]	32	serv1	rht-007	rhm-003
productHolon[1464]	40	serv1	rht-005	rhm-003	productHolon[876]	130	serv2	rht-004	rhm-009	productHolon[6]	262	serv2	rht-006	rhm-006
productHolon[228]	21	serv1	rht-001	rhm-010	productHolon[829]	101	serv1	rht-002	rhm-001	productHolon[1318]	46	serv1	rht-002	rhm-001
productHolon[939]	66	serv1	rht-005	rhm-009	productHolon[219]	231	serv2	rht-005	rhm-004	productHolon[387]	268	serv2	rht-005	rhm-008
productHolon[1015]	38	serv1	rht-004	rhm-007	productHolon[1532]	259	serv2	rht-006	rhm-003	productHolon[104]	279	serv2	rht-003	rhm-004
productHolon[2089]	149	serv1	rht-009	rhm-002	productHolon[1158]	250	serv2	rht-001	rhm-005	productHolon[874]	39	serv1	rht-008	rhm-006
Simulation 4					Simulation 5					Simulation 6
ph	step	service	rhtId	rhmId	ph	step	service	rhtId	rhmId	ph	step	service	rhtId	rhmId
productHolon[70]	3	serv1	rht-009	rhm-008	productHolon[54]	5	serv1	rht-005	rhm-009	productHolon[35]	8	serv1	rht-008	rhm-006
productHolon[766]	17	serv1	rht-008	rhm-005	productHolon[299]	11	serv1	rht-009	rhm-008	productHolon[230]	10	serv1	rht-003	rhm-008
productHolon[155]	19	serv1	rht-001	rhm-001	productHolon[366]	13	serv1	rht-003	rhm-010	productHolon[85]	2	serv1	rht-005	rhm-002
productHolon[213]	10	serv1	rht-006	rhm-006	productHolon[148]	2	serv1	rht-003	rhm-004	productHolon[788]	19	serv1	rht-007	rhm-004
productHolon[206]	7	serv1	rht-005	rhm-001	productHolon[1967]	63	serv1	rht-008	rhm-010	productHolon[722]	60	serv1	rht-004	rhm-006
productHolon[69]	6	serv1	rht-006	rhm-003	productHolon[136]	3	serv1	rht-009	rhm-006	productHolon[56]	1	serv1	rht-006	rhm-007
productHolon[999]	40	serv1	rht-001	rhm-005	productHolon[1316]	41	serv1	rht-004	rhm-008	productHolon[175]	37	serv1	rht-009	rhm-005
productHolon[1407]	33	serv1	rht-007	rhm-007	productHolon[114]	1	serv1	rht-010	rhm-005	productHolon[489]	22	serv1	rht-001	rhm-003
productHolon[1232]	42	serv1	rht-004	rhm-006	productHolon[2601]	120	serv1	rht-002	rhm-006	productHolon[85]	105	serv2	rht-007	rhm-004
productHolon[284]	14	serv1	rht-010	rhm-010	productHolon[2556]	230	serv1	rht-003	rhm-008	productHolon[371]	18	serv1	rht-002	rhm-008
productHolon[1514]	178	serv1	rht-009	rhm-003	productHolon[103]	19	serv1	rht-009	rhm-003	productHolon[788]	141	serv2	rht-006	rhm-008
productHolon[244]	27	serv1	rht-005	rhm-002	productHolon[2429]	87	serv1	rht-001	rhm-004	productHolon[151]	7	serv1	rht-007	rhm-010
productHolon[174]	20	serv1	rht-006	rhm-008	productHolon[2663]	146	serv1	rht-004	rhm-010	productHolon[2246]	98	serv1	rht-008	rhm-007
productHolon[2235]	100	serv1	rht-007	rhm-005	productHolon[93]	21	serv1	rht-010	rhm-009	productHolon[2670]	132	serv1	rht-003	rhm-003
productHolon[105]	37	serv1	rht-009	rhm-002	productHolon[136]	253	serv2	rht-007	rhm-004	productHolon[308]	16	serv1	rht-003	rhm-009
productHolon[791]	21	serv1	rht-010	rhm-001	productHolon[789]	27	serv1	rht-009	rhm-007	productHolon[522]	48	serv1	rht-007	rhm-005
productHolon[2697]	221	serv1	rht-007	rhm-010	productHolon[366]	188	serv2	rht-006	rhm-010	productHolon[2586]	95	serv1	rht-010	rhm-002
productHolon[213]	287	serv2	rht-010	rhm-007	productHolon[2064]	122	serv1	rht-002	rhm-005	productHolon[2198]	215	serv1	rht-008	rhm-003
Simulation 7					Simulation 8					Simulation 9
ph	step	service	rhtId	rhmId	ph	step	service	rhtId	rhmId	ph	step	service	rhtId	rhmId
productHolon[148]	33	serv1	rht-005	rhm-005	productHolon[95]	3	serv1	rht-006	rhm-010	productHolon[627]	31	serv1	rht-007	rhm-007
productHolon[53]	1	serv1	rht-003	rhm-003	productHolon[281]	10	serv1	rht-010	rhm-003	productHolon[696]	26	serv1	rht-003	rhm-003
productHolon[228]	23	serv1	rht-005	rhm-001	productHolon[285]	30	serv1	rht-009	rhm-006	productHolon[192]	23	serv1	rht-009	rhm-007
productHolon[160]	14	serv1	rht-006	rhm-006	productHolon[163]	5	serv1	rht-010	rhm-004	productHolon[686]	19	serv1	rht-001	rhm-006
productHolon[148]	112	serv2	rht-008	rhm-007	productHolon[644]	32	serv1	rht-006	rhm-005	productHolon[531]	17	serv1	rht-004	rhm-010
productHolon[964]	25	serv1	rht-001	rhm-008	productHolon[954]	13	serv1	rht-009	rhm-001	productHolon[86]	4	serv1	rht-005	rhm-004
productHolon[956]	41	serv1	rht-003	rhm-003	productHolon[709]	21	serv1	rht-006	rhm-008	productHolon[122]	3	serv1	rht-006	rhm-001
productHolon[68]	4	serv1	rht-010	rhm-009	productHolon[499]	24	serv1	rht-009	rhm-003	productHolon[1017]	25	serv1	rht-008	rhm-009
productHolon[360]	13	serv1	rht-008	rhm-004	productHolon[163]	202	serv2	rht-009	rhm-009	productHolon[854]	28	serv1	rht-009	rhm-005
productHolon[581]	9	serv1	rht-006	rhm-007	productHolon[1817]	148	serv1	rht-005	rhm-004	productHolon[1182]	48	serv1	rht-005	rhm-008
productHolon[53]	132	serv2	rht-005	rhm-001	productHolon[1851]	75	serv1	rht-002	rhm-006	productHolon[141]	8	serv1	rht-001	rhm-002
productHolon[402]	52	serv1	rht-010	rhm-005	productHolon[1016]	16	serv1	rht-001	rhm-001	productHolon[2206]	171	serv1	rht-009	rhm-004
productHolon[2121]	155	serv1	rht-002	rhm-008	productHolon[139]	4	serv1	rht-008	rhm-002	productHolon[2337]	107	serv1	rht-008	rhm-010
productHolon[228]	269	serv2	rht-004	rhm-006	productHolon[1045]	39	serv1	rht-005	rhm-005	productHolon[294]	20	serv1	rht-010	rhm-009
productHolon[355]	12	serv1	rht-008	rhm-010	productHolon[2275]	166	serv1	rht-002	rhm-003	productHolon[331]	10	serv1	rht-007	rhm-008
productHolon[1178]	36	serv1	rht-010	rhm-002	productHolon[285]	185	serv2	rht-007	rhm-008	productHolon[1284]	34	serv1	rht-004	rhm-006
productHolon[1454]	197	serv1	rht-006	rhm-006	productHolon[1006]	20	serv1	rht-001	rhm-010	productHolon[854]	236	serv2	rht-003	rhm-008
productHolon[2046]	124	serv1	rht-007	rhm-003	productHolon[1559]	146	serv1	rht-003	rhm-004	productHolon[2243]	121	serv1	rht-005	rhm-002
Simulation 10
ph	step	service	rhtId	rhmId
productHolon[214]	5	serv1	rht-010	rhm-009
productHolon[356]	12	serv1	rht-009	rhm-010
productHolon[908]	30	serv1	rht-002	rhm-002
productHolon[6]	11	serv1	rht-008	rhm-005
productHolon[273]	28	serv1	rht-009	rhm-005
productHolon[1371]	44	serv1	rht-008	rhm-009
productHolon[142]	128	serv1	rht-006	rhm-005
productHolon[528]	9	serv1	rht-005	rhm-002
productHolon[356]	130	serv2	rht-004	rhm-004
productHolon[13]	1	serv1	rht-010	rhm-006
productHolon[1351]	43	serv1	rht-006	rhm-001
productHolon[1436]	79	serv1	rht-003	rhm-005
productHolon[902]	17	serv1	rht-008	rhm-007
productHolon[150]	10	serv1	rht-010	rhm-003
productHolon[490]	78	serv1	rht-004	rhm-002
productHolon[715]	20	serv1	rht-002	rhm-004
productHolon[1917]	111	serv1	rht-007	rhm-001
productHolon[2493]	189	serv1	rht-001	rhm-009

is an extract from the comparison of the columns:

• ph—Product holon instance;
• step—Step of the simulation;
• service—Requested service;
• rhtId—Resource holon providing the transport service;
• rhmId—Resource holon providing the requested service.

It shows the first twenty lines of the logs of each simulation.

As can be observed, the sequence between simulations is always different. If the rows with a yellow background, from Table 5, are compared, it becomes evident that all simulations present different values for the columns ph, rhtId, and rhmId, and, in some simulations, until the service presented is the service2.

This shows that although the model is deterministic in its execution, it is non-deterministic relative to who runs the services or the services to be executed.

This characteristic is the one that enables the model to find a way to perform the proposed task. For as long as an Rh provides the necessary service, the model will adapt to the use of this Rh.

Considering the case study, if there is a need to put one of the Rh under maintenance, the model continues running as long as another Rh or others guarantee the needed services. The model carries this out automatically and dynamically, without previous intervention or the need to stop production to reorganize the production chain.

The execution of the model in the form of simulations allows for validating the concept of using this class of Petri nets connected to physical devices leveraging the creation of CPSs. The interaction between the CPSs can be defined in the nets. The digital counterpart also enables the possibility of extending the current physical device.

In this work, the Playground net is presented as the factory’s shop floor, where services are provided to the product holons. As the product holons are the ones that know the production plan, requesting them to the shop floor enables the adaptability of the execution to the available resources.

Because the model allows for defining the information to log during the execution, it is possible to use the provided data of the logs to convert them into information to be analyzed for different purposes, as presented in the previous section.

Finally, the PRESIB architecture characteristics match with the Industry 5.0 pillars as follows:

• Centered on the human being—Although the architecture is not centered on the human being, it allows for a way to interact with the shop floor through the model. The model can be adjusted to users and can be considered for different levels of digital literacy, the purpose of the model, and the level of automation or desired interaction;
• Sustainability—As presented in [34], mass customization allows for a better management of existing resources. PRESIB architecture fits this kind of production paradigm due to its adaptability to changes. However, sustainability also involves reusing the current equipment park to prevent them from becoming obsolete. PRESIB architecture enables the creation of CPSs by integrating physical systems with the networks of the model, and, in this way, the reuse of the current machinery park;
• Resilience—The adaptability to the change in PERSIB architecture allows for a reduction in the impact on the suppression of established supply chains as a consequence of the COVID-19 pandemic.

9. Conclusions

An architecture was presented and materialized in a model that dynamically adapts to production needs or to eventual changes, whether internal or external, without the need for human intervention or supervision.

In the proposed approach, the shop floor becomes a service provider for the products being built. In addition to contributing to the system’s dynamic, this also creates new opportunities, such as mass customization.

The presented simulations demonstrate how the results obtained can be interpreted in several ways, attributing value to the model.

The ability to use the same model to perform simulations and to integrate with physical systems has the benefit of reducing the implementation error, either by programming errors or by a misinterpretation of requirements. It is also beneficial because it allows for the reuse of existing equipment. This characteristic of the model, integrated with physical equipment, also allows users to interact with the shop floor through the model, providing another alternative form of interaction between humans and machines. Finally, the suggested architecture follows the values of Industry 5.0.