.:: ALL-TIMES / Timing analysis ::.
A large class of embedded systems has safety, availability, reliability,
and performance requirements. Very often, these requirements relate to
timing. Timing analysis is therefore needed in many steps
of the development process; it is a key to rapid designing and prototyping
of embedded systems, to reduce system overall cost through efficient resource
management (especially: tradeoffs when co-developing hardware and software),
to find bottlenecks in the software, and to validate that the system meets
its timing requirements.
The most important timing measures for real-time systems are:
- The worst-case execution time (WCET) on the code level.
- The worst-case response time (WCRT) on the system level.
A variety of techniques have been developed to perform timing analysis.
The most important code-level timing analysis techniques include:
- Measurement: a wide variety of measurement tools can be employed, including
emulators, logic analyzers, oscilloscopes, and software profiling tools. Given that the
correct inputs and system state can be identified for the worst case, measurements can
derive an exact WCET, BCET and AET. However, triggering the inputs to generate a
certain situation (best case, worst case) can be difficult. The strengths of measurement
are thus more in obtaining typical or average execution times for interesting input
patterns, and obtaining statistical distribution of execution times.
- Static analysis, which analyses the program without actually running it.
It relies on mathematical models of the software and hardware involved. The analysis considers
the effects of all possible inputs, including possible system states, together with the
program's interaction with the hardware. Given that the models are correct, the
analysis can derive a WCET estimate that is safe. The analysis can be refined by the
user to exclude combinations of inputs and system states which cannot occur in
- Measurement-based (or hybrid) analysis, which combines static analysis and
measurements, gives the advantage of avoiding building hardware models, but instead
measuring execution times for small parts of the code on the hardware itself. A highlevel
static analysis stage then combines these parts to compute the final timing estimate.
The most important system-level analysis techniques include:
- Measurement: essentially the same approach as on the code-level. However, the focus
is not on a single piece of code but instead on scheduling multiple tasks, in a sense
providing an oscilloscope for the operating system.
- Scheduling analysis: typically, WCRTs of tasks and functions are
statically calculated based on the WCETs of the different tasks of the system, the
scheduling strategy and the activation frequency of each task. WCRTs can then be
compared with deadlines to determine if they can be met under all relevant conditions.
Scheduling analysis works equally well with code execution times obtained by any of
the code-level techniques, as well as with estimated code execution times. This allows
early-stage exploration and budgeting.