Real-time software in AUTOSAR series development – approaches and processes for ECU configuration
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 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.
Figure 1: Software architecture with timing information and data paths/timing chains
Figure 2: Load analysis
Figure 1 shows an example with three software components (SWCs) with respectively several runnables and the respective execution times (et) and cycle times (ts: time sample). Figure 2 shows the result of a load analysis for the complete system (71%) as well as for the single contributing parts.
Through a more and more detailed description of the system, the execution time of single functions and components becomes more precise during the course of the project. The load model is refined during the course of the project as well. Hence critical load situations can be identified at an early stage and specific countermeasures, for example through reducing execution times and/or increasing cycle times can be implemented.
The estimate of the expected load is a first indication for the feasibility of a system, but it is not sufficient. Integration and scheduling effects like jitter, data path/timing chain latencies, temporary load peaks etc. are not being considered in a mere load analysis and have to be analyzed separately.
Task generation and scheduling analysis
Based on the set of functions (runnables in AUTOSAR terminology), we are able to build a first virtual task schedule. Hereby we follow a scheduling concept suitable for the project, for example:
- Runnables with the same cycle time are grouped in one task
- The shorter the cycle time, the higher the task priority
- The task deadline matches the cycle time (no multiple activations)
In AUTOSAR, this information is maintained in the RTE and OS configuration. Virtual task generation is therefore easily automated and can be extended with project specific rules.
The virtual task schedule allows to perform a scheduling analysis in order to determine the tasks´ response times (the time span between a task’s activation and its completion). Preemptions by tasks with higher priority are considered, which is an essential integration effect. Typically, each task has to be executed completely before its next activation (implicit deadline). If this is not the case, task activations may get lost during runtime, and functional correctness may be violated. In early development phases, the response times should be about 30 – 50% below deadline to keep sufficient space for extensions.
If a deadline is missed, respective measures have to be taken, for example increasing the cycle time of a runnable if this is possible. Code optimization may allow reducing runnable execution times which not only reduces their own response time but also the response times of interrupted tasks. Additionally, selecting a faster CPU will speed up the complete system. An automation of this scheduling analysis enables fast exploration of different optimization options. The scheduling analysis tool SymTA/S offers this automation and reduces the risk of late and costly design modifications.
When the individual runnable response times are within the permitted limits, the next step is the analysis of the data paths´/timing chains´ latencies.
Figure 3: SymTA/S Timing model with load, schedule, and data path/timing chain analysis
Data path/timing chain analysis
Data paths/timing chains describe the communication between runnables and are comparable to signal paths/signal flows in Simulink or ASCET. The communication between runnables is realized via memory-based communication (data produced by a runnable is read by the next runnable in the chain). The example from figure 1 shows the three data paths/timing chains WK1, WK2, and WK3 which all start at a sensor S and end at an actuator A. In practice, such data paths/timing chains are subject to timing constraints like maximum reaction times or controller dead times. These data paths/timing chains can be easily specified in SymTA/S.
A data path’s/timing chain’s latency depends on the response times of the individual runnables, buffering periods between runnable executions, up and down sampling effects while changing cycle times etc. As the runnables´ response times are influenced by preemptions by tasks with higher priority, the data path/timing chain latencies are likewise influenced by scheduling effects. The Gantt chart in the right lower corner of Figure 3 shows this for data path/timing chain WK3.
Timing analysis with SymTA/S allows to determine a data path’s/timing chain’s latency considering all influencing factors. A comparison with the deadline shows if the latency is good enough or close to the limiting value or even above it. If the latter is the case, appropriate measures have to be taken to reduce the latency.
Besides the already mentioned opportunities (cycle times, execution times, priorities), there are further mechanisms available to reduce the data path/timing chain latency. The parameter “PositionInTask“ determines the order in which the runnables are executed within a task. This parameter can become particularly important for data paths/timing chains in case two or more data path/timing chain runnables are placed within the same task. If for example a runnable, which is the last one to be executed within the task, writes data, which then is read by the first runnable within the task, a complete task cycle is “wasted“. A better solution is to put the runnables in reverse order within the task. Such effects are displayed immediately through the data path/timing chain analysis. Afterwards, the schedule can be optimized manually or automatically.
The same procedure applies to task offsets. Offsets allow to delay task activation times. That way, load peaks as well as data path/timing chain latencies can be reduced further. For multi-core systems, individual cores can also be scheduled synchronously (using a common clock) or independently. Both approaches are supported by AUTOSAR as well as SymTA/S.
Consideration of the basic software
To this point, we have been focusing on timing analysis on the application level. In the next step, we are going to complement the existing timing model with basic software (BSW) elements as these do use CPU time as well, and thus may influence the present schedule. This is one purpose of the previously mentioned load reserve. The BSW focus is on independent tasks (for example TX-COM) or long-running interrupts (for example RX-CAN or crankshaft interrupts), as they have the biggest influence. Context-switch overheads need to be considered, too.
Having considered all these elements, the scheduling analysis provides us with more precise information on load, task schedule, and data path/timing chain latencies. After performing modifications as needed, the configuration (SW architecture, configuration of RTE and OS, BSW) is complete and can be adopted for software development and implementation with a minimized project risk.
Figure 4: Methodology process
Methodology and process integration
Figure 4 shows a summary of the methodology. It can be used for new as well as existing systems. Applying the methodology provides a timing model at each step during the development of an ECU. For each integration step or product update, the timing impact of SW modifications can always be verified „virtually“ first, and optimized, if necessary. The presented methodology is fully compliant with the AUTOSAR standard. The tool SymTA/S automatically supports all mentioned phases.
As a result we obtain an optimized ECU configuration as well as a well-founded, quantifiable evaluation of the project´s feasibility. This evaluation is well-suited for communication and reasoning, especially with the project management, software suppliers, and OEM customers (e.g. through a requirements specification).The established timing models are ideal development artifacts for the exchange between different development groups and along the supply chain. The presented methodology minimizes integration risks for ECU projects from the very beginning and constantly keeps real-time capabilities in focus.
About the authors: Christoph Ficek is Applications Engineer at Symtavision. Dr. Kai Richter is CTO at Symtavision.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
