AMALTHEA Trace Database (ATDB) Example

The ATDB provides tables and view definitions to hold trace data and represent it in comprehensive views. In this section we will show a small example BTF trace, convert it to its ATDB equivalent, and enrich it with event chains. The relevant tables and views will given for better understanding.

Source BTF Trace

The source BTF trace has two cores, three stimuli, three tasks, and four runnables.

#version 2.1.5
#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_2,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_1,0,C,Core_1,0,set_frequence,10000000
0,Core_2,0,C,Core_2,0,set_frequence,11000000
0,Stimulus_Task_1,0,STI,Stimulus_Task_1,0,trigger
0,Stimulus_Task_1,0,T,Task_1,0,activate
0,Stimulus_Task_2,0,STI,Stimulus_Task_2,0,trigger
0,Stimulus_Task_2,0,T,Task_2,0,activate
100,Core_1,0,T,Task_1,0,start
100,Task_1,0,R,Runnable_1_1,0,start
100,Core_2,0,T,Task_2,0,start
100,Task_2,0,R,Runnable_2_1,0,start
20800,Task_1,0,R,Runnable_1_1,0,terminate
20800,Task_1,0,R,Runnable_1_2,0,start
40900,Task_1,0,R,Runnable_1_2,0,terminate
40900,Core_1,0,T,Task_1,0,terminate
45000,Stimulus_Task_3,0,STI,Stimulus_Task_3,0,trigger
45000,Stimulus_Task_3,0,T,Task_3,0,activate
45100,Task_2,0,R,Runnable_2_1,0,suspend
45100,Core_2,0,T,Task_2,0,preempt
45100,Core_2,0,T,Task_3,0,start
45100,Task_3,0,R,Runnable_3_1,0,start
55800,Task_3,0,R,Runnable_3_1,0,terminate
55800,Core_2,0,T,Task_3,0,terminate
55900,Core_2,0,T,Task_2,0,resume
55900,Task_2,0,R,Runnable_2_1,0,resume
61000,Task_2,0,R,Runnable_2_1,0,terminate
61000,Core_2,0,T,Task_2,0,terminate

There is exacly one instance of each entity in the trace, so the tables in the database do not become to big for a small example. The visualized Gantt chart of the above trace is depicted in the following figure:

Equivalent ATDB Contents

The tables and/or relevant views for the above BTF trace are listed in the following: Note that if the table’s header starts with a “v” it is a view for better readability.

MetaInformation
name value
timeBase ns


Entity
id name entityTypeId
1 SIM 1
2 ECU_1 2
3 Processor_1 3
4 Core_1 4
5 Core_2 4
6 Stimulus_Task_1 5
7 Task_1 6
8 Stimulus_Task_2 5
9 Task_2 6
10 Runnable_1_1 7
11 Runnable_2_1 7
12 Runnable_1_2 7
13 Stimulus_Task_3 5
14 Task_3 6
15 Runnable_3_1 7
EntityInstance
entityId sqcnr
1 -1
2 -1
3 -1
4 -1
4 0
5 -1
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 0
13 0
14 0
15 0
EntityType
id name
1 SIM
2 ECU
3 Processor
4 C
5 STI
6 T
7 R
Property
id name type
1 processors entityIdRef
2 cores entityIdRef
3 frequencyInHz long
4 stimuli entityIdRef
5 executingCore entityIdRef
6 runnables entityIdRef
7 ecItems entityIdRef
8 ecStimulus eventIdRef
9 ecResponse eventIdRef
10 ecMinItemsCompleted long

Note that in the entityInstance table there are actually two instances of the cores (entityIds 4 and 5). Also note, the event chain properties are already contained in the property table.

vTraceEvent
timestamp sqcnr entityName entityType entityInstance sourceEntityName sourceEntityType sourceEntityInstance eventType value
0 0 Stimulus_Task_1 STI 0 Stimulus_Task_1 STI 0 trigger
0 1 Task_1 T 0 Stimulus_Task_1 STI 0 activate
0 2 Stimulus_Task_2 STI 0 Stimulus_Task_2 STI 0 trigger
0 3 Task_2 T 0 Stimulus_Task_2 STI 0 activate
100 0 Task_1 T 0 Core_1 C 0 start
100 1 Runnable_1_1 R 0 Task_1 T 0 start
100 2 Task_2 T 0 Core_2 C 0 start
100 3 Runnable_2_1 R 0 Task_2 T 0 start
20800 0 Runnable_1_1 R 0 Task_1 T 0 terminate
20800 1 Runnable_1_2 R 0 Task_1 T 0 start
40900 0 Runnable_1_2 R 0 Task_1 T 0 terminate
40900 1 Task_1 T 0 Core_1 C 0 terminate
45000 0 Stimulus_Task_3 STI 0 Stimulus_Task_3 STI 0 trigger
45000 1 Task_3 T 0 Stimulus_Task_3 STI 0 activate
45100 0 Runnable_2_1 R 0 Task_2 T 0 suspend
45100 1 Task_2 T 0 Core_2 C 0 preempt
45100 2 Task_3 T 0 Core_2 C 0 start
45100 3 Runnable_3_1 R 0 Task_3 T 0 start
55800 0 Runnable_3_1 R 0 Task_3 T 0 terminate
55800 1 Task_3 T 0 Core_2 C 0 terminate
55900 0 Task_2 T 0 Core_2 C 0 resume
55900 1 Runnable_2_1 R 0 Task_2 T 0 resume
61000 0 Runnable_2_1 R 0 Task_2 T 0 terminate
61000 1 Task_2 T 0 Core_2 C 0 terminate

The vTraceEvent table view intentionally resembles the original BTF trace. However, some information is omitted since it is extracted and stored in other tables (e.g. the frequency of the cores). All tags (eventType “tag”) have been stored in property values.

vPropertyValue
entityName entityType propertyName propertyType value
ECU_1 ECU processors entityIdRef Processor_1
Processor_1 Processor cores entityIdRef Core_1, Core_2
Core_1 C frequencyInHz long 10000000
Core_2 C frequencyInHz long 11000000
Task_1 T stimuli entityIdRef Stimulus_Task_1
Task_1 T executingCore entityIdRef Core_1
Task_1 T runnables entityIdRef Runnable_1_1, Runnable_1_2
Task_2 T stimuli entityIdRef Stimulus_Task_2
Task_2 T executingCore entityIdRef Core_2
Task_2 T runnables entityIdRef Runnable_2_1
Task_3 T stimuli entityIdRef Stimulus_Task_3
Task_3 T executingCore entityIdRef Core_2
Task_3 T runnables entityIdRef Runnable_3_1


vRunnableInstanceTraceInfo
runnableName entityInstance startEventCount resumeEventCount terminateEventCount suspendEventCount isComplete
Runnable_1_1 0 1 0 1 0 1
Runnable_2_1 0 1 1 1 1 1
Runnable_1_2 0 1 0 1 0 1
Runnable_3_1 0 1 0 1 0 1

All runnable instances are completely represented in the trace, as are the task instances. To keep it simple we leave out the vProcessInstanceTraceInfo table since it is too wide (it has more event types).

Adding Event Chains

Thus far, all information contained in the database has been extracted from the original BTF trace. Event chains, however, are not actually visible in the trace. So we insert their specification (which may originate from an AMALTHEA model) manually. Our event chain is specified as follows:

Runnable_1_1:start -> Runnable_1_1:terminate -> Runnable_3_1:start -> Runnable_3_1:terminate

In order to define our event chain for the respective events (which must be present even without a trace), we define them in the event table:

vEvent
name eventType entityName entityType sourceEntityName sourceEntityType
Runnable_1_1_start start Runnable_1_1 R
Runnable_1_1_terminate terminate Runnable_1_1 R
Runnable_3_1_start start Runnable_3_1 R
Runnable_3_1_terminate terminate Runnable_3_1 R

The following two tables then extend the existing ones by the event chains.

Entity
id name entityTypeId
16 EC1 8
17 EC1_segment1 8
18 EC1_segment2 8
19 EC1_segment3 8
EntityType
id name
8 EC

In the values of properties, we employ event chain items to represent the segments. As the vPropertyValue view indicates, at this point we refer to the stimulus/response events we created in the event table.

vPropertyValue
entityName entityType propertyName propertyType value
EC1 EC ecItems entityIdRef EC1_segment1, EC1_segment2, EC1_segment3
EC1 EC ecStimulus eventIdRef Runnable_1_1_start
EC1 EC ecResponse eventIdRef Runnable_3_1_terminate
EC1_segment1 EC ecStimulus eventIdRef Runnable_1_1_start
EC1_segment1 EC ecResponse eventIdRef Runnable_1_1_terminate
EC1_segment2 EC ecStimulus eventIdRef Runnable_1_1_terminate
EC1_segment2 EC ecResponse eventIdRef Runnable_3_1_start
EC1_segment3 EC ecStimulus eventIdRef Runnable_3_1_start
EC1_segment3 EC ecResponse eventIdRef Runnable_3_1_terminate

There is the additional view which explicitly combines event chains and their properties:

vEventChainEntity
eventChainName stimulus response items minItemsCompleted isParallel
EC1 Runnable_1_1_start Runnable_3_1_terminate EC1_segment1, EC1_segment2, EC1_segment3 0
EC1_segment1 Runnable_1_1_start Runnable_1_1_terminate 0
EC1_segment2 Runnable_1_1_terminate Runnable_3_1_start 0
EC1_segment3 Runnable_3_1_start Runnable_3_1_terminate 0

Each event chain has exactly one instance in the EntityInstance table. So the derived view for event chain instances is as follows:

vEventChainInstanceInfo
eventChainName ecInstance stimulusTimestamp stimulusEntityName stimulusEntityInstance stimulusEvent responseTimestamp responseEntityName responseEntityInstance responseEvent latencyType
EC1 0 100 Runnable_1_1 0 start 55800 Runnable_3_1 0 terminate age/reaction
EC1_segment1 0 100 Runnable_1_1 0 start 20800 Runnable_1_1 0 terminate age/reaction
EC1_segment2 0 20800 Runnable_1_1 0 terminate 45100 Runnable_3_1 0 start age/reaction
EC1_segment3 0 45100 Runnable_3_1 0 start 55800 Runnable_3_1 0 terminate age/reaction

Metrics on the Trace

There are numerous metrics for entities. The most important ones include the times that each entity instance remains in a specific state (according to their corresponding BTF state automaton). In addition to these metrics, there are also some counting metrics (e.g. how often a specific task instance was preempted). Lastly, there are also metrics for specific entity types and instances, e.g., the latency for a specific event chain instance (either age or reaction). The metrics themselves and these entity instance specific metrics for our example are listed in the following:

Metric
id name dimension
1 startDelayTime time
2 runningTime time
3 pollingTime time
4 parkingTime time
5 waitingTime time
6 readyTime time
7 responseTime time
8 coreExecutionTime time
9 netExecutionTime time
10 grossExecutionTime time
11 activateToActivate time
12 startToStart time
13 endToEnd time
14 endToStart time
15 slack time
16 activations count
17 preemptions count
18 suspensions count
79 ageLatency time
84 reactionLatency time

As indicated by th id numbering, we omitted some of the metrics. These include the respective Min/Max/Avg/StDev of each metric with dimension “time”. Here is the view of the entity instance metric values:

vEntityInstanceMetricValue
entityName entityType entityInstance metricName value
Task_1 T 0 startDelayTime 100
Task_1 T 0 runningTime 40800
Task_1 T 0 pollingTime 0
Task_1 T 0 parkingTime 0
Task_1 T 0 waitingTime 0
Task_1 T 0 readyTime 0
Task_1 T 0 responseTime 40900
Task_1 T 0 coreExecutionTime 40800
Task_1 T 0 netExecutionTime 40800
Task_1 T 0 grossExecutionTime 40800
Task_2 T 0 startDelayTime 100
Task_2 T 0 runningTime 50100
Task_2 T 0 pollingTime 0
Task_2 T 0 parkingTime 0
Task_2 T 0 waitingTime 0
Task_2 T 0 readyTime 10800
Task_2 T 0 responseTime 61000
Task_2 T 0 coreExecutionTime 50100
Task_2 T 0 netExecutionTime 50100
Task_2 T 0 grossExecutionTime 60900
Runnable_1_1 R 0 runningTime 20700
Runnable_1_1 R 0 readyTime 0
Runnable_2_1 R 0 runningTime 50100
Runnable_2_1 R 0 readyTime 10800
Runnable_1_2 R 0 runningTime 20100
Runnable_1_2 R 0 readyTime 0
Task_3 T 0 startDelayTime 100
Task_3 T 0 runningTime 10700
Task_3 T 0 pollingTime 0
Task_3 T 0 parkingTime 0
Task_3 T 0 waitingTime 0
Task_3 T 0 readyTime 0
Task_3 T 0 responseTime 10800
Task_3 T 0 coreExecutionTime 10700
Task_3 T 0 netExecutionTime 10700
Task_3 T 0 grossExecutionTime 10700
Runnable_3_1 R 0 runningTime 10700
Runnable_3_1 R 0 readyTime 0
EC1 EC 0 ageLatency 55700
EC1 EC 0 reactionLatency 55700
EC1_segment1 EC 0 ageLatency 20700
EC1_segment1 EC 0 reactionLatency 20700
EC1_segment2 EC 0 ageLatency 24300
EC1_segment2 EC 0 reactionLatency 24300
EC1_segment3 EC 0 ageLatency 10700
EC1_segment3 EC 0 reactionLatency 10700

Note that since each event chain instance also is either age, reaction, or both, there are two latency metrics to distinguish between the two. There are also cumulated Min/Max/Avg/StDev values calculated from these entity instance metric values. Since there is only one instance of each entity in the example trace the values are all the same, so we omit the EntityMetricValue table here (it has roughly four times as many entries).