RapiTest, when used with RapiTime, lets you configure and review the results of tests to support multicore timing analysis. Using a dedicated test editor, RapiTest lets you write tests that configure the application of RapiDaemons to generate interference and the definition of success criteria for test outcomes. After your tests have run, RapiTest presents the pass/fail status of your tests against their success criteria. 

RVS make it easy to get started with a range of resources:

• Interactive tutorials guide you through using each RVS tool.
• Example projects, reports and tests let you explore using RVS with example code, while sandbox projects let you plug in Ada, C and C++ snippets and get started with on-host verification quickly.
• If you’re looking for more detail about specific topics, the RVS documentation is at hand.  

And no matter what your question, RVS’s help search can link you to the most helpful resources at the click of a button. 

RVS make it easy to get started with a range of resources:

• Interactive tutorials guide you through using each RVS tool.
• Example projects, reports and tests let you explore using RVS with example code, while sandbox projects let you plug in Ada, C and C++ snippets and get started with on-host verification quickly.
• If you’re looking for more detail about specific topics, the RVS documentation is at hand.  

And no matter what your question, RVS’s help search can link you to the most helpful resources at the click of a button. 

RVS make it easy to get started with a range of resources:

• Interactive tutorials guide you through using each RVS tool.
• Example projects, reports and tests let you explore using RVS with example code, while sandbox projects let you plug in Ada, C and C++ snippets and get started with on-host verification quickly.
• If you’re looking for more detail about specific topics, the RVS documentation is at hand.  

And no matter what your question, RVS’s help search can link you to the most helpful resources at the click of a button. 

RVS make it easy to get started with a range of resources:

• Interactive tutorials guide you through using each RVS tool.
• Example projects, reports and tests let you explore using RVS with example code, while sandbox projects let you plug in Ada, C and C++ snippets and get started with on-host verification quickly.
• If you’re looking for more detail about specific topics, the RVS documentation is at hand.  

And no matter what your question, RVS’s help search can link you to the most helpful resources at the click of a button. 

RVS make it easy to get started with a range of resources:

• Interactive tutorials guide you through using each RVS tool.
• Example projects, reports and tests let you explore using RVS with example code, while sandbox projects let you plug in Ada, C and C++ snippets and get started with on-host verification quickly.
• If you’re looking for more detail about specific topics, the RVS documentation is at hand.  

And no matter what your question, RVS’s help search can link you to the most helpful resources at the click of a button. 

RVS make it easy to get started with a range of resources:

• Interactive tutorials guide you through using each RVS tool.
• Example projects, reports and tests let you explore using RVS with example code, while sandbox projects let you plug in Ada, C and C++ snippets and get started with on-host verification quickly.
• If you’re looking for more detail about specific topics, the RVS documentation is at hand.  

And no matter what your question, RVS’s help search can link you to the most helpful resources at the click of a button. 

RVS make it easy to get started with a range of resources:

• Interactive tutorials guide you through using each RVS tool.
• Example projects, reports and tests let you explore using RVS with example code, while sandbox projects let you plug in Ada, C and C++ snippets and get started with on-host verification quickly.
• If you’re looking for more detail about specific topics, the RVS documentation is at hand.  

And no matter what your question, RVS’s help search can link you to the most helpful resources at the click of a button. 

RVS make it easy to get started with a range of resources:

• Interactive tutorials guide you through using each RVS tool.
• Example projects, reports and tests let you explore using RVS with example code, while sandbox projects let you plug in Ada, C and C++ snippets and get started with on-host verification quickly.
• If you’re looking for more detail about specific topics, the RVS documentation is at hand.  

And no matter what your question, RVS’s help search can link you to the most helpful resources at the click of a button. 

RapiCover Zero can help you meet DO-178C objective 6.4.4.c, which indicates that structural coverage analysis is performed on the software based on requirements-based tests of its behavior. RapiCover Zero supports structural coverage analysis at the statement and decision levels. Since Modified Condition/Decision Coverage examines source-level decisions, it can only be measured on object code in very limited circumstances. Instead, we recommend using RapiCover for full support of all MC/DC source code analysis.

RapiCover Zero justifications help you with DO-178C “structural coverage resolution” by letting you mark coverage holes as justified or covered by analysis.

As RapiCover Zero is designed to collect results from tests run on-target, it also helps you achieve DO-178C objective 6.4.e.

RapiCover Zero (together with RapiCover) can also support meeting the “additional code verification” part of DO-178C objective 6.4.4.c for DAL A software, which indicates that evidence is available for the correctness of additional code introduced by the compiler. 

For a detailed description of how RVS tools including RapiCover Zero can help you achieve DO-178C certification, see our web page on how to achieve DO-178C certification.

RapiTime Zero can help you meet DO-178C objective 6.3.4.f, which calls for evidence that “Source code is accurate and consistent”, including worst-case execution time analysis.

It can also help you meet DO-178C objective 6.3.3.f “Software partitioning integrity is confirmed” by letting you measure the impact of deliberate attempts to breach partitioning on your software’s timing behavior.

As RapiTime Zero is designed for on-target execution, it also helps you achieve DO-178C objective 6.4.e.

For a detailed description of how RVS tools including RapiTime Zero can help you achieve DO-178C certification, see our web page on how to achieve DO-178C certification.

RapiTime can help you meet DO-178C objective 6.3.4.f, which calls for evidence that “Source code is accurate and consistent”, including worst-case execution time analysis.

It can also help you meet DO-178C objective 6.3.3.f “Software partitioning integrity is confirmed” by letting you measure the impact of deliberate attempts to breach partitioning on your software’s timing behavior.

As RapiTime is designed for on-target execution, it also helps you achieve DO-178C objective 6.4.e.

RapiTime is a key part of the MACH¹⁷⁸ solution to provide verification results for multicore timing analysis. When used in this context, it can help you achieve AC 20-193 and AMC 20-193 objectives MCP_Resource_Usage_4 and MCP_Software_1.

For a detailed description of how RVS tools including RapiTime can help you achieve DO-178C certification, see our web page on how to achieve DO-178C certification.

RapiCover can help you meet DO-178C objective 6.4.4.c, which indicates that structural coverage analysis is performed on the software based on requirements-based tests of its behavior. RapiCover supports structural coverage analysis at the statement, decision, and Modified Condition/Decision Coverage levels, completing the evidence you need for the analysis.

RapiCover justifications help you with DO-178C “structural coverage resolution” by letting you mark coverage holes as justified or covered by analysis.

As RapiCover is designed to collect results from tests run on-target, it also helps you achieve DO-178C objective 6.4.e.

RapiCover (together with RapiCover Zero) can also support meeting the “additional code verification” part of DO-178C objective 6.4.4.c for DAL A software, which indicates that evidence is available for the correctness of additional code introduced by the compiler. 

For a detailed description of how RVS tools including RapiCover can help you achieve DO-178C certification, see our web page on how to achieve DO-178C certification.

RapiTest can help you meet DO-178C objectives 6.4.a, 6.4.b, 6.4.c and 6.4.d, which indicate that requirements-based testing is performed on the DO-178C software against both high and low-level requirements.

RapiTest helps you do the analysis needed to meet DO-178C objective 6.4.5.c. When a check fails, RapiTest provides the expected and actual results, making it easy to identify discrepancies, as required to meet the objective.

As RapiTest is designed for on-target execution and supports integration with a wide variety of third-party requirements management software applications, it also helps you achieve DO-178C objectives 6.4.e, 6.4.4.a and 6.4.4.b.

RapiTest is a key part of the MACH¹⁷⁸ solution to provide verification results for multicore timing analysis. When used in this context, it can help you achieve AC 20-193 and AMC 20-193 objectives MCP_Resource_Usage_4 and MCP_Software_1.

For a detailed description of how RVS tools including RapiTest can help you achieve DO-178C certification, see our web page on how to achieve DO-178C certification.

RVS can help you achieve the objectives in DO-178C tables A-6 and A-7, as well as some additional objectives:

• RapiTest can help you achieve DO-178C requirements-based testing objectives 6.4.a, 6.4.b, 6.4.c, 6.4.d
• RapiCover and RapiCover Zero can help you achieve DO-178C structural coverage analysis objective 6.4.4.c
• RapiTime and RapiTime Zero can help you achieve DO-178C objectives 6.3.4.f and 6.3.3.f
• RVS tools integrate with third-party requirements management software, which can help you achieve DO-178C objectives 6.4.4.a and 6.4.4.b
• All RVS tools are designed to support on-target testing, which can help you achieve DO-178C objective 6.4.e

For a detailed description of how RVS can help you achieve DO-178C certification, see our web page on how to achieve DO-178C certification. 

As well as supporting objectives in the main DO-178C guidance, RVS tools can help you achieve AC 20-193 and AMC 20-193 objectives:

• RapiTest and RapiTime can help you achieve A(M)C 20-193 objectives MCP_Resource_Usage_4 and MCP_Software_1 

For a detailed description of how RVS can help you achieve AC 20-193 and AMC 20-193 objectives, see this webpage.

MACH¹⁷⁸ Foundations provides template documents, procedures, templates and checklists to help you achieve the following AC 20-193 and AMC 20-193 objectives:

• MCP_Planning_1 and MCP_Planning_2 – Plan for Multicore Aspects of Certification template & checklist, Multicore Software Verification Plan template
• MCP_Resource_Usage_1 – Critical Configuration Settings Identification Procedure, template and checklists
• MCP_Resource_Usage_3 and MCP_Resource_Usage_4 – Procedures, templates and checklists
• MCP_Software_1 – Software Analysis & Characterization Procedures, templates and checklists

Rapita Systems can provide support for A(M)C 20-193 objectives including those not listed on this page through other elements of the MACH¹⁷⁸ Solution.

To identify interference channels on a multicore platform, it is necessary to analyze technical documentation that describes the functionality of platform components. This documentation will generally be accurate, descriptive and helpful, but will likely contain some errors, omissions, contradictions and ambiguities. This might include missing or vague information about a feature or definitions that are in contradiction with the actual functionality. In general, issues can often be resolved or clarified through support from the vendor to enable continued analysis.

Anomalies or errors are generally detected through on-target testing, and they are generally discovered when attempting to stress associated interference channels by targeted testing of a specific device or feature. A DDR interference channel, for example, will require tests to correctly miss L1, L2 and maybe even L3 cache. Depending on the architecture of the system, this may require using different datasets, strides through pages and access patterns.

Performance counters can be used to provide assurance for the correct execution of tests to characterize interference channels. Their use can highlight unexpected behaviors due to deviations from expected test outcomes, which should prompt further investigation and analysis. In an extreme example of this, we discovered and reverse-engineered an entire undocumented cache, which of course had associated interference channels.

We have found unexpected hardware behaviors on every project we’ve worked on. Causes can range from silicon bugs to undocumented IP blocks that have interference channels associated with them. Solutions can range from no action needed to needing to reverse engineer devices to understand their architecture and enable interference channel characterization. 

The MACH¹⁷⁸  approach has been used in a successful certification of multicore software with the Spanish National Institute for Aerospace Technology (INTA), which oversees certification for Spanish military avionics. There have only been very few complete certifications of multicore software for avionics so far, and we are frequently involved in projects at every stage of the process.

The MACH¹⁷⁸ approach has been developed with multiple rounds of feedback from individuals associated with EASA, and has been presented and discussed with civil and military authorities across Europe, the UK and the US.

This is dependent on your system safety analysis, your safety argument, and your method for WCET analysis. There is no “right answer” and these factors should be discussed with your certification authority. More details on methods for WCET determination can be found in the WCET Considerations white paper in MACH¹⁷⁸ Foundations.

There are some promising paths for doing WCET analysis for multicore systems that utilize statistical approaches. No statistical methodologies have been well established in terms of certification, so your chosen approach should be agreed upon with your certification authority.

Execution time in a multicore system does not follow a normal distribution, so the standard deviation cannot be used to meaningfully estimate exceedance probability for a deadline. This is due to consecutive executions of software not being independent from each other. One cause of this is it not being possible to know or control the initial state of deeply embedded hardware elements, which may have been left in any number of states by previous executions.  

The use of statistical models for WCET analysis is discussed in detail in the white paper WCET Considerations in MACH¹⁷⁸ Foundations. 

This is not inherently a multicore problem – it can also be encountered on single core systems. The additional complexity of high-performance multicore platforms may add to the required effort to construct the test vectors and test environment required for software characterization, which must be sufficient to construct “worst-case” scenarios. This may require external stimulation or inputs that can add to the complexity of the activity as it may make it hard to synchronize events or create other challenges. This is often achievable, but the additional effort and de-risking activities should be considered during planning. 

While it may not be necessary to test all permutations of interference channels, as some permutations may never be able to produce a worst-case timing result, a strong justification is required to remove the need to test a permutation. As such, the initial starting point may be to test all permutations of interference channels and the software under test, mapped to all active cores. Where you can justify why specific permutation(s) could never produce a worst-case timing result, for example where interference channels are mutually exclusive, you can remove these permutations from your analysis. Information helpful to this can be found in the MACH¹⁷⁸ Foundations white paper WCET Considerations. 

A(M)C 20-193 includes two software objectives, MCP_Software_1 and MCP_Software_2, which explicitly require calculation of the worst-case execution time and understanding of the data coupling and control coupling of your software, respectively. To achieve these objectives, you will first need to understand the platform and the interference channels within it (MCP_Resource_Usage_3). MCP_Resource_Usage_4 also indicates that the ability of the platform to allocate sufficient resources to the hosted software is verified. MACH¹⁷⁸ Foundations provides details of how to achieve the objectives in its procedures, templates and white papers.

The appropriate tool qualification level for interference generators depends on how they are used, and with some use cases, some organizations may argue that tool qualification is not required at all.

If tool qualification is required, RapiDaemon interference generators that are used in the MACH¹⁷⁸ solution can be considered as criteria 3, and thus classified as TQL 5 tools. This is discussed in detail in the template Plan for Multicore Aspects of Certification in MACH¹⁷⁸ Foundations. 
 

Interference generators such as Rapita’s RapiDaemons can interfere with each other.

The procedures in Rapita’s MACH¹⁷⁸ solution, which utilize RapiDaemons to produce on-target verification evidence, account for this.

During Interference Channel Characterization, we specify the selection of a RapiDaemon that is sensitive to an interference channel to use as a victim as well as aggressive RapiDaemons. Using sensitive and aggressive RapiDaemons together in this way allows measurement of the impact of the interference channel they are designed for. It is possible for aggressive interference generators, including RapiDaemons to interfere with each other. To determine the full interference profile, we specify testing all possible configurations of aggressive RapiDaemons against a victim RapiDaemon.

During Software Characterization, a similar approach is specified, where the combinations of interference channels are considered and all viable permutations of aggressive RapiDaemons are tested.

Detailed guidance on selecting interference generators is available in the MACH¹⁷⁸ Foundations white papers Interference Generator Selection and WCET Considerations.
 

Interference generators such as Rapita’s RapiDaemons are utilized in all on-target testing activities to characterize interference channels, verify mitigations and determine software WCET. Interference generators are an important part of constructing “worst-case” scenarios for multicore platforms. As such, they are required for on-target testing and analysis activities to address A(M)C 20-193 objectives MCP_Resource_Usage_3, MCP_Resource_Usage_4 and MCP_Software_1. 

Interference channel mitigations differ from platform to platform, though some general approaches exist such as using cache partitioning, disabling unnecessary devices and features, and applying good principles for software architecture and schedule design. 

Some mitigation strategies are discussed in our joint white paper with Wind River “Mitigation of interference in multicore processors for A(M)C 20-193”. The MACH¹⁷⁸ Foundations white papers RTOS Selection Considerations and Software Architecture Considerations provide some considerations on the topic, and a dedicated white paper on the topic is on a shortlist to be added to future versions of MACH¹⁷⁸ Foundations.

Your scheduling and partitioning mechanisms must be developed to the highest DAL of any hosted software, so relying on them to provide some mitigation methods is a valid approach to mitigating interference channels.

To satisfy the objectives of A(M)C 20-193, all active resources should be investigated for interference channels, and characterization should be performed on all identified interference channels that are not verifiably mitigated. Disabling unnecessary resources can remove them, and their associated interference channels, from the scope of analysis early on, which can reduce overall verification effort.

Whether a parallel or sequential approach to analyzing resources is most efficient likely depends on the configuration of your platform analysis team.

MACH¹⁷⁸ Foundations includes details on what should be analyzed and how. This is introduced in a template Multicore Software Verification Plan (MSVP) and described in individual procedures for specific activities, beginning with Hardware Resource Identification.
 

Interference channels can be identified through analysis of the documentation of all resources that are in scope for analysis. This should include detailed analysis of all devices, mechanisms and features to understand the potential interactions each presents for software running concurrently on different cores of the multicore processor. We provide detailed instructions of how to perform this activity in the Interference Channel Identification procedure in MACH¹⁷⁸ Foundations. 

Most suppliers that provide multicore platform components to avionics customers are aware of the need to provide detailed documentation and support. However, there can still be issues with IP blocks that have been embedded on a supplied board, for which the vendor has no access to the documentation from their supplier. In these cases, it can become potentially blocking if the information cannot be obtained, or is difficult to obtain, for example requiring additional legal or procurement costs.

In some cases, the only option for achieving A(M)C 20-193 evidence related to such a device’s interference channels may be to perform testing as a black box or reverse engineering the device in question. Such approaches should be discussed with your certification authority as they may not be viable in all cases. In our MACH¹⁷⁸ solution, we recommend a means to de-risk platform selection through the Hardware Resource Identification procedure, using the principles described in the Processor Selection Considerations white paper. Both documents are available in MACH¹⁷⁸ Foundations. 
 

This is not inherently a multicore problem. Most avionics developers have mechanisms in place for the acceptance of new deliveries from suppliers, but these may not cover testing of multicore-specific problems. This is where tools that allow for efficient re-testing and automation are important. Once the on-target platform characterization tests for interference channel characterization and hardware event monitor validation have been implemented, they can be reused to ensure that results are consistent across different batches of platforms. 

The movement of applications between two cores can be interpreted in two main ways, the dynamic allocation of applications to cores at run time (symmetric multi-processing, SMP), or the use of multiple static schedules that assign an application to different cores.

In general, dynamic (at run time) allocation of applications to cores is not covered by A(M)C 20-193. If you use this approach, you will likely need to agree an approach to demonstrating compliance with your certification authority.

If software is designed with multiple static schedules that can be selected between at run time, this will increase the complexity of A(M)C 20-193 verification. For each schedule, the software would need to meet relevant A(M)C 20-193 objectives such as MCP_Software_1 and MCP_Software_2.

In principle, there is nothing preventing IMA (Integrated Modular Avionics, DO-297) systems from including multicore processors. However, IMA requires robust time partitioning to be in place, which is challenging when multicore interference could allow one partition on one core to interfere with timing properties of other partitions on other cores.

There are some concessions that may need to be made, in terms of requirements for resource usage and/or CPU utilization on new partitions to be accepted. IMA requires the ability to integrate new partitions without the need for the re-acceptance of other partitions, which is incompatible with A(M)C objective MCP_Software_1, which requires that the WCET is determined in the intended final configuration. A white paper on this topic is on a shortlist be added to future versions of MACH¹⁷⁸ Foundations.

In principle, using GPUs as a graphics co-processor of a CPU for use with displays is a well understood and established approach, which is not fundamentally different in multicore systems.

However, using a GPU for general purpose GPU compute can put the GPU in scope as a core, requiring similar treatment as a CPU with respect to A(M)C 20-193. The exact use case can change the required activities drastically, particularly as there is a gray area as to how core-like the GPU may be.

A white paper on this topic is on a shortlist to be added to future versions of MACH¹⁷⁸ Foundations.
 

Simultaneous multithreading (hyperthreading) is out of scope of A(M)C 20-193 as this is not specifically a multicore issue.

In practice, simultaneous multithreading adds even more complexity to the testing and reasoning about the complex behaviors of a multicore system. As there is no additional guidance or means of compliance available from A(M)C 20-193, any approaches to making a certification argument should be discussed with your certification authority. 

You cannot know the performance of multicore software considering interference without determining and testing the interference channels. However, it is very important to de-risk the performance not being sufficient when selecting a platform and software stack.

These considerations are explained in detail in the MACH¹⁷⁸ Foundations white papers Processor Selection Considerations, RTOS Selection Considerations, and Software Architecture Considerations.
 

The complex nature of multicore platforms and the activities associated with addressing A(M)C 20-193 objectives generate many artifacts. As such, it is crucial to structure the planning documents accordingly. 

A(M)C 20-193 does not indicate the need for explicit multicore planning documents, so multicore specific documentation may be incorporated into existing PSAC, SVP and PHAC documents. Alternatively, a multicore version of corresponding DO-178C documents can be written to allow A(M)C artifacts to be independently generated without impacting the existing documents. In either case, it is crucial that traceability mechanisms are in place. We have seen both approaches to documenting A(M)C 20-193 activities to implemented successfully. Which option is best likely depends on the existing infrastructure and team structure in place. 

MACH¹⁷⁸ Foundations includes a template Plan for Multicore Aspects of Certification (PMAC) and Multicore Software Verification Plan (MSVP), which structurally follow the PSAC and SVP respectively, to allow easy integration into existing documents or use as standalone documents.
 

CAST-32A and A(M)C 20-193 was used as a guideline for writing AA-22-01, which will be incorporated in the upcoming MIL-HNDBK-516D. Almost all aspects of A(M)C 20-193 are defined by at least one criterion of AA-22-01. Some small clarifications or differences exist, for example AA-22-01 includes guidelines for an engineering margin (maximum 90% utilization), a specification that the lowest levels of cache must be private, and advice for building and loading processes. 

There is generally a lot more leniency in the defense industry when it comes to adhering to DO or A(M)C 20-193 objectives. It should be noted, however, that interference can have serious impacts on execution time, and may be a performance-limiting factor, not simply a barrier to certification. Generally, military certification authorities may have their own interpretation of the certification objectives, for example the AA-22-01 (USAF) or “Defence Standard 00-970” (UK MAA, though this points to AMC 20-193), but the core activities required to demonstrate airworthiness remain the same. 

Thermal effects can impact any platform, not just multicore platforms, and DO-254 currently has no additional considerations for multicore systems. While a revision to DO-254 is upcoming in which some multicore concerns may be addressed, it may be sensible to assume that on-target testing for A(M)C 20-193 should take environmental testing in mind.

A(M)C 20-193 objectives state that worst-case scenarios are implicit for WCET analysis, which implies ensuring the objectives are met in the worst-case conditions the system will be subjected to. For example, thermal throttling of one core may cause operating frequency changes in other cores.
 

The effort required to meet the objectives of the A(M)C 20-193 is heavily dependent on a number of factors, not least the complexity of the platform and software. With the same high-level requirements, the certification effort associated with a project could have orders of magnitude in difference depending on the platform, RTOS and configuration used, and software architecture choices made. For a simple platform with a carefully curated configuration of active devices and interference channel mitigations in place, together with sensibly structured software, some small number of person years effort may be required. A complex, no compromises platform used to host software with a complex architecture may require tens or even hundreds of person years of effort, and for such a system, there may even be no clear path to certification.

The key to an achievable certification is early planning. Taking multicore certification into account at early design and decision-making stages not only de-risks the certification itself, but will also have massive time and cost saving impacts.

More information on making decisions related to processor, RTOS and software architecture are discussed in a series of dedicated white papers in MACH¹⁷⁸ Foundations focused on each area.
 

Using a multicore processor with only a single core active is a popular approach for organizations making their first efforts towards using multicore processors. In principle, developing software where only a single core is active avoids meeting the objectives of A(M)C 20-193, which specifies that applicable Airborne Electronic Hardware guidance (A(M)C 20-152A, DO-254) can be followed to inform how a core should be deactivated. 

In practice, however, not all deactivation methods may be available, appropriate, or without unforeseen side effects. For example, we have seen hardware deactivation cause timing penalties due to bus accesses requiring communication from now deactivated cores. Different certification authorities have differing opinions about core deactivation methodologies, which can include requiring the use of redundant methods to deactivate cores. 

A detailed white paper on this topic is available in MACH¹⁷⁸ Foundations.  
 

Per the DO-178C definition, it is not possible to demonstrate “determinism” for multicore systems based due to their inherent non-deterministic nature. Accordingly, A(M)C 20-193 utilizes the DO-297 definition of determinism; “the ability to produce a predictable outcome” where “the outcome occurs in a specific period of time with repeatability”. 

We believe this can be achieved if sensible design decisions are made. We discuss this in the Software Architecture Considerations white paper in MACH¹⁷⁸ Foundations. Your approach to demonstrating WCET in a multicore system should be agreed with your certification authority in advance. You can find information that’s helpful for achieving this in the WCET Considerations white paper in MACH¹⁷⁸ Foundations.

A(M)C 20-193 provides some definitions of terms, for example for “Robust Partitioning” and “Determinism”, which differ from those in other documentation such as DO-178C. As multicore certification is in its infancy, how these definitions are interpreted and their impact on the activities associated with achieving the A(M)C objectives can differ between certification authorities. As such, we strongly recommend establishing and agreeing upon the definition and scope of what is required with your certification authority early in the process.

When developing our MACH¹⁷⁸ solutions, we have extensively discussed any terms in A(M)C 20-193 that are open to interpretation or are ambiguous (due to being redefinitions that differ from DO documentation, e.g., “Determinism”) with certification authorities and representatives and used terms accordingly in MACH¹⁷⁸ Foundations.

Differences can be seen in how certification authorities interpret what is necessary to meet A(M)C 20-193 objectives. An example of this is interpretation of the MCP_Resorce_Usage_4 objective. Even between the organizations and individuals that wrote the guidance, the required activities can range from a demonstration of functionally correct software meeting deadlines to understanding the maximum capacity of all MCP Resources as well as the maximum usage of hosted software. It is important to agree on these concepts early in the certification process.

The A(M)C 20-193 objectives apply for DAL A-C software. However, DO-178C requires robustness testing at DAL D, which would include some level of multicore interference analysis. While this will not require the same rigor as a full platform analysis, some generic interference generators on key resources may be necessary. A white paper on this topic is on a shortlist be added into a future version of MACH¹⁷⁸ Foundations.

It’s true that some A(M)C 20-193 objectives only apply at DAL A/B. However, the MCP_Software_1 objective requires determination of software worst-case execution time (WCET) even for DAL C systems. This will require some understanding of the interference channels on the platform and their impact on the software. You should speak to your certification authority to determine what level of rigor may be necessary for related activities. A white paper on the topic is on a shortlist to be added to a future version of MACH¹⁷⁸ Foundations.

A(M)C 20-193 specifies the objectives that are expected to demonstrate airworthiness of avionics that include multicore software based on software DAL. No objectives are indicated for DAL D systems, and only a portion of the objectives are indicated for DAL C systems, but this does not necessarily mean that related activities should be performed – see the corresponding FAQs below. 

In the general case, the simplest path to certification of a multicore processor should be by addressing the applicable A(M)C 20-193 objectives. If you wish to use alternative methods of compliance, you should discuss these with your certification authority.

MC/DC - "Modified Condition/Decision Coverage" - is defined in terms of source code level constructs such as conditions and decisions. These don't directly exist in the object code as it only contains branch statements. Object level code coverage can thus only tell you which branches were or were not covered.

In order to infer MC/DC coverage from branch coverage you would need a way of mapping branch statements back to conditions/decisions in the source code. This might be possible in some circumstances, but is not possible in the general case using off the shelf compilers, which try to remove branch statements where possible as they are bad for performance (branch misprediction can cause an entire pipeline to be invalidated).

For example, consider the following source code, which returns the value of bit n in the input value:

int check_bit_is_set(int value, int n) {
  if (value & (0x1 << n))
    return 1;
  else
    return 0;
}

It contains a decision which means MC/DC is required (even though there is only one condition). Using the GCC compiler for Arm at optimization level 1, this compiles down to a series of instructions with no branches:

check_bit_is_set(int, int):
asrs   r0, r0, r1
and   r0, r0, #1
bx    lr

It is thus impossible to infer MC/DC coverage of the source code from branch coverage in this case.

MACH¹⁷⁸ Foundations comes with the following training:

• 5 hours of introductory training to help you get started using MACH¹⁷⁸ Foundations and to help you understand the MACH¹⁷⁸ workflow.
• One seat on Rapita Systems’ public multicore DO-178C (A(M)C 20-193) training courses, which are delivered in Europe and the USA.

Documents included in MACH¹⁷⁸ Foundations are licensed on a perpetual basis for use on the project or program identified in the corresponding Commercial Agreement.

MACH¹⁷⁸ Foundations provides procedures, templates and checklists that you can use to produce and deliver multicore DO-178C compliance evidence in alignment with A(M)C 20-193 objectives.

These procedures are best followed using RVS automation tools, which ensure efficient verification for multicore software.

Both MACH¹⁷⁸ Foundations and RVS are included in the MACH¹⁷⁸ Core Pack.

MACH¹⁷⁸ Foundations was designed to help you produce compliance evidence for DO-178C projects that involve the use of multicore computing platforms. The materials included support certification whether multicore platforms are used in multicore mode or only a single active core is used. 

You can also use MACH¹⁷⁸ Foundations for R&D and to better equip your organization to prepare for multicore certification in the future.

MACH¹⁷⁸ Foundations is delivered as a library of documents with a user-friendly front-end that helps you navigate through its contents. This makes it easy to find the information and documents you need to understand and execute the MACH¹⁷⁸ workflow.

Both RapiCover and RapiCover^Zero support on-target structural coverage analysis for critical software. 

Depending on your project and needs, one or both solutions may be better for you. Consult the table below to determine which is best for your project.

Both RapiCover and RapiCover^Zero support on-target structural coverage analysis for critical software. 

Depending on your project and needs, one or both solutions may be better for you. Consult the table below to determine which is best for your project.

Both RapiTime and RapiTime^Zero support on-target worst-case execution time analysis for critical software. 

Depending on your project and needs, one or both solutions may be better for you. Consult the table below to determine which is best for your project.

Both RapiTime and RapiTime^Zero support on-target worst-case execution time analysis for critical software. 

Depending on your project and needs, one or both solutions may be better for you. Consult the table below to determine which is best for your project.

Both RapiTask and RapiTask^Zero support task-level scheduling visualization for critical software. 

Depending on your project and needs, one or both solutions may be better for you. Consult the table below to determine which is best for your project.

Both RapiTask and RapiTask^Zero support task-level scheduling visualization for critical software. 

Depending on your project and needs, one or both solutions may be better for you. Consult the table below to determine which is best for your project.

Both instrumentation-based and zero-footprint (instrumentation-free) RVS verification tools are available to support the following activities:

• Structural coverage analysis – (RapiCover and RapiCover^Zero)
• Worst-case execution time analysis (RapiTime and RapiTime^Zero)
• Scheduling visualization – (RapiTask and RapiTask^Zero)

Depending on your project and needs, instrumentation-based, zero-footprint, or both solutions for each activity may be better for you. Consult the table below to determine which is best for your project.

No, but you can use RapiTask^Zero for your scheduling visualization. 

No, but you can use RapiTime^Zero for your worst-case execution time analysis. 

No, but you can use RapiCover^Zero for your structural coverage analysis.

Yes. Zero-footprint (instrumentation-free) RVS verification tools are available to support the following activities:

• Structural coverage analysis – (RapiCover^Zero)
• Worst-case execution time analysis (RapiTime^Zero)
• Scheduling visualization – (RapiTask^Zero)

The following software tools support multicore DO-178C (AC 20-193 and AMC 20-193) compliance using the MACH¹⁷⁸ workflow:

• RapiDaemons enable the targeted generation of traffic on shared hardware resources to generate interference during tests, so the impact of interference on platform and software behavior can be analyzed
• RapiTest supports writing and executing tests (including the application of RapiDaemons) to analyze and verify software performance
• RapiTime supports collecting performance metrics including execution time and values from Hardware Event Monitors during testing, and analyzing the results
• RapiTask supports visualizing and analyzing software scheduling

RapiTest, RapiTime and RapiDaemons, which are used to automate MACH¹⁷⁸ processes, are classified as Tool Qualification Level 5 tools as per DO-330. Qualification kits and services provide the evidence needed to qualify their use in MACH¹⁷⁸ projects.

RVS supports meeting standards and guidelines for verification of mission and safety-critical applications including:

• Civil aerospace software guidelines DO-178C (ED-12C), DO-278A (ED-109), AC 20-193 & AMC 20-193
• Military & defense aerospace standards MIL-HDBK-516C, AA-22-01 AMACC, EMACC, ADSM, Def Stan 00-55 & Def Stan 00-56
• Automotive standard ISO 26262
• Space software standards NASA-STD-8739.8B, ECSS-E-ST-40C
• Other standards based on IEC 61508, including IEC 62279, EN50128 & EN 50657 (rail), IEC 61511 (industrial processes), IEC 61513 (power), IEC 60880 (nuclear) & IEC 62061 (machinery)

RVS supports meeting standards and guidelines for verification of mission and safety-critical applications including:

• Civil aerospace software guidelines DO-178C (ED-12C), DO-278A (ED-109), AC 20-193 & AMC 20-193
• Military & defense aerospace standards MIL-HDBK-516C, AA-22-01 AMACC, EMACC, ADSM, Def Stan 00-55 & Def Stan 00-56
• Automotive standard ISO 26262
• Space software standards NASA-STD-8739.8B, ECSS-E-ST-40C
• Other standards based on IEC 61508, including IEC 62279, EN50128 & EN 50657 (rail), IEC 61511 (industrial processes), IEC 61513 (power), IEC 60880 (nuclear) & IEC 62061 (machinery)

RVS supports meeting standards and guidelines for verification of mission and safety-critical applications including:

• Civil aerospace software guidelines DO-178C (ED-12C), DO-278A (ED-109), AC 20-193 & AMC 20-193
• Military & defense aerospace standards MIL-HDBK-516C, AA-22-01 AMACC, EMACC, ADSM, Def Stan 00-55 & Def Stan 00-56
• Automotive standard ISO 26262
• Space software standards NASA-STD-8739.8B, ECSS-E-ST-40C
• Other standards based on IEC 61508, including IEC 62279, EN50128 & EN 50657 (rail), IEC 61511 (industrial processes), IEC 61513 (power), IEC 60880 (nuclear) & IEC 62061 (machinery)

RVS supports meeting standards and guidelines for verification of mission and safety-critical applications including:

• Civil aerospace software guidelines DO-178C (ED-12C), DO-278A (ED-109), AC 20-193 & AMC 20-193
• Military & defense aerospace standards MIL-HDBK-516C, AA-22-01 AMACC, EMACC, ADSM, Def Stan 00-55 & Def Stan 00-56
• Automotive standard ISO 26262
• Space software standards NASA-STD-8739.8B, ECSS-E-ST-40C
• Other standards based on IEC 61508, including IEC 62279, EN50128 & EN 50657 (rail), IEC 61511 (industrial processes), IEC 61513 (power), IEC 60880 (nuclear) & IEC 62061 (machinery)

RVS supports meeting standards and guidelines for verification of mission and safety-critical applications including:

• Civil aerospace software guidelines DO-178C (ED-12C), DO-278A (ED-109), AC 20-193 & AMC 20-193
• Military & defense aerospace standards MIL-HDBK-516C, AA-22-01 AMACC, EMACC, ADSM, Def Stan 00-55 & Def Stan 00-56
• Automotive standard ISO 26262
• Space software standards NASA-STD-8739.8B, ECSS-E-ST-40C
• Other standards based on IEC 61508, including IEC 62279, EN50128 & EN 50657 (rail), IEC 61511 (industrial processes), IEC 61513 (power), IEC 60880 (nuclear) & IEC 62061 (machinery)

RVS supports meeting standards and guidelines for verification of mission and safety-critical applications including:

• Civil aerospace software guidelines DO-178C (ED-12C), DO-278A (ED-109), AC 20-193 & AMC 20-193
• Military & defense aerospace standards MIL-HDBK-516C, AA-22-01 AMACC, EMACC, ADSM, Def Stan 00-55 & Def Stan 00-56
• Automotive standard ISO 26262
• Space software standards NASA-STD-8739.8B, ECSS-E-ST-40C
• Other standards based on IEC 61508, including IEC 62279, EN50128 & EN 50657 (rail), IEC 61511 (industrial processes), IEC 61513 (power), IEC 60880 (nuclear) & IEC 62061 (machinery)

How is RapiCover Zero optimized to support my industry?

Different variants of RapiCover Zero are available, each of which is optimized to best meet the verification needs of specific software industries:

• RapiCover Zero - Aero includes example projects, tutorials and analysis profiles optimized for engineers working on DO-178C/ED-12C projects. Coverage analysis profiles are available based on verification requirements for DAL A-C software.
• RapiCover Zero - Auto includes example projects, tutorials and analysis profiles optimized for engineers working on ISO 26262 projects. Coverage analysis profiles are available based on verification requirements for ASIL A-D software.
• RapiCover Zero - Space includes example projects, tutorials and analysis profiles optimized for engineers working on NASA-STD-8739.8B and ECSS-E-ST-40C projects. For ECSS-E-ST-40C, coverage analysis profiles are available based on verification requirements for software Criticality Category.

Different variants of RapiCover are available, each of which is optimized to best meet the verification needs of specific software industries:

• RapiCover Aero includes example projects, tutorials and analysis profiles optimized for engineers working on DO-178C/ED-12C projects. Coverage analysis profiles are available based on verification requirements for DAL A-C software.
• RapiCover Auto includes example projects, tutorials and analysis profiles optimized for engineers working on ISO 26262 projects. Coverage analysis profiles are available based on verification requirements for ASIL A-D software.
• RapiCover Space includes example projects, tutorials and analysis profiles optimized for engineers working on NASA-STD-8739.8B and ECSS-E-ST-40C projects. For ECSS-E-ST-40C, coverage analysis profiles are available based on verification requirements for software Criticality Category.

Different variants of RVS are available, each of which is optimized to best meet the verification needs of specific software industries:

• RVS Aero includes example projects, tutorials and analysis profiles optimized for engineers working on DO-178C/ED-12C projects. Analysis profiles are available based on verification requirements for DAL A-C software.
• RVS Auto includes example projects, tutorials and analysis profiles optimized for engineers working on ISO 26262 projects. Analysis profiles are available based on verification requirements for ASIL A-D software.
• RVS Space includes example projects, tutorials and analysis profiles optimized for engineers working on NASA-STD-8739.8B and ECSS-E-ST-40C projects. For ECSS-E-ST-40C, analysis profiles are available based on verification requirements for software Criticality Category.

RapiTime^Zero lets you merge timing results from different test runs into a single report. This supports the collection of timing data from multiple test campaigns, and lets you merge results from different builds, for example system test and low-level test builds, so long as the functions under test are identical.

RapiTest can let you test your unmodified object code. This capability can be set up as part of an RVS integration. For more information, contact us.

RapiTest lets you write support functions in C or C++ code that you can include in your RapiTest tests. These let you define reusable test logic to perform functions such as initialization or teardown, defining complex sets of checks, implementing complex stubs, and instantiating templates.  

RVS can supplement model-based development workflows using MATLAB® Simulink® to support on-target verification of model-based code and verification of handwritten code.   

RapiCover supports generating structural coverage metrics for model-based code in SIL, PIL and HIL testing environments, while RapiTime supports execution time analysis including WCET analysis of model-based code from on-target testing in PIL and HIL environments.

RVS can be used to support functional testing, structural coverage analysis and execution time/WCET analysis of additional handwritten code used in projects that use Simulink.

RVS can supplement model-based development workflows using MATLAB® Simulink® to support on-target verification of model-based code and verification of handwritten code.   

RapiCover supports generating structural coverage metrics for model-based code in SIL, PIL and HIL testing environments, while RapiTime supports execution time analysis including WCET analysis of model-based code from on-target testing in PIL and HIL environments.

RVS can be used to support functional testing, structural coverage analysis and execution time/WCET analysis of additional handwritten code used in projects that use Simulink.

RVS can supplement model-based development workflows using MATLAB® Simulink® to support on-target verification of model-based code and verification of handwritten code.   

RapiCover supports generating structural coverage metrics for model-based code in SIL, PIL and HIL testing environments, while RapiTime supports execution time analysis including WCET analysis of model-based code from on-target testing in PIL and HIL environments.

RVS can be used to support functional testing, structural coverage analysis and execution time/WCET analysis of additional handwritten code used in projects that use Simulink.

RVS analyzes the structure of your code and presents information on your code’s structure, helping you understand your code and its dependencies in a variety of forms such as the following:

• RVS analyzes the McCabe complexity of your code and presents the complexity of each code element, letting you easily identify code with high complexity. 
• RVS Treemaps present the hierarchy of your code’s components and source files graphically.
• RVS lets you view and explore the call dependencies in your code.  

RVS analyzes the structure of your code and presents information on your code’s structure, helping you understand your code and its dependencies in a variety of forms such as the following:

• RVS analyzes the McCabe complexity of your code and presents the complexity of each code element, letting you easily identify code with high complexity. 
• RVS Treemaps present the hierarchy of your code’s components and source files graphically.
• RVS lets you view and explore the call dependencies in your code.  

RVS analyzes the structure of your code and presents information on your code’s structure, helping you understand your code and its dependencies in a variety of forms such as the following:

• RVS analyzes the McCabe complexity of your code and presents the complexity of each code element, letting you easily identify code with high complexity. 
• RVS Treemaps present the hierarchy of your code’s components and source files graphically.
• RVS lets you view and explore the call dependencies in your code.  

RVS analyzes the structure of your code and presents information on your code’s structure, helping you understand your code and its dependencies in a variety of forms such as the following:

• RVS analyzes the McCabe complexity of your code and presents the complexity of each code element, letting you easily identify code with high complexity. 
• RVS Treemaps present the hierarchy of your code’s components and source files graphically.
• RVS lets you view and explore the call dependencies in your code.  

RVS analyzes the structure of your code and presents information on your code’s structure, helping you understand your code and its dependencies in a variety of forms such as the following:

• RVS analyzes the McCabe complexity of your code and presents the complexity of each code element, letting you easily identify code with high complexity. 
• RVS Treemaps present the hierarchy of your code’s components and source files graphically.
• RVS lets you view and explore the call dependencies in your code.  

RVS analyzes the structure of your code and presents information on your code’s structure, helping you understand your code and its dependencies in a variety of forms such as the following:

• RVS analyzes the McCabe complexity of your code and presents the complexity of each code element, letting you easily identify code with high complexity. 
• RVS Treemaps present the hierarchy of your code’s components and source files graphically.
• RVS lets you view and explore the call dependencies in your code.  

RVS analyzes the structure of your code and presents information on your code’s structure, helping you understand your code and its dependencies in a variety of forms such as the following:

• RVS analyzes the McCabe complexity of your code and presents the complexity of each code element, letting you easily identify code with high complexity. 
• RVS Treemaps present the hierarchy of your code’s components and source files graphically.
• RVS lets you view and explore the call dependencies in your code.  

RVS analyzes the structure of your code and presents information on your code’s structure, helping you understand your code and its dependencies in a variety of forms such as the following:

• RVS analyzes the McCabe complexity of your code and presents the complexity of each code element, letting you easily identify code with high complexity. 
• RVS Treemaps present the hierarchy of your code’s components and source files graphically.
• RVS lets you view and explore the call dependencies in your code.  

RapiTime lets you configure custom sequences to collect measurements for anywhere in your code. You can use this feature to collect a range of timing metrics for your code, such as response times, periodicity and separation.

RVS supports the analysis of shared code compiled by build systems with multiple executables by letting you specify the source files that will be compiled in each executable. 

If you have functions that are declared in multiple components with the same name but have different definitions, RVS can treat each such function uniquely, for example to provide separate coverage in RapiCover and separate execution time results in RapiTime.

RVS supports the analysis of shared code compiled by build systems with multiple executables by letting you specify the source files that will be compiled in each executable. 

If you have functions that are declared in multiple components with the same name but have different definitions, RVS can treat each such function uniquely, for example to provide separate coverage in RapiCover and separate execution time results in RapiTime.

RVS supports the analysis of shared code compiled by build systems with multiple executables by letting you specify the source files that will be compiled in each executable. 

If you have functions that are declared in multiple components with the same name but have different definitions, RVS can treat each such function uniquely, for example to provide separate coverage in RapiCover and separate execution time results in RapiTime.

RVS supports the analysis of shared code compiled by build systems with multiple executables by letting you specify the source files that will be compiled in each executable. 

If you have functions that are declared in multiple components with the same name but have different definitions, RVS can treat each such function uniquely, for example to provide separate coverage in RapiCover and separate execution time results in RapiTime.

RVS supports the analysis of shared code compiled by build systems with multiple executables by letting you specify the source files that will be compiled in each executable. 

If you have functions that are declared in multiple components with the same name but have different definitions, RVS can treat each such function uniquely, for example to provide separate coverage in RapiCover and separate execution time results in RapiTime.

RVS supports the analysis of shared code compiled by build systems with multiple executables by letting you specify the source files that will be compiled in each executable. 

If you have functions that are declared in multiple components with the same name but have different definitions, RVS can treat each such function uniquely, for example to provide separate coverage in RapiCover and separate execution time results in RapiTime.

RVS supports the analysis of shared code compiled by build systems with multiple executables by letting you specify the source files that will be compiled in each executable. 

If you have functions that are declared in multiple components with the same name but have different definitions, RVS can treat each such function uniquely, for example to provide separate coverage in RapiCover and separate execution time results in RapiTime.

RVS supports the analysis of shared code compiled by build systems with multiple executables by letting you specify the source files that will be compiled in each executable. 

If you have functions that are declared in multiple components with the same name but have different definitions, RVS can treat each such function uniquely, for example to provide separate coverage in RapiCover and separate execution time results in RapiTime.

Yes. RVS has an out-of-the-box integration with Deos, which makes it possible to generate an RVS project including a RapiTask integration in just 3 clicks from an existing OpenArbor project.

This benefits from the debug capabilities offered by Deos to automatically apply configuration settings needed for your project and RapiTask integration.

In addition to letting you visualize the scheduling behavior of your code, the generated integration lets you perform on-target structural coverage analysis with RapiCover and on-target worst-case execution time analysis with RapiTime.

Yes. RVS has an out-of-the-box integration with Deos, which makes it possible to generate an RVS project including a RapiTime integration in just 3 clicks from an existing OpenArbor project.

This benefits from the debug capabilities offered by Deos to automatically apply configuration settings needed for your project and RapiTime integration.

In addition to supporting on-target worst-case execution time analysis, the generated integration lets you perform on-target structural coverage analysis with RapiCover and visualize the scheduling behavior of your code with RapiTask.

Yes. RVS has an out-of-the-box integration with Deos, which makes it possible to generate an RVS project including a RapiCover integration in just 3 clicks from an existing OpenArbor project.

This benefits from the debug capabilities offered by Deos to automatically apply configuration settings needed for your project and RapiCover integration.

In addition to supporting on-target structural coverage analysis, the generated integration lets you perform on-target worst-case execution time analysis with RapiTime and visualize the scheduling behavior of your code with RapiTask.

Yes. RVS has an out-of-the-box integration with Deos, which makes it possible to generate an RVS project and integration in just 3 clicks from an existing OpenArbor project.

This benefits from the debug capabilities offered by Deos to automatically apply configuration settings needed for your RVS project.

The generated project and integration lets you use RapiCover for on-target structural coverage analysis, RapiTime for on-target worst-case execution time analysis, and RapiTask to let you visualize the scheduling behavior of your code.

Yes. You can use RapiTime to support on target worst-case execution time analysis of your model code as well as any handwritten code you use in your project.

Yes. RapiTest lets you automatically convert your existing SCADE Test tests into RapiTest tests so you can test your code on target.

You can also use RapiTime to support on target worst-case execution time analysis of your model code and any handwritten code you use in your project.

Yes, you can create and manage groups of users for your floating RVS licenses. You can restrict each group to only serve licenses to specific hostnames or IP addresses. This allows you to reserve licenses for specific groups or specific purposes such as supporting the use of RVS on a continuous integration server.

Any licenses that you don’t reserve will remain available as floating licenses that can be shared among different users and geographic locations.

Yes, you can create and manage groups of users for your floating RVS licenses. You can restrict each group to only serve licenses to specific hostnames or IP addresses. This allows you to reserve licenses for specific groups or specific purposes such as supporting the use of RVS on a continuous integration server.

Any licenses that you don’t reserve will remain available as floating licenses that can be shared among different users and geographic locations.

Yes, you can create and manage groups of users for your floating RVS licenses. You can restrict each group to only serve licenses to specific hostnames or IP addresses. This allows you to reserve licenses for specific groups or specific purposes such as supporting the use of RVS on a continuous integration server.

Any licenses that you don’t reserve will remain available as floating licenses that can be shared among different users and geographic locations.

Yes, you can create and manage groups of users for your floating RVS licenses. You can restrict each group to only serve licenses to specific hostnames or IP addresses. This allows you to reserve licenses for specific groups or specific purposes such as supporting the use of RVS on a continuous integration server.

Any licenses that you don’t reserve will remain available as floating licenses that can be shared among different users and geographic locations.

Yes, you can create and manage groups of users for your floating RVS licenses. You can restrict each group to only serve licenses to specific hostnames or IP addresses. This allows you to reserve licenses for specific groups or specific purposes such as supporting the use of RVS on a continuous integration server.

Any licenses that you don’t reserve will remain available as floating licenses that can be shared among different users and geographic locations.

Yes, you can create and manage groups of users for your floating RVS licenses. You can restrict each group to only serve licenses to specific hostnames or IP addresses. This allows you to reserve licenses for specific groups or specific purposes such as supporting the use of RVS on a continuous integration server.

Any licenses that you don’t reserve will remain available as floating licenses that can be shared among different users and geographic locations.

Yes, you can create and manage groups of users for your floating RVS licenses. You can restrict each group to only serve licenses to specific hostnames or IP addresses. This allows you to reserve licenses for specific groups or specific purposes such as supporting the use of RVS on a continuous integration server.

Any licenses that you don’t reserve will remain available as floating licenses that can be shared among different users and geographic locations.

Yes, you can create and manage groups of users for your floating RVS licenses. You can restrict each group to only serve licenses to specific hostnames or IP addresses. This allows you to reserve licenses for specific groups or specific purposes such as supporting the use of RVS on a continuous integration server.

Any licenses that you don’t reserve will remain available as floating licenses that can be shared among different users and geographic locations.

RapiTime supports multicore timing analysis by enabling the collection and analysis of results when timing tests are run on the multicore platform.

It supports the collection of results by enabling the instrumentation of code so execution time results and values from hardware event monitors that monitor behavior such as cache hits can be collected when the multicore software is run, and by enabling the processing of collected results into an RVS report so the results can be easily analyzed.

RapiTime supports the analysis of collected results by providing helpful charts and visualization tools, allowing filtering of results by test or hardware event, and supporting the comparison of results against baseline control tests. 

To see whether we have already developed PSPs compatible with the components on your platform, see our zero-footprint Platform support.

If we have not yet developed PSPs compatible with one or more components of your platform, we may be able to develop them. For more information, contact us at info@rapitasystems.com.

To see whether we have already developed PSPs compatible with the components on your platform, see our zero-footprint Platform support.

If we have not yet developed PSPs compatible with one or more components of your platform, we may be able to develop them. For more information, contact us at info@rapitasystems.com.

To see whether we have already developed PSPs compatible with the components on your platform, see our zero-footprint Platform support.

If we have not yet developed PSPs compatible with one or more components of your platform, we may be able to develop them. For more information, contact us at info@rapitasystems.com.

Platform Support Packages are required to support software analysis by zero-footprint RVS tools. They interface between the tools and the platform in order to do the following:

• Convert the specific format of native branch traces generated by the platform into a format that the RVS tool understands and can use for subsequent analysis.
• Disassemble the object code to understand the structure and control flow of the code so this can be used for subsequent analysis.

Each PSP is designed to support various components of a platform. These include:

• The compiler(s) used to generate executables
• The instruction set of object code to be analyzed
• The native branch trace format generated from the platform – this depends on the mechanism used to generate branch traces, which may be the target hardware (or simulator) or a third-party device e.g. debugger.
• The real-time operating system.

Different PSPs are needed to support analysis by zero-footprint RVS tools when any of the above items are different between two platforms. For more information on how PSPs support analysis by zero-footprint RVS tools, see our Requirements for zero-footprint RVS analysis Technical note.

Platform Support Packages are required to support software analysis by zero-footprint RVS tools. They interface between the tools and the platform in order to do the following:

• Convert the specific format of native branch traces generated by the platform into a format that the RVS tool understands and can use for subsequent analysis.
• Disassemble the object code to understand the structure and control flow of the code so this can be used for subsequent analysis.

Each PSP is designed to support various components of a platform. These include:

• The compiler(s) used to generate executables
• The instruction set of object code to be analyzed
• The native branch trace format generated from the platform – this depends on the mechanism used to generate branch traces, which may be the target hardware (or simulator) or a third-party device e.g. debugger.
• The real-time operating system.

Different PSPs are needed to support analysis by zero-footprint RVS tools when any of the above items are different between two platforms. For more information on how PSPs support analysis by zero-footprint RVS tools, see our Requirements for zero-footprint RVS analysis Technical note.

Platform Support Packages are required to support software analysis by zero-footprint RVS tools. They interface between the tools and the platform in order to do the following:

• Convert the specific format of native branch traces generated by the platform into a format that the RVS tool understands and can use for subsequent analysis.
• Disassemble the object code to understand the structure and control flow of the code so this can be used for subsequent analysis.

Each PSP is designed to support various components of a platform. These include:

• The compiler(s) used to generate executables
• The instruction set of object code to be analyzed
• The native branch trace format generated from the platform – this depends on the mechanism used to generate branch traces, which may be the target hardware (or simulator) or a third-party device e.g. debugger.
• The real-time operating system.

Different PSPs are needed to support analysis by zero-footprint RVS tools when any of the above items are different between two platforms. For more information on how PSPs support analysis by zero-footprint RVS tools, see our Requirements for zero-footprint RVS analysis Technical note.

Floating RVS licenses follow an “Enterprise” model. You can use them across geographical boundaries*, in different projects, with different users, and share them with suppliers working on the same project.

^*Some floating licenses may be restricted to use within a specific geographical region. Where this is the case, this is agreed before licenses are issued.

Floating RVS licenses follow an “Enterprise” model. You can use them across geographical boundaries*, in different projects, with different users, and share them with suppliers working on the same project.

^*Some floating licenses may be restricted to use within a specific geographical region. Where this is the case, this is agreed before licenses are issued.

Floating RVS licenses follow an “Enterprise” model. You can use them across geographical boundaries*, in different projects, with different users, and share them with suppliers working on the same project.

^*Some floating licenses may be restricted to use within a specific geographical region. Where this is the case, this is agreed before licenses are issued.

Floating RVS licenses follow an “Enterprise” model. You can use them across geographical boundaries*, in different projects, with different users, and share them with suppliers working on the same project.

^*Some floating licenses may be restricted to use within a specific geographical region. Where this is the case, this is agreed before licenses are issued.

Floating RVS licenses follow an “Enterprise” model. You can use them across geographical boundaries*, in different projects, with different users, and share them with suppliers working on the same project.

^*Some floating licenses may be restricted to use within a specific geographical region. Where this is the case, this is agreed before licenses are issued.

Floating RVS licenses follow an “Enterprise” model. You can use them across geographical boundaries*, in different projects, with different users, and share them with suppliers working on the same project.

^*Some floating licenses may be restricted to use within a specific geographical region. Where this is the case, this is agreed before licenses are issued.

Floating RVS licenses follow an “Enterprise” model. You can use them across geographical boundaries*, in different projects, with different users, and share them with suppliers working on the same project.

^*Some floating licenses may be restricted to use within a specific geographical region. Where this is the case, this is agreed before licenses are issued.

Floating RVS licenses follow an “Enterprise” model. You can use them across geographical boundaries*, in different projects, with different users, and share them with suppliers working on the same project.

^*Some floating licenses may be restricted to use within a specific geographical region. Where this is the case, this is agreed before licenses are issued.

To support verification, RVS stores a copy of your source code in your verification results. RVS lets you remove this copy of your source code from your RVS project, so any subcontracting organizations you’re working with can’t see your proprietary information. A subcontracting organization can then verify aspects of your software using the redacted results, and you can later restore the copy of your source code for your internal use by merging your results.

Note that, as running functional tests requires access to the source code under test, this feature is not available for RapiTest.

To support verification, RVS stores a copy of your source code in your verification results. RVS lets you remove this copy of your source code from your RVS project, so any subcontracting organizations you’re working with can’t see your proprietary information. A subcontracting organization can then verify aspects of your software using the redacted results, and you can later restore the copy of your source code for your internal use by merging your results.

Note that, as running functional tests requires access to the source code under test, this feature is not available for RapiTest.

To support verification, RVS stores a copy of your source code in your verification results. RVS lets you remove this copy of your source code from your RVS project, so any subcontracting organizations you’re working with can’t see your proprietary information. A subcontracting organization can then verify aspects of your software using the redacted results, and you can later restore the copy of your source code for your internal use by merging your results.

Note that, as running functional tests requires access to the source code under test, this feature is not available for RapiTest.

To support verification, RVS stores a copy of your source code in your verification results. RVS lets you remove this copy of your source code from your RVS project, so any subcontracting organizations you’re working with can’t see your proprietary information. A subcontracting organization can then verify aspects of your software using the redacted results, and you can later restore the copy of your source code for your internal use by merging your results.

Note that, as running functional tests requires access to the source code under test, this feature is not available for RapiTest.

RapiTime lets you merge timing results from different builds or test runs into a single report. This supports the collection of timing data from multiple test campaigns and from multiple test rigs.

Yes, you do not need to use RapiTest to collect coverage results. As long as you have a compatible execution environment, RapiCoverZero can collect coverage results from your system.

Yes, you do not need to use RapiTest to collect coverage results. RapiCover can instrument your test code so coverage results can be automatically collected as your tests as run, then displayed for analysis.

Yes, we can. Contact us if you want to learn more.

In general, statistical modeling approaches are not applicable to timing analysis of software as software timing behavior does not fit standard statistical assumptions.

In some cases, software timing behavior may fit standard statistical assumptions, but this is the exception rather than the rule and must be proven before relying on results from statistical modeling.

In general, statistical modeling approaches are not applicable to timing analysis of software as software timing behavior does not fit standard statistical assumptions.

In some cases, software timing behavior may fit standard statistical assumptions, but this is the exception rather than the rule and must be proven before relying on results from statistical modeling.

Email us at info@rapitasystems.com and we’ll get in touch with you to discuss your needs and arrange a course.

Our multicore timing analysis training courses are delivered by our multicore timing analysis engineers.

As we deliver multicore timing analysis training courses to your organization, this really depends on your needs. We prefer small class sizes as this supports interactive training.

Yes, we provide certificates to attendees that attend multicore timing analysis training courses, which identify the training topics that they have learned about during the course.

Yes, we can customize our multicore timing analysis training courses to meet your specific needs. Please get in touch with us at info@rapitasystems.com if you want to discuss custom training.

Generally, we provide multicore timing analysis training courses for a specific organization. This allows us to customize the course to meet each organization’s unique needs.

Yes, our multicore timing analysis training courses include both theoretical and practical components. In the practical components, attendees use RVS and RapiDaemons to write and run multicore tests and analyze results under guidance from our trainers. We provide licenses that allow all attendees to work through the practical training.

Attendees of our RVS tool training courses leave with a strong theoretical understanding of relevant verification activities and a practical understanding of how to efficiently perform these verification objectives using the Rapita multicore timing analysis workflow, RVS and RapiDaemons.

We offer courses that help attendees learn how to use Rapita’s multicore timing analysis workflow, including following relevant processes and using the Rapita Verification Suite (RVS) and RapiDaemons efficiently to perform multicore timing analysis. Topics include:

• Writing the multicore timing analysis process into your DO-178C planning documents using the template documents provided by Rapita.
• Setting up RapiDaemons and configuring tuneable RapiDaemons.
• Writing multicore tests in RVS, which use RapiDaemons to investigate the effects of timing behavior when interference is present on different interference channels.
• Analyzing timing results and values from hardware event monitors to understand and quantify interference effects on different interference channels.
• Importing requirements into RVS and using ReqLink to ensure that verification artifacts are traceable and produce traceability reports.

Where necessary, we also include training on fundamental concepts of multicore timing analysis and CAST-32A/A(M)C 20-193 compliance.

We customize our multicore timing analysis training courses to meet your specific needs.

Email us at info@rapitasystems.com and we’ll get in touch with you to discuss your needs and arrange a course.

As we deliver RVS tool training courses to your organization, this really depends on your needs. We prefer small class sizes as this supports interactive training.

Yes, we provide certificates to attendees that attend RVS tool training courses, which identify the training topics that they have learned about during the course.

Our RVS tool training courses are delivered by Rapita Field Application Engineers, who are experts at integrating RVS into a wide variety of development environments and using it to produce verification results.

Yes, we can customize our RVS tool training courses to meet your specific needs. Please get in touch with us at info@rapitasystems.com if you want to discuss custom training.

Generally, we provide RVS tool training courses for a specific organization. This allows us to customize the course to meet each organization’s unique needs.

Yes, our RVS tool training courses include both theoretical and practical components. In the practical components, attendees use RVS themselves. When allowed by your organization, we demonstrate how to use RVS efficiently on your software. We provide licenses that allow all attendees to work through the practical training.

Attendees of our RVS tool training courses leave with a strong theoretical understanding of relevant verification activities and a practical understanding of how to efficiently perform these verification objectives using RVS.

We offer courses that help attendees learn how to use the Rapita Verification Suite (RVS) efficiently to verify critical software in a variety of ways, including:

• Performing requirements-based testing. Using RapiTest to write requirements-based tests, run them to collect verification results, review and export test results, and support requirements traceability.
• Analyzing the structural coverage achieved by software tests. Using RapiCover to automatically instrument code to collect coverage results while tests are run and to review and analyze coverage results.
• Analyzing software worst-case execution time and optimizing code to reduce worst-case timing behavior. Using RapiTime to instrument code to collect timing results while tests are run, refining RapiTime analysis to reduce pessimism in worst-case execution time calculation, using RapiTime to review and analyze execution time results, and using RapiTime to identify optimization candidates for worst-case execution time behavior.
• Understanding system event scheduling behavior. Using RapiTask to collect task-level timing behavior while software tests are run, analyze scheduling behavior and identify rare events such as race conditions in critical software.
• Using RVS with continuous integration systems to follow software and verification development throughout the life cycle of a project.
• Verifying software for coverage and timing behavior and understanding system scheduling behavior without needing instrumentation or access to source code (in compatible environments). Using RapiCover^Zero, RapiTime^Zero and RapiTask^Zero and which environments are compatible with zero-footprint RVS verification.
• Integrating RVS into development environments, including build system integration and target integration for data capture.

Where necessary, we also include training on fundamental concepts of verification, such as requirements-based testing, structural coverage analysis and worst-case execution time analysis.


We customize our RVS tool training courses to meet your specific needs.

Due to the COVID-19 pandemic, we have been unable to provide training either on-site or through local workshops. We continue to deliver training courses online as virtual instructor-led training courses.

We have flexible delivery options for our training sessions. Depending on the type of training course, we offer different options, offering:

• Online training, where our trainers host training through an online platform.
• On-site training, where our trainers meet you at your site.
• Local workshop training, where our trainers host training at a public venue.

Yes, we can customize our training courses to cover the specific topics that best meet your training needs.

We offer a range of training courses on topics related to verification of critical software; our: 

• RVS tool training courses train attendees in how to use the Rapita Verification Suite (RVS) to efficiently verify critical software.
• Multicore timing analysis training courses train attendees in how to use the Rapita multicore timing analysis workflow to analyze software timing behavior in the context of multicore interference.

The Rapita Verification Suite (RVS) has been used in the critical embedded industry for over 15 years and supported a number of avionics projects globally. Qualification kits for qualified RVS products have supported more than 20 DO-178B and C certification projects up to and including DAL A.

The Rapita Verification Suite (RVS) has been used in the critical embedded industry for over 15 years and supported a number of avionics projects globally. Qualification kits for qualified RVS products have supported more than 20 DO-178B and C certification projects up to and including DAL A.

The Rapita Verification Suite (RVS) has been used in the critical embedded industry for over 15 years and supported a number of avionics projects globally. Qualification kits for qualified RVS products have supported more than 20 DO-178B and C certification projects up to and including DAL A.

The Rapita Verification Suite (RVS) has been used in the critical embedded industry for over 15 years and supported a number of avionics projects globally. Qualification kits for qualified RVS products have supported more than 20 DO-178B and C certification projects up to and including DAL A.

The Rapita Verification Suite (RVS) has been used in the critical embedded industry for over 15 years and supported a number of avionics projects globally. Qualification kits for qualified RVS products have supported more than 20 DO-178B and C certification projects up to and including DAL A.

The Rapita Verification Suite (RVS) has been used in the critical embedded industry for over 15 years and supported a number of avionics projects globally. Qualification kits for qualified RVS products have supported more than 20 DO-178B and C certification projects up to and including DAL A.

The Rapita Verification Suite (RVS) has been used in the critical embedded industry for over 15 years and supported a number of avionics projects globally. Qualification kits for qualified RVS products have supported more than 20 DO-178B and C certification projects up to and including DAL A.

The Rapita Verification Suite (RVS) has been used in the critical embedded industry for over 15 years and supported a number of avionics projects globally. Qualification kits for qualified RVS products have supported more than 20 DO-178B and C certification projects up to and including DAL A.

RVS qualification kits are designed to make the qualification process easier. Each kit includes a qualification timeline that clearly identifies key stages in the process, and compliance checklists help you check your progress.

We customize RVS qualification kits to reflect aspects of your development environment in order to reduce review effort. They include documentation, requirements and test results for the specific RVS tools you are using and the programming languages used in your project.

Qualification kits also include tool user document templates and compliance checklists that help you check your compliance with DO-330 tool user objectives.

We support the migration of unit tests produced for use with a variety of unit testing tools, including both commercial and internally developed tools, into RapiTest tests. We work with you to create a solution, which may be a combination of automatic test conversion, manual conversion by our engineers, and review.

The formats we can migrate unit tests from include, but are not limited to:

• VectorCAST® tests
• Legacy Ada testing tool tests
• Google® Test tests

For more information and to see how we can help you, contact us at info@rapitasystems.com.

Google® is the trade mark of Google LLC.
VectorCAST® is the trade mark of Vector Software, Inc. registered in USA under number 4949992.

RapiTime automatically applies instrumentation based on a default instrumentation profile that you select. You can easily configure the instrumentation applied to specific functions or areas of your code using the RVS Project Manager.

You can also use time bands to assign instrumentation automatically based on the expected call frequencies of functions in your code, and set optional rules that reduce or omit instrumentation in functions that don’t require detailed timing information.

RapiTest makes it easy to select the tests you run with each build of the test harness. Test selection options in the RVS Project Manager help you to quickly select to run only new or modified tests, tests that are failing, tests for specific requirements, or any combination thereof.

If your code has changed, you can use the Optimal Dataset Calculator to automatically select the most efficient set of tests to run to achieve the same coverage you did in a previous report. This helps you quickly ensure that your coverage hasn’t been affected by the code changes before committing to running your full test suite.

If you’re using the RapiTest Editor, RapiTest’s integrated testing interface, this provides guidance throughout the test authoring process, making it easy to set up new test vectors and stubs and including real-time error reporting and context-sensitive links to RapiTest’s user documentation. If you have any questions on specific topics, this is available through a dedicated help system, which also highlights relevant example projects and tests for the task at hand. 

RapiTest lets you quickly generate templates that you can use to write your tests. When generating templates, you can quickly link requirements to your tests, set input and expected output values for units under test and stubbed functions, and set configuration options. 

RapiTest can also automatically generate test vectors to test functions that handle numeric inputs – this generates tests for the min, max, and optionally step values of the function under test. 

Yes. RapiTest integrates with ANSYS® SCADE® Test™, letting you perform back-to-back testing of your SCADE models. By interpreting and executing your model-based tests against generated source code for both on-host and on-target testing, RapiTest improves efficiency by letting you reuse your SCADE tests through all phases of the verification lifecycle.

You don’t need to register for support. If you have a license with active support and maintenance, you are automatically registered for our support services and can request support by contacting our support team.

When you purchase a perpetual license for one of our products, we include one year’s support and maintenance in the purchase price. After this period, you need to buy a support service contract to continue taking advantage of our support and maintenance.

When you buy an annual license of one of our products, we include support and maintenance for the duration of the license.

Find out more here about support service duration and purchasing here.

You can contact the Rapita support team by email or telephone. Our support team is available Monday to Friday during UK and US office hours and we offer support outside these hours on a best effort basis.

Email address: support@rapitasystems.com
If you contact us by email, you will receive an automated response and our team will respond to your personally within one working day.

Telephone (international): +44 1904 413945
Telephone (US): +1 248-957-9801

Our support and maintenance package includes the following:

• Support – access to our support team, who can resolve any issues you may have while using our software
• Maintenance – bug fixes and workarounds to any issues caused by problems in our software
• Updates and information – access to all known issues in our software and assurance bulletins

Our standard support and maintenance package covers current, superseded and deprecated versions of all our software, subject to our Product Lifecycle Policy.

RapiDaemons are licensed as part of MACH¹⁷⁸. For more information, contact us.

We deliver RapiDaemons themselves as binary applications that are ported for compatibility with your multicore system. We also include documentation describing the purpose of each RapiDaemon in the library and how to use them.

We include support and maintenance for RapiDaemons, giving you access to our support team and to new RapiDaemons that we develop.

DO-330 Qualification kits are available for RapiDaemons to support the use of RapiDaemons in projects certifying to DO-178C or similar guidelines. These are available separately.

Some of the multicore systems that we’ve worked with are listed in our FAQ “Which hardware architectures can you analyze?”. Standard RapiDaemons are available for many of the systems that we’ve analyzed. For more information, contact us.

After linking RapiDaemons object files with your software (see “How do I use RapiDaemons?”), RapiDaemons are typically initialized through either RapiTest or RapiTime, which automate the initialization, making it easy to use RapiDaemons.

RapiDaemons are delivered as object files that are compatible with your multicore platform. To configure these for use on your platform, these need to be linked together with your software’s object files. After this initial work, RapiDaemons can be automatically initialized using RapiTest and RapiTime.

When we deliver RapiDaemons, we include documentation describing how to configure and initialize them.

Yes. We have run projects analyzing the Nvidia Xavier AGX (CUDA) and AMD’s Embedded Radeon E9171 GPU (featuring the CoreAVI Vulkan SC driver).

We recommend that, when performing functional testing of safety-critical applications for a final run-for-score, you run your full test suite both with and without coverage instrumentation applied, then confirm that the results match. This provides evidence that RVS instrumentation has not changed the functional behavior of your code.

We recommend that, when using RVS tools to perform functional testing of safety-critical applications for a final run-for-score, you run your full test suite both with and without coverage instrumentation applied, then confirm that the results match. This provides evidence that coverage instrumentation has not changed the functional behavior of your code.

We recommend that, when producing timing evidence for certification, you use RapiTime to improve your test data so that the high watermark path and predicted worst-case path align as closely as possible and then perform task boundary only instrumentation to measure the high-watermark execution times. These values will be representative of the estimated worst case times, and the minimal level of instrumentation applied will have a negligible effect on the application's timing behavior.

RVS integrates with a range of continuous integration tools, allowing you to collect unit test, coverage and execution time results with every new build, track your verification progress over time and easily identify anomalies in your software's behavior as they are introduced.

RapiTest, RapiCover and RapiTime (including zero-footprint versions) include custom plugins to integrate with Jenkins and Bamboo. RapiTest and RapiCover results can also be displayed in a range of other continuous integration tools through the JUnit and Cobertura plugins, which are compatible with most continuous integration software. 

RVS integrates with a range of continuous integration tools, allowing you to collect unit test, coverage and execution time results with every new build, track your verification progress over time and easily identify anomalies in your software's behavior as they are introduced.

RapiTest, RapiCover and RapiTime (including zero-footprint versions) include custom plugins to integrate with Jenkins and Bamboo. RapiTest and RapiCover results can also be displayed in a range of other continuous integration tools through the JUnit and Cobertura plugins, which are compatible with most continuous integration software. 

RVS integrates with a range of continuous integration tools, allowing you to collect unit test, coverage and execution time results with every new build, track your verification progress over time and easily identify anomalies in your software's behavior as they are introduced.

RapiTest, RapiCover and RapiTime (including zero-footprint versions) include custom plugins to integrate with Jenkins and Bamboo. RapiTest and RapiCover results can also be displayed in a range of other continuous integration tools through the JUnit and Cobertura plugins, which are compatible with most continuous integration software. 

RVS integrates with a range of continuous integration tools, allowing you to collect unit test, coverage and execution time results with every new build, track your verification progress over time and easily identify anomalies in your software's behavior as they are introduced.

RapiTest, RapiCover and RapiTime (including zero-footprint versions) include custom plugins to integrate with Jenkins and Bamboo. RapiTest and RapiCover results can also be displayed in a range of other continuous integration tools through the JUnit and Cobertura plugins, which are compatible with most continuous integration software. 

RVS integrates with a range of continuous integration tools, allowing you to collect unit test, coverage and execution time results with every new build, track your verification progress over time and easily identify anomalies in your software's behavior as they are introduced.

RapiTest, RapiCover and RapiTime (including zero-footprint versions) include custom plugins to integrate with Jenkins and Bamboo. RapiTest and RapiCover results can also be displayed in a range of other continuous integration tools through the JUnit and Cobertura plugins, which are compatible with most continuous integration software. 

RVS integrates with a range of continuous integration tools, allowing you to collect unit test, coverage and execution time results with every new build, track your verification progress over time and easily identify anomalies in your software's behavior as they are introduced.

RapiTest, RapiCover and RapiTime (including zero-footprint versions) include custom plugins to integrate with Jenkins and Bamboo. RapiTest and RapiCover results can also be displayed in a range of other continuous integration tools through the JUnit and Cobertura plugins, which are compatible with most continuous integration software. 

RapiTest supports your traceability workflow by interfacing with your requirements management and traceability software, allowing you to reuse information about requirements and test artifacts that you have already defined.   

RapiTest’s part in the traceability workflow is simple, involving import, assignment, reporting and export. 

You can import information about requirements and test artifacts in formats including Word, Excel, and the Requirements Interchange Format (ReqIF), which is compatible with many requirements traceability tools. If you’re using Jama Connect®, you can configure RVS to automatically pull in information on requirements or test artifacts from the software. 

With this information in your project, you can tag your tests with the requirements they test and/or assign the test artifact IDs you use to identify each test uniquely.  

After running your tests, RapiTest displays your requirements coverage and the status of each test tagged with each requirement, and lets you export your results in RapiTest exports. If you're using Jenkins or Bamboo, you can view your requirements coverage in each build and follow the trend in requirements coverage throughout your project. 

If you’re using Jama Connect®, you can automatically export key information such as test pass/fail status back into the software, so you can continue to monitor your project’s traceability from Jama Connect. 

As RapiCover^Zero analyzes object code directly to produce results, it supports any language that targets machine code.

If you are using an external device to collect branch trace information, the data will remain in place while your system reboots, after which you can begin data collection again. This means that you can collect coverage data across a shutdown or reset sequence. This may be subject to your target hardware architecture and the device you use to collect branch trace information.

If your source code is available, yes. By importing your source code and debug symbols into your RVS project, you can view your results in the context of both your object and source code, and trace between them.

If your source code is available, yes. By importing your source code and debug symbols into your RVS project, you can view your results in the context of both your object and source code, and trace between them.

If your source code is available, yes. By importing your source code and debug symbols into your RVS project, you can view your results in the context of both your object and source code, and trace between them.

RapiCover^Zero uses two types of inputs from which to produce structural coverage results. The first is the executable file and a disassembly of it, and the second is a branch trace* collected while the program under analysis is executed. From these inputs, RapiCover^Zero can understand both the program structure and the events that occurred during the program execution, allowing it to perform structural coverage analysis and produce coverage results.

*In some circumstances, other data collection methods such as using a branch map may be possible.

Software analysis by zero-footprint RVS tools has the following requirements:

• The platform (target and any external devices e.g. debuggers) must be capable of producing a branch trace without gaps to ensure that the full program trace can be reconstructed.
• The OS needs to make context switches observable. For some systems, supporting this may require modifications to be made to the OS.
• A Platform Support Package (PSP) is needed for RVS to interface with the platform, including the target hardware and trace capture mechanisms, in order to convert the branch trace into a format that the RVS tool understands and disassemble the executable and parse the resulting object code. PSPs are developed to be compatible with four components of the platform: Compilers, Instruction sets, Branch traces and Real-time operating systems.

For more information on the requirements for software analysis by zero-footprint RVS tools and a list of currently supported platforms, see our Platform support page.

For more detailed information on the requirements, see our Technical note.

Software analysis by zero-footprint RVS tools has the following requirements:

• The platform (target and any external devices e.g. debuggers) must be capable of producing a branch trace without gaps to ensure that the full program trace can be reconstructed.
• The OS needs to make context switches observable. For some systems, supporting this may require modifications to be made to the OS.
• A Platform Support Package (PSP) is needed for RVS to interface with the platform, including the target hardware and trace capture mechanisms, in order to convert the branch trace into a format that the RVS tool understands and disassemble the executable and parse the resulting object code. PSPs are developed to be compatible with four components of the platform: Compilers, Instruction sets, Branch traces and Real-time operating systems.

For more information on the requirements for software analysis by zero-footprint RVS tools and a list of currently supported platforms, see our Platform support page.

For more detailed information on the requirements, see our Technical note.

Software analysis by zero-footprint RVS tools has the following requirements:

• The platform (target and any external devices e.g. debuggers) must be capable of producing a branch trace without gaps to ensure that the full program trace can be reconstructed.
• The OS needs to make context switches observable. For some systems, supporting this may require modifications to be made to the OS.
• A Platform Support Package (PSP) is needed for RVS to interface with the platform, including the target hardware and trace capture mechanisms, in order to convert the branch trace into a format that the RVS tool understands and disassemble the executable and parse the resulting object code. PSPs are developed to be compatible with four components of the platform: Compilers, Instruction sets, Branch traces and Real-time operating systems.

For more information on the requirements for software analysis by zero-footprint RVS tools and a list of currently supported platforms, see our Platform support page.

For more detailed information on the requirements, see our Technical note.

You can measure function, call, statement, branch and decision coverage using RapiCover^Zero.

RapiCover^Zero produces coverage results by analyzing a branch trace produced during program execution. While coverage metrics up to decision coverage can be inferred from branch traces, most branch traces do not include sufficient information from which to produce MC/DC results.

If you need to collect MC/DC results, you can do so using RapiCover.

You can request a trial version of RVS, which includes RapiTask^Zero. You can also arrange a demonstration, where a member of our team will work with you to show the benefits that RapiTask^Zero can offer you.

As RapiTask^Zero analyzes object code directly to produce results, it supports any language that targets machine code.

RapiTime and RapiTime^Zero abstract away from the OS tasking model and only report the execution time of a task as if it were the only thing running on the CPU. If you are interested in the response time of your code, or the interaction between tasks and your OS, you'll need RapiTask or RapiTask^Zero.

RapiTask^Zero displays results in two applications, the RVS Project Manager that is shared with all RVS tools, and an application specifically designed to display task scheduling information. You can synchronize the two applications to ensure that you can easily identify specific timing events in your system.

RapiTask^Zero 's Invocation Timeline Chart helps you to understand the high-level scheduling behavior of your system at a glance.

As with all RVS tools, RapiTask^Zero supports data collection on multicore architectures. To analyze the task-level scheduling behavior of multicore architectures, RapiTask^Zero simply needs to know which branches corresponded to which core during program execution. This information can be inferred by providing a combined trace that includes information on the core on which each branch was taken.

RapiTask^Zero is OS-agnostic; as with all Rapita tools the integration with the operating environment needs to be customized. If we can get information about items of interest from the OS we can add ‘user events’ to a RapiTask^Zero trace.

RapiTask^Zero is OS-agnostic so you can keep the same visualization and metrics if you change OS, and you can use RapiTask^Zero results as a point of reference to compare operating systems.

Additionally, you can capture and display custom events not related to the operating system (for example ARINC 429 messages) and display them in the trace.

RapiTask^Zero uses two types of inputs from which to produce task-level scheduling results. The first is the executable file and a disassembly of it, and the second is a branch trace collected while the program under analysis is executed. From these inputs, RapiTask^Zero can understand both the program structure and the events that occurred during the program execution, allowing it to perform task-level scheduling analysis and produce results.

RapiTask^Zero is a scheduling visualization tool that requires no project source code or modification of the development environment being used. To extract task-level scheduling information from a program, RapiTask^Zero analyzes branch trace information collected from a compatible target or data collection mechanism.

As part of the RVS toolsuite, it forms part of a software verification solution that also includes tools for structural coverage analysis, worst-case execution time analysis and functional testing.

You can request a trial version of RVS, which includes RapiTime^Zero. You can also arrange a demonstration, where a member of our team will work with you to show the benefits that RapiTime^Zero can offer you.

As RapiTime^Zero analyzes object code directly to produce results, it supports any language that targets machine code.

RapiTime^Zero includes a Rewind Trace utility, which lets you step through the events that occurred during program execution like you can with a debugger. This lets you set breakpoints and easily analyze the execution of your program.

As with all RVS tools, RapiTime^Zero supports data collection on multicore architectures. To analyze the timing behavior of multicore architectures, RapiTime^Zero simply needs to know which branches corresponded to which core during program execution. This information can either be inferred by providing an individual branch trace for each core, or a combined trace that includes information on the core on which each branch was taken.

RapiTime^Zero collects and reports data on your code’s worst-case-execution time, high water mark path, and reports minimum, average and maximum execution times for each test.

RapiTime^Zero uses two types of inputs from which to analyze software execution times. The first is the executable file and a disassembly of it, and the second is a branch trace collected while the program under analysis is executed. From these inputs, RapiTime^Zero can understand both the program structure and the events that occurred during the program execution, allowing it to perform execution time analysis and produce execution time results.

RapiTime^Zero is an execution time analysis tool that requires no project source code or modification of the development environment being used. To extract execution time information, RapiTime^Zero analyzes branch trace information collected from a compatible target or data collection mechanism.

As part of the RVS toolsuite, it forms part of a software verification solution that also includes tools for structural coverage analysis and functional testing.

You can request a trial version of RVS, which includes RapiCover^Zero. You can also arrange a demonstration, where a member of our team will work with you to show the benefits that RapiCover^Zero can offer you.

All RVS tools include a friendly user-interface that presents your results in both tabular and graphical formats. Using this interface, you can filter your results to zoom in on target functions, making it easy to find the information you are looking for.

Treemaps provide a high-level overview of your code base and help you understand the coverage of your code at a glance.

You can view RapiCover and RapiCover^Zero results in continuous integration software, allowing you to track your verification progress over time. 

All RVS tools include a friendly user-interface that presents your results in both tabular and graphical formats. Using this interface, you can filter your results to zoom in on target functions, making it easy to find the information you are looking for.

Treemaps provide a high-level overview of your code base and help you understand the coverage of your code at a glance.

You can view RapiCover and RapiCover^Zero results in continuous integration software, allowing you to track your verification progress over time. 

RapiCover and RapiCover^Zero retain information about the revision of your code it used to generate results. The tool will report an error if you try to merge coverage from incompatible revisions. RapiCover includes an Optimal Dataset Calculator feature you can use to calculate the least expensive tests you need to run again when your code changes, saving you valuable testing effort.

RapiCover and RapiCover^Zero retain information about the revision of your code it used to generate results. The tool will report an error if you try to merge coverage from incompatible revisions. RapiCover includes an Optimal Dataset Calculator feature you can use to calculate the least expensive tests you need to run again when your code changes, saving you valuable testing effort.

RapiCover and RapiCover^Zero include a powerful “justification” mechanism that lets you mark code as covered. Using this feature, you can provide a rationale for justifying the code and create templates to justify code more easily. When your code changes, justifications are automatically migrated to represent the new location of your justified code.

For more information on using justifications, see our white paper.

RapiCover and RapiCover^Zero include a powerful “justification” mechanism that lets you mark code as covered. Using this feature, you can provide a rationale for justifying the code and create templates to justify code more easily. When your code changes, justifications are automatically migrated to represent the new location of your justified code.

For more information on using justifications, see our white paper.

We provide an extensive set of RVS documentation with each of our products, and offer training courses guiding you through the most effective use of RVS tools. All our users can benefit from privileged access to our website, which includes downloads for new product releases. 

We provide an extensive set of RVS documentation with each of our products, and offer training courses guiding you through the most effective use of RVS tools. All our users can benefit from privileged access to our website, which includes downloads for new product releases. 

We provide an extensive set of RVS documentation with each of our products, and offer training courses guiding you through the most effective use of RVS tools. All our users can benefit from privileged access to our website, which includes downloads for new product releases. 

We provide an extensive set of RVS documentation with each of our products, and offer training courses guiding you through the most effective use of RVS tools. All our users can benefit from privileged access to our website, which includes downloads for new product releases. 

We provide an extensive set of RVS documentation with each of our products, and offer training courses guiding you through the most effective use of RVS tools. All our users can benefit from privileged access to our website, which includes downloads for new product releases. 

We provide an extensive set of RVS documentation with each of our products, and offer training courses guiding you through the most effective use of RVS tools. All our users can benefit from privileged access to our website, which includes downloads for new product releases. 

We provide an extensive set of RVS documentation with each of our products, and offer training courses guiding you through the most effective use of RVS tools. All our users can benefit from privileged access to our website, which includes downloads for new product releases. 

We provide an extensive set of RVS documentation with each of our products, and offer training courses guiding you through the most effective use of RVS tools. All our users can benefit from privileged access to our website, which includes downloads for new product releases. 

All RVS licenses include access to our dedicated in-house support team, who will work with you to provide a rapid fix to your issue. This is a critical part of our vision. During 2021, we resolved 63% of our support requests within 7 working days and 93% within 30 working days. We also inform our customers of known issues via our website and email.

All RVS licenses include access to our dedicated in-house support team, who will work with you to provide a rapid fix to your issue. This is a critical part of our vision. During 2021, we resolved 63% of our support requests within 7 working days and 93% within 30 working days. We also inform our customers of known issues via our website and email.

All RVS licenses include access to our dedicated in-house support team, who will work with you to provide a rapid fix to your issue. This is a critical part of our vision. During 2021, we resolved 63% of our support requests within 7 working days and 93% within 30 working days. We also inform our customers of known issues via our website and email.

All RVS licenses include access to our dedicated in-house support team, who will work with you to provide a rapid fix to your issue. This is a critical part of our vision. During 2021, we resolved 63% of our support requests within 7 working days and 93% within 30 working days. We also inform our customers of known issues via our website and email.

All RVS licenses include access to our dedicated in-house support team, who will work with you to provide a rapid fix to your issue. This is a critical part of our vision. During 2021, we resolved 63% of our support requests within 7 working days and 93% within 30 working days. We also inform our customers of known issues via our website and email.

All RVS licenses include access to our dedicated in-house support team, who will work with you to provide a rapid fix to your issue. This is a critical part of our vision. During 2021, we resolved 63% of our support requests within 7 working days and 93% within 30 working days. We also inform our customers of known issues via our website and email.

All RVS licenses include access to our dedicated in-house support team, who will work with you to provide a rapid fix to your issue. This is a critical part of our vision. During 2021, we resolved 63% of our support requests within 7 working days and 93% within 30 working days. We also inform our customers of known issues via our website and email.

All RVS licenses include access to our dedicated in-house support team, who will work with you to provide a rapid fix to your issue. This is a critical part of our vision. During 2021, we resolved 63% of our support requests within 7 working days and 93% within 30 working days. We also inform our customers of known issues via our website and email.

We offer both “Node-locked” and “Floating” licenses, and a license server to support use of our tools in your specific development environment. 

For more information on our licensing models, see our RVS licensing FAQs.

We offer both “Node-locked” and “Floating” licenses, and a license server to support use of our tools in your specific development environment. 

For more information on our licensing models, see our RVS licensing FAQs.

We offer both “Node-locked” and “Floating” licenses, and a license server to support use of our tools in your specific development environment. 

For more information on our licensing models, see our RVS licensing FAQs.

We offer both “Node-locked” and “Floating” licenses, and a license server to support use of our tools in your specific development environment. 

For more information on our licensing models, see our RVS licensing FAQs.

We offer both “Node-locked” and “Floating” licenses, and a license server to support use of our tools in your specific development environment. 

For more information on our licensing models, see our RVS licensing FAQs.

We offer both “Node-locked” and “Floating” licenses, and a license server to support use of our tools in your specific development environment. 

For more information on our licensing models, see our RVS licensing FAQs.

We offer both “Node-locked” and “Floating” licenses, and a license server to support use of our tools in your specific development environment. 

For more information on our licensing models, see our RVS licensing FAQs.

We offer both “Node-locked” and “Floating” licenses, and a license server to support use of our tools in your specific development environment. 

For more information on our licensing models, see our RVS licensing FAQs.

RVS tools are designed to handle very large code bases. Because of the efficient algorithms used by RVS tools, there is no fundamental limitation to the number of lines of code that RVS can process, and our RVS tools have been used on projects with millions of lines of code.

RVS tools are designed to handle very large code bases. Because of the efficient algorithms used by RVS tools, there is no fundamental limitation to the number of lines of code that RVS can process, and our RVS tools have been used on projects with millions of lines of code.

RVS tools are designed to handle very large code bases. Because of the efficient algorithms used by RVS tools, there is no fundamental limitation to the number of lines of code that RVS can process, and our RVS tools have been used on projects with millions of lines of code.

RVS tools are designed to handle very large code bases. Because of the efficient algorithms used by RVS tools, there is no fundamental limitation to the number of lines of code that RVS can process, and our RVS tools have been used on projects with millions of lines of code.

RVS tools are designed to handle very large code bases. Because of the efficient algorithms used by RVS tools, there is no fundamental limitation to the number of lines of code that RVS can process, and our RVS tools have been used on projects with millions of lines of code.

RVS tools are designed to handle very large code bases. Because of the efficient algorithms used by RVS tools, there is no fundamental limitation to the number of lines of code that RVS can process, and our RVS tools have been used on projects with millions of lines of code.

RVS tools are designed to handle very large code bases. Because of the efficient algorithms used by RVS tools, there is no fundamental limitation to the number of lines of code that RVS can process, and our RVS tools have been used on projects with millions of lines of code.

RVS tools are designed to handle very large code bases. Because of the efficient algorithms used by RVS tools, there is no fundamental limitation to the number of lines of code that RVS can process, and our RVS tools have been used on projects with millions of lines of code.

RapiCover^Zero is a structural coverage analysis tool that requires no project source code or modification of the development environment being used. To extract coverage information, RapiCover^Zero analyzes branch trace information collected from a compatible target or data collection mechanism.

As part of the RVS toolsuite, RapiCover^Zero forms part of a software verification solution that also includes tools for functional testing and worst-case execution time analysis.

RapiTask is OS-agnostic; as with all Rapita tools the integration with the operating environment needs to be customized. If we can get information about items of interest from the OS we can add ‘user events’ to a RapiTask trace.

You can measure the most common coverage criteria required to support DO-178B/ED-12B, DO-178C/ED-12C and ISO 26262 certification using RapiCover. This includes function, call, statement, branch, decision and condition coverage, and MC/DC.

The length of the tool qualification process varies depending on the complexity of your project and integration.

In general, we can deliver a qualified target integration service in around 6 weeks from the submission of a purchase order, subject to any configuration changes and the availability of Rapita engineers.

We confirm the delivery schedule after we receive your purchase order.

Note that changes to the configuration of your integration during the service delivery process may affect engineering effort, delivery dates and costs.

We offer a frozen version support service for qualified RVS integrations, so you can rest assured that you will have access to the version of RVS you're qualifying even if your project has a very long life cycle.

If it’s a genuine mistake, we can issue an addendum report or reissue any affected documents, as appropriate. If you need a different scope or level of information, that can be accommodated but requires more effort. For more information, contact us.

If you make a change to the RVS tool version or integration of RVS into your development environment after we have produced qualification materials, we will need to reproduce those materials, which will incur extra costs.

For more information, see our Tool Qualification Product briefs.

Licenses for our qualification support are valid for a specific version of the RVS tools you’re using, a specific integration of those tools into your development environment, and a specific customer project.

Please contact us if you need to use our qualification kits in multiple projects, or projects with multiple certifications.

We use flexible tool components and custom integrations to maximize the efficiency of our tools and their compatibility with a wide range of targets and test environments. The price of this flexibility is additional tool qualification work. We’ve split our qualification support into two parts – one for the flexible tool components and one for the custom integration – and we’ve done everything we can to reduce the effort involved in the custom part.

We follow the DO-330/ED-215 guidance for qualification of a COTS (commercial off-the-shelf) tool. Per these standards, a tool vendor cannot provide all of the evidence needed for tool qualification – some of it must be provided by the tool user.

Our qualified target integration service includes all of the DO-330 tool developer items, as well as documentation and effort to help you to complete DO-330 tool user items.

This includes generic documents, on-site tests and expected results that help you produce a large proportion of the evidence you need for qualification, including all of the documentation that needs to be provided by the tool vendor (us). In addition to what we provide, you will need to run on-site tests, check results against a list of expected results, and produce some documents, such as the user Tool Operation Requirements, yourself. We provide template tool user documents to help you with this.

See our Tool Qualification Product Briefs for more details.

If you want qualification support for using an RVS tool in a specific safety context and we don’t already offer qualification support for this combination, we’d be happy to hear from you to discuss extending our support. Contact us for more information.

The qualification support we already have available is listed on our Resources page. If you need qualification support that isn’t listed, contact us to see how we can help.

RVS tool qualification covers the use of RVS in projects written in Ada, C and C++, including mixed language projects.

We produce our qualification material to support DO-178C, DO-278A and ISO 26262 certification in alignment with guidelines in RTCA’s DO-330: Software Tool Qualification Considerations.

You can request a trial version of RVS, which includes RapiTest. You can also arrange a demonstration, where a member of our team will work with you to show the benefits RapiTest can offer you.

If you're interested in RapiTest in academia, you can search for it in the academic press. 

While RapiCover has very low instrumentation overheads, it may not be possible to collect all coverage from the same build or run due to code size or timing-related constraints.

RapiCover lets you collect coverage incrementally from multiple builds, allowing you to generate full coverage reports efficiently, even on resource-constrained systems.

The RTBx is a data logger that provides a cost-effective, easy-to-use solution for collecting and timestamping long streams of verification data from software tests run on embedded hardware. It is target-independent, supporting a wide variety of target architectures, and provides an excellent way of collecting trace data for use by RVS.

The instrumentation overheads for RapiTime tools are very low, and zero-instrumentation overhead can even be supported in some cases, depending on your target hardware and data collection strategy. This means that you can use RapiTime with virtually any target. 

If your available memory is very limited, you can use RapiTime's Time Bands feature to automatically select the depth of instrumentation of your code based on the expected execution frequencies of your code. 

RapiTime includes a Rewind Trace utility, which lets you step through the events that occurred during program execution like you can with a debugger. This lets you set breakpoints and easily analyze the execution of your program.

All RVS tools include a friendly user-interface that presents your data in both tabular and graphical formats. Using this interface, you can filter your results to zoom in on target functions, making it easy to find the information you are looking for.

RapiTime includes charts designed to help you easily understand your data:

• Its Treemaps provide a high-level overview of your code base and help you understand the timing behavior of your code at a glance.
• Its Invocation Timeline and Aggregate Profile Charts let you visualize your results in of your code's call tree, identify the calls with the highest execution times, and investigate specific timing events more easily.

You can view RapiTime and RapiTime^Zero results in continuous integration software, allowing you to track your verification results over time.

All RVS tools include a friendly user-interface that presents your data in both tabular and graphical formats. Using this interface, you can filter your results to zoom in on target functions, making it easy to find the information you are looking for.

RapiTime includes charts designed to help you easily understand your data:

• Its Treemaps provide a high-level overview of your code base and help you understand the timing behavior of your code at a glance.
• Its Invocation Timeline and Aggregate Profile Charts let you visualize your results in of your code's call tree, identify the calls with the highest execution times, and investigate specific timing events more easily.

You can view RapiTime and RapiTime^Zero results in continuous integration software, allowing you to track your verification results over time.

All RVS tools include a friendly user-interface that presents your results in both tabular and graphical formats. Using this interface, you can filter your results to zoom in on target functions, making it easy to find the information you are looking for.

You can view RapiTest, RapiCover and RapiTime results (and results for zero-footprint versions) in continuous integration software, allowing you to track your verification results over time. 

RapiTime abstracts away from the OS tasking model and only reports the execution time of a task as if it were the only thing running on the CPU. If you are interested in the response time of your code, or the interaction between tasks and your OS, you'll need RapiTask.

You can use RapiTask as a standalone tool with either automatic or manual instrumentation.

RapiTask is OS-agnostic so you can keep the same visualization and metrics if you change OS, and you can use RapiTask results as a point of reference to compare operating systems.

Additionally, you can capture and display custom events not related to the operating system (for example ARINC 429 messages) and display them in the trace.

As with all RVS tools, RapiTask supports data collection on multicore architectures. 

RapiTask is a component of Rapita's MACH¹⁷⁸ solution, which analyzes the timing behavior of multicore systems.

RapiTask displays results in two applications, the RVS Project Manager that is shared with all RVS tools, and an application specifically designed to display task scheduling information. You can synchronize the two applications to ensure that you can easily identify specific timing events in your system. 

RapiTask's Invocation Timeline Chart helps you to understand the high-level scheduling behavior of your system at a glance. 

When you run your code on-target, or on-host using a simulator, RapiTime collects and reports on several timing metrics. These include worst-case execution time, the high water mark path, and minimum, average and maximum execution times for each test of your code. 

You can also configure RapiTime to collect additional measurements between any points in your code. This allows you to collect measurements such as response times, periodicity and separation.

The worst-case execution time reported by RapiTime is pessimistic, meaning the actual worst-case execution time of your code could not be higher than that reported by RapiTime. This satisfies the stringent requirements of embedded system certification. 

As with all RVS tools, RapiTime supports data collection on multicore architectures. RapiTime achieves this by suspending data collection during a task interrupt and reinitializing collection when the task on the current core resumes execution. You can also use RapiTime to identify the interference produced by other cores on your system under test.

RapiTime is a key component of Rapita's MACH¹⁷⁸ solution, which supports the analysis of timing behavior for multicore systems.

You can use timing metrics to optimize your code for timing behavior. RapiTime highlights the costliest functions in terms of execution time, guiding you towards the best optimization candidates. By running RapiTime again after you optimize your code, you can determine performance improvements.

RapiTime includes inbuilt functionality to let you determine the execution time overhead of adding instrumentation to your source code. This overhead can then be automatically subtracted from the timing metrics reported by the tool. 

RapiTime is designed to meet the most stringent needs of certification processes, such as the DO-178B/C process used in the aerospace industry and the ISO 26262 process used in the automotive industry. We can provide developer qualification documents, a template integration qualification report and on-site tests to support you in qualifying RapiTime tools in projects requiring certification.

By default, RapiCover supports 30 conditions per decision, and includes support for up to 1000 conditions per decision using an alternate, inbuilt instrumentation strategy.

RapiCover can be configured to collect data in real-time while your software runs. By writing data to an external device, the data will remain in place while your system reboots, and collection can be reinitialized when it restarts. This means that you can collect coverage data across a shutdown or reset sequence. This is subject to your target hardware architecture. 

RapiCover is designed to meet the most stringent needs of certification processes, such as the DO-178B/C process used in the aerospace industry and the ISO 26262 process used in the automotive industry. We can provide developer qualification documents, a template integration qualification report and on-site tests to support you in qualifying RapiCover tools in projects requiring certification.

You can use RapiTest to generate code for testing both high- and low-level requirements, and it supports the generation of tests for various levels and definitions understood in the industry, such as unit, module, integration and system tests.  

RapiTest provides flexibility in test authoring by letting you write tests in one of three formats. These are the RapiTest Editor (an integrated testing interface), spreadsheets, and scripts, with each format having its advantages. You can also convert tests at any time between formats (though you cannot convert test scripts to other formats as they include more complex features). 

RapiTest is customizable to support existing or alternative test formats. If necessary, we can develop a converter for RapiTest to interpret tests written in your existing non-RapiTest format.

The test generation algorithms RapiTest uses are powerful and support generation of all types of stubs used in the industry, including stubs, mocks, fakes, spies and dummies. 

You can include as many tests as you want to in a single build on your target, subject to the resources available on your target and your data collection strategy. As with all our RVS tools, RapiTest has a very low overhead, meaning you can complete your test cycle in fewer builds than using other tools.

RapiTest results are presented in a friendly user-interface. When you run a test, your results are displayed based on just the subprograms you tested, letting you quickly check your results against requirements. 

You can also view RapiTest results in continuous integration software, allowing you to track your verification process over time. 

RapiTest is designed to meet the most stringent needs of certification processes, such as the DO-178B/C process used in the aerospace industry and the ISO 26262 process used in the automotive industry. We can provide developer qualification documents, a template integration qualification report and on-site tests to support you in qualifying RapiTest in projects requiring certification.

RapiCover supports C, C++ and Ada projects, including mixed-language ones.

RapiTime supports C, C++ and Ada projects, including mixed-language ones.

RapiTest supports C, C++ and Ada projects, including mixed-language ones.

RVS supports C, C++ and Ada projects, including mixed-language ones.

RapiTask can be integrated to work with almost any compiler and target hardware. Our integration service promises to deliver a robust integration of RapiTask into your build system.

RapiTime can be integrated to work with almost any compiler and target hardware. Our integration service promises to deliver a robust integration of RapiTime into your build system.

RapiTest can be integrated to work with almost any compiler and target hardware. Our integration service promises to deliver a robust integration of RapiTest into your build system.

RapiCover can be integrated to work with almost any compiler and target hardware. Our integration service promises to deliver a robust integration of RapiCover into your build system.

RVS tools can be integrated to work with almost any embedded target. Our engineers can work with you to determine the optimal strategy for integrating the tool with your target, even for multi-core architectures. For more information on the hardware architectures we have integrated RVS tools with, see the compatibility information on our RVS product pages.

RVS tools can be integrated to work with almost any embedded target. Our engineers can work with you to determine the optimal strategy for integrating the tool with your target, even for multi-core architectures. For more information on the hardware architectures we have integrated RVS tools with, see the compatibility information on our RVS product pages.

RVS tools can be integrated to work with almost any embedded target. Our engineers can work with you to determine the optimal strategy for integrating the tool with your target, even for multi-core architectures. For more information on the hardware architectures we have integrated RVS tools with, see the compatibility information on our RVS product pages.

RVS tools can be integrated to work with almost any embedded target. Our engineers can work with you to determine the optimal strategy for integrating the tool with your target, even for multi-core architectures. For more information on the hardware architectures we have integrated RVS tools with, see the compatibility information on our RVS product pages.

RVS tools can be integrated to work with almost any embedded target. Our engineers can work with you to determine the optimal strategy for integrating the tool with your target, even for multi-core architectures. For more information on the hardware architectures we have integrated RVS tools with, see the compatibility information on our RVS product pages.

All RVS tools can be integrated to work with almost any compiler and target hardware. Our integration service promises to deliver a robust integration of RVS into your build system.

RVS tools can be run on the following x86-64 operating systems:

• Windows 10 and 11
• Windows Server 2019+
• Variety of Linux distributions (including Ubuntu and Red Hat)

RVS tools can be used on projects with unsupported operating systems by using a clone integration to split the process and delegate parts of it to the unsupported machine.

RVS tools can be run on the following x86-64 operating systems:

• Windows 10 and 11
• Windows Server 2019+
• Variety of Linux distributions (including Ubuntu and Red Hat)

RVS tools can be used on projects with unsupported operating systems by using a clone integration to split the process and delegate parts of it to the unsupported machine.

RVS tools can be run on the following x86-64 operating systems:

• Windows 10 and 11
• Windows Server 2019+
• Variety of Linux distributions (including Ubuntu and Red Hat)

RVS tools can be used on projects with unsupported operating systems by using a clone integration to split the process and delegate parts of it to the unsupported machine.

RVS tools can be run on the following x86-64 operating systems:

• Windows 10 and 11
• Windows Server 2019+
• Variety of Linux distributions (including Ubuntu and Red Hat)

RVS tools can be used on projects with unsupported operating systems by using a clone integration to split the process and delegate parts of it to the unsupported machine.

RVS tools can be run on the following x86-64 operating systems:

• Windows 10 and 11
• Windows Server 2019+
• Variety of Linux distributions (including Ubuntu and Red Hat)

RVS tools can be used on projects with unsupported operating systems by using a clone integration to split the process and delegate parts of it to the unsupported machine.

The instrumentation overheads for RVS tools are the lowest in the market, and the tools can support zero-instrumentation overhead in some cases. Because of this, RVS can generate verification data from your source code in fewer builds than possible using other tools. For example, in a recent customer evaluation, RapiCover instrumentation overhead was 4 to 5 times lower than competitor tools, leading to a 92% reduction in the number of builds necessary to test the code base. If necessary, you can configure RVS tools to instrument your code in multiple builds and compile collected data into a single report. 

All our RVS tools are designed to meet the most stringent needs of certification processes, such as the DO-178B/C process used in the aerospace industry and the ISO 26262 process used in the automotive industry. We can provide developer qualification documents, a template integration qualification report and on-site tests to support you in qualifying RVS tools in projects requiring certification.

All RVS tools support numerous data collection strategies, which are optimized to achieve a minimal instrumentation overhead. You can collect data using debuggers, logic analyzers, directly from the address bus, or using our datalogger, RTBx. By working with you to determine the optimal data collection strategy, we can together ensure that you achieve results with minimal effort.

The design requirements of all RVS tools include the ability to work alongside your existing development environment. You can configure these tools to generate verification metrics and run tests using custom scripts, and can integrate the tools into your existing version control and continuous build systems. 

All RVS tools can be run from the command line, supporting your automation workflow.  

You can request a trial version of RVS. You can also arrange a demonstration, where a member of our team will work with you to show the benefits RVS can offer you.

We have been providing state-of-the-art verification solutions to companies in the aerospace, automotive, and space software industries since 2004, as demonstrated by our case studies.

As our products are designed to meet the stringent requirements for DO-178C certification in the aerospace industry, they are well-suited for use to verify any mission or safety-critical applications, such as those developed in the nuclear, medical, industrial and rail industries.

RVS works by combining static and dynamic analyses of software execution to gain an understanding of the software architecture. Using this understanding, RVS injects and/or instruments code to perform a variety of functions including generating and running functional test harnesses, analyzing the structural coverage achieved during functional testing, and analyzing the timing behavior of code being executed.

By integrating into the existing development environment and continuous build servers, RVS reduces the cost of software verification. The flexible nature of RVS integrations and its extremely low instrumentation overheads support its use on even the most complex systems, including multicore systems.

RapiTask provides an RTOS-independent tool for visualization and exploring the scheduling behavior of embedded systems, and rapidly diagnosing and identifying potential problems.

It lets you visualize scheduling behavior across threads and processor cores, and reports response times from your system.

RapiTime works by injecting instrumentation code into source code and executing the native build system so that timing results are collected during program execution. Data can be collected from almost any target hardware by a variety of approaches.

RapiTest works by using input tests in a variety of formats and an understanding of the program structure achieved through dynamic analysis to produce test harnesses that it executes on the native build system to collect test results. When collecting data from hardware targets, data can be collected from almost any target hardware by a variety of approaches.

RapiCover works by injecting instrumentation code into source code and executing the native build system so that coverage results are collected during program execution. Data can be collected from almost any target hardware by a variety of approaches.

RapiTask is the leading tool for task-level scheduling analysis of critical software.

Used globally in the aerospace and automotive industries, it reduces the cost of understanding software scheduling behavior and troubleshooting scheduling issues.

As part of the RVS toolsuite, it forms part of a software verification solution that also includes tools for functional testing, structural coverage analysis and worst-case execution time analysis. 

RapiTest is the leading tool for functional testing of critical software.

Used globally in the aerospace and automotive industries, it reduces the cost of functional testing at all levels, including system, integration and unit testing. 

As part of the RVS toolsuite, it forms part of a software verification solution that also includes tools for structural coverage analysis and worst-case execution time analysis. 

RapiTime is the leading tool for worst-case execution time analysis of critical software.

Used globally in the aerospace and automotive industries, it reduces the cost of analyzing the worst-case timing behavior of critical software.

As part of the RVS toolsuite, it forms part of a software verification solution that also includes tools for functional testing and structural coverage analysis. 

RapiCover is the leading tool for structural code coverage analysis of critical software.

Used globally in the aerospace and automotive industries, it reduces the cost of analyzing structural code coverage analysis up to and including MC/DC.

As part of the RVS toolsuite, it forms part of a software verification solution that also includes tools for functional testing and worst-case execution time analysis. 

RVS is the leading toolsuite for the verification of critical software.

Used globally in the aerospace and automotive industries, it includes tools for functional and requirements-based testing, timing analysis including worst-case execution time analysis, and structural code coverage analysis. 

You can request a trial version of RVS, which includes RapiTime. You can also arrange a demonstration, where a member of our team will work with you to show the benefits RapiTime can offer you.

If you're interested in RapiTime in academia, you can search for it in the academic press. 

You can request a trial version of RVS, which includes RapiCover. You can also arrange a demonstration, where a member of our team will work with you to show the benefits RapiCover can offer you.

If you're interested in RapiCover in academia, you can search for it in the academic press. 

You can request a trial version of RVS, which includes RapiTask. You can also arrange a demonstration, where a member of our team will work with you to show the benefits RapiTask can offer you.

If you’re interested in RapiTask in academia, you can search for it in the academic press.

We’ve described this in our Tool Qualification Product Briefs.

RapiTask supports C, C++ and Ada projects, including mixed-language ones.

You have three options. You could:

• Purchase two node-locked licenses, one for your office computer and one for the lab computer.
• Purchase a floating license with one core license and the plugin licenses you require. By doing so, you can use RVS on your office computer and in the lab, but not at the same time.
• Purchase a node-locked license configured to a USB license key, and move it between the office and the lab.

Annual RVS licenses include support and maintenance for the full duration of the license period.

Perpetual RVS licenses include support and maintenance for the first year. After this, you can purchase a Rapita support and maintenance contract to cover one or more years of additional support. You can purchase this support in advance to ensure that your products are covered. As long as your license is covered by a support and maintenance contract, you can access the latest version of RVS, all bug fixes and the Rapita support team.

Yes. We’ll continue to use USB license keys for customers with older versions of RVS (both floating and node-locked). You can also upgrade to our file license system for use with your legacy version of RVS, or purchase the latest version of the RVS software, which includes built-in support for using file licenses.

We provide additional support for using RLM licensing with legacy versions of RVS. This may involve patching your RVS software to support RLM (note that this change can be implemented without affecting your RVS qualification).

More detailed guidance is included in the RVS Installation and Licensing Guide, which is provided with the RVS software. You can also contact us at any time if you’re unsure how to proceed, or need any advice or assistance.

Note that upgrading to the latest version of RVS is the best way to access the benefits of RLM licensing.

You have several options for managing third-party use of our software. You can:

• Configure your license server to allow the contractor to access the licenses they need for a limited time.
• Provide the contractor with access to an on-site machine that has a node-locked license.
• Provide the contractor with a node-locked license tied to a USB license key, which they must return when their contract ends.
• Purchase a new annual license for the contractor to use, with an end date that aligns with the end of their contract.

Contact us to discuss these options – we’re happy to arrange a solution that will best meet your needs.

Yes, but not concurrently. With a node-locked license, multiple people can use a single license on a single machine, but not at the same time. With a node-locked license, you cannot install RVS on shared-user machines, thin clients, systems that use remote desktop, or servers, nor can you use it in continuous
integration environments. If you want to use RVS in these systems or environments, you can use a floating license, which you can upgrade to at any time.

You can check the status of your license server(s) in the RVS License Manager. You can also generate reports showing active users using the command line. More detailed guidance is provided in the RVS Installation and Licensing Guide, which is included with the RVS software.

You can set up license groups by editing the options file (e.g. rapita.opt) that accompanies your file license. This lets you define user groups, and reserve licenses for specific groups or users. Detailed instructions are provided in the RVS Installation and Licensing Guide, which is included with the RVS software.

Requirements: You can only configure license groups if you install the generic RLM license server, which can only be used with RVS version 3.8a or later. If you have a legacy version of RVS (version 3.8 or earlier), you’ll need further support to configure license groups. Contact us and we’ll talk you through
the details.

Yes. You can restrict access to floating licenses to specific users.

According to your requirements, you can set up pools or ‘groups’ of licenses for various types of users. For example, you can reserve licenses for specific departments, sites, projects, teams within a project or users within a team. Each license reserved for each group can be configured with different start
and end dates, helping you control who is using the software and when. By doing so, you can ensure that high-priority users can always access the licenses they require, and other users can’t access licenses they don’t need or shouldn’t be using after a certain date.

Yes. You can add RVS licenses to your existing RLM license server.

Requirements: You can only use the generic RLM license server with RVS versions 3.8a or later. If you have a legacy version of RVS (version 3.8 or earlier), you’ll need a patch to support RLM. More detail is provided in the Installation and Licensing Guide, which is included with the RVS software.

Contact us for more information.

If you have a floating license, you will need a license server. We provide you with license server software (either Windows or Linux versions) with your RVS software.

Contact us to upgrade your license. When your license is upgraded, we send you an updated file license with the new details. After the file license is installed and active, the old one is no longer usable.

If you are using a USB license key, you may need to generate a key information file and send this to us. We then supply you with an updated file, which you use to upgrade your license. More detailed guidance is included in the RVS Installation and Licensing Guide, which is provided with the RVS software.

Contact us to start the renewal process. When your license is renewed, we send you an updated file license with the new details. After the file license is installed and active, the old one is no longer usable.

If you are using a USB license key, you may need to generate a key information file and send this to us. We then supply you with an updated file, which you use to renew your license. More detailed guidance is included in the RVS Installation and
Licensing Guide, which is provided with the RVS software.

If one or more of the licenses you need has expired, you will be unable to run RVS. Make sure you renew your licenses before they expire. Contact us to renew your licenses.

You can check your licensing information, including expiry dates, in the RVS License Manager application and/or in your license file. If your license is due to expire, contact us to start the renewal process.

You can find out the types of licenses you have using the RVS License Manager application, which is included with the RVS software. You can also view the numbers and expiration dates of your core and plugin licenses.

Contact us and we’ll be happy to help.

Yes. You can convert your annual license to a perpetual license at any time while your license is active. Converting a license from annual to perpetual incurs a small fee, and requires the purchase of a support and maintenance contract with a duration of at least 1 year.

Annual licenses let you use RVS for a number of annual periods. This is useful for projects with short durations.

Perpetual licenses let you use RVS indefinitely. This supports the use of RVS in projects with long life cycles, such as those common in the aerospace domain.

Depending on your system and environment, you may require a USB license key as well as a license file.

We will let you know if this is the case, and provide you with everything you need to install and manage your USB license key.

Older versions of RVS (up to version 3.8) may be licensed with USB license keys.

Key elements in our file licenses (including the host ID, license numbers, and start and end dates) are signature-protected, and are unable to be changed by anyone outside of Rapita Systems. If any signature-protected part of a file license is edited, the license is automatically invalidated.

Our licensing system is based on Reprise License Manager (RLM). Licenses are provided as file licenses, which are configured with the required numbers of core and plugin licences. In a floating license configuration, the file license is locked to the license server’s host ID. In a node-locked configuration, the file license is locked to the machine’s host ID.

We work with you to find the licensing solution that best suits your needs.

Depending on your organization or project, you may need more than one license configuration.

For example, you may need a floating license that can be used by multiple project participants, and with licenses allocated to certain users or groups. You may also benefit from one or more node-locked licenses that can be used at a specific location. Contact us, and we’ll be happy to talk you through your options in more detail.

Yes. You can upgrade node-locked licenses to floating licenses for a fee. Contact us at any time, and we’ll arrange this.

Yes. Contact us and we’ll discuss this process with you.

Generally, a node-locked license cannot be used on shared-user machines, thin clients, or systems that use remote desktop or servers. You cannot use a node-locked license in a continuous integration environment.

Contact us if you need more information on node-locked licenses.

Floating licenses can be used anywhere within a country or geographical region, as agreed prior to the license being issued.

A floating license lets multiple people within an organization use RVS in a shared environment. 

Floating licenses work running an RVS License Server on a networked machine accessible by all computers that have RVS installed.

Access to floating licenses is managed by TCP/IP connection to license server software, which we provide for you to install on a Windows or Linux server.

When a user runs RVS, a core license token and the relevant plugin license tokens are requested from the license server. When the user stops using RVS, the tokens are returned to the server. After being returned to the server, a license token is held in a checked-out state for a specified ‘linger time’ (the default linger time is 10 minutes).

If one or more of the required license tokens aren’t available, either because they are in use or in ‘check-out’ time, the user won’t be able to run RVS.

RVS core licenses provide a set of common tools and are required to run any RVS product. RVS plugin licenses are required to run specific products (RapiTest, RapiCover, RapiTime, RapiTask, or any other Rapita tool). When you purchase RVS, you receive one or more RVS core licenses, and one or more plugin licenses depending on your requirements.

We supply standard data cables, an adapter, and flying leads to connect RTBx to LVDS or TTL I/O ports. If your target hardware uses non-standard pins or electrical signalling, we provide advice on the best way to connect RTBx to your target, and can develop high performance custom cables to meet your needs.

Yes. We develop and test RapiDaemons against appropriate requirements, e.g. RapiDaemon M should access resource R when run N times.

RTOS vendors may provide partitioning mechanisms for their multicore processors, but these do not guarantee the complete elimination of multicore interference. Instead, they are designed to provide an upper limit on interference, sometimes at the expense of average-case performance.

In aerospace, these partitioning mechanisms may be referred to as ‘robust partitioning’. The multicore guidance in AC 20-193, AMC 20-193 and CAST-32A identify allowances for some of the objectives if you have robust partitioning in place, but it is still necessary to verify that the partitioning is as robust as it is claimed to be.

From a certification standpoint, regardless of the methodology behind the RTOS vendor’s approach to eliminating interference, the effectiveness of the technology needs to be verified.

Before timing analysis can begin, it is essential to confirm that existing RapiDaemons operate as intended on a specific board. If they do not, it may be necessary to customize them to make them behave as they are designed to (a similar intention to a target integration, where we get the instrumented application software running on a specific target).

'Porting’ and ‘configuration’ of RapiDaemons are roughly equivalent terms in this context. For RapiDaemons to work as intended, they need to go through a configuration phase where their internal parameters are tuned as required. They’re then tested to ensure compatibility with the platform in question.

Each type of RapiDaemon may be implemented for a different instruction-set architecture and platform. While the main logic behind their behavior remains the same, they must be ported to execute correctly on each new platform.

A RapiDaemon is an application designed to create contention in a predictable and controlled manner on a specific shared resource in a multicore system. The effect of this contention can then be measured to identify interference channels and impacts on execution times.

Rapita have developed and optimized a set of standard RapiDaemons that target shared resources common to most multicore architectures, such as main memory. Some projects will require the creation of custom RapiDaemons for a specific architecture.

Yes. Our solution can be used to produce timing evidence needed to satisfy DO-178C objectives (in line with AC 20-193, AMC 20-193 and CAST-32A guidance), and ISO 26262 standards.

We offer tool qualification support for DO-178B, DO-178C, DO-278A and ISO 26262 safety standards.

Tool qualification provides evidence that the software you’re using doesn’t introduce or fail to detect errors in your software when it is being used within your project. If you’re working in the context of safety standards such as DO-178 or ISO 26262, you need to provide this evidence if the tool you’re using automates or replaces a manual process and you aren't manually reviewing output from the tool.

We’ll run the bug through our usual problem reporting, triage and assurance issue analysis processes. If you cannot use a workaround, we can provide add-on fixes or new wavefront versions of the tool that fix your issue, depending on your needs.

We regularly announce tool bugs that could affect existing integrations, when those bugs affect the assurance of the tool output. This includes false positives, missed code constructs (for coverage analysis) and unwanted functional changes to the software under test. We provide advice, workarounds and fix schedules for all assurance issues that we publish this way.

Decision coverage and branch coverage are closely-related forms of structural coverage analysis. Decision coverage is referenced by DO-178B/DO-178C whereas branch coverage is referenced by ISO 26262. Branch coverage requires every exit from a conditional source code statement to be executed. Thus, for an if statement, branch coverage requires the then part and the else part to be executed (if there is no else part, the if statement should still execute the decision as true and false). For decision coverage, the DO-178B/DO-178C definition of decision covers conditional statements, in the same way as branch coverage, but it also includes assignments of Boolean variables, for example:

a := b or (c and d); (Ada)
a = b || (c && d); (C/C++)

In this case, decision coverage would require tests for the above assignment making a both true and false.

Moreover, given the same source code and tests to exercise it, the percentage of coverage reported may be different between branch and decision coverage. For example, if 3 out of the 4 branches of a switch statement are executed, the branch coverage would be reported as 75%, but for decision coverage, a decision is considered covered only if all its branches are covered, so the coverage of the switch statement would be reported as 0%.

Find out more about structural coverage in our white paper.

The RTBx automatically timestamps data it collects, using either an internal clock or that on embedded hardware. This removes the need to configure a timestamping procedure on the embedded target itself, which would incur code size and execution time overheads.

Compared to other hardware that can be used for timestamping such as debuggers and logic analyzers, the RTBx can collect trace data for far longer, meaning that it doesn't become a bottleneck in your testing.

This is the maximum tracing rate that can be sustained over time, calculated from the number of ipoints the RTBx can process per second. The RTBx can support a higher tracing rate for short periods of time, provided that the minimum separation between instrumentation points is met.

This depends on the number of CPU cycles it takes to output successive ipoints, and the rate ipoints are written at. For example, RTBx 2220 can collect trace data via an I/O port with a minimum separation of 4 ns (250 MHz). This model can therefore support a 1 GHz CPU that outputs trace data once every 4 cycles. 

You can connect RTBx to an address bus that runs at up to 250 MHz. To do this, you must reserve a range of addresses for ipoints, with one bit reserved to indicate that the value on the address bus is an ipoint. The ipoint instrumentation writes a value to a specific address in that region to denote a specific ipoint. This approach reduces the maximum trace duration of the RTBx.

Tracing is a specialized use of logging to record information about a program’s execution. It is typically used by programmers for debugging purposes. A trace captures every single instance at which an instrumentation point is executed during operation. For example, if you’re using RapiTime, you need need to use a trace. Each time an instrumentation point is executed, a trace entry is generated containing the instrumentation point ID and a timestamp. The length of the trace depends upon the number of instrumentation points in your code and also on the length of the tests. The trace data can be stored on the target if there’s enough free memory, or output to an external capture device, for example an RTBx. A map captures whether an instrumentation point is executed or not. For instance, if you’re using RapiCover, you can use a map, which stores coverage data in a fixed-size area of memory. The size of the map depends on the number of instrumentation points in your code, not on the length or number of tests.

Static stack analysis involves examining every instruction in the compiled object code to see where stack pointer(s) are adjusted and by how much. Following calls through pointers is not possible without additional information (which is usually supplied manually).

DO-178B, also known as ED-12B, is the worldwide avionics guidance with which all airborne software is required to comply. It is recognized as "acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment certification." DO-178B has been superseded by DO-178C. See also: What is the difference between DO-178B and DO-178C

ED-12B is the EUROCAE release of DO-178B (“Software Considerations in Airborne Systems and Equipment Certification”), the worldwide de-facto standard for developing avionics software. ED-12B has been superseded by ED-12C (DO-178C). EUROCAE and RTCA jointly contributed to ED-12C/DO-178C, hence the joint designation.

ED-12C is the EUROCAE release of DO-178C (“Software Considerations in Airborne Systems and Equipment Certification”), the worldwide de-facto standard for developing avionics software. EUROCAE and RTCA jointly contributed to ED-12C/DO-178C, hence the joint designation. ED-12C is an update to ED-12B.

Learn more about DO-178C here.

Code coverage (which is also known as “structural coverage analysis”) is a measure used to describe the degree to which the source code of a program is tested by a particular test suite. Structural coverage analysis is an important verification tool for establishing the completeness of testing. The DO-178B/C standard emphasizes the use of requirements-based testing as an important part of the software verification process. In requirements-based testing, the high and low-level requirements are used to derive source code and the tests for that source code. Measuring code coverage when the test cases are executed is essential for this process – where coverage is less than 100%, this points to code that is not traceable to requirements, tests or both.

To achieve statement coverage, it is necessary for each statement in the source code to have been executed by at least one test in the test suite. If a particular statement cannot be covered it is important to identify why. This may reveal dead code, for example, or it may be code that cannot be traced to a requirement or architectural structure. Statement coverage is particularly useful for dealing with loops and returns.

According to DO-178B/DO-178C, to achieve decision coverage, the typical criterion is that every decision in the source code must be shown to produce both a true outcome and a false outcome, and that execution has reached every point of entry and exit in the code. This means that decision coverage criteria assess the ability of a set of tests to adequately exercise the routes through the logic of a program. CAST-10 provides specific elaboration of the meaning of decisions within decision coverage.

DO-178C, also known as ED-12C, is an update to the DO-178B guidance that governs the certification of software for airborne systems in commercial aircraft. It has replaced DO-178B as the primary document by which the certification authorities such as FAA and EASA will approve all commercial software-based aerospace systems.

Branch coverage is a testing method which aims to ensure that each one of the possible branch from each decision point is executed at least once and thereby ensuring that all reachable code is executed. That is, every branch taken each way, true and false. ISO 26262 recommends or highly recommends the use of branch coverage.

Modified Condition/Decision Coverage (MC/DC) is a code coverage approach, required by DO-178B/C guidelines to ensure that Level A software is tested adequately. It is an extension of decision coverage; instead of just examining the outcome of each decision, the coverage check also shows that for each condition in the source code, that condition has resulted in each possible outcome (true, false) at least once, and also that each condition in a decision has been shown to independently affect that decision’s outcome.

A condition is a Boolean expression that contains no Boolean operators. Examples of conditions are: “true”, “iterations > 5” or the name of a Boolean variable, such as “MaintenanceMode”. If the same Boolean expression is repeated several times, each specific instance is a different condition.

The Certification Authorities Software Team (CAST) issue guidance on various issues regarding the interpretation of DO-178B and DO-178C. In the CAST 10 paper, they discuss the interpretation of a “decision”. Three possible interpretations are made. The first is a “literal” interpretation of DO-178B, namely a Boolean expression composed of conditions and zero or more Boolean operators.The second is a “relaxed” interpretation of DO-178B, namely a decision is equivalent to a branch. The third is an intermediate position, where the literal interpretation applies to MC/DC, and the relaxed interpretation applies to branch coverage. Our coverage tool, RapiCover, supports both interpretations to provide maximum flexibility.

Worst-case execution time (WCET) is a recommended activity for avionics systems developed according to the DO-178B or DO-178C guidelines. The worst-case execution time of a computational task is the maximum length of time the task could take to execute on a specific hardware platform. This excludes any time spent executing other tasks or interrupts.

Dynamic stack analysis involves tracking the stack usage as code is executed. This is particularly useful for tracking the behaviour of indirect calls (such as function pointers).

The key principle behind testing an application on-target is that code is executed in the environment for which it was designed, rather than in an environment where it was never intended to be executed. Test results are typically evaluated and analysed on a host.

On-host testing involves compiling the application code to run on the host processor, rather than the target processor. Typically, the application also requires a certain amount of adaptation to work in the host environment.

Coverage holes are small sections of untested code within a large codebase. They are the sections of code that have not been tested by the test suite. Depending upon the level of coverage being analysed, coverage holes could be untested functions, calls, statements, decisions, branches, MC/DC decisions, or MC/DC conditions. The benefit of using a coverage tool such as RapiCover is to identify coverage holes and clearly display their location within a large codebase.

In requirements-based testing, the high and low-level requirements are used to derive source code and the tests for that source code. Traceability between the requirements, the test cases and the source code demonstrates that every requirement has a test case and all source code is traceable to a requirement. Measuring code coverage when the test cases are executed is essential for this process; where coverage is less than 100%, this points to code that is traceable to requirements, tests or both.