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
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 on the development phase. Execution time estimations from previous projects may be used at the beginning of the development. Budgeting is another commonly used approach. Once first implementations are available in the course of the project, they can be measured using processor simulators (for example by VAST), prototype hardware or later on the real target hardware (using for example Gliwa´s T1). Static execution time analysis (for example by AbsInt
) provides absolutely reliable upper execution time bounds. To read the complete article, which includes task generation and scheduling analysis, and data path/timing chain analysis, click here, courtesy of EE Times Europe Automotive.
If you liked this article, go to the Automotive Designline home page
for the latest in automotive electronics design, technology, trends, products, and news. Also, receive a weekly highlights update delivered directly to your inbox by signing up for our weekly automotive electronics newsletter here