(In real-world automotive computing environments, resources can be scarce and timing becomes tricky. Vector Informatik's TimingAnalyzer tool helps engineers to manage timing and resource conflicts.)
Software design is easy when the processor can provide far more computing time than the application needs. In practice, however, just the opposite is often the case. Good real-time embedded programming requires a lot of time and effort by the software engineer - to steer clear of the cliffs of insufficient computing time. Now an embedded operating system offers welcome assistance; not only does it determine runtimes of tasks and interrupts directly, the TimingAnalyzer analysis tool also reveals runtime conflicts.
Modern embedded software is often complex and consists of multiple processes (tasks) running time-independently and interrupt service routines (ISRs). The use of a pre-emptive operating system like MICROSAR OS from Vector Informatik makes a significant contribution toward realizing a clear structure, shortened development times and better maintainability. The interactions of all implemented tasks must also be considered to obtain a stable system. Primary areas of focus are to achieve data consistency when accessing commonly used data areas and to optimize the runtime behavior of individual tasks.
Mechanisms provided by the operating system help to ensure data consistency. However, the developer is responsible for correct runtime behavior. The developer must ensure that all processes can be completed within their time limits.
Consider a case in which a user should be able to notice an effect within 10 ms after actuating a control; this is a typical example of a time limit for execution of a task. However, developers are usually confronted by periodic processes in which it is essential to complete every operation before the beginning of the next cycle. Another aspect relevant to software design is that a running task may be interrupted at any time by an interrupt or a higher priority task.
Figure 1: Simultaneous occurrence of both interrupts leads to unacceptable delay of Task A. For a full-size image, click here.
Figure 1 illustrates what is required based on an application consisting of Task A and interrupts ISR 1 and ISR 2. The task is called periodically every 10 ms and requires an execution time of 5 ms; this results in 50% processor load. The execution time of the two interrupts is 3 ms each. Although interrupting the task with just one interrupt is non-critical (cycle 2), when both interrupts occur in the same cycle this leads to a computing time of 11 ms, which is unacceptable since it would extend beyond the time of the next starting point (cycle 5). Such time conflicts may lead to sporadically occurring and difficult to identify errors; such as data losses, timeouts, perceptible delays, etc. Therefore, a thorough analysis is essential before delivery of the software.
Measuring execution time in the OS
Each analysis is based on precise knowledge of task and interrupt execution times, which can be determined by various methods. A simple solution is to insert special test routines for toggling IO ports at the beginning and end of the tasks. The IO ports are then observed, e.g. via an external oscilloscope or logic analyzer. Another option is to trigger special measurement routines that generate time stamps via their own timers and pass their data to a PC via a (serial) data interface.
The disadvantages of these methods are evident:
Figure 2: Methods of runtime measurement: The areas shown in red are software modifications to be made by the user.
- At many points, the code needs to be modified manually; this involves substantial effort and there is high risk of errors.
- The measured time interval, besides covering the execution time of the routine being analyzed, also includes the execution times of all interrupting tasks and ISRs.
Effective immediately, MICROSAR OS now offers a function for measuring the execution and blocking times of selected tasks and interrupts directly in the operating system, where interruptions are considered in calculating execution time. This simplifies the test engineer's work significantly, because now it is no longer necessary to modify the application code. All that is needed is a test routine for reading out the measured data. In principle, any supported serial or parallel interface of the processor or ECU hardware or a memory map in the emulator can be used for this. The user can then conveniently switch the measurement function on or off in the operating system configuration. Figure 2 describes these simplifications.