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:

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

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

Entity Events

Trigger Events

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:

So for example the event-type-enumeration for a process event contains the events activate, start, resume, ...

Details

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

Event Class Event Type Description
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.
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.
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.
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
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.
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.
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.