RVS 3.19 Launched
Rapita is proud to be an ISOLDE Partner
Rapita and SYSGO underline partnership
RVS 3.18 Launched
Measuring response times and more with RapiTime
Why mitigating interference alone isn’t enough to verify timing performance for multicore DO-178C projects
There are how many sources of interference in a multicore system?
Supporting modern development methodologies for verification of safety-critical software
DO-178C Guidance: Introduction to RTCA DO-178 certification
MATLAB® Simulink® MCDC coverage and WCET analysis
Code coverage for Ada, C and C++
AMC 20-193
DASC 2023
DO-178C Multicore In-person Training (Huntsville)
HISC 2023
NXP's MCFA 2023
When an industry-leading avionics supplier set out to develop the Flight Control System for a new class of aircraft, its key objectives were to improve product quality while simultaneously driving down development costs.
In critical applications such as flight control systems, the timing behavior of the system is as important as functional behavior. Therefore, establishing the system’s execution timing cannot be an afterthought.
Early detection and resolution of potential timing problems brings benefits both in terms of reduced development costs, but also in improved quality.
Summary
The challenge
- To improve early detection and resolution of timing problems on a flight control system while reducing development effort
The solution
- RapiTime on-target profiling automates execution time measurement and highlights potential problem areas
The benefits
- Identifying the causes of timing problems with less than 10% of the effort of previous approaches
- Showing specific fixes are free of side-effects
- Providing convincing evidence that timing requirements have been met.
The challenge
The supplier’s approach to ensuring execution timing relied upon effort-intensive manual processes:
- Large quantities of tests were required to obtain time measurements
- Painstaking effort was then required to map the measurements back onto the underlying architecture
- The high cost of collecting this information made it undesirable to repeat measurements throughout the process.
The solution
The avionics supplier considered several alternative approaches for automating the process of measuring software execution timing before selecting RapiTime from Rapita.
RapiTime (part of the Rapita Verification Suite, RVS) is a tool suite that analyzes the timing behavior of embedded software by combining a static model of the code structure with dynamic results in the form of detailed measurements of on-target timing behavior.
In addition to recording the distribution of execution times (including minimum, maximum and average) and code coverage, RapiTime adds the ability to predictively model untested paths (which it creates by composing previously tested path components).
“It was the combination of static and dynamic analysis that attracted us. We were concerned that an approach that relied only on static analysis was dependent upon getting the model of the hardware exactly right. RapiTime’s ability to measure code executed on the target hardware removes that risk from the outset.”
Wayne King
Engineering Fellow
RapiTime distils huge amounts of information into digestible, human-readable tables and charts. This enables better optimization, debugging and more detailed confirmation of execution timing than ever before.
RapiTime places particular emphasis on analysis of the worst-case execution time (WCET), the key factor in determining responsiveness of real-time systems.
The benefits
“The biggest benefit that RapiTime brought to our development process was just how quickly we could get comprehensive timing measurements from our tests.
Not only did we reduce our effort requirements for the testing, but we could use our results in ways that were infeasible before. It is now significantly faster for us to identify a timing issue, update the software to resolve the issue, test the updated software and verify that it’s fixed.
RapiTime has also helped us to identify some very specific performance bottlenecks with the underlying hardware that were causing very real difficulty to identify.”
Wayne King
Engineering Fellow
Other case studies
