Introduction

Cyber-Physical Systems (CPS), sometimes seen as a new generation of networked embedded systems, have been growing significantly in terms of visibility and importance. Among their characteristics, one can mention dependability, functioning in a reliable, safe, and secure manner, as argued in [1], which identifies research gaps and future directions for the different phases of the industrial system development life cycle. In parallel with other components, one of the CPS constituent parts is the controller part. Model-driven Development (MDD) approaches have an important role to play within their design methodologies. In order to cope with the above referred constraints it is of paramount importance to rely on a modeling formalism equipped with a precise execution semantics adequate to support a design automation approach supported by computational tools and covering all development phases, from specification to automatic execution code generation, and including tools for simulation and verification of behavioral properties.

Taking into consideration the main characteristics of most of the embedded controllers used in cyber-physical systems, Petri nets can be seen as the perfect candidate to be selected for the role of supporting modeling formalism. In particular, as the design of embedded controllers is intended, a non-autonomous class of Petri nets supporting explicit dependencies on its execution semantics to input and output signals and events is of interest, as will also allow their full integration in model-driven development approaches supporting automatic generation of execution code without writing a line of code.

In this paper the emphasis is put on the modeling and development tasks of the embedded controller to be carried out in the classroom. For that, a specific type of embedded controllers targeting parking lot access control is used. The advantages of selecting this class of applications are two-fold: being very well know by the students contributing to keep them involved and grab their interest, and exhibit different types of behavioral dependencies which can find in Petri nets a proper modeling formalism to use.

The paper is structured as follows. In the next section, the proposed challenge is presented, introducing a type of controlled systems to be modeled and analysed. In Section 3 a few relevant classes of Petri nets used for the referred tasks are identified. In Section 4 a discussion on the modeling strategies to be used is presented, followed by the Section 5 where a brief discussion is produced. Section 6 concludes.

The challenge

Students are challenged to tackle a practical problem involving a real-world scenario, considering a system's controller equipped with several physical sensors and actuators. Their task involves modeling both the behavior of the system and its actuators.

The proposed line of exercises relies on the analysis of a parking lot controller, including controlling its entrance and exit gates alongside monitoring parking capacity. Figure 1 shows the simplest parking lot configuration, with one entrance and one exit, where each entrance/exit has a presence detector on the floor to detect arrival of a car and a button to be activated by the driver (to get a ticket at the entrance, or to insert ticket after payment at the exit). At this point, simultaneous activities at entrance and exit needs to be considered (locality on evaluation and concurrency modeling) in a similar way as in a producer-consumer system. Resource availability modeling is also present, as the number of free parking places can be seen as resources that are competitively shared by incoming users.

However, starting with this simplest parking lot configuration, several complications can be considered, namely:

• including several entrances, where some conflicts may occur, e.g when the number of cars trying to enter the parking lot is higher than the free places available inside. • including also several exits as well as several parking areas or floors considering some modular structure of the parking lot (and where modular composition of the Petri nets models can be used). • including additional sensors at entrances and exits to improve detection of the driver behaviour, e.g. leaving the entrance after trying to enter and goes reverse afterwards.

In the referred complications, several abstraction levels can be adopted, ranging from a generic description of the system behavior, to a fine detailed control actions allowing direct association with actuation of gates.

Also different types of goals can be addressed, ranging from high-level description and analysis of the system behavior, to generation of operational models to be directly deployed in the parking lot controller, including simulation of the system's behaviour considering randomly arriving and exiting of cars, among others.

From the above, it is clear that the modeling of several key characteristics of the system can be adequately accommodated through Petri nets modeling (locality, concurrency, conflicts, resources, and so on).

On the Petri net classes of interest

From the above, depending on the specific goals included on specific courses where students are enrolled, different types of Petri nets classes can be considered, including autonomous classes, such as elementary nets [2], place-transition nets [3], and coloured Petri nets [4], as well as non-autonomous classes, such as interpreted and synchronized Petri nets [5] [6] [7].

In this last group, the Input-Output Place-Transition nets (IOPT-nets) [8] [9] [10], and their associated tools framework (IOPT-Tools) [11], are of special interest. IOPT nets and IOPT-Tools allow explicit modeling of inputs and output signals dependencies, as well as automatic generation of execution code, which can be directly deployed in some popular boards, such as Arduino, Raspberry Pi, and FPGA-based (using C and VHDL code).

In the following sections, without loss of adequacy for the usage of the other referred classes, IOPT-nets will be used, illustrating possible lines of conduct.

Practicing basic modeling strategies

Coming back to the simplest parking lot configuration illustrated in Figure 1, one possible approach to follow may rely on identification of sub-models associated with the different parts of the system. In this case, one may build separated models associated with the entrance, the parking area, and the exit, as illustrated in Figure 2, where explicit reference on input signals dependencies as well as output actuators are included. The modeling strategy may initially adopt a kind of simplified (or naif) approach, where when a car comes to the entrance/exit area will eventually enter/leave (as illustrated in Figure 2(a) and (c)).

Staying with the simpler parking lot configuration (one entrance and one exit), the next step will compose the models producing the parking lot controller model, relying on the net addition operation between models [12] [13]. For the case at hand, a synchronous composition is selected, where fusion of groups of transitions as illustrated in Figure 3 is used, allowing reaching the model of Figure 4.

Further complications may consider different drivers' behavior where after being present at the entrance/exit, the driver goes reverse and leave the entrance/exit area (even before gate opening). In this line of complications, one additional ground detector can also be considered to be installed after the gate in order to confirm that the car actually cross the gate, or goes reverse not crossing the gate (as well as to avoid closing the gate while the car is entering). In this case, sub-models need to be more elaborated, as instead of considering an atomic action associated with the fusion of transitions at entrance and at the parking area, it will be necessary to consider a two-phase operation, where the first phase checks availability of a free place to park and reserve the place (removing a token from the FreePlaces place), but only create a token during the second phase in the PlacesOccupied place after actually crosses the gate afterwards. If driver goes reverse, the token is regenerated at FreePlaces place.

Going further with composition of sub-models, one may consider to build the model of a parking lot with two entrances and two exits, considering the disjoint addition of two entrance models, two exit models, and one parking area model, and four fusion sets of transitions to be merged (synchronous composition), as presented in Figure 5, resulting in the model of Figure 6. Other complication that can be considered for large parking lot infrastructures is the existence of different floors or parking areas, while continue to monitoring the movement of vehicles between Coming back to the model of Figure 6, some effective conflicts may occur. In particular when only one place is free inside the parking lot and two cars are present at both entrances willing to enter, two transitions at the entrances are in conflict. This situation can be used to introduce the concept of arbiters, responsible to a-priori manage the conflict (for some types of controllers, where a non-deterministic behavior is not allowed, this type of arbiters may be necessary to consider).

Figure 8 presents two possible types of arbiters to a-priori fix conflicts, where the transitions at the top and at the bottom of the models will be fused with the in-conflict transitions of the entrances. Important to refer that using the model on the left of Figure 8 will still introduce a conflict (between one of the two transitions of the arbiter and one of the two transitions initially in-conflict), which can be fixed introducing priorities among the in-conflict transitions (giving low priority to the transitions of the arbiter). This can be used to introduce the concept of priorities associated with transitions.

On the other hand, if the right hand model of Figure 8 is used instead, no priorities are necessary to be introduced, but it will be necessary to consider test arcs, resulting in the model of Figure 9.

Brief discussion

Other than the modeling activities referred in the previous sections, where the students were challenged to build the behavioral model of a parking lot controller taking advantage of composability of Petri net models, from the pedagogical point of view, other aspects important in controllers' development are emphasized.

One of them is related with the benefits of adoption of a model-driven development approach, where the system model can be used during all phases of development, ranging from specification to implementation, including simulation and verification of properties.

For that end, a set of web-based computational tools, the IOPT-Tools framework [11], freely available at http://gres.uninova.pt/IOPT-Tools/, is used to support the whole phases of development. IOPT-Tools have been in use at several universities supporting experimentation in several engineering courses [14,15]. Some of the tools available within the IOPT-Tools provide support for simulation of the model, where students can validate their solutions. The simulator tool uses an interactive token-player interface, as well as a timing diagram (similar to those obtained with data analysers), which provides a visual representation of the evolution of the marking and transition firing, as well as of the input and output signals of the controller. In this sense, students can analyse the behavior of the controller from two different points of view, namely from a model-centric view, or from the input-output interface view.

The validation through the simulation of the model is complemented with a set of tools allowing property verification through the construction of the reachability graph representing the associated state space of the model and a querying system providing answers to specific questions on boundedness and reachability aspects, among others.

Also the physical implementation of the controllers is addressed as the IOPT-Tools provides automatic code generators for software-centric implementations based on C, as well as for hardware-based implementations based on VHDL. Generated code can be directly deployed (without writing additional lines of code) in popular low-cost boards used in the lab such as Arduino, ESP-32, LattePanda, Raspberry Pi and other Linux platforms, as well as on several FPGA boards from AMD-Xilinx. Current practice at our University is to loan a FPGA board to students to allow extensive and autonomously experimentation by them on the whole phases of development.

Overall, students enjoy having a web-based tool for development and a board for autonomous experimentation always available and are motivated to participate actively in the lab activities.

Conclusions and future work

In this paper, a non-autonomous Petri net class based on Place-Transition nets and including priorities and test arcs was used (the class of IOPT-nets). However, as referred in Section 3, several classes of Petri nets can be equally used to explore exercises in this challenge framework.

As a matter of fact, most of the goals (namely introducing concurrency, locality on evaluation, conflict modeling, and so on) can also be achieved with autonomous Petri nets, namely Place-Transition nets, or other types of autonomous classes. Introducing high-level characteristics on the net, such as in Coloured Petri nets, will allow introducing new challenges, as different types of vehicles.

Also a final challenge (not presented in this paper) can address distributed execution of the global model, relying on the decomposition of the model into a set of sub-models and allowing their execution by a set of distributed controllers (one per entrance and exit, for instance), where the interaction between the different sub-controllers is achieved asynchronously (and overall the whole system can be seen as a Globally-Asynchronous Locally-Synchronous system).