plugins/org.eclipse.app4mc.help/docu/example_btf_mta3.textile

h3(#example-btf-mta3). BTF Example (MultipleTaskActivationLimit 3)

To clarify the interpretation of the multipleTaskActivationLimit (MTA) property of tasks, we provide a simple BTF trace example. In this example we focus on one task with an MTA = 3. Here we will show the internal task instance states of each of the three task instances. MTA = 3 means that at any given time only three task instances of the same task shall be active. A fourth activation will just be ignored. So at any given time, according to the BTF process state machine, only three state machines will exist to represent the state of their corresponding task instance.

Consider the following BTF trace:

bc. #version 2.2.1
#timeScale ns
0,ECU_1,-1,SIM,SIM,-1,tag,ECU_INIT
0,Processor_1,-1,SIM,SIM,-1,tag,PROCESSOR_INIT
0,Core_1,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_1,0,C,Core_1,0,set_frequence,10000000
0,Stimulus_Task,0,STI,Stimulus_Task,0,trigger
0,Stimulus_Task,0,T,Task,0,activate
100,Core_1,0,T,Task,0,start
100,Task,0,R,Runnable_1,0,start
19800,Task,0,R,Runnable_1,0,terminate
19800,Task,0,R,Runnable_2,0,start
20000,Stimulus_Task,1,STI,Stimulus_Task,1,trigger
20000,Stimulus_Task,1,T,Task,1,activate
40000,Stimulus_Task,2,STI,Stimulus_Task,2,trigger
40000,Stimulus_Task,2,T,Task,2,activate
42000,Task,0,R,Runnable_2,0,terminate
42000,Core_1,0,T,Task,0,terminate
42100,Core_1,0,T,Task,1,start
42100,Task,1,R,Runnable_1,1,start

The corresponding states, at specific points in time are shown in the following. We therefore show the composed state of three state machines for _Task_, indexed with [1..3]. The light blue colored state is the current state the state machine is in. So at the beginning of the trace the three state machines look like this:

!../pictures/mta3example1.svg!

h4. State after timestamp 0

After Task has been activated _Task<notextile>[1]</notextile>_ is now in the state activated and the state machines look like this:

!../pictures/mta3example2.svg!

h4. State after timestamp 100

Once the scheduler decided the task should run, _Task_ starts and, correspondingly, changes its state:

!../pictures/mta3example3.svg!

h4. State after timestamp 20000

Here, a second instance of _Task_ is activated while the first has not yet terminated. So _Task<notextile>[2]</notextile>_ enters the activated state:

!../pictures/mta3example4.svg!

h4. State after timestamp 40000

Again, another instance of _Task_ is activated so _Task<notextile>[3]</notextile>_ enters the activated state:

!../pictures/mta3example5.svg!

h4. State after timestamp 42000

_Task<notextile>[1]</notextile>_ has terminated (displayed in grey):

!../pictures/mta3example6.svg!

h4. State after timestamp 42100

Now, there is room for the state machine for the next task instance, we called it _Task<notextile>[4]</notextile>_. Also, the scheduler decided to let _Task<notextile>[2]</notextile>_ run:

!../pictures/mta3example7.svg!