plugins/org.eclipse.app4mc.amalthea.model.help/docu/model_events.textile

h2. Event Model

The event model provides the classes to describe the BTF-Events that can be used for the tracing configuration, for the modeling of event chains and for some timing constraints. 

The top level structure is the following:

!(scale)../pictures/model_events_event.svg!

There are different event classes for the different entity types that can be traced: 

table(classic). 
|_. Entity |_. Event Class |
| Process (Task, ISR) | ProcessEvent |
| ProcessChain | ProcessChainEvent |
| Stimulus | StimulusEvent |
| Runnable | RunnableEvent |
| Label | LabelEvent |
| ModeLabel | ModeLabelEvent |
| Channel | ChannelEvent |
| Semaphore | SemaphoreEvent |
| Component | ComponentEvent|

h3. Entity Events

!(scale)../pictures/model_events_entity_event.svg!

h3. Trigger Events

!(scale)../pictures/model_events_trigger_event.svg!

h3. Process Events

In a running system, each entity can have different states. An event trace consists of the events that are visualizing the state-transitions of the traced entities. To define such an event in the model, each kind of event class contains an event-type-enumeration that provides the event-types for the state-transitions of its entity. The following picture shows the possible states of a process: 

!../pictures/model_events_process.svg!

So for example the event-type-enumeration for a process event contains the events __activate__, __start__, __resume__, ...

h3. Details

A description of the individual events can be found in the following table:

table(classic). 
|_. Event Class |_. Event Type |_. Description |
|/12. ProcessEvent | activate | The process instance is activated by a stimulus. |
| start | The process instance is allocated to the core and starts execution for the first time. |
| resume | The preempted process instance continues execution on the same or other core. |
| preempt | The executing process instance is stopped by the scheduler, e.g. because of a higher priority process which is activated. |
| poll | The process instance has requested a resource by polling (active waiting) which is not available. |
| run | The process instance resumes execution after polling (i.e. active waiting) for a resource. |
| wait | The process has requested a non-set OS EVENT (see OSEK 2.2.3 Extended Task Model, WAIT_Event()). |
| poll_parking | The parking process instance is allocated to the core and again polls (i.e. actively waits) for a resource. |
| park | The active waiting process instance is preemptedby another process. |
| release_parking | The resource which is requested by a parking process instance becomes available, but the parking process stays preempted and changes to READY state.|
| release | The OS EVENT which was requested by a process is set (see OSEK 2.2.3 Extended Task Model, SET_Event()) and the process is ready to proceed execution. |
| terminate | The process instance has finished execution.|
|/4. RunnableEvent | start | The runnable instance is allocated to the core and starts execution for the first time. |
| suspend | The executing runnable instance is stopped, because the calling process is suspended. |
| resume | The suspended runnable instance continues execution on the same or another core. |
| terminate | The runnable instance has finished execution. |
|/2. ComponentEvent | start | The execution of the component started, i.e. the first runnable in the list of runnables of the component instance is started. |
| end | The execution of the component completed, i.e. all runnables in the list of runnables of the component instance were executed at least once. |
|/2. ChannelEvent | send | A process or runnable has just sent data via the channel. |
| receive | A process or runnable has just received data via the channel |
|/2. LabelEvent | read | The read event indicates that a label is read by a process or runnable. |
| write | The write event indicates that a label is written by a process or runnable. |
|/4. ModeLabelEvent | read | The read event indicates that a mode label is read. |
| write | The write event indicates that a mode label is written. |
| increment | The increment event indicates that a mode label is written and the new value is greater than the old value. |
| decrement | The decrement event indicates that a mode label is written and the new value is less than the old value. |
|/2. SemaphoreEvent | lock | The semaphore has been requested by a runnable or process for a specific processing unit and reached the maximum number (usually 1) of assigned users. |
| unlock | The semaphore has been released by a process or runnable for a specific processing unit and can now be assigned to an other user. |

If it is required to define an event like "start-event of *some* process" then it is enough to create a object of type __ProcessEvent__ and set the event-type __start__.

It is also possible to restrict the definition of an event to a special entity. So it can be defined like "start-event of task T_1". Therefore it is possible to reference a process from __ProcessEvent__. In general, each event class can reference an entity of the corresponding type. In addition to that, each event class provides individual restrictions. So it is possible for __ProcessEvent__ that the event is not only restricted to a special process, it can be also restricted to a core. So that would be like "start-event of task T_1 on core C_2". Another example is the class __RunnableEvent__, it allows to restrict the event to a runnable, the process that executes the runnable and the core that executes the process.