How does RapiCover work?
Resource Limitations of the Embedded System
One of the key challenges to on-target code coverage is resource limitations in embedded systems. The commonly-adapted approach to measuring coverage is to instrument source code to write into a memory buffer. Because the exact nature of the resource constraints varies between systems, this is not always the best approach. Data areas might be limited or code size constrained. On other systems high CPU utilization might limit what could be achieved.
RapiCover was designed from inception to recognize these limitations can exist, and to provide a viable route to dealing with them. There are many solutions available including the following:
- Alternative data collection In many cases, using an array of Booleans to represent whether a specific instrumentation point has been executed or not will be feasible. However, when there is not enough room to store this data structure, or if the execution overhead of this approach is too high, alternative approaches need to be available. One such approach involves recording a trace of instrumentation points via an I/O port. This avoids the need for a large area of memory and simultaneously makes instrumentation overheads very low, typically 1-2 machine instructions. Advanced debuggers (e.g. Nexus or ARM ETM-based tracing debuggers) can also be used to collect data.
- Partial instrumentation Rather than completely instrumenting an application, instrument specific parts of it, perform the tests and combine the results to provide an overall picture.
- Optimized instrumentation Measuring certain types of coverage, for example MC/DC, can require significant memory overheads. Instrumenting an embedded system for coverage requires knowledge of how instrumentation is carried out. Once set up, there are opportunities to make trade-offs between exactly how the level of coverage is achieved, and the amount of instrumentation required.
Code Coverage and Certification
If evidence of code coverage is mandatory for the project, for example because the customer requires strict adherence to DO-178B/C guidance, it’s also important to be able to provide evidence that the process used to collect the data has worked correctly.
RapiCover is supported through qualification. For more information on this subject please visit the qualification page.
The evidence must show that the tool works correctly within the context of the development environment for which it is producing results. In the case of DO-178B, recommendations for tool qualification are given.
You can find more detailed information on DO-178B/C or ISO 26262 certification, including the DO-178B recommendations for tool qualification in the whitepaper Six top code coverage questions in embedded avionics systems.
Additional Benefits from Measuring On-Target
When you instrument source code to run on your embedded target, you are opening the door to collecting other information besides simply code coverage. For example, if you collect a trace (i.e. recording the sequence of instrumentation points that are executed), it’s possible to identify which test cases execute specific execution paths. Using the traces, it is possible to step through the code forwards and backwards. If a trace also records the specific time at which instrumentation points are executed, it is possible to determine timing information. For example, RapiTime uses such information to provide a wide range of timing measurements that can be used for:
- Execution time measurement
- Worst-case execution time (WCET) calculation
- Performance optimization