Covering Industry Standards

Each industry has its own requirements, which are defined in industry-specific standards. What these standards usually have in common is the demand for tests based on the requirements and the measurement of structural coverage.

 
 
 

With Requirements-based testing you can provide the evidence for the correctness of your code. The code coverage is used as a measure of the completeness of the test activities. This coverage is measured by recording the source code of an application that is covered by the execution of each test case in the test suite.

Industry Standards

Keeping track of the different standards can be difficult. 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, whether you operate in 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.

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!