AUTOSAR

It is often the case with excep­tion­al­ly com­plex appli­ca­tions, such as AUTOSAR based, safe­ty crit­i­cal, mul­ti-core micro­con­troller auto­mo­tive sys­tems, that advanced analy­sis tech­niques are required to prove func­tion­al safe­ty. AUTOSAR appli­ca­tions can be espe­cial­ly chal­leng­ing, which is why TASKING pro­vides appro­pri­ate hard­ware and soft­ware that deliv­ers insights of such sys­tems.

TASKING not only offers stan­dard AUTOSAR OS aware­ness based on the ORTI spec­i­fi­ca­tion. We can pro­vide far more advanced Tim­ing-Analy­sis solu­tions. The solu­tions are a result of our long-term coop­er­a­tion with the major AUTOSAR Tool ven­dors and have been enabled by many sophis­ti­cat­ed winIDEA Ana­lyz­er fea­tures such as:

  • Task State Pro­fil­ing,
  • Event Analy­sis via so called Pro­fil­er Inspec­tors and
  • Trace Export in var­i­ous for­mats such as BTF.

AUTOSAR ven­dor spe­cif­ic con­fig­u­ra­tions and adaptation/instrumentation allow for more com­pre­hen­sive Tim­ing Analy­sis includ­ing OS objects such as task and ISRs, but also Soft­ware Com­po­nents and RTE objects such as Runnables and Ports as well as net­work com­mu­ni­ca­tion.

On this page

Advanced AUTOSAR Analy­sis
Pro­fil­er Inspec­tors
AUTOSAR Develop­ment Part­ner
Tool Coop­er­a­tions
More resources

The message to you as an AUTOSAR System Developer

Think about your test­ing and tim­ing analy­sis require­ments already in an ear­ly project phase and bring all the tool ven­dors men­tioned above togeth­er!

Then we can make sure all your require­ment can be ful­filled and pro­vid­ed to you in a user-friend­ly fash­ion.

Sam­ple AUTOSAR Soft­ware Archi­tec­ture

AUTOSAR OS Awareness

Today AUTOSAR OS aware­ness is main­ly based on the so-called OSEK Run­time Inter­face (ORTI) spec­i­fi­ca­tion. ORTI orig­i­nates from the OSEK Stan­dard and has been adopt­ed by AUTOSAR. An OSEK com­pli­ant OS gen­er­ates a so-called ORTI file. This ORTI is import­ed into a debug/trace tool to make it “OS-aware”.

The ORTI file:

  • Is gen­er­at­ed by the AUTOSAR OS Gen­er­a­tor tool,
  • Informs the Debug/Trace Tool about OS Objects (tasks, ISRs, Stack, Sched­ul­ing Tables…),
  • Con­tains sym­bol­ic infor­ma­tion.

The address infor­ma­tion of these Sym­bols is obtained from the ELF file (OS Code needs to be com­piled with ‑g Option to include Debug Infor­ma­tion).

The Debug/Trace tool may use it’s OS aware­ness to inform the User about OS inter­nal in two dif­fer­ent ways:

  • Sta­t­ic Dis­play of the cur­rent Sta­tus of OS Objects,
  • Dynam­ic behav­ior of the OS Objects over time, e.g. OS task sched­ul­ing analy­sis.

The OS typ­i­cal­ly main­tains some inter­nal sta­t­ic data struc­tures con­tain­ing the cur­rent sta­tus of OS objects. The ORTI “tells” the debug/trace tool about the rel­e­vant data struc­tures and how to inter­pret their con­tents.

ORTI Generation and Import into Debug/Trace Tool
ORTI Gen­er­a­tion and Import into Debug/Trace Tool

AUTOSAR OS Objects Status Display (based on ORTI File)

A snap shot of the cur­rent sta­tus of all OS objects described in the ORTI file can be obtain by mean of the OS Objects view.

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

Tim­ing analy­sis of the AUTOSAR OS is typ­i­cal­ly accom­plished by mon­i­tor­ing spe­cif­ic OS vari­ables by means of on-chip hard­ware trace.  By writ­ing a unique ID or a point­er val­ue to these vari­ables the OS sig­nals the new, cur­rent­ly run­ning OS task, or ISR, respec­tive­ly.

Sample OS Objects View
Sam­ple OS Objects View

The sym­bol­ic names of these OS vari­ables in the ORTI file is giv­en below. A sam­ple OS task and ISR Cat.2 pro­fil­er time­line of a dual-core AUTOSAR OS is giv­en on the right.

OS XY
{
RUNNINGTASK{0} = "OS_taskCurrent{0}";
RUNNINGTASK{0} = "OS_isr2Current{0}";
...
}
Sample Profiler Timeline (RUNNINGTASK and RUNNINGISR2)
Pro­fil­er Time­line (RUNNINGTASK and RUNNINGISR2)

Advanced AUTOSAR Analysis

As dis­cussed above, the ORTI file based tim­ing analy­sis focus­es on the OS, but ignores oth­er AUTOSAR mod­ules such as Soft­ware Com­po­nents (SWCs) and Run-Time Envi­ron­ment (RTE). The sched­ul­ing of the AUTOSAR Runnables (by means of OS tasks) is often the rel­e­vant sub­ject of tim­ing analy­sis.

ORTI file based AUTOSAR Analy­sis has the fol­low­ing deficits:

  • Accord­ing to ORTI, the OS only sig­nals the cur­rent­ly run­ning task (RUNNINGTASK). This does not allow to dis­tin­guish between Task Ter­mi­na­tion, Pre­emp­tion and Wait­ing.
  • Does not allow for detailed Tim­ing Analy­sis like Acti­va­tion Delays, Total Response Time…
  • Runnables are not cov­ered by the ORTI file as Runnables are imple­ment­ed in Appli­ca­tion Lay­er, above RTE.
  • Soft­ware com­po­nents com­mu­ni­cate via RTE ports, i.e. com­mu­ni­ca­tion is hid­den in the RTE and not cov­ered by the ORTI file.
AUTOSAR Tool Interaction for Advanced AUTOSAR Analysis & Optimization
Advanced AUTOSAR Tool Inter­ac­tion & Opti­miza­tion

Task State Profiling

For a more in-depth analy­sis of the OS sched­ul­ing behav­ior it is often not enough to trace the cur­rent­ly run­ning task. Instead, the detailed sta­tus of each task needs to be traced and ana­lyzed.

Depend­ing on the under­ly­ing AUTOSAR OS (i.e. OS ven­dor), it may be required to trace addi­tion­al OS data objects (sig­nal­ing state changes of each OS task). In case the OS does not sig­nal the state change events via glob­al data objects or in case the on-chip trace hard­ware does not sup­port data access trace, it may be need to add trace instru­men­ta­tion code into the OS code, ide­al­ly uti­liz­ing already exist­ing trace instru­men­ta­tion hooks (i.e. macros) of the OS.

The sam­ple OS task pro­fil­er time­line depict­ed on the right shows that pro­fil­ing results pure­ly based on ORTI RUNNINGTASK trac­ing may be rather mis­lead­ing. The pro­file on the bot­tom actu­al­ly shows a sin­gle instance of an OS task, enter­ing a READY state inter­me­di­ate­ly (due to pre­emp­tion), where­as the pro­file on the top inter­prets the task resump­tion (from pre­emp­tion) as a new instance of the task.

winIDEA Pro­fil­er

Profiler Inspectors

An advanced and ver­sa­tile fea­ture of the TASKING Ana­lyz­er are Inspec­tors, allow­ing a user-defined post-analy­sis of the Pro­fil­er Time­line.

An AUTOSAR OS ven­dor spe­cif­ic Inspec­tor con­fig­u­ra­tion can, for instance, be used to derive stan­dard AUTOSAR Tim­ing Para­me­ters (accord­ing to AUTOSAR Tech­ni­cal Report AUTOSAR_TR_TimingAnalysis.pdf) from a task state pro­file.

Sam­ple on the right shows a sam­ple Pro­fil­er Time­line includ­ing OS Tasks, states of Task “T_100MS” and the AUTOSAR Tim­ing Para­me­ters derived by means of Inspec­tors. This sam­ple was gen­er­at­ed using an EB tre­sos Auto­Core OS.

Advanced AUTOSAR OS Timing Metric Calculation via Profiler Inspectors
Advanced AUTOSAR OS Tim­ing Met­ric

TASKING is an AUTOSAR Development Partner

We are active in the fol­low­ing AUTOSAR Work­pack­ages, Con­cept Groups, Fea­ture Teams.

  • Work Pack­age WP-A1 – Con­cept Group ARTI – AUTOSAR Run­time Inter­face
  • Work Pack­age WP-M1 — Tim­ing Analy­sis
  • AUTOSAR Adap­tive Fea­ture Team FT DI – Demon­stra­tor Inte­gra­tion

AUTOSAR Tool Cooperations

Elektrobit

Besides many joint cus­tomer projects, Elek­tro­bit and TASKING have worked close­ly togeth­er to cre­ate var­i­ous demon­stra­tor plat­forms used to present advanced tim­ing analy­sis con­cepts. You plan to use TASKING tools togeth­er with EB tre­sos Stu­dio to run tim­ing analy­sis on EB tre­sos Auto­Core or Safe­ty OS? You want to pro­file OS Task/Thread States or pro­file Runnables? Get in touch with us and we will help you set­ting it all up!

Vector

Through Vec­tor’s cus­tomer projects and ref­er­ence plat­forms TASKING can offer var­i­ous con­cepts for an in-depth analy­sis on MICROSAR-based appli­ca­tions. OS sched­ul­ing analy­sis can be accom­plished in var­i­ous ways, rang­ing from stan­dard-ORTI, Task-State pro­fil­ing to more advanced trac­ing capa­bil­i­ties uti­liz­ing ded­i­cat­ed Trace Instru­men­ta­tion Hooks of the Vec­tor AUTOSAR stack (so-called “Tim­ing Hooks”).

ETAS

Dri­ven by some demand­ing cus­tomer projects, ETAS and TASKING have joint­ly devel­oped pro­fil­ing solu­tions beyond stan­dard ORTI, intro­duc­ing ven­dor-spe­cif­ic exten­sions allow­ing a bet­ter insight into OS task sched­ul­ing. Anoth­er result of such demand­ing cus­tomer projects is the abil­i­ty to pro­file mul­ti­ple RTA-OS instances run­ning with­in Vir­tu­al Machines cre­at­ed by the ETAS Hyper­vi­sor RTA-HVR.

Evidence

Eri­ka Enter­prise is a roy­al­ty free auto­mo­tive OSEK/VDX cer­ti­fied Hard Real Time Oper­at­ing Sys­tem (RTOS) main­tained by Evi­dence in Italy. Evi­dence is an AUTOSAR develop­ment mem­ber and a long term part­ner of TASKING. The inter­face between Eri­ka Enter­prise and winIDEA sup­ports stan­dard run­ning Task and ISR pro­fil­ing of Eri­ka Enter­prise via ORTI, as well as more advanced use-cas­es such as task state pro­fil­ing.

Software Modeling / Simulation Tool Cooperations

INCHRON

The inte­gra­tion of TASKING and INCHRON tools is, on one hand, dri­ven by many cus­tomer projects, on the oth­er hand, both com­pa­nies have joint­ly cre­at­ed ref­er­ence plat­forms to extend and demon­strate the high-lev­el of inte­gra­tion. One good exam­ple for this coop­er­a­tion is the mul­ti-ECU plat­form, demon­strat­ing event-chain analy­sis across mul­ti­ple ECUs.

Luxoft/SymtaVision

Dri­ven by demand­ing cus­tomer projects, both com­pa­nies have worked togeth­er to ensure a SymTA/S sys­tem mod­el can be cor­re­lat­ed against real hard­ware tim­ing infor­ma­tion cap­tured by TASKING trace tools. TASKING trace export files can be seam­less­ly import­ed into the Sym­taVi­sion Trace Ana­lyz­er.

Avelabs

Through a close coop­er­a­tion, the export/import inter­faces of the TASKING and Ave­labs tools have been adjust­ed to allow a seam­less import of hard­ware trace data, cap­tured by TASKING trace tools, into the Ave­labs Gaspra Tool.

Vector Informatik

For devel­op­ers seek­ing to ver­i­fy tar­get sys­tems behav­iour, Vec­tor tools allow the exam­i­na­tion of tim­ing and resource con­sump­tion against tim­ing require­ments. The Vec­tor TA Inspec­tor tool con­nects to TASKING to import hard­ware trace data.

More resources

TypeLink Descrip­tion
 Intro­duc­tion to AUTOSAR Clas­sic Pro­fil­ingOverview of the AUTOSAR Clas­sic Pro­fil­ing
 AUTOSAR Clas­sic Tim­ing Analy­sis — Hard­ware Trace Based Real-Time Analy­sisAn overview of dif­fer­ent tim­ing-analy­sis tech­niques, hard­ware trace-based AUTOSAR OS and RTE pro­fil­ing, and how to uti­lize these approach­es for dif­fer­ent use-cas­es.
 ETAS RTA-OS Pro­fil­ingA detailed look into the OS and RTE pro­fil­ing, start­ing with the “Hel­lo, world!” of tim­ing-analy­sis – Run­ning Task/ISR trace, and more com­plex use-cas­es such as task state and Runnable pro­fil­ing.
 Non-Intru­sive AUTOSAR OS and RTE Pro­fil­ing of Vec­tor MICROSAR Appli­ca­tionsRecord the OS and RTE behav­ior with­out instru­men­ta­tion; recon­struct task states by record­ing dif­fer­ent OS vari­ables with Pro­fil­er Inspec­tors; con­fig­ure the steps via iTCHi — TASKING Trace Con­fig­u­ra­tion Helper.
 AUTOSAR OS and RTE Pro­fil­ing of Vec­tor MICROSAR Appli­ca­tions with Instru­men­ta­tionRecord Runnable events with instru­men­ta­tion via the VBF trace hooks; record task states and ISRs via the Vec­tor OS tim­ing hooks; con­fig­ure the steps via iTCHi — TASKING Trace Con­fig­u­ra­tion Helper.
Scroll to Top