AUTOSAR Classic Profiling
In this topic:
It assumes that:
•An OSEK builder was used to generate the application, with debug support for at least RUNNINGTASK indication. Make sure that a valid ORTI file is generated by entering the appropriate definitions into the OIL file. winIDEA supports ORTI 1.x and 2.x files.
•The OSEK and user sources have been compiled and linked to an executable.
Profiling is the process of recording, analyzing, and evaluating the timing behavior of an embedded system. If we talk about AUTOSAR Classic Profiling, we mean profiling the runtime behavior of:
•AUTOSAR Classic-based application, specifically the application itself
•Run-Time Environment (RTE)
•Operating System (OS)
•other parts of the Basic Software (BSW)
With the resulting data, you can cover use cases such as:
•CPU load analysis
•Event-chain analysis
•Timing requirements validation
•Timing constraint validation
•OS metric calculation
•etc.
If you are entirely new to this topic, we recommend watching the Introduction to AUTOSAR Classic Profiling webinar. |
Below you can see the result of AUTOSAR Profiling in winIDEA. The Gantt-Chart shows the state of different OS (Tasks/ISRs) and RTE (Runnables) objects over time. The dark red color indicates that an object is running.
Before we discuss the workflow, it is essential to understand the variables that influence the steps:
•Defines the objects of interest in the analysis. For example, CPU load analysis requires profiling only Tasks and ISRs, while event-chain analysis may require Runnables and RTE-Port communication data.
•Depending on the microcontroller, certain trace features may or may not be available. For example, data trace is not available on all microcontrollers that have trace capabilities, in which case instrumentation trace may be required.
•Not all AUTOSAR Operating Systems and RTEs are equal. Some differences between vendors need consideration to end up with a working setting.
To summarize, you must consider the three factors desired objects, available trace capabilities, and operating system and RTE vendor, for the configuration. The section Background discusses each element in more detail.
To configure AUTOSAR Profiling correctly, working knowledge of trace objects, trace techniques, and operating systems is necessary. The following sections discuss these topics.
An AUTOSAR application consists of different objects such as Tasks, ISRs, Runnables, Functions, RTE Ports, and more. You must decide which types of objects are relevant for their use case. Profiling the Running Task and ISR is a good start if the use case is not clear.
The most common objects for timing analysis are Tasks and ISRs. Tasks are operating system containers for Runnables. ISRs are interrupt triggered service routines for high priority computations. A trace containing only the information about the currently running Task and ISR is called a Running Task/ISR Trace. Some operating systems use Thread as an umbrella term for Tasks and ISRs.
A Running Task/ISR Trace is not always sufficient for timing analysis. For example, while the information is adequate to calculate the CPU utilization of a system, it is not enough to calculate the response time of a given task. Response time is the time from activation to termination of a Task, including the times during which the task is in the ready state (meaning a higher priority task is running). With a running Task/ISR, trace information about activations and preemptions is not available. In this case, a Task State/Running ISR trace is necessary because it includes to task state model of each task. With the knowledge about the states, the Profiler knows when a task is terminated or just preempted. Task states make calculating a couple of advanced metrics, including the response time, feasible.
AUTOSAR Runnables are special functions defined in the RTE. They are mapped to tasks and executed in the context of those tasks. RTE events, such as timing events and data-received events, trigger the execution of Runnables. Runnable tracing becomes essential when a more detailed view of the application is required. Runnable tracing can be done independently from Task/ISR tracing. However, whenever not only the currently running Runnable is of interest, but also the information about preemptions and resumes, it is mandatory to record a Task/ISR state trace in conjunction with the Runnables. By tracing the Task State and Running ISR information, the Profiler can reconstruct the Runnable preempt and resume events.
AUTOSAR Profiling currently focuses on the three discussed objects, Tasks, ISRs, and Runnables. In the future, additional classes are going to become relevant, and we will extend this section accordingly. AUTOSAR Runnables map to software components. Communication between different software components happens via communication interfaces, such as sender/receiver and client/server interfaces. Profiling communication via these interfaces is one possible future use-case. Additional objects are Spinlocks, Resources, OS Critical Sections, and other synchronization mechanisms. Finally, a user may want to record custom events such as write and read accesses to a specific signal. Tracing signals allows for verification of so-called data age constraints. A data age constraint is a time limit on the period between data production and consumption.
There are three main trace measurement techniques:
•software
•hybrid
•hardware-based tracing
A trace is a list of events with timestamps in ascending order enabling the user to examine the runtime behavior of a system. In this section, we focus on hardware-based tracing. Hardware-based tracing relies on dedicated on chip trace logic, which captures events of interest and sends them off-chip. The figure below shows the steps involved in recording trace data from the target. Depending on the microcontroller, zero or more of the following techniques are available. The available trace techniques influence which Trace Objects are recordable on for how long.
Recording a hardware trace with winIDEA. Dedicated on-chip trace logic generates trace messages that are captured by the debugger and send to the host computer for profiling.
If you are entirely new to this topic, we recommend following the Getting started with Trace Tutorials. |
A program flow trace (also called instruction trace) records the instructions the CPU executes. This technique shows the complete execution path of an application for the duration of the trace recordingProgram flow tracing can be used for debugging, but also for profiling Runnables and functions. Note that the on-chip trace logic does not create a dedicated trace message for every instruction. Instead, it only creates messages for instructions that change the flow of the program, such as calls and conditional jumps. winIDEA then reconstructs the full program flow trace from the compressed data. Even with compressed function trace, program flow trace still generates high amounts of data. Therefore, depending on the trace interface (the interface between the microcontroller and the debugger), recording program flow traces may only be possible for short periods (less than 100ms).
Data tracing records read and write accesses to memory, and thus allows recording of write accesses to global variables. Comparators enable the user to configure the memory areas and variables of interest. An example use-case for data tracing is monitoring the OS running task variable to generate a task trace.
For some use-cases, pure data tracing is not sufficient to record all necessary information. For example, the RTE does not provide a variable indicating the currently running Runnable. In such cases, adding instrumentation to write the desired information into a dedicated variable is a compromise between pure hardware-based tracing and software trace. This compromise is also commonly used for recording task state traces for specific operating systems.
Instrumentation trace is similar to Instrumented Data Trace. Instrumentation trace utilizes microcontroller specific memory areas or instructions. When the application writes into one of these memory areas, or when it executes one of the instructions, the on-chip trace logic automatically generates a trace message. Examples for Instrumentation Trace are Software Trace (SFT) for RH850 based microcontrollers and Ownership Trace Messages (OTM) for PowerPC based microcontrollers.
For example, the RH850 software trace provides three trace instructions: DBCP messages include the current PC value, DBTAG messages include a constant value (specified at compile-time), and DBPUSH takes a value from a specific general-purpose register. The software trace module sends the trace messages off-chip via the serial port LPD-4 interface. The LPD-4 interface contains an eight-line FIFO where each line has 48 bits capacity. While the FIFO helps to overcome short term bottlenecks generating too many software trace messages may still result in overflows. On microcontrollers where data-trace is not available, instrumentation trace is often a good alternative.
Even though all AUTOSAR OS adhere to the same specification, there are still differences that impact AUTOSAR OS and RTE Profiling.
For example, while all AUTOSAR-based OS have a so-called task-state attribute for each task, the method for each OS differs significantly. For some operating systems, the formula points to a simple global variable; for others, it is a complex expression containing multiple variables, as shown in the code snippet below. The first task signals the state via a simple global variable. The operating system keeps track of the task states via a global array and each field maps to a specific task. By recording write accesses to this array, the Profiler can reconstruct the states for all task objects.
The second task uses a complex formula consisting of multiple global variables to signal the state. To reconstruct the state, we must record the write accesses to each of these variables. We then use a unique winIDEA feature, the so-called Profiler Inspectors, to reconstruct the state from the individual variables. We provide a tool that generates the Profiler Inspectors for all tasks automatically.
ORTI task state attributes for two tasks. We can record the state of the first task via a single global variable. However, the second task encodes the state information into multiple global variables.
TASK Init_Task { STATE = "OS_taskState[1]"; /* lines removed for readability */ }; TASK QM_Task { STATE = "(((Os_RunningTask == Os_const_tasks[0]) * 1) & 1) + ((Os_ReadyTasks.p0 & 0x1) << 1)"; /* lines removed for readability */ }; |
The most common AUTOSAR Classic OS are:
•Elektrobit AutoCore OS
•Elektrobit Safety OS
•ETAS RTA-OS
•Vector MICROSAR OS
With a basic understanding of the technologies involved in AUTOSAR Classic Profiling, we can now discuss the workflow in more detail. The general process for AUTOSAR profiling always follows the same pattern:
1. Assessing the available trace capabilities, the OS and RTE in use, and the trace objects.
2. Configuring the OS, winIDEA, and the hardware trace logic.
3. winIDEA traces the application, profiles the recorded data, and makes it available for analysis. The result is a detailed view of the OS and RTE.
You can then analyze the data in winIDEA itself, generates reports, or exports the data for analysis in other tools.
The first step is to decide which types of objects to record based on the trace techniques you have available on your microcontroller. Currently supported classes are running tasks and running ISR, task states and running ISR, and Runnables. Depending on the microcontroller, there may or may not be a way to record the desired information. The row headers in table list the different hardware trace techniques, and the column headers contain the different types of objects. Note that there is an additional column for signals. Signals are global variables, and winIDEA can profile them with regular data areas.
Trace techniques allow profiling of specific types of objects:
Running Task ISR |
Task State Running ISR |
Runnables |
Signals |
|
Program Flow Trace |
|
|
XML |
|
Data Trace |
ORTI XML |
XML |
|
XML |
Instrumented Data Trace |
|
XML OS Trace Hooks |
XML VFB Trace Hooks |
|
Instrumentation Trace |
XML OS Trace Hooks |
XML OS Trace Hooks |
XML VFB Trace Hooks |
|
The table shows which trace techniques can record a specific class of objects. Not all combinations are feasible. In such cases, the respective cell in the table is empty. For supported combinations, the field shows the winIDEA configuration file format in bold (either ORTI or Profiler XML) and the underlying instrumentation technique (for instrumentation-based use-cases). Task and ISR profiling relies on OS Trace Hooks, and Runnable profiling uses the so-called VFB Trace Hooks.
All use cases require a:
•ORTI (OSEK Runtime-Interface) file - The OS generates this file (usually it has an ORT or ORTI file ending), which includes information about OS objects such as Tasks, ISRs, and alarms.
•winIDEA OS Info XML - For all use cases except the basic Running Task/ISR profiling (and even there it may be necessary), a winIDEA specific configuration file is mandatory. This file informs the winIDEA Profiler about the profiling objects, the entity mapping (for example, the task ID to task name mapping), and further options such as BTF trace export configuration.
A tool called Trace Configuration Helper (iTCHi) can generate the XML file automatically. With the trace objects and the underlying trace technology to record them available, the last step is to find out the operating system used by the application.
To summarize, go through the following three points:
•Specify the object classes you want to record.
•Verify the trace capabilities of your microcontroller.
•Find out which operating system your application uses.
Once you have this information available, you are ready to configure your profiling use case.
With the assessment complete, you are now able to configure the OS and RTE, winIDEA, and the winIDEA Analyzer to profile the data based on your specific use-case. The first step is to enable ORTI support. Additionally, for instrumentation-based use-cases, the respective OS timing-hooks and RTE virtual function bus trace hooks must be equipped.
Please, refer to the operating system specific documentation for this step:
•Elektrobit EB tresos AutoCore Profiling
•EB tresos Safety OS 2.x Thread Profiling
If your operating system is not on this list, feel free to reach out to us, and we can assist you with the setup. As long as you are using an AUTOSAR based operating system, winIDEA supports OS and RTE profiling.
The next step is to implement the instrumentation hooks if used and to make winIDEA aware of the profiling use case. To create OS and RTE awareness, you have to generate an Profiler XML file via Trace Configuration Helper (iTCHi).
The table is similar to the previous one, except it shows the iTCHi commands for the tracing technique/object class pairings. You can run multiple commands at the same time, for example, if you want to profile task states via instrumentation and Runnables via program flow trace the respective iTCHi call would be:
itchi-bin.exe –-task_state_instrumentation –-runnable_program_flow |
iTCHi commands for the different trace technique to trace object mappings:
Running Task ISR |
Task State Running ISR |
Runnables |
|
Program Flow Trace |
|
|
runnable_program_flow |
Data Trace |
running_taskisr |
task_state_simple_variable task_state_complex_expression |
|
Instrumented Data Trace |
|
task_state_instrumentation |
runnable_instrumentation |
Instrumentation Trace |
|
task_state_instrumentation |
|
After generating an Profiler XML file, a Profiler Inspectors JSON file, and instrumentation code (do not forget to rebuild if you use instrumentation), you can move on to configure winIDEA. First, add the Profiler XML to winIDEA and then start with the Analyzer configuration. Depending on the use case, you may have to configure the trace manually.
Check the following documentation for detailed information:
•Instrumented Vector MICROSAR Profiling
•Non-Instrumented MICROSAR Profiling
Once you have completed these steps, you are ready to profile the OS and RTE of your application.
Congratulations, you can now run the microcontroller and start profiling your application.
•Introduction to Tracing - Webinar
•AUTOSAR CLASSIC Timing Analysis – Hardware-Trace-Based Real-Time Analysis - Webinar
•ETAS RTA-HVR Hypervisor & Multi RTA-OS Profiling - Application Note
•ETAS RTA-OS Profiling - Application Note