IOPT Petri Net State Space Generation Algorithm with Maximal-Step Execution Semantics

This paper presents an algorithm to efficiently generate the state-space of systems specified using the IOPT Petri-net modeling formalism. IOPT nets are a non-autonomous Petri-net class, based on Place-Transition nets with an extended set of features designed to allow the rapid prototyping and synthesis of system controllers through an existing hardware-software co-design framework. To obtain coherent and deterministic operation, IOPT nets use a maximal-step execution semantics where, in a single execution step, all enabled transitions will fire simultaneously. This fact increases the resulting state-space complexity and can cause an arc "explosion" effect. Real-world applications, with several million states, will reach a higher order of magnitude number of arcs, leading to the need for high performance state-space generator algorithms. The proposed algorithm applies a compilation approach to read a PNML file containing one IOPT model and automatically generate an optimized C program to calculate the corresponding state-space.

Automatic synthesis of VHDL Hardware Components from IOPT Petri Net models

Conferência: 39th Annual Conference of the IEEE Industrial-Electronics-Society (IECON), Vienna, Austria, Nov 10-14, 2013

Remote operation of embedded controllers designed using IOPT Petri-nets

This paper presents a new communication architecture to enable the remote control, monitoring and debug of embedded-system controllers designed using IOPT Petri nets. IOPT Petri nets and the related tools (http://gres.uninova.pt) have been used as a rapid prototyping and development framework, including model-checking, simulation and automatic code generation tools. The new architecture adds remote operation capabilities to the controllers produced by the automatic code generators, enabling quasi-real-time remote debugging and monitoring using the IOPT simulator tool. Furthermore, it enables the creation of graphical user interfaces for remote operation and the development of distributed systems where a Petri net model running on a central system supervises the actions of multiple remote subsystems. © 2015 IEEE.

Distributed controllers modeling through Petri nets with multi-asynchronous-channels

This paper proposes the concept of multi-asynchronous-channel for Petri nets. Petri nets extended with multi-asynchronous-channels and time-domains support the specification of distributed controllers, where each controller has a synchronous execution but the global system is asynchronous (globally-asynchronous locally-synchronous systems). Each multi-asynchronous-channel specify the interaction between two or more distributed controllers. These channels, together with the time-domain concept, ensure the creation of network-independent models to support implementations using heterogeneous communication networks. The created models support not only the systems documentation but also their validation and implementation through simulation tools, verification tools, and automatic code generators. An application example illustrates the use of a Petri net class extended with the proposed channels. © 2015 IEEE.

High-level Petri nets modules for embedded controllers design

Modular design is crucial to manage large-scale systems and to support the divide-and-conquer development approach. It allows hierarchical representations and, therefore, one can have a system overview, as well as observe component details. Petri nets are suitable to model concurrent systems, but lack on structuring mechanisms to support abstractions and the composition of sub-models, in particular when considering applications to embedded controllers design. In this paper we present a module construct, and an underlying high-level Petri net type, to model embedded controllers. Multiple interfaces can be declared in a module, thus, different instances of the same module can be used in different situations. The interface is a subset of the module nodes, through which the communication with the environment is made. Module places can be annotated with a generic type, overridden with a concrete type at instance level, and constants declared in a module may have a new value in each instance.