Skip to main content
RVS 3.19 Launched
Rapita is proud to be an ISOLDE Partner
Rapita and SYSGO underline partnership
RVS 3.18 Launched
Introduction to Data Coupling and Control Coupling for DO-178C
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?
Data Coupling & Control Coupling
Verifying additional code for DO-178C
DO-178C Guidance: Introduction to RTCA DO-178 certification
MATLAB® Simulink® MCDC coverage and WCET analysis
Upcoming Webinar: Deep Dive on Multicore Interference
The Solar Orbiter is a joint project by the European Space Agency® (ESA) and the National Aeronautics and Space Administration® (NASA) to study the behaviour of the Sun. Due to be launched in 2017, the Solar Orbiter’s payload of telemetry equipment includes the Energetic Particle Detector (EPD) suite of five telescopes, designed to measure the energy created by solar particles.
The University of Alcala, the developers of the onboard software for the Instrument Control Unit (ICU) of the EPD, selected Rapita Verification Suite (RVS) to support schedulability analysis for the ICU software.
Summary
The challenge
- To create a measurement-based analysis of Solar Orbiter on-board software for schedulability.
The solution
- To collect worst-case execution time data for individual tasks using RVS integrated with other tools.
The benefits
- Developers were able to analyze different design alternatives with different elements with worst-case execution time (WCET) data.
- The effectiveness of the test suites were improved by measuring code coverage at the same time.
The challenge
Schedulability analysis aims to provide guarantees of deadline satisfaction. To automate the schedulability analysis of the on-board software, the project required an integration between RVS and the MAST (Modeling and Analysis Suite for real Time applications) analysis tool.
The University of Alcala’s integration was based on a new framework (MICOBS) for developing modeldriven component-based embedded software systems under a multi-platform approach and integrating different development and analysis technologies.
The project chose RVS to perform the on-target worst-case execution analysis. Apart from analysing the worst-case execution time (WCET), RVS could also measure code coverage in compliance with ESA’s ECSS-E-40C standard, in addition to ISO 26262 and DO-178B guidelines.
The solution
The preferred solution was to carry out tests of each of the components and service libraries that are part of the system using RVS. This means that schedulability analysis could be performed without the need to take timing measures on the complete system.
The overall schedulability analysis solution is based on the execution time measurements of:
- The component reactions to the reception of a message or the notification of an event
- The code of the service libraries
The WCET measurements are obtained by analysing each component and service library separately, using on-target measurement and subsequent WCET analysis based on the measurements. In order to perform the final system-level schedulability analysis, a transformation has to be used to obtain, from the MICOBS models, the appropriate MAST model.
The RVS toolset is used to perform the WCET analysis. Apart from analysing the WCET, the RapiCover component of the toolset is also capable of measuring code coverage in a variety of levels up to and including MC/DC.
In order to analyse the WCET using RVS, an appropriate set of test benches has to be defined. These test benches could comprise the unit tests used for software validation and code coverage analysis or they could be developed ad-hoc, a solution that, in principle, might provide a less pessimistic measurement of the WCET.
MICOBS allows the integration of the data obtained from RVS together with the specification of the configuration parameters than were used for each component or service library, as well as the platform on which they were run.
This information is used by MICOBS to create an instance of a particular analysis-oriented model (AOM) instance that will be later used during the transformation that will produce the MAST model of the complete system.
In this final stage, MICOBS forces the definition of the vector of parameter values used to configure each element and the platform on which the system is to be deployed.
The benefits
Using this integration, the developers could rapidly analyze different design alternatives with different elements once they had worst-case execution time (WCET) data.
Other case studies
