### 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).