Achieving robust timing requirements with earlier WCET analysis

In the development of a real-time control system, the timing requirements themselves are typically much harder to develop than the corresponding functional requirements. The amount of time taken depends on a huge number of hardware and software architecture factors. As a WCET analysis tool, RapiTime can help to show that execution time aspects of low-level requirements are consistent (DO-178B/C 6.3.2b) and that software partitioning integrity is achieved (DO-178B/C 6.3.3f). The key is to introduce execution time measurement as early as possible in the development lifecycle. For low-level requirements, we recommend a process of setting a budget (based on the overall scheduling requirements, past experience and perhaps some rough calculations) and evaluating early builds of the software against this budget. For this type of analysis, simple end-to-end measurements will be sufficient. RapiTime can produce an execution time profile showing the distribution of execution times for each of the tasks in the system. This reveals issues such as budget much too high, budget much too low, unexpected execution time variation or execution times that are clustered close to the defined budget. From this information, you can adjust budgets and identify specific execution time risks to monitor as the software implementation develops. Testers can also get involved at this stage, providing worst-expected data loads and interfering concurrent behaviour to show that the execution time requirements work together at the level of the software design.

For partitioning integrity, the issue is to demonstrate that the software for each partition cannot escape the confines of that partition. In the time domain, this is a combination of several aspects:

• showing that software within the partition is schedulable, by feeding the WCET values from RapiTime into the schedulability analysis appropriate to the scheduling;
• showing that partition switches occur when expected, which can be obtained from the RapiTime trace for each partition;
• showing that the only software executing in the time-slot for an allocation is software that was intended for that partition. With a combination of trace analysis and instrumentation partitioning, additional confidence may be obtained that the partitions are achieving temporal isolation.

Automated, early checks provides a valuable, independent check of the health of the system being developed. Earlier use of RapiTime gives the added benefit of allowing more lead-time to customise tool operation and instrumentation to achieve minimal pessimism in the reported figures. Visit RapiTime for more information.