Covering Industry Standards

Each industry has its own requirements, which are defined in industry-specific standards. Although each standard is different, they all require requirements‑based testing and structural coverage.

 
 
 

Requirements-based testing can provide the evidence for the correctness of your code. Code coverage serves as a measure for the completeness of the test activities. Coverage is measured by recording which parts of your source code are executed by each test case.

Industry Standards

It can be hard to keep track of all the different standards. But thanks to our long experience in the field of software development based on these standards, we can offer the right approach for each of them. Our solution is tailored for your needs. We support compliance across industries such as automotive, aerospace, healthcare or any other sector.

Industrial (IEC 61508:2010)

IEC 61508 is the international industry standard governing functional safety of programmable electronic systems. IEC 61508 certification confirms that a product or system complies with objectives set by the standard. IEC 61508 is comprised of seven (7) parts. In “Part 3: Software requirements” (IEC 61508-3), the document defines software requirements and sets the safety lifecycle for software, including validation and verification. The safety lifecycle begins with a risk analysis to determine the Safety Integrity Level (SIL) required. IEC 61508-3 highly recommends certified tools and translators for safety integrity levels of SIL-2 and higher.

Medical (IEC 62304)

The International Electrotechnical Commission created the IEC 62304 standard. The standard, formulated to govern the requirements for medical software, describes the process that medical software must go through in order to be approved for use in Europe. The standard includes guidelines for testing any software components that are part of a medical device.

Aerospace (RTCA/DO-178C)

The DO-178C, Software Considerations in Airborne Systems and Equipment Certification, has been published jointly by the RTCA and the EUROCAE. For certification authorities, it is the main document for approving commercial software-based aerospace systems. The current version is available since 2012 and has replaced the DO-178B, which was the leading document in the field for twenty years.

The DO-178C is based on objectives that must be achieved with the processes and activities of the corresponding project. The strictness of these objectives is determined by the Data Assurance Level (DAL), which is defined from A (most stringent requirements) to D (lowest requirements). The core of the development process is a requirements-based approach, based on High-Level and Low-Level Requirements, with full bi-directional traceability to source code, executable object code, and test cases, procedures, and results.

Railway (EN 50128:2011 and EN 50657:2017)

The European Standards EN 50128:2011 and EN 50657:2017 provide a process framework and a procedural model for the development and test of safety critical electronic systems in railway systems. It is a derivative of the International Electronic Commission document, IEC 61508 adapted for the challenges met in railway systems.

Automotive (ISO 26262:2018)

First published in 2011, the ISO 26262 is the international standard for functional safety of electrical and/or electronical systems, which are installed in serial production road vehicles. Since the release of the second edition in December 2018, this includes cars, trucks, busses, vocational vehicles and motorcycles (not mopeds). It is derived from the standard for functional safety in industrial applications, the IEC 61508. And, like the IEC 61508 the ISO 26262 is a risk-based standard. In contrast to cybersecurity, functional safety is about protecting the environment and people in it from negative effects caused by malfunctions of the system being developed. The starting point for each development project is the Hazard Analysis and Risk Assessment (HARA), which can lead to the definition of safety-relevant functions with an Automotive Safety Integrity Level (ASIL), reaching from A (low residual risk) to D (high residual risk). Based on the ASIL more requirements must be fulfilled and more methods are recommended to be applied.

Requirements Coverage

All the standards listed on this page put emphasis on requirements-based testing. Testing against requirements is widely considered to be the best way to find defects. This includes the testing of equivalence classes, boundary cases and behavior in cases of abnormal inputs. 

Requirements coverage provides evidence for the correctness of the tested code or software

By measuring the structural coverage using requirements-based tests the absence of undesired functionalities, undesired properties and unintended behavior can be demonstrated

Full Coverage

For full coverage, each requirement must be fully verified individually, and all requirements must be covered together. For individual coverage, VectorCAST can import your requirements using the Requirements Gateway. This gateway works in both directions. The imported requirements can be linked to test cases and VectorCAST can export the linkage together with the corresponding tests results. This way, you always have a complete overview of the tests and results directly at the linked requirements. 

Monitor Completeness

To monitor completeness, Squore always offers you the whole picture. It not only shows the requirements that are covered, but it also makes it easy to find those requirements where coverage is still incomplete. Squore also shows you the test cases that are not linked to requirements and keeps track of the coverage achieved.

Structural Coverage

All the standards listed above incorporate one or more of the following structural coverage types, ensuring save and comprehensive testing:

Statement Coverage:
Ensures that each line of code or statement in the software has been executed at least once.

Branch Coverage:
Determines if each branch point (e.g., if-else statements) has taken each possible outcome at least once.

MC/DC: (Modified Condition Decision Coverage):
Ensures that each component of a condition can independently affect the outcome. It's a more comprehensive form of Branch Coverage.

Function Coverage:
Indicates whether a specific function in the code has been called.

Function Call Coverage:
Identifies all the calls that can be made from a function and whether those calls have been tested.

MC/DC in Safety Critical Software

Modified Condition/Decision Coverage (MC/DC) is one of the highest‑integrity code coverage criteria used in safety‑critical software development. It ensures that every individual Boolean condition in a decision is proven to independently affect the outcome, a level of precision required by standards such as DO‑178C Level A, ISO 26262 ASIL D, IEC 62304 Class C, and EN 50128 SIL4.

MC/DC exposes logical flaws that simpler coverage metrics like statement or branch coverage cannot detect. By requiring each condition to vary independently, it ensures:

  • Full visibility into decision logic
  • Detection of hidden or untested conditions
  • Maximum confidence in safety‑critical behavior

It delivers deep structural assurance while keeping the number of required test cases manageable. This makes MC/DC essential wherever software failure is not an option.

The Challenges of Achieving MC/DC

Achieving full Modified Condition/Decision Coverage (MC/DC) is essential for safety‑critical software, but doing it correctly and efficiently is far from trivial. Each of the following challenges is common in real-world embedded development and significantly increases the effort and risk when working without a specialized toolchain.

Complex Boolean Logic Requires Careful Test Design

Real-world decision logic often includes multiple Boolean conditions, nested expressions, and intermediate variables. Designing tests that demonstrate each condition’s independent influence becomes exponentially harder as the number of conditions grows.

  • A simple if (a && b && c) already requires multiple carefully paired test cases.
  • Nested and chained expressions (a && (b || c) && d) increase complexity further.
  • Manual reasoning about which variable to hold constant while another varies becomes error-prone.

 

Without automation, teams frequently miss valid MC/DC pairs, leading to incomplete coverage or the illusion of completeness.

Short Circuit Evaluation Can Hide Condition Behavior

Programming languages like C and C++ use short‑circuit evaluation:

  • In a && b, if a is false, b may never be evaluated.
  • In a || b, if a is true, b may be skipped.

 

This creates several problems:

  • Teams may create test cases assuming all conditions were evaluated, even when they weren’t.
  • Coverage tools not aware of runtime behavior may show misleading results.
  • Developers must design tests to force evaluation of each condition, which is difficult to do manually.

 

Correct MC/DC requires tracking actual evaluations at runtime, not just static paths.

Hidden Decisions Can Go Undetected

Not all decisions are visible at first glance. Examples:

  • Conditions stored in intermediate variables:
    >
    > bool ready = (sensorOk && calibrationPassed);
    >
    > if (ready && overrideEnabled)
    > { … }
     
  • Conditions embedded in helper functions.
  • Compound assignments:
    > flag |= (x > 5);

 

These hidden decisions must also be proven to independently influence outcomes. But identifying them manually requires deep code inspection, which does not scale in large codebases.

Test Suites Become Hard to Maintain Over Time

MC/DC test suites must be precise and minimal, but still complete. As code evolves:

  • A small change in a condition often invalidates multiple MC/DC pairs.
  • A new branch or condition may require several new tests.
  • Old tests may no longer provide required independence.

 

Maintaining these relationships by hand is extremely time‑consuming. Most teams either overshoot (too many redundant tests) or undershoot (missing MC/DC pairs).

Code Changes Frequently Invalidate Coverage

MC/DC is sensitive to even minor code modifications:

  • Renaming a variable
  • Splitting a Boolean expression
  • Adding a new configuration flag
  • Refactoring into intermediate variables

 

Even if the logic is functionally unchanged, MC/DC pair relationships may be disrupted. Re-evaluating manually which tests are still valid often requires redoing the entire analysis, which slows down development.

Multi Compiler, Multi Platform Projects Add Complexity

Safety‑critical systems often run:

  • On multiple processors
  • With different compilers
  • With varying optimization levels
  • Across host and target environments

 

MC/DC must be validated for the actual compiled code, not just source logic. Maintaining consistent coverage across all build variants becomes extremely challenging without tool support.

Manual MC/DC Reporting Is Error Prone and Not Auditor Ready

Safety standards such as DO‑178C or ISO 26262 require:

  • Evidence of MC/DC
  • Traceability to requirements
  • A clear demonstration of independence
  • Repeatable and reviewable reports

 

Manually assembling this documentation:

  • Consumes substantial time
  • Is prone to human error
  • Often fails during audits due to missing details or unclear test justification

All these types are supported and measured by VectorCAST. Many of the standards additionally use a criticality indicator, which again influences the code coverage requirements. VectorCAST offers you the "Industry Modes" to ensure that you always measure the correct types despite all these factors. Here, the appropriate coverage measurements are selected for the standard to be met and the criticality level to be maintained. 

The fact that we reliably meet and cover the various standards is regularly approved and certified by TÜV.

Connect with Our Experts

Whether you're seeking advice, looking for solutions, or just curious about our services, we're here to help.
Our team of experienced developers is here to provide the support, and technical expertise you need. Contact us to schedule your consultation and start your journey with us. 

Subscribe To Our Newsletter

Are you passionate about software development?
Want to stay updated with the latest, tools, and best practices we offer?

Join our community by subscribing today!