Simplifying the Verification of Simulation Models through Petri Net to FlexSim Mapping

Abstract

Simplifying the encoding of a simulation conceptual model representation reduces the number of errors that will be detected in the verification phase. In this paper, we present a mapping between Petri nets, a well-known formalism, and FlexSim, a well-known simulation tool. The proposal is illustrated through an example of how a model specified in a Petri net can be encoded easily, reducing the time needed to understand and verify the model. In the proposed methodology, the mapping must be defined at the initial stage of the encoding, starting from (in this case) a Petri net conceptual model, and ending at the encoding tool (FlexSim in this case). The main advantages of the proposed methodology are discussed.

1. Introduction

The development of any simulation project is guided by the verification, validation and accreditation processes. The three phases must be carried out in agreement with the hypotheses that govern the model, which are mainly defined in the conceptual model.

The conceptual model to be used to represent the systems must be selected in agreement with the client and experts in the system. In order to simplify the subsequent validation, the experts must focus on the conceptual model and not on any specific encoding, so they must feel confident with the language used to produce conceptual representations of their system. The only requirements for these languages are that they must be complete and unambiguous, and able to define the structure and the behavior of all the model elements, all of which are met by languages like the Specification and Description Language (SDL) [1,2], Petri nets [3,4,5] and Discrete Event System Specification (DEVS) [6] Interestingly once there has been a formal definition of a simulation model one can undertake transformations of the model from one of these formal representations to another; as an example, taking DEVS as a common formalism [7], one can transform an SDL model to DEVS [8] or Petri nets to DEVS [9]. The possibility of transforming the conceptual model from one representation to another allows it to be independent of the final language used to represent this conceptual model. The structure and behavior of the model are preserved.

In this paper we show a mapping between timed Petri nets and FlexSim, proposing a methodology that will simplify the verification and encoding process. This methodology opens the door to the implementation of automatic encoding algorithms for different tools. The mapping can also be extended to colored timed Petri nets since the concept of color is equivalent to the concept of an attribute in the FlexSim target simulation environment. However, it has been decided to narrow the scope of this article mostly to timed Petri nets to facilitate the description of the methodological process.

Figure 1 shows the simplified modeling process [10]; in red are the aspects that will be simplified with the application of the proposed methodology.

2. Literature Review

The need for a formal representation to include the stakeholders in the model validation and verification is becoming increasingly relevant because of the growing complexity of the models [11], the use of languages to simplify the communication between the parts to accelerate the agreement is encouraged. For example, in the frame of health, [12] discusses how to assure the engagement of the stakeholders in the modelling process, proposing the use of diagrams and drawings to ensure that the model is fully understood and that an agreement on the parts exists. On the same scope, some solutions are proposed aligned with the idea of representing graphically the model, like on [13,14] where the use of Business Process Model and Notation (BPMN) is proposed, see [15], extending it in order to make it fully executable and unambiguous. Along the same lines, [16] proposed the use of SDL; in that case, due to the nature of the language, SDL is complete and not ambiguous, and one can define the model involving the stakeholders without the need of add an extension to the language. This codification in SDL can be achieved automatically if one uses a tool that understands any of these formal languages, like [17,18,19], among many others. Petri Nets, like SDL does not need the addition of any extension, hence a model defined in a Petri Net is complete and can be fully codified. Petri Nets become an excellent alternative to represent simulation models and to analyze the correctness of executing a task or representing its behavior, in multiple areas, like in robotics and microcontrollers [20,21], to study biological and social systems [22,23,24] or infrastructures and logistics analysis [25,26,27] among other multiple scopes, hence several works exist to transform to Petri Nets models represented in other languages, like BPMN or Flowcharts, see [28,29,30] as an example.

In the frame of Petri nets there exists a database that, although not exhaustive, collects the most important software capable of running a model represented with a Petri Net, see [31]. Some studies have been undertaken to generate cose automatically, from this formalization of the models [32,33,34], but few analyses have been undertaken regarding how to map a conceptual model to one of the more popular all-purpose simulation tools [35] so that through this mapping these generic simulation tools can be used and to take advantage of the features that for a specific project may be needed, without losing the independence of the model with respect to the tool used for the codification. Some applications that combines the use of Petri Nets and FlexSim environment exist, like [36,37], with a mapping in the context of Arena environment [38] and Petri Nets [39], but no description on how to undertake mapping between Petri Nets and the FlexSim environment is detailed. Doing so gives the modelers a clearer picture of how the final tool will encode the different assumptions. Moreover, it guides the encoding process which is simplified and highly automatized.

3. Petri Nets

Petri nets have become established as a powerful modeling formalism in computer science, system engineering, and many other disciplines. They combine well-defined mathematical theory with a graphical representation of dynamic system behavior. The theoretical component provides a precise model of the system behavior for analysis while the graphical component simplifies the visualization of complex systems and enables the representation of changes in the system. This combination is the main reason for the huge spread of the use of Petri Nets [40].

3.1. Basic Definition

A Petri net, see Figure 2, is a specific type of graph comprising three kinds of objects: places, represented by circles; transitions, represented by bars, and directed arcs, which connect places and transitions. The dynamic nature of the system is represented by the movement of entities, in a Petri net, and this can be represented as tokens (drawn as dots) that are dynamically created and destroyed through the net.

A Petri net is formally defined as a 5-tuple N = (P, T, A, W, M₀), where:

• P = {P₁, P₂, P₃, ....., P_np} is a finite set of places;
• T = {T₁, T₂, T₃, ....., T_ne} is a finite set of transitions;
• A = {A₁, A₂, A₃, ....., A_na} is a finite set of arcs that connect places to transitions and vice versa;
• W: A_i → {1, 2, 3, ....} ∀ A_i is the weight associated with each arc;
• M₀: P_i → {1, 2, 3, ....} ∀ P_i is the initial number of entities in each place (initial marking).

The current location and distribution of entities in a Petri net is called a marking.

A transition can be fired if each transition input has the required number of entities specified by the weight associated with the arc from the place to the transition. Firing the transitions (that represent the simulation events) removes entities from the input places and adds entities to the output places. The number of entities removed or added equals the weight of the associated arc [3].

3.2. Timed Petri Nets

Time is a crucial aspect when dealing with dynamic logistics, manufacturing or transportation processes, such as automatic guided vehicle (AGV) systems. Therefore, the notion of time must be included in the Petri nets. The most commonly used model shows the associated delay time for enabling a transition to be fired.

The firing of a transition in a Petri net corresponds to an event that changes the state of the system. This may be the result of the verification of a logical condition in the system, as discussed in the previous section (immediate transitions) or induced by the completion of an activity, which naturally takes a certain amount of time (timed transitions); see Figure 3.

As a convention, this document will use the PIPE software representation [41,42]: black rectangles for immediate transitions and white rectangles for timed transitions. The white rectangle must have a time function (tf), which specifies the duration of the transition [3].

4. FlexSim

FlexSim^® [43] is a commercial simulation package that allows the execution of discrete and continuous simulation models. Being a commercial suite, it allows the definition of the simulation models following a proprietary and graphical approach, based on the connection of different simulation objects that allows representing the model behavior in a process interaction paradigm [44], see Figure 4.

Like several simulation packages, one of the main features of the tool is the simplification of the model definition and the faster execution of the simulation models. Some interesting features of FlexSim is the capability to generate C++ code from the models and the integration with the internet of things (IoT) through some well-known protocols, like OPC-UA [45]; the OPC (Open Platform Communications) is a set of standards and specifications for industrial telecommunication released in 1996; the UA stands for Unified Architecture (UA), released in 2008, which expands OPC to become a platform-independent service-oriented architecture. OPC-UA integrates all the functionality of the individual OPC classic specifications into one extensible framework.

The use of proprietary tools to define and codify the model implies that the model recodification in other tools (because a requirement in the project changes or because of the end of the live cycle of the product) becomes a complex and time-consuming task. Also, it increases the possibility of errors due to this recodification process.

In order to avoid these drawbacks but without avoiding the use of tools like FlexSim, we propose to define an automatic mapping between a well-known formalism widely used in the simulation frame, timed Petri nets, to FlexSim. Also, FlexSim, allowing the definition of new logics and element templates, can include easily the proposed mapping, allowing an automatic execution of models based on timed Petri net formalism.

5. Mapping Petri Nets to a FlexSim Model

Once a Petri net conceptual model has been created and validated by the problem owners, it is important to determine the validity of the model and its relevance to the executable model. This is achieved using the mapping approaches explained below and finally confirmed in the verification phase.

This state-space and causal or flow process logic expressed in the Petri net must be mapped into a model that uses the FlexSim library blocks. It is convenient to use a table to map the Petri net process model and the transition specifications to a FlexSim model [46]. The Petri net models can then be mapped into the equivalent FlexSim model code.

5.1. Sequential Execution

In the Petri net shown in Figure 5, transition T1 can only be fired after T0 has fired. This construct a sequential relationship between activities. The place/timed transition pair can be coded in FlexSim using the Delay activity.

5.2. Conflict

Transitions T0 and T1 are in conflict in this Petri net: both are enabled, but the firing of either one disables the other, see Figure 6. This situation will arise, for example, when an AGV must choose at an intersection between two different routes. The resulting conflict may be resolved in a non-deterministic or probabilistic way. This situation, in which the entity must choose between two different transitions, can be coded in FlexSim using the Decide activity and can also be solved in either of the two ways.

The Decide activity can have one or multiple inputs as well as one or multiple outputs, see Figure 7. Each output is assigned a positive integer number (the first option is 1, the second option is 2, etc.) All inputs enter the Decide activity and exit to the assigned output. Therefore, the deterministic or probabilistic solution of the conflict will depend on the number that is “assigned” to each token, as the number assigned for each output is not changeable. For a deterministic solution, labels (equivalent to colors in a colored Petri net) can be used. These labels can be assigned before the Decide activity or may exist from previous processes.

Let us imagine that, depending on the weight of the cargo, we will choose one option or another (deterministic decision). Specifically, if the cargo weighs less than 1000 u, it will exit by option 1; otherwise, it will exit by option 2. This can be configured in FlexSim by assigning the labels previously, see Figure 8.

Conflict can also be solved probabilistically using this system, but in this case, a statistical expression must be added. For instance, in Figure 9 the condition is selected by a normal distribution. There are several different statistical distributions, such as Bernoulli, Uniform, Poisson, etc.

5.3. Concurrency with Temporal Entities

In Figure 10, T1 and T2 transitions are concurrent. Concurrency is an important attribute of system interactions. In order to create concurrent transitions, there must be a forking transition that deposits a temporal entity at two or more output places. This might represent, for example, an AGV that transports two packages and splits the cargo indiscriminately between two conveyor belts. The Split activity in FlexSim deposits temporal entities at two (or more) output places.

5.4. Synchronization with Temporal Entities

In Figure 11, places P0 and P1 need to receive an entity in order for T0 to be enabled. Synchronization is common in a dynamic system for an event to occur. This can be represented, for example, by a situation in which two pieces need to be assembled before being transported. The existence of two different parts makes no sense at the point at which they are joined to form a single entity.

5.5. Concurrency and Synchronization with Resources

The timed Petri net shown in Figure 12 models a single-queue single-server process. This is a classic queuing model in which arriving entities (T0) wait in a queue (P0) for the resource. When the resource becomes available (P2) it starts to process the entity (if there is an entity in P0), remaining at P1 (working) until T2 is fired. The resource returns to P2 and final pieces go to P3. As can be seen, the model provides resource synchronization (P0-P2-T1) and concurrency (T2-P2-P3).

This whole Petri net can be simulated using Join and Split activities, as explained above. However, because resources are so common in Petri nets, and in order to provide a rapid and comprehensive view of the scheme (imagine using the same resource for several concurrent Petri nets), they have specific activities. Therefore, Figure 12 can be represented in FlexSim as shown in Figure 13.

This simple scheme is the basis for resource use in our manufacturing systems. For example, it might signify the use of an AGV (the resource), and the delay is the product transportation time from the source to the destination.

6. Example: Bridge Crossing Deadlock

In this example, we analyze the use of Petri nets to detect a deadlock (using an AGV example) before encoding the resulting scenarios in FlexSim. The most basic deadlocks in AGV systems would be when two of the vehicles use the same bidirectional lane but travel in opposite directions. An example of this is shown in Figure 14.

In this example, AGV1 needs to move cargo from Load1 to Unload1 and analogously for AGV2. Eventually, AGV1 and AGV2 may enter the same lane from opposite sides, blocking the whole system. This situation arises because AGV1 wants to access Unload1 and AGV2 wants to access Unload2, but they cannot collide or pass over one another, leaving us with two vehicles that want to move but whose paths are blocked.

6.1. Petri Net Model

The case shown in Figure 12 can be transformed into a Petri net. While one AGV covers part of the tracks, the other AGV cannot. Ideally, every inch of the tracks should be a resource, but this is not helpful. Therefore, the representation is divided into different sections according to their use by the AGVs. The different paths are divided as shown in Figure 15, where they are represented with different colors.

Now that each path has been labeled, the Petri net can be constructed as shown in Figure 16.

In this case, we had to assume that there is just one part waiting to be loaded at both load stations; when it returns it waits to be loaded again so it can be represented in the PIPE simulator. Figure 17 shows the different terminal states in which two different systems can be found (S10 and S11).

The corresponding deadlocks are represented in Figure 18. Note that it is particularly easy to interpret the problem of two vehicles on a one-lane bridge: they cannot use it at the same time because they are traveling in opposite directions.

There are only two deadlock situations because the bridge has been divided into three sections.

Alternative 1: Avoiding Deadlock

The system becomes deadlocked if both AGVs attempt to use the middle path at the same time from opposite sides. One possible solution is, for the first AGV to reach the middle path road, traps all the resources until the vehicle departs. The other AGV, if idle, must wait until the first vehicle releases the resource. The new Petri pet is displayed in Figure 19.

Note that the different sub-paths (green, yellow, and pink) no longer exist. This is because in the new situation it does not make sense to describe the path as three different resources since one catches them all up at the same time. The corresponding reachability graph can be seen in Figure 20, which shows that the system is totally cyclical and, therefore, not susceptible to deadlocks.

6.2. FlexSim Process Simulation Flow

The two proposed solutions need to be simulated in FlexSim to obtain results for different state systems so that they can be compared. This is different to the previous cases, as there are two possible alternatives to prevent deadlocks: (i) original case (possible deadlock) and (ii) solution (blocking the middle path with only one AGV), see Figure 21 for the original case with possible deadlock, and Figure 22 for the proposed solution (blocking the middle path).

7. Discussion

Static analysis of the two Petri nets reveals a deadlock at design time, through the analysis of the reachability graph. By encoding the two alternatives and performing an execution with non-validated systemic data assumptions, we can see that the first model is very likely to lead to a deadlock in the system. If both AGVs enter the bridge at the same time, the problem occurs in FlexSim and the process cannot continue, as shown in Figure 23.

In this case, is clear that the analysis of the conceptual model allows detection of behavior in the system (that can be known by the stakeholders of the system or not). This implies that the conceptual model itself can be considered as a valuable tool, not only for the documentation of the model and to allow multiple codifications, but also to understand and to validate the assumptions we use for modeling.

8. Conclusions

The conceptualization of a simulation model is a necessary task that sometimes is not undertaken because of the constraints in the time needed to finish the project or because of a misunderstanding in the differentiation between the model and the codification of the model. However, the conceptualization of a simulation model is a key aspect for undertaking the validation process and to detect, as is shown here, some issues in the system structure prior to any execution of the simulation model. For this reason, the conceptual model can be considered a product in itself [47], being a central element in the validation, verification and accreditation cycle [48,49].

This paper has shown how we can use a widely used formalism, the Petri net, to define a conceptual model and from it, following the proposed mapping, systematically obtain the codification for a FlexSim platform. This process reduces the change to introduce errors due to the codification process, implying a reduction in the time needed to undertake the verification of the FlexSim simulation model.

Since FlexSim allows extension and personalization of the behavior of the objects in question, one can use this mapping to create a library that automatically does this mapping, allowing the code to be obtained in a shorter time and with few errors, keeping the distinction between the conceptual model, and allowing all the advantages of the conceptual model to be obtained, like the possibility of an analysis prior to any codification and the possibility to reimplement the model in other tools. Also, this mapping allows existing Petri net models to use a commercial and powerful tool like FlexSim to perform the codifications of its models.