Workload Specification

In DAL, the functionality of the system is composed of a set of applications, each of which is described as a process network where processes that are connected by channels perform the application's function. The runtime behavior of the application set is described by a finite state machine.

This page describes the specification of the finite state machine and the process networks using XML. Besides the specification of the process network, the functionality of each process must be implemented using C/C++ as described on the page Process Source Code.

Finite State Machine

In DAL, a finite state machine defines the control behavior over a set of applications which run on the target platform. Each application can be represented as a process network as shown below. To represent several operating modes of a system, we define scenarios as system states, each of which has a set of applications running simultaneously. Each state of a finite state machine corresponds to a scenario and defines the set of process networks that are paused or running. A transition between states is triggered by an event sent from processes.

The proposed finite state machine specification can be used to describe the control behavior as follows.

Each application refers to a process network.
Each state implies an operating scenario in which a subset of applications is active.
Transitions between states stand for scenario changes.
Events that cause changes of scenarios are specified as triggering conditions of transitions.
The applications that running or pausing in a scenario are specified as properties of a state.
One specific scenario is defined to be the last scenario of the execution.

Example

The following exemplified specification of a finite state machine consists of two applications and three scenarios, whereby one scenario just represents the last scenario. More details, scenarios 'A' and 'B' can be switched to each other through transition 'a2b' and 'b2a', which are triggered by event 'e_a' and 'e_b' respectively. Required actions, i.e., addition/deletion or pausing/resuming applications, are taken per each transition to change the system status appropriately.

```
<?xml version="1.0" encoding="utf-8"?>
```

<fsm xmlns="http://www.tik.ee.ethz.ch/~euretile/schema/FSM"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

```
    name="fsm_example1"
```

    xsi:schemaLocation="http://www.tik.ee.ethz.ch/~euretile/schema/FSM">

  <application id="0" name="APP1" src="app1/pn.xml" critical="1" />

  <application id="1" name="APP2" src="app2/pn.xml" critical="0" />

```
 
```

  <transition name="2a" nextstate="State_A" />

```
 
```
```
  <state name="State_A">
```

    <transition name="a2b" nextstate="State_B">

```
      <event name="e_a"/>
```
```
    </transition>
```
```
    <run application="APP1" />
```
```
  </state>
```
```
 
```
```
  <state name="State_B">
```

    <transition name="b2a" nextstate="State_A">

```
      <event name="e_b"/>
```
```
    </transition>
```

    <transition name="b2f" nextstate="END_STATE">

```
      <event name="e_f"/>
```
```
    </transition>
```
```
    <run application="APP2" />
```
```
    <pause application="APP2" />
```
```
  </state>
```
```
 
```
```
  <state name="END_STATE"/>
```
```
 
```
```
  <endstate name="END_STATE"/>
```
```
</fsm>
```

Elements of the Finite State Machine Specification

Next, we describe the usage of the allowed elements in the finite state machine specification, i.e., the elements application, state, transition, event, run, pause, and endstate.

`application`

The element application is used to described a process network that might be active in one or multiple scenarios. It has four attributes: id, name, src, and critical. The attribute id is an integer that uniquely identifies an application. Suppose that there are n applications, the id attribute uniquely numbers the applications from 0 to n-1. The name attribute is of type string and is the name of the application. The src attribute is also a string specifying a relative path to the process network description of the application. Finally, the critical attribute is an integer and specifies if the application is a safety critical application. If the attribute critical is 1, the application is safety critical, and if the attribute critical is 0, it is not safety critical.

`state`

The element state is used to describe a state in the finite state machine, which corresponds to a scenario or a system state with a set of applications running simultaneously. It has one attribute name, which is a string and may contain the child element transition, run, and pause. Outgoing transition of a state is specified as a child node similar to the set of applications running or pausing in a state.

`transition`

The element transition is used to describe an outgoing transition of a certain state. It has two attributes: name and nextstate, and both are strings. The name is the name of the transition, while newstate indicates the name of the destination state that the transition is directing.

Two different types of transitions are discerned depending on the parent element. The element fsm has exactly one transition as child node. It describes the default transition that is executed when the system starts. In this case, the element has no child elements. The element state may contain any number of transitions. In this case, the element contains any number of a child element event.

The system repetitively checks the event queue, always gets the first event in the queue, and enables the corresponding transition. Only after the transition completes, i.e., the system is in the final state associated with this transition, the next event will be fetched. Undefined events and events that are not acceptable in the current state of the finite state machine, will be discarded and the finite state machine will simply remain in the current state.

`event`

The element event is used to describe the triggering condition of a certain transition. It has one attribute name which is a string.

`run`

The element run specifies an application that is running in a certain state. It has one attribute, namely application. The application attribute is a string that indicates the name of the application specified by the attribute name of the corresponding application element.

`pause`

The element pause specifies an application that is pausing in a certain state. It has one attribute, namely application. The application attribute is a string that indicates the name of the application specified by the attribute name of the corresponding application element.

`endstate`

The element endstate is used to specify the last scenario that is executed in the system. It has one attributed, namely name that is a string and indicates the name of the state. It has to correspond to the attribute name of an element state.

Process Network

The specification of the process network describes the connections between the different processes. It consists of three different parts, namely the specification of the processes, the channels, and the connections between the processes and the channels. Repetitive structures can be described by using iterators. Iterators can thus be used for compact and easy description of parameterizable process networks.

Process

The process tag specifies the input and output ports of a process together with the location of the underlying source code file:

<process name="square" type="local">
	<port type="input" name="in" tokenrate="1"/>
	<port type="output" name="out" tokenrate="1" blocksize="1"/>
	<source type="c" location="square.c"/>
</process>

The process tag specifies a process with a given name and some type.
The port tag adds an input or output port with name to the process according to the type attribute. The tokenrate attribute defines the number of tokens consumed/produced in each execution cycle. Output ports can also define a blocksize which refers to the number of tokens in one output block. Note that the specification of the tokenrate and the blocksize is only required if the OpenCL back-end is used.
The source tag is required to specify the location of the source code for the process. The type attribute defines the source code language and can be either c, c++, or openclc, whereby the openclc type defines that the source code is actually specified as an OpenCL kernel. Note that DAL is also able to generate OpenCL kernel code automatically from a given DAL process.

Channel

The specification of a FIFO channel basically consists of an input and an output port. Additionally, a FIFO channel must specify the size of a single token and the number of tokens the channel can store. The following channel is names "C1" and has a capacity of 10 tokens with each token having a size of 4 bytes.

<sw_channel type="fifo" size="10" tokensize="4" name="C1">
	<port type="input" name="in"/>
	<port type="output" name="out"/>
</sw_channel>

The sw_channel tag specifies a software channel with a given name and some type. The type can be either fifo (standard FIFO) or wfifo (windowed-FIFO). With the size attribute, the maximum number of stored tokens within the channel can be specified and with tokensize the size of a single token can be set in bytes.
The port tag allows to add an input or output port with name to the channel according to the type attribute.

Connection

The connection elements specifies a connection between a process and a channel:

<connection name="channel-square">
	<origin name="C1">
		<port name="out"/>
	</origin>
	<target name="square">
		<port name="in"/>
	</target>
</connection>

The connection tag specifies a connection with a given name between a channel and a process and vice versa.
The origin tag selects the channel / process with name as the origin of the connection.
The target tag selects the channel / process with name as the target of the connection.
The port tag selects the port with name from the origin / target which needs to be connected.

Example Specification

Below is an example of a complete process network specification. The process network consists of three processes and two FIFO channels.

<processnetwork name="Squaring"> 
	<process name="generator" type="io"> 
		<port type="output" name="out"/>
		<source type="c" location="generator.c"/>
	</process>
	<process name="consumer" type="io"> 
		<port type="input" name="in"/> 
		<source type="c" location="consumer.c"/>
	</process>
	<process name="square" type="local"> 
		<port type="input" name="in" tokenrate="1"/>
		<port type="output" name="out" tokenrate="1" blocksize="1"/>
		<source type="c" location="square.c"/>
	</process>
 
	<sw_channel type="fifo" size="10" tokensize="4" name="C1">
		<port type="input" name="in"/>
		<port type="output" name="out"/>
	</sw_channel>
	<sw_channel type="fifo" size="10" tokensize="4" name="C2">
		<port type="input" name="in"/>
		<port type="output" name="out"/>
	</sw_channel>
 
	<connection name="g-c">
		<origin name="generator">
			<port name="out"/>
		</origin>
		<target name="C1">
			<port name="in"/>
		</target>
	</connection>
	<connection name="c-s">
		<origin name="C1">
			<port name="out"/>
		</origin>
		<target name="square">
			<port name="in"/>
		</target>
	</connection>
	<connection name="s-c">
		<origin name="square">
			<port name="out"/>
		</origin>
		<target name="C2">
			<port name="in"/>
		</target>
	</connection>
	<connection name="c-c">
		<origin name="C2">
			<port name="out"/>
		</origin>
		<target name="consumer">
			<port name="in"/>
		</target>
	</connection>
</processnetwork>

Personal tools