Measuring software timing under DO-178B – does multicore make a difference?

Execution time analysis in a single-core environment

If you’re doing execution time analysis for DO-178B on a control system project, the approach you’re likely taking is:

• Provide some way of measuring timing end-to-end, to gather “high water-mark” timing values from your application; then
• Perform appropriate testing to exercise worst-case behaviour.

In other words, you are claiming that you are reasonably certain that you’ve exposed a representative worst-case path with respect to execution time.

Moving to a multicore environment

When you move to multicore, you need to re-examine and adjust both of these aspects. Firstly, making reliable measurements in a multicore environment is challenging for a variety of reasons:

• If there is code that migrates between cores, asymmetric communication facilities may have an impact on the timing. You should consider separately analysing its behaviour on each core.
• If utility code is called from applications on different cores, or if the same application is replicated across multiple cores, the same code may have differing execution times. It’s important to consider separate analysis and some comparison of the results.

If a shared resource is used for storing or communicating the timing measurements across the cores, this is another possible source of interference to the measurements. Secondly, providing a test case to stimulate possible worst-case behaviour is arguably an even harder task. The worst-case in a multicore environment arises from the path executed and local core effects (as it does on a single core system) as well as the interference effects from the other cores.

These interference effects can only be seen by executing different interleavings of the applications on the different cores. It is impractical, if not impossible, to force all of the possible such interleavings to occur during test. At the level of worst-case times for individual components within the system, the key issue is to examine contention for shared resources. Pathological contention can be created artificially in some cases, and with appropriate synchronisation, this can be both forced in tests and dissuaded in actual operation.

However, at the level of system scheduling, care must be taken that the scheduling policy is compatible with potentially-shortened execution times; it may be worth pushing the implementation towards straight-line and forced pathological behaviours so that the scheduling can remain stable.

Using RapiTime to measure the timing of multicore systems

If you’re considering using RapiTime for measuring the timing of multicore systems, it can support you by providing in-depth analysis of where the worst-case time comes from and the observed distributions of execution times, helping the analyst to determine consistency of execution during the tests.

For certification and DO-178B, this consistency is vital for establishing traceable evidence. Our future product plans include some exciting developments specific to multicore analysis. The options range from sensitivity analysis through report comparison to multicore-specific visualisation and workflows. To get more information on multicore and execution time analysis, please do get in touch.