Skip to main content
RapiTest - Functional testing for critical software
RapiCover - Low-overhead coverage analysis for critical software
RapiTime - In-depth execution time analysis for critical software
RapiTask - RTOS scheduling visualization
RVS Qualification Kits - Tool qualification for DO-178 B/C and ISO 26262 projects
RapiCouplingPreview - DCCC analysis
MACH178 - Multicore Avionics Certification for High-integrity DO-178C projects
MACH178 Foundations - Lay the groundwork for A(M)C 20-193 compliance
Multicore Timing Solution - Solving the challenges of multicore timing analysis
RapiDaemon - Analyze interference in multicore systems
RTBx - The ultimate data logging solution
Sim68020 - Simulation for the Motorola 68020 microprocessor
V&V Services
Data Coupling & Control Coupling
Training
Consultancy
Tool Integration
Support
Rapita System Announces New Distribution Partnership with COONTEC
Rapita partners with Asterios Technologies to deliver solutions in multicore certification
SAIF Autonomy to use RVS to verify their groundbreaking AI platform
RVS 3.22 Launched
What does AMACC Rev B mean for multicore certification?
How emulation can reduce avionics verification costs: Sim68020
Multicore timing analysis: to instrument or not to instrument
How to certify multicore processors - what is everyone asking?
Certifying Unmanned Aircraft Systems
DO-278A Guidance: Introduction to RTCA DO-278 approval
ISO 26262
Data Coupling & Control Coupling
IEEE SMC-IT/SCC 2025
DASC 2025
DO-178C Multicore In-person Training (Fort Worth, TX)
DO-178C Multicore In-person Training (Toulouse)
Since 1969 Embraer® has built more than 5,000 aircraft that operate in 92 countries on five continents.
Working on the R&D stage of a DO-178B Level A Flight Control System (FCS) software application, Embraer wanted to obtain worst-case execution times (WCET) and worst-case stack usage data.
Their solution was to choose Rapita Verification Suite (RVS) from Rapita Systems.
An important part of the development of this system’s software was meeting the verification objectives required by DO-178B while at the same time decreasing development costs.
Summary
The challenge
- To capture WCET times and data while meeting DO-178B standards and reducing costs
The solution
- Use RVS tools to instrument the FCS source code and analyze the results from on-target testing
The benefits
- Obtaining a WCET and stack usage value without the need to generate and demonstrate a test scenario saves resources and time by automatically determining test scenarios for WCET and largest stack usage
The challenge
The Embraer FCS employs Fly-By-Wire (FBW) technology. Data processing and the logic of the FCS are implemented by software, which due to the criticality of the FCS function, is classified as Level A software. Initial requirements for the FCS application required a WCET of less than 5 milliseconds, and a maximum stack usage of 20,000 bytes.
Embraer faced three major challenges during FCS development:
- Effectively capture worst case execution times and worst case stack usage data
- Meet DO-178B requirements
- Reduce development costs
The solution
Instrumenting source code
Using RVS, instrumentation is added to the source code, which is then built using a compiler configured in the same way as during development activities.
The process for stack analysis is similar to that for timing analysis, except that points of instrumentation are only used for function entry and exits, and timestamps are replaced with the value of the stack pointer.
Analyzing the source code
RVS analyzes the source code and determines an overall structure of the code and the paths through it.
It was not necessary to design a test case for the paths leading to WCET or biggest stack usage because RapiTime calculates them and reports whether that path corresponds to the longest path observed during testing.
This leads to a significant reduction of resource effort since generating a worst-case time scenario is a time consuming activity.
On-target testing
Since the purpose of this testing activity was only to exercise the paths of the application, the outputs were not evaluated and could be ignored. This method achieved coverage of approximately 77% of the instrumentation points for timing analysis, and 100% of the instrumentation points for stack analysis.
The benefits
Because it was not necessary to manually design a test case for the worst-case path, a significant resource effort was avoided, saving time and money.
After running and processing data, the WCET value for the whole integrated application was computed as 2.279ms and the worst-case stack usage was 3416 bytes.
Even with the partial timing coverage, the results confirmed that the FCS was compliant with the required limit on the execution time of 5ms, and that the stack usage was below the limit of 20,000 bytes.
“We have successfully shown the viability of using RapiTime to measure WCET.
It was able to support our hardware platform and once the system was set up, the analysis method could be repeated with relative ease.
With the WCET results, time partitioning was easily configured in the platform for the FCS application.
Processing resources could be optimized by tightening the time window, even leaving some room for future expansion.
Additionally the application hard deadline could be configured based on the results, with a Health Monitor to trigger if exceeded.”
Felipe Kamei
Embraer
