3rd Party Software Support

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.

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.

 

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

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

 

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 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

AUTOSAR Tool Cooperations

Elektrobit Besides many joint customer projects, Elektrobit and iSYSTEM have worked closely together to create various demonstrator platforms used to present advanced timing analysis concepts. You plan to use iSYSTEM tools together with EB tresos Studio to run timing analysis on EB tresos AutoCore or Safety OS? You want to profile OS Task/Thread States or profile Runnables? Get in touch with us and we will help you setting it all up! 
Vector Through customer projects and reference platforms iSYSTEM can offer various concepts for an in-depth analysis on MICROSAR-based applications. OS scheduling analysis can be accomplished in various ways, ranging from standard-ORTI, Task-State profiling to more advanced tracing capabilities utilizing dedicated Trace Instrumentation Hooks of the Vector AUTOSAR stack (so-called “Timing Hooks”).
ETAS Driven by some demanding customer projects, ETAS and iSYSTEM have jointly developed profiling solutions beyond standard ORTI, introducing vendor-specific extensions allowing a better insight into OS task scheduling. Another result of such demanding customer projects is the ability to profile multiple RTA-OS instances running within Virtual Machines created by the ETAS Hypervisor RTA-HVR.
Evidence Erika Enterprise is a royalty free automotive OSEK/VDX certified Hard Real Time Operating System (RTOS) maintained by Evidence in Italy. Evidence is an AUTOSAR development member and a long term partner of iSYSTEM. The interface between Erika Enterprise and winIDEA supports standard running Task and ISR profiling of Erika Enterprise via ORTI, as well as more advanced use-cases such as task state profiling.

 

Software Modeling/Simulation Tool Cooperations

INCHRON  The integration of iSYSTEM and INCHRON tools is, on one hand, driven by many customer projects, on the other hand, both companies have jointly created reference platforms to extend and demonstrate the high-level of integration. One good example for this cooperation is the multi-ECU platform, demonstrating event-chain analysis across multiple ECUs. 
Luxoft/SymtaVision Driven by demanding customer projects, both companies have worked together to ensure a SymTA/S system model can be correlated against real hardware timing information captured by iSYSTEM trace tools. iSYSTEM trace export files can be seamlessly imported into the SymtaVision TraceAnalyzer.
Avelabs Through a close cooperation, the export/import interfaces of the iSYSTEM and Avelabs tools have been adjusted to allow a seamless import of hardware trace data, captured by iSYSTEM trace tools, into the Avelabs Gaspra Tool.
Vector Informatik For developers seeking to verify target systems behaviour, Vector tools allow the examination of timing and resource consumption against timing requirements. The Vector Informatik TA Inspector tool connects to iSYSTEM to import hardware trace data.

 

Application Notes

Document Description
Vector Microsar Profiling

This application note describes how to use the iSYSTEM winIDEA Analyzer for the timing analysis of the Vector MICROSAR operating system

EB tresos Safety OS 2.x Thread Profiling

This application note describes two approaches for OS scheduling analysis on EB tresos Safety OS.

ETAS RTA-HVR Hypervisor & Multi RTA-OS Profiling

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

Elektrobit EB tresos AutoCore ProfilingThis application note describes how to use the iSYSTEM winIDEA Analyzer for the timing analysis of the EB tresos AutoCore operating system.
Elektrobit EB tresos Runnable ProfilingThis application note describes how to use the iSYSTEM winIDEA Analyzer for the timing analysis of AUTOSAR Runnables of the two Elektrobit AUTOSAR solutions “EB tresos AutoCore” and “EB tresos Safety”.

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.