Next: , Up: Petri Net Mapping Rules


8.1 Mapping Patterns

The AADL elements to map into Petri nets are the software components. Indeed, execution platform components are used to model the deployment of the software components; such deployment information is not to in the scope of Petri nets. AADL threads and AADL subprograms are the most important components, since they can host subprogram call sequences: they describe the actual execution flows in the architecture. AADL processes and systems are actually boxes containing threads or other components, hence they do not provide any “active” semantics; data components are not active components either. The following table lists the main rules of the mapping:

8.1.1 Component Features

     feature : in data port;
images/feature.png

8.1.2 Subprograms

     subprogram a_subprogram
     features
       input_1 : in parameter;
       input_2 : in parameter;
       output : out parameter;
     end a_subprogram;
images/subprogram.png

8.1.3 Other Components

     process a_process
     features
       input_1 : in data port;
       input_2 : in data port;
       output : out data port;
     end a_process;
images/component.png

8.1.4 Connections

     connection : data port output -> input;
images/connection.png

8.1.5 Subprogram Connections

     connection : parameter output -> input;
images/spg_connection.png

This mapping mainly consists of translating the AADL execution flows into Petri nets. Components that do not have any subcomponents nor call sequences are modeled by a transition that consumes inputs and produces outputs. Component features are modeled by places. Tokens stored in input features are to be consumed by the components or connections; tokens produced by component or connection transitions are stored in output features. Components that have subcomponents are modeled by merging the transition with the models of the subcomponents.

We model a place per feature. This systematic approach help the user identify the translation between AADL models and corresponding Petri nets. In addition, it facilitates the expansions of the feature places. For example, we might want to describe the queue protocols defined by the AADL properties: in this case we would replace each place by Petri nets modeling FIFOs or whatever type of queue is specified by the AADL properties.

Connections between features are modeled by transitions. We distinguish connections between subprograms parameters and between other component ports.

If an AADL port is connected to several other ports at a time, the Petri net transition shall be connected to all the corresponding places: a token will be sent to each target place, thus modeling the fact that each destination port receives the output of the initial port.

Connections of subprograms parameters are slightly more complex. Indeed, output places of subprograms model variables, that can be read many times. Therefore, a subprogram produces two tokens: one that carries the output value and the control information, and an extra one that only carries the value. The extra token is stored in a place where subprograms from other call sequences can get it—the transition shall put the token back into the place. In order to ensure the correct replacement of the token whenever a new value is produced by the subprogram, the subprogram itself consumes its old extra output token to produce the new one.

Call sequences are made of subprograms that are connected. We use an extra token to model the execution control. There is a single execution control token in each thread or subprogram, thus reflecting the fact that there is no concurrency in call sequences, and in threads and subprograms in general.