Overview

It is often the case with exceptionally complex applications, such as AUTOSAR based, safety critical, multi-core microcontroller automotive systems, that advanced analysis techniques are required to prove functional safety. AUTOSAR applications can be especially challenging, which is why iSYSTEM provides appropriate hardware and software that delivers insights of such systems.

iSYSTEM not only offers standard AUTOSAR OS awareness based on the ORTI specification. We can provide far more advanced Timing-Analysis solutions. The solutions are a result of our long-term cooperation with the major AUTOSAR Tool vendors and have been enabled by many sophisticated winIDEA Analyzer features such as

  • Task State Profiling,
  • Event Analysis via so called Profiler Inspectors and
  • Trace Export in various formats such as BTF.

AUTOSAR vendor specific configurations and adaptation/instrumentation allow for more comprehensive Timing Analysis including OS objects such as task and ISRs, but also Software Components and RTE objects such as Runnables and Ports as well as network communication.

 

Figure 1: Sample AUTOSAR Software Architecture

Figure 1: Sample AUTOSAR Software Architecture

AUTOSAR OS Awareness

Today AUTOSAR OS awareness is mainly based on the so-called OSEK Runtime Interface (ORTI) specification. ORTI originates from the OSEK Standard and has been adopted by AUTOSAR. An OSEK compliant OS generates a so-called ORTI file. This ORTI is imported into a debug/trace tool to make it “OS-aware”.

The ORTI file:

  • Is generated by the AUTOSAR OS Generator tool
  • Informs the Debug/Trace Tool about OS Objects (tasks, ISRs, Stack, Scheduling Tables,….)

Contains symbolic information. The address information of these Symbols is obtained from the ELF file (OS Code needs to be compiled with -g Option to include Debug Info.).

The Debug/Trace tool may use it’s OS awareness to inform the User about OS internal in two different ways:

  • Static Display of the current Status of OS Objects.
  • Dynamic behavior of the OS Objects over time, e.g. OS task scheduling analysis.

 

Figure 2: ORTI Generation and Import into Debug/Trace Tool

Figure 2: ORTI Generation and Import into Debug/Trace Tool

 

The OS typically maintains some internal static data structures containing the current status of OS objects. The ORTI “tells” the debug/trace tool about the relevant data structures and how to interpret their contents.

The Debug/Trace tool may use it’s OS awareness to inform the User about OS internal in two different ways:

  • Static Display of the current Status of OS Objects.
  • Dynamic behavior of the OS Objects over time, e.g. OS task scheduling analysis.

AUTOSAR OS Objects Status Display (based on ORTI File)

A snap shot of the current status of all OS objects described in the ORTI file can be obtain by mean of the OS Objects view (winIDEA Menu: “View – Operating Systems… -  Objects…”).

 

Firgure 3: Sample OS objects View of a Multi-core AUTOSAR OS

Figure 3: Sample OS Objects View of a Multi-Core AUTOSAR OS

Basic AUTOSAR OS Timing-Analysis (based on ORTI File)

Timing analysis of the AUTOSAR OS is typically accomplished by monitoring specific OS variables by means of on-chip hardware trace.  By writing a unique ID or a pointer value to these variables the OS signals the new, currently running OS task, or ISR, respectively. The The symbolic names of these OS variables is given in the ORTI file (as shown in the code listing below).

 

Listing 1: Sample ORTI File Section

Listing 1: Sample ORTI File Section

Figure 4 shows a sample OS task and ISR Cat.2 profiler timeline of a dual-core AUTOSAR OS.

 

Figure 4: Sample Profiler Timeline (RUNNINGTASK and RUNNINGISR2)

Figure 4: Sample Profiler Timeline (RUNNINGTASK and RUNNINGISR2)

Advanced AUTOSAR Analysis

As discussed above, the ORTI file based timing analysis focuses on the OS, but ignores other AUTOSAR modules such as Software Components (SWCs) and Run-Time Environment (RTE). The scheduling of the AUTOSAR Runnables (by means of OS tasks) is often the relevant subject of timing analysis. 

ORTI file based AUTOSAR Analysis has the following deficits:

  • According to ORTI, the OS only signals the currently running task (RUNNINGTASK). This does not allow to distinguish between Task Termination, Preemption and Waiting.
  • Does not allow for detailed Timing Analysis like Activation Delays, Total Response Time ,...
  • Runnables are not covered by the ORTI file as Runnables are implemented in Application Layer, above RTE.
  • Software components communicate via RTE ports, i.e. communication is hidden in the RTE and not covered by the ORTI file.

The limitations can be overcome by a close cooperation of the tools involved in AUTOSAR-based software development.

 

Figure 5: AUTOSAR Tool Interaction for Advanced AUTOSAR Analysis & Optimization

Figure 5: AUTOSAR Tool Interaction for Advanced AUTOSAR Analysis & Optimization

So, the message to you as an AUTOSAR System Developer (Architect/Integrator): Think about your testing and timing analysis requirements already in an early project phase and bring all the tool vendors mentioned above together! Then we can make sure all your requirement can be fulfilled and provided to you in a user-friendly fashion.

 

Task State Profiling and Profiler Inspectors

For a more in-depth analysis of the OS scheduling behavior it is often not enough to trace the currently running task. Instead, the detailed status of each task needs to be traced and analyzed.

Depending on the underlying AUTOSAR OS (i.e. OS vendor), it may be required to trace additional OS data objects (signaling state changes of each OS task). In case the OS does not signal the state change events via global data objects or in case the on-chip trace hardware does not support data access trace, it may be need to add trace instrumentation code into the OS code, ideally utilizing already existing trace instrumentation hooks (i.e. macros) of the OS.

The sample OS task profiler timeline depicted in Figure 6 shows that profiling results purely based on ORTI RUNNINGTASK tracing may be rather misleading. The profile on the bottom actually shows a single instance of an OS task, entering a READY state intermediately (due to preemption), whereas the profile on the top interprets the task resumption (from preemption) as a new instance of the task.

 

Figure 6: Sample OS Task Profile, based on ORTI RUNNINGTASK (top)  and based on Task State Trace (bottom)

Figure 6: Sample OS Task Profile, based on ORTI RUNNINGTASK (top) and based on Task State Trace (bottom)

An advanced and versatile feature of the iSYSTEM Trace Analyzer, the so-called Inspectors, allow a user-defined post-analysis of the Profiler Timeline.

An AUTOSAR OS vendor specific Inspector configuration can, for instance, be used to derive standard AUTOSAR Timing Parameters (according to AUTOSAR Technical Report “AUTOSAR_TR_TimingAnalysis.pdf”) from a task state profile. Figure 7 shows a sample Profiler Timeline including OS Tasks, states of Task “T_100MS” and the AUTOSAR Timing Parameters derived by means of Inspectors. This sample was generated using an EB tresos AutoCore OS.

 

Figure 7: Advanced AUTOSAR OS Timing Metric Calculation by means of Profiler Inspectors

Figure 7: Advanced AUTOSAR OS Timing Metric Calculation by means of Profiler Inspectors

AUTOSAR Timing Metrics

iSYSTEM is an AUTOSAR Development Partner

We are active in the following AUTOSAR Workpackages, Concept Groups, Feature Teams.

  • Work Package WP-A1 – Concept Group ARTI – AUTOSAR Runtime Interface
  • Work Package WP-M1 - Timing Analysis
  • AUTOSAR Adaptive Feature Team FT DI – Demonstrator Integration

 

Figure 8: “ARTI – What is it?” Slide from Embedded Multicore Conference 2017

Figure 8: “ARTI – What is it?” Slide from Embedded Multicore Conference 2017

Application Notes

Document Description
EB tresos Safety OS 2.x Thread Profiling (2.32MB)This application note describes two approaches for OS scheduling analysis on EB tresos Safety OS.
ETAS RTA-HVR Hypervisor & Multi RTA-OS Profiling (1.21MB)

This documents describes how to use winIDEA for Multi-OS timing analysis (profiling) using the ETAS Lightwight Hypervisor, RTA-HVR.

If you require further help to understand how iSYSTEM's software and BlueBox On-Chip Analyzers can be used in combination with AUTOSAR applications, why not get in touch using the contact link on the right.