Real-time software in AUTOSAR series development – approaches and processes for ECU configuration

February 23, 2012 // By Christoph Ficek, Dr. Kai Richter, Symtavision
Meanwhile AUTOSAR has been introduced as an automotive standard for Electronic Control Unit (ECU) software development and is now used in series projects either in version 3.2 or 4.0 (including Timing Extensions), depending on the OEM. From the software development perspective, AUTOSAR is already increasing productivity tremendously through standardization.

However, from the system development perspective, key questions remain:

  • Feasibility: How much software can be handled by the ECU? Will all real-time requirements /timing constraints be fulfilled?
  • Safety/Availability/Expendability: How to avoid late and costly design modifications?
  • Documentation of real-time capability and requirements (including requirements specifications)

The goal is to have a system integration available at the end of the development which fulfils the above mentioned requirements, which uses the ECU resources in the best way, and which can accommodate extensions. The steps to this system integration include the mapping of functional architectures to software architectures, the creation of the Run-Time Environment (RTE) and OS configuration (schedule), and the integration of basic software (BSW) elements.

When it comes to securing real-time capability, the creation and verification of the ECU configuration (including runnables mapping, task layout, and schedule configuration) is particularly important. Timing analyses help to evaluate and document configurations, and to specify timing requirements for suppliers as necessary. Furthermore, they provide the basis for pending design decisions.  

Suitable timing analysis approaches already exist and are widely in use. The most important aspects here are the CPU load (the load broken down into software components, tasks, and runnables) and the relationship between data paths/timing chains and the software architecture. Timing requirements for timing chains and the scheduling of all the functions to be integrated are equally important.

Load, cycle times, and execution times

The overall load of a CPU is the sum of the load of all executed functions and components. The load of a single function is the quotient of the function's execution time and cycle time.

A function's cycle time is known from function modeling, for example in Matlab/Simulink or ASCET. It is described as cycle or sample time. In case of non-periodic processes, the activation frequencies can be derived by simulating the  functional model.

To determine the execution time of a function, several approaches are available, depending

Design category: