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.

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.

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.

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 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. 

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 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.

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. 

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.

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 measure function, call, statement, branch and decision coverage using RapiCover^Zero.

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.

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.

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 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.

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

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. 

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.

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.

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.

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.

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.

Check PSP compatibility

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.

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 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.  

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 NPR 7150.2D and ECSS-E-ST-40C projects. For ECSS-E-ST-40C, coverage analysis profiles are available based on verification requirements for software Criticality Category.

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 NPR 7150.2D, 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)

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.

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.