This paper presents a new code generation infrastructure for the IOPT-Tools framework, that automatically produces code in multiple languages from Input-Output Place-Transition (IOPT) Petri net models, to support the development of hardware/software controllers for embedded systems. The proposed infrastructure employs a two-step approach that starts with the creation of a language-independent XML document describing the execution semantics of the original Petri net model, which is later transformed into the syntax of the desired target programming or hardware description languages. The output of the first step is shared by all target languages, ensuring execution behavior consistency, independent of the chosen target language. As the IOPT simulation and model-checking tools also employ the code generated automatically, the proposed solution contributes to obtaining consistency between the behavior observed during simulation and model-checking and the final controllers running on embedded devices.
The usage of design automation tools frameworks has a strong impact on the way the current system’s development is performed, namely when considering the development of controllers for embedded and cyber-physical systems. Design automation frameworks have an important role in contributing to several societal challenges. Among those challenges, important to refer the contributions to digital transformation, as well as to reduce carbon emissions, contributing to performance, availability, and robustness improvements on final systems, as well as on wastes on materials used during the development processes. In this sense, design automation frameworks are completely in line with the goals of the ”twin transition” concept, promoted within European initiatives combining digital transformations and decarbonising and sustainability approaches. Portugal †These authors contributed equally.
The IOPT-Tools framework [
The IOPT-Tools framework contains a simulator tool used to test and debug models, presented in Figure 1, with a graphical user interface to manipulate the values of the input signals and events and observe the evolution of the system state and the resulting output signals. In addition, a state-space-based model-checking tool may be used to automatically verify certain model properties, including the reachability of desired states, the reachability of undesired states that could represent hazardous situations, or the existence of deadlocks.
Using these tools, it is possible to debug and validate the models directly on the IOPT-tools user interface, and most errors are detected in the early design stages. This aspect is specially important, as any mistakes undetected before the prototype implementation may result in damaged hardware or cause hazardous situations.
After a model has been debugged using the software tools, the framework ofers several automatic code generators that are employed to create software programs to run on embedded micro-controller boards, or hardware descriptions for Field Programmable Gate Arrays (FPGAs). In the prototype implementation phase, the inputs and output signals/events of the original IOPT model are associated with General Purpose Input/Output (GPIO) pins. This way, the controllers are able to read sensors, command the status of mechanical actuators or read button/switch values, and control displays/LEDs to communicate with the users.
As mentioned before, any remaining undetected mistakes may cause expensive malfunctions that may damage the prototype hardware. This way, it is very important to avoid the introduction of new coding errors in the software/hardware that will run on the embedded devices. Compared to manual coding, the availability of automatic code generation tools was a major contribution to solve this problem. However, even the code produced by diferent code generation tools may exhibit small inconsistencies, that may lead to behavioral changes.
A common situation happens when a Petri net [4] model contains conflicts between Petri net Transitions that share common input Places: there are tokens to fire any of the Transitions, but not enough to fire all of them. In this situation, the code generated automatically must choose the Transitions that will fire and the ones that do not fire. The IOPT-net class ofers Transitions priorities to help solve conflicts, always firing the transitions with the lowest priority value. However, if two transitions in conflict have the same priority, is the code generators that decide which transition fires.
Traditional autonomous Petri net classes typically solve this problem using a round-robin or random strategy. However, as IOPT-nets were created to support the design of embedded systems, the execution must be absolutely deterministic and must perform the same behavior consistently. This way, all the code generation tools must produce code with identical behavior, consistent with the simulation and model-checking tools.
This consistency is very dificult to ensure for code created manually, as each developer may sort the sequence of Transitions firing evaluation in diferent orders and even automatic tools may employ diferent ordering strategies. Although none of these strategies may be wrong, it is important to maintain consistent behavior between tools, to ensure that the resulting systems obey the same rules verified during simulation and model-checking. This problem is not exclusive to the Transitions evaluation sequence, as similar considerations could be applied to other aspects of the generated code, including the processing of input and output signals and events.
The automatic code generation infrastructure presented in this paper aims to contribute in this direction, by splitting the code generation into two steps. The first step is common to all languages and deals with the execution semantics of the models. It generates an XML document with a meta-program containing an algorithm that implements the model semantic rules. The second step deals with syntax and simply converts the language-independent XML to the syntax of the target language. This way, the code for the final implementation will share the first phase with the code used by the simulation and model-checking tools, ensuring the same behavior.
This paper has the following structure. The next section presents the IOPT-nets class, and section 3 presents related work. Then, in section 4, the proposed generation approach is described, followed by a generated code example in section 5. Finally, section 6 presents conclusions and future work.
A formal description of the IOPT-net class can be found at [5]. Petri-net based formalisms ofer many advantages to model discrete event systems, due to the capability to express parallelism and concurrency, in addition to a long list of mathematical properties. The IOPT-tools framework takes advantage of these properties to ofer simulation, model-checking, and code generation tools.
The IOPT-nets inherit the characteristics of the low-level P/T nets, with the addition of input and output signals and events. It is a non-autonomous Petri net class, as the system state evolution is limited by external conditionalities: a) Transition firing can be inhibited by guard functions, consisting of logical expressions related to the values of input signals; b) Transition ifring can also be inhibited with input events; c) Output actions associated with Places are used to define the value of output signals, that are only active when the places hold tokens; d) Transition firing can trigger output events, that may cause changes in output signals; e) Output actions associated with transitions may also change the value of output signals when the Transitions fire. The input and output signal can hold Boolean or integer range values, and are usually associated to physical GPIO pins on the hardware controller boards. Integer range signals are usually to represent analog values and Boolean signals are associated with digital GPIOs. This way, an IOPT-net model can read information from sensors, buttons, and switches and can also control physical actuators and motors, etc. As the main goal of IOPT-nets is the design of embedded system controllers, execution determinism is very important. This way, a maximal step execution semantics is used, meaning that all Transitions enabled and ready to ifre, will fire on the next execution step. In order to help solve conflicts between transitions, the class also ofers Test arcs, that prevent transition firing but do not remove tokens from the input Places and support Transition priorities.
Figure 2 presents a very simple example model, presenting 4 places (yellow circles) and 4 Transitions (cyan squares). This model also employs 3 input signals (cyan left arrows), two input events (cyan triangles), and two output signals (green arrows). The IE1 and IE2 input events are used to monitor changes in the IN1 and IN2 signals, detecting positive edges that happen when the signal changes from 0 to 1. These events are associated with Transitions T1 and T2 that can only fire when place P1 is marked and the respective event is triggered. The output signals OUT1 and OUT2 are associated with places P2, P3, and P4 by means of output actions. The value of OUT1 will be 1 when P2 is marked, 2 when P3 has tokens, and revert to a default value 0 when none of these Places is Marked. In the same way, OUT2 will have a value of 5 when P4 is marked or the default value is 0 otherwise.
Figure 3 presents the state-space (reach-ability graph) of the model presented in Figure 2, produced by the IOPT-tools model-checking tools. The model-checking tools detected 2 deadlock states (drawn as red) and two states containing Transition conflicts (drawn as magenta). This is a result of a design mistake in this model, whose correct execution depends on the sequence of external events: if events IN1 and IN2 occur in an alternate fashion, then both transitions T1 and T2 will fire. However, if two consecutive IN1 events occur (or two consecutive IN2 events) then one of the transitions T1 or T2 will fire twice, leading to a marking with two tokens on one of the P2/P3 Places and none in the other, that will prevent T3 from firing. This problem may be solved with two additional high-priority Transitions, to detect two tokens in one of the P2/P3 Places and inform the user about a possible error on the external hardware that generates EV1/EV2.
The IOPT-tools framework has ofered several automatic code generator tools for many years [
Other tools employing Petri nets to design embedded system controllers, or to execute software code from Petri net models should be mentioned. For example, the CPN tools [ 10] framework allows the execution of Standard-ML code from high-level Colored Petri nets, and the Renew framework [11] combines Reference Petri nets with Java code. Other tools include CPN-AMI [12], Signal/Event nets [13], and Signal Interpreted Petri nets [14]. Finally, many works have been published that use code generated automatically using Petri nets. Some of these works include[15, 16, 17].
The execution of an IOPT-net model is performed in discrete steps that happen at a predetermined frequency. Each step starts by reading all input signals from the respective hardware GPIO pins, followed by the computation of input events according to changes in the input signals. Next, the Transitions are evaluated according to a predefined sequence, evaluating both the pre-conditions related to the marking of input Places and also the guard conditions and input events. When a transition fires, tokens are removed from the input places, and new tokens are added to output Places. After all, transitions have been evaluated, the new values of output signals and events are calculated according to the resulting marking and the transitions that fired. The evaluation sequence takes into account the Transition priorities and when multiple transitions have the same priority, they are sorted according to the respective name and identifier. This way, a deterministic sequence o evaluation is always respected.
As mentioned previously, the automatic code generation process is divided into two steps: 1. Execution semantics: In the first step, an XSL transformation examines a PNML file containing an IOPT model and produces an XML file containing a meta-program that implements the model execution rules. This step is shared by all code generators for the diferent languages: C, Javascript, VHDL, Python, etc. 2. Target language syntax: The second step uses other XSL transformations to convert the
XML produces in the first step to the syntax of the desired target language.
Figure 4 illustrates the code generation process. In the first step, an XSL transformation receives a PNML file with an IOPT model and creates an XML file with a syntax independent description of a program to execute the model semantics. In the second step, diferent XSL transformations translate the XML document to the desired target language. The resulting code may be deployed on physical embedded devices, or may be used by the simulation (Javascript) and state-space generation (C code) tools. At the moment, these tools employ the code produced by the previous version of the code generation tools, which should be replaced by the new version.
The XML documents produced in the first step contain all the information required to build executable programs that implement the original model’s behavior. It is divided into two sections: a header containing a description of the variables and data structures, and a code section with a set of procedures that perform several tasks. The data structures include variables to represent all input and output signals and events, data structures to hold the Petri net marking, and another data-structure to record the transitions that have fired. The execution algorithm employs three copies of the marking data-structure, one to memorize the previous marking, another to hold the remaining tokens after each transition fires, and another to store the new tokens created. At the end of each step, the remaining tokens are added to the newly created. The code section contains procedures to initialize all variables, initialize GPIO pins, read input signal values from GPIO, delay/pause between steps, compute input events, compute output signals associated with transition firing and marked places, and compute signals afected by output events. Another procedure performs a single execution step, evaluating all transitions and performing the corresponding token manipulation. Finally, a main procedure coordinates all the other procedures running a continuous loop. Instead of defining a touring-complete language, the XML documents produced in the first step employ just a minimal set of XML tags (presented in Table 1), required to execute IOPT models. Mathematical expressions, besides containing a list of operands and operators, may also contain multiple levels of sub-expressions.
In addition to the tags listed in Table 1, each tag has a set of configuration attributes. For example, variables have data-types, default values, and a min/max range. Operators have diferent types and operands may contain references to other variables or structure fields. Based on these tags it is possible to create diferent XSL transformations that convert the XML metamay difer from one language to another: in this case, the transformation may have to insert additional parenthesis in the resulting code.
Applying the new code generator to the model in Figure 2, resulted in an XML executionsemantics document containing variables corresponding to each signal and event, data structures to store place-making and transitions fired, plus a series of procedures.
Some of the variables include: < v a r i a b l e name =” IN1 ” o r i g −node =” s i g n a l ” mode=” i n p u t ” type =” boolean ” v a l u e = ” 0 ” i o _ p i n = ” 1 ” s h i f t − r e g i s t e r − depth =”1”/ > < v a r i a b l e name =” IN2 ” o r i g −node =” s i g n a l ” mode=” i n p u t ” type =” boolean ” v a l u e = ” 0 ” i o _ p i n = ” 2 ” s h i f t − r e g i s t e r − depth =”1”/ > < v a r i a b l e name =” IN3 ” o r i g −node =” s i g n a l ” mode=” i n p u t ” type =” boolean ” v a l u e = ” 0 ” i o _ p i n =”3”/ > < v a r i a b l e name =”OUT1” o r i g −node =” s i g n a l ” mode=” o u t p u t ” type =” boolean ” v a l u e = ” 0 ” i o _ p i n = ” 4 ” wrap =”0”/ > < v a r i a b l e name =”OUT2” o r i g −node =” s i g n a l ” mode=” o u t p u t ” type =” boolean ” v a l u e = ” 0 ” i o _ p i n = ” 5 ” wrap =”0”/ > <!−− I n p u t and o u t p u t e v e n t s : −−> < v a r i a b l e name =” IE1 ” o r i g −node =” e v e n t ” mode=” i n p u t ” type =” boolean ”/ > < v a r i a b l e name =” IE2 ” o r i g −node =” e v e n t ” mode=” i n p u t ” type =” boolean ”/ > <!−− Net marking : −−> < s t r u c t name =” marking ” > < f i e l d name =” p_2 ” type =” range ” min = ” 0 ” max = ” 2 5 5 ” node −name=” P1 ” d e f _ v a l u e =”2”/ > < f i e l d name =” p_5 ” type =” range ” min = ” 0 ” max = ” 2 5 5 ” node −name=” P2 ” d e f _ v a l u e =”0”/ > < f i e l d name =” p_12 ” type =” range ” min = ” 0 ” max = ” 2 5 5 ” node −name=” P4 ” d e f _ v a l u e =”0”/ > < f i e l d name =” p_17 ” type =” range ” min = ” 0 ” max = ” 2 5 5 ” node −name=” P3 ” d e f _ v a l u e =”0”/ > </ s t r u c t >
Procedures to read and write inputs and outputs: < p r o c e d u r e name =” r e a d I n p u t s ” > <read − i n p u t v a r i a b l e =” IN1 ” type =” boolean ” i o _ p i n =”1”/ > <read − i n p u t v a r i a b l e =” IN2 ” type =” boolean ” i o _ p i n =”2”/ > <read − i n p u t v a r i a b l e =” IN3 ” type =” boolean ” i o _ p i n =”3”/ > </ procedure > < p r o c e d u r e name =” w r i t e O u t p u t s ” > < write − o u t p u t v a r i a b l e =”OUT1” type =” boolean ” i o _ p i n =”4”/ > < write − o u t p u t v a r i a b l e =”OUT2” type =” boolean ” i o _ p i n =”5”/ > </ procedure > < p r o c e d u r e name =” s e t u p _ i o ” > < c a l l − p r o c e d u r e name=” pinMode ” i o _ p i n = ” 1 ” mode=” INPUT ”/ > < c a l l − p r o c e d u r e name=” pinMode ” i o _ p i n = ” 2 ” mode=” INPUT ”/ > < c a l l − p r o c e d u r e name=” pinMode ” i o _ p i n = ” 3 ” mode=” INPUT ”/ > < c a l l − p r o c e d u r e name=” pinMode ” i o _ p i n = ” 4 ” mode=”OUTPUT”/ > < c a l l − p r o c e d u r e name=” pinMode ” i o _ p i n = ” 5 ” mode=”OUTPUT”/ > </ procedure >
The procedure that executes a single step of the model contains code to evaluate the firing of each transition and the corresponding token consumption and creation. For example, transition T3 can only fire when both P2 and P3 contain tokens and the guard condition «IN3 = 1» is true:
This XML document is subsequently transformed into the target language syntax. For example, the above XML fragment is transformed into the equivalent Javascript code: i f ( a v a i l _ m a r k i n g . p_2 >= 1 && a v a i l _ m a r k i n g . p_3 >= 1 && d a t a . IN3 == 1 ) { t r a n s i t i o n _ f i r e d . t _ 3 = Boolean ( 1 ) ; a v a i l _ m a r k i n g . p_2 = ( a v a i l _ m a r k i n g . p_2 − 1 ) ; a v a i l _ m a r k i n g . p_3 = ( a v a i l _ m a r k i n g . p_3 − 1 ) ; new_marking . p_4 = ( new_marking . p_4 + 1 ) ; } The equivalent code produced using VHDL syntax is:
I f ( avail_marking_p_2 >= 1 AND avail_marking_p_3 >= 1 AND s_IN3 = 1) Then t r a n s i t i o n _ f i r e d _ t _ 3 := 1 ; avail_marking_p_2 := avail_marking_p_2 − 1 ; avail_marking_p_3 := avail_marking_p_3 − 1 ; new_marking_p_4 := new_marking_p_4 + 1 ; End I f ;
The entire code can be consulted on the development area of IOPT-Tools, currently available at http://89.38.135.221/ fjp/iopt-tools/, opening the model ”test.pnml” and executing the XML2Step code generator tool. Currently, there are syntax transformations to produce C, Javascript, Python, and VHDL code.
The new approach to IOPT code generation ofers advantages in terms of consistency in the output produced for diferent languages, as the first step, which deals with execution semantics, is common to all generators. The second step just performs direct syntactic translation and should not produce any semantic changes. This is specially important, as the simulation and model-checking tools make use of the Javascript/C code generated automatically. This way, the new solution contributes to ensure consistency between the code used during testing and debugging and the final version running on real hardware. Finally, the two-step approach greatly contributes to simplifying the creation of new code generators for diferent languages, that will reuse the existing execution-semantics XML and only require the development of a diferent transformation to the syntax of the desired language. Using this strategy, most of the code required to create a new code generator is re-used, contributing to reduce development time. As the second-step transformation does not deal with model semantics details, the developer can just focus on the target language syntax, meaning that possible design choices regarding open semantic details were already taken when the first-step transformation was created. Future work includes the creation of more transformations to generate code for other languages and porting the current IOPT simulator and model-checking tools to start using the code produced by the new code generator.
This research was funded (in part) by the Portuguese FCT program, Center of Technology and Systems (CTS) UIDB/00066/2020/UIDP/00066/2020. [2] F. Pereira, F. Moutinho, L. Gomes, IOPT-tools - Towards cloud design automation of digital controllers with Petri nets, in: 2014 International Conference on Mechatronics and Control (ICMC), 2014, pp. 2414–2419. doi:1 0 . 1 1 0 9 / I C M C . 2 0 1 4 . 7 2 3 2 0 0 2 . [3] L. Gomes, F. Moutinho, P. Fernando, J. Ribeiro, A. Costa, J.-P. Barros, Extending inputoutput place-transition Petri nets for distributed controller systems development, in: 2014 International Conference on Mechatronics and Control (ICMC), 2014, pp. 1099–1104. doi:1 0 . 1 1 0 9 / I C M C . 2 0 1 4 . 7 2 3 1 7 2 3 , doi: https://doi.org/10.1109/ICMC.2014.7231723. [4] W. Reisig, Petri nets: an Introduction, Springer-Verlag New York, Inc., 1985. [5] L. Gomes, J. P. Barros, A. Costa, R. Nunes, The Input-Output Place-Transition Petri Net Class and Associated Tools, in: 2007 5th IEEE International Conference on Industrial Informatics, volume 1, 2007, pp. 509–514. doi:1 0 . 1 1 0 9 / I N D I N . 2 0 0 7 . 4 3 8 4 8 0 9 . [6] JavaScript Tutorial, https://www.w3schools.com/js/, 2023. Accessed: 2023-04-05. [7] V. A. Pedroni, Circuit Design with VHDL, MIT Press, Cambridge, MA, USA, 2004. [8] MATLAB - MathWorks, https://www.mathworks.com/products/matlab.html, 2023. Accessed: 2023-04-05. [9] IEC 61131-3:2013, Programmable controllers - Part 3: Programming languages, International Standard, International Electrotechnical Commission, 2013. [10] K. Jensen, Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical Use, volume 1, Springer Berlin, Heidelberg, 1997. [11] F. D. M. C. L. Kummer, O.; Wienberg, Renew – User Guide, University of Hamburg,
Department for Informatics, Theoretical Foundations Group, 2009. [12] A. Hamez, L. Hillah, F. Kordon, A. Linard, E. Paviot-Adet, X. Renault, Y. Thierry-Mieg, New features in CPN-AMI 3: focusing on the analysis of complex distributed systems, in: Sixth International Conference on Application of Concurrency to System Design (ACSD’06), 2006, pp. 273–275. doi:1 0 . 1 1 0 9 / A C S D . 2 0 0 6 . 1 5 . [13] P. Starke, H.-M. Hanisch, Analysis of signal/event nets, in: 1997 IEEE 6th International Conference on Emerging Technologies and Factory Automation Proceedings, EFTA ’97, 1997, pp. 253–257. doi:1 0 . 1 1 0 9 / E T F A . 1 9 9 7 . 6 1 6 2 7 8 . [14] M. Minas, G. Frey, Visual PLC-programming using signal interpreted Petri nets, in: Proceedings of the 2002 American Control Conference (IEEE Cat. No.CH37301), volume 6, 2002, pp. 5019–5024 vol.6. doi:1 0 . 1 1 0 9 / A C C . 2 0 0 2 . 1 0 2 5 4 6 1 . [15] T. Mohammadpour, M. Yadollahi, A. Haghighat, A system modeling and simulation tools with capability of code generation using color-timed Petri net, 2009. doi:1 0 . 1 1 4 2 / 9 7 8 9 8 1 4 2 8 9 9 8 6 _ 0 0 0 6 . [16] H. Dezani, N. Marranghello, A. S. Pereira, A. C. R. da Silva, M. Węgrzyn, Automatic Code Generation for Microcontrollers from Place-Transition Petri Net Models, IFAC Proceedings Volumes 44 (2011) 7873–7878. URL: https://www.sciencedirect.com/science/ article/pii/S1474667016448731. doi:h t t p s : / / d o i . o r g / 1 0 . 3 1 8 2 / 2 0 1 1 0 8 2 8 - 6 - I T - 1 0 0 2 . 0 2 9 3 4 , 18th IFAC World Congress. [17] F. Pereira, L. Gomes, Combining data-flows and petri nets for cyber-physical systems specification, in: L. M. Camarinha-Matos, A. J. Falcão, N. Vafaei, S. Najdi (Eds.), Technological Innovation for Cyber-Physical Systems, Springer International Publishing, Cham, 2016, pp. 65–76.