Measuring response times and more with RapiTime

Daniel Wright & Greg Manning

2023-03-10

Analysis of the timing behavior of avionics software helps avoid errors such as timing overruns and is needed to support DO-178C certification.

While many timing requirements relate to the worst-case execution time of software, some may relate to other metrics such as response time, periodicity of execution, or separation between different instances of a sequence running.

Execution time vs. response time

The execution time of a piece of software is the time taken for a task to finish, ignoring time spent executing other functions or interrupts.

The response time of a piece of software is the total time taken for a task to finish, including time spent executing code in other functions or interrupts.

As of RVS 3.18, RapiTime includes a sequence analysis feature that provides a flexible framework for making these kinds of timing observations. This lets you define sequences of checkpoints within your code across which you want to take measurements. For each sequence, you can define the measurements you want taken, which can be the elapsed time between any two checkpoints within the sequence. After measurements have been defined, RapiTime can instrument your code appropriately, collect the necessary results during software execution, and display these results in your RapiTime report.

Sequence analysis conceptual diagram — Interesting timing metrics across and between sequences include response time, periodicity and separation

Checkpoints and measurements for RapiTime sequences — Checkpoints and measurements for a sequence configured in RapiTime

Results from RapiTime sequence analysis — Results from measuring execution of sequences in RapiTime

This flexible framework also supports multicore timing analysis such as that carried out in our MACH¹⁷⁸ solution to meet A(M)C 20-193 objectives for multicore DO-178C projects. Sequence analysis makes it possible to measure end-to-end timing metrics for sequences of events when multiple tasks run simultaneously, even when sequences involve checkpoints executing on different cores (as shown below).

References support distinguishing between different instances of sequences — Example multicore sequence involving multiple instances of a sequence executing on multiple cores, for which timing results can be collected by RapiTime

To support analysis in situations where multiple instances of a task may be running simultaneously, we needed to have a way to uniquely attribute checkpoints as belonging to a specific instance of a sequence. We did this by annotating each checkpoint with a sequence reference. When you define a checkpoint, you can supply a snippet of code that returns an integer shared by all checkpoints in the sequence, and is unique to each instantiation of the sequence. When each checkpoint is hit, this code is evaluated and the resulting integer is recorded in the checkpoint. This allows RVS to demultiplex sequences that execute simultaneously, so long as there is a distinguishing integer available.

We're looking forward to see how RVS’s new sequence analysis feature can help you verify your critical software. We’ll be building on the feature to support more complex, non-linear sequences and sequences where no single distinguishing integer reference is available in future RVS versions, stay tuned!

To learn more about sequence analysis, visit our feature page or contact us. For more information on multicore certification, visit our MACH¹⁷⁸ page.