News

Functional Safety in Automotive: ISO 26262 Testing Best Practices

Functional safety is a non-negotiable requirement in modern automotive software development. ISO 26262 provides the regulatory framework to ensure reliability and effective risk management across vehicle electronic and electrical (E/E) systems. To meet these demands, certified tools from QA Systems, Cantata and QA-MISRA, form the backbone of robust ISO 26262 testing strategies, enabling rigorous verification, automation, and full traceability for projects targeting Automotive Safety Integrity Levels (ASIL) up to D, the highest integrity tier for critical systems such as autonomous braking and airbag deployment.     ISO 26262 Testing Principles   ISO 26262 defines a structured, lifecycle-driven verification process that begins with hazard classification and ASIL determination and continues through: requirements definition and bidirectional traceability unit and integration testing fault injection and robustness testing structural and code coverage analysis   For example, in Level 4 Autonomous Emergency Braking (AEB) systems, the lifecycle starts with item definition and Hazard Analysis and Risk Assessment (HARA), followed by measurable safety requirements mapped directly to verification activities. This disciplined approach has been critical in preventing failures such as unintended acceleration, incidents that historically led to major recalls and industry-wide safety reforms.     QA Systems: Enabling ISO 26262 Compliance   Cantata   SGS-TÜV independently certified for use up to ASIL D, Cantata automates: unit and integration test generation branch and MC/DC structural coverage requirements-based testing fault-injection and robustness validation Cantata directly supports the confirmation review phase of ISO 26262, where independent assessors validate the effectiveness of implemented safety measures.     QA-MISRA   QA-MISRA complements Cantata by providing: automated static code analysis enforcement of MISRA C/C++ coding standards tool qualification kits for compliance reporting early detection of unsafe language constructs and resource usage Together, Cantata and QA-MISRA deliver a certified workflow that supports ISO 26262 requirements across all ASIL levels.     Real-World Testing Examples   Emergency Braking Systems (AEB): Automotive OEMs use Cantata to simulate sensor faults, actuator failures, and unexpected vehicle maneuvers, verifying that embedded software consistently responds within defined safety limits. QA-MISRA ensures the underlying ADAS codebase complies with MISRA rules to prevent undefined behavior before deployment.   Electronic Throttle Control: In one documented case, ISO 26262 verification activities uncovered shortcomings in functional safety implementation, prompting revised software architectures and significantly strengthened validation processes.     ISO 26262 Testing Best Practice   To build a defensible functional safety case, automotive organisations should:   establish bidirectional traceability between requirements, tests, and results   adopt automation for regression, fault injection, and interface testing   maintain comprehensive documentation using certified tools (Cantata and QA-MISRA) to streamline independent confirmation reviews   integrate simulation methodologies (MIL, SIL, HIL) to validate fault behaviour and edge cases   continuously update safety plans and audits to reflect new risks, technologies, and regulatory updates   By combining these best practices with QA Systems’ proven toolsets, automotive teams can confidently meet ISO 26262 requirements, safeguard public trust, and protect road users against the evolving risks of embedded vehicle systems.       Mapping QA Systems Tools to Unit, Integration, and System Testing   QA Systems tools align precisely with the classic software testing pyramid: unit, integration, and system testing.   Unit Testing   Cantata is purpose-built for automated unit testing of embedded C and C++ software. It enables verification of individual functions or modules in isolation using:   white-box testing techniques branch and MC/DC code coverage full requirements traceability   Key capabilities include automatic test case generation, stubbing, and mocking, ensuring dependencies are controlled and each test focuses strictly on the logic under test, fully aligned with ISO 26262 expectations.   Integration Testing   Cantata extends seamlessly into integration testing by allowing multiple modules, subsystems, and APIs to be verified together. It supports:   call interception and wrapping controlled fault injection interaction and interface validation   This ensures that not only do individual components behave correctly in isolation, but that data flows, error handling, and interfaces remain robust, as required for ISO 26262 item integration.   System Testing   While Cantata focuses primarily on unit and integration levels, its outputs form the foundation of system-level qualification evidence. For full system validation:   Cantata provides low-level dynamic test and coverage evidence QA-MISRA supplies coding-standard compliance evidence Both tools contribute traceable, auditable artefacts required for final system certification   Together, they ensure that system-level safety is built on verified, standards-compliant software from the earliest phases of development.     Summary Table     Test Level Main QA-Systems Tool Capability Highlight Unit Testing Cantata Isolate modules, auto-generate tests, and coverage analysis Integration Testing Cantata Combine modules, wrap/call intercept, interface testing System Testing Cantata & QA-MISRA Evidence & compliance for system qualification     Together, Cantata and QA-MISRA provide end-to-end ISO 26262 verification, from precise code-level correctness to system-level safety assurance with certification-ready evidence.     © 2025 QA Systems. Published by JORAL Technologies.

DO-278A and the Importance of a Qualifiable Toolchain for Aerospace Software

  Developing safety-critical C and C++ software for air traffic management or aerospace systems under DO-278A demands the highest level of reliability and verification rigour.A qualifiable toolchain for aerospace software, combining static analysis, dynamic unit testing, and code coverage, is essential to meet the standard’s requirements for traceability, compliance, and software assurance.     Why a Qualifiable Toolchain for Aerospace Software is Essential   Early Defect Detection & Compliance: Static analysis tools identify vulnerabilities and standard violations (such as buffer overflows, insecure libraries, and directive violations) early, before code execution, preventing defects from propagating. This proactive approach supports DO-278A’s emphasis on defect prevention and standard conformance.   Dynamic Testing & Coverage Evidence: Dynamic unit and integration testing, together with structural coverage (statement, branch, and MC/DC), proves that requirements are correctly implemented. These metrics are essential for high-assurance levels (AL1/AL2), ensuring no hidden errors remain in safety-critical code.   Traceability & Bidirectional Verification: DO-278A requires complete traceability from requirements through implementation and testing. A qualified toolchain for aerospace software ensures every test, requirement, and code path is linked maintaining audit-ready traceability when changes occur.   Tool Qualification for Reliability: If a tool’s output influences further development or verification without manual review, tool qualification guarantees reliability. As with DO-178C, qualification ensures that tools do not introduce verification errors, preserving software integrity and certification readiness.     Benefits and Regulatory Rationale   Increased confidence in software integrity by automating error detection, remediation, and traceability.   Empirical and structural coverage data, as demanded by high-assurance AL1/AL2 software components.   Minimization of manual error and fulfilling regulatory requirements for tool usage in safety-critical development, crucial for approval and certification in aerospace and air traffic management domains.   Together, these practices ensure safe, reliable, and certifiable C/C++ software that meets DO-278A’s strict verification and traceability standards.     How to Meet These Challenges   Cantata and QA-MISRA from qa-systems.com form an expertly certified and integrated toolset for developing, testing, and qualifying safety-critical C and C++ software compliant with the DO-278A standard. This toolset is uniquely suited to accelerate safety standards compliance through automated static and dynamic analysis, comprehensive coverage metrics, and test automation capabilities critical to aerospace software development.     Why Cantata and QA-MISRA Are Ideal for DO-278A   Cantata   Automates unit and integration testing for C/C++ Supports dynamic execution on both host and embedded targets Provides code coverage analysis, regression testing, and requirements traceability TÜV-certified for the highest integrity levels, meeting DO-278A verification needs   QA-MISRA   Performs static source code analysis with 900+ compliance checks Enforces MISRA C/C++ and other safety-related coding standards Ensures zero false negatives for precise, early defect detection Complements Cantata by improving code quality before runtime testing   Together, Cantata and QA-MISRA deliver end-to-end coverage of DO-278A verification needs, from static compliance to dynamic validation, backed by certification kits and qualification documentation for efficient regulatory approval.     Applications in Aerospace and Air Traffic Management   The combined Cantata and QA-MISRA toolset is ideally suited for   Avionics Flight Control Systems: Software controlling aircraft flight surfaces and stability, requiring rigorous unit and integration testing to avoid runtime failures. Air Traffic Management Systems: Safety-critical control and communication software ensuring safe airspace operation with strict code quality and traceability demands. On-board Diagnostics and Safety Monitoring: Embedded software performing real-time monitoring and fault detection with a need for exhaustive compliance with coding standards. Mission-Critical Navigation Systems: Systems that demand flawless operation due to navigation safety requirements, verified through automated unit tests and static checks. Satellite Command and Control Software: Software in satellites controlling functions under extreme conditions, validated using these tools to ensure robust, error-free operation.   Conclusion   DO-278A compliance relies on a qualifiable toolchain for aerospace software that integrates static and dynamic verification, structural coverage, and full traceability.   Cantata and QA-MISRA deliver this capability in one certified, automated environment, enabling early defect detection, comprehensive testing, and assured qualification. Together, they provide aerospace developers with a faster, more reliable path to compliance with safety-critical software standards.   For more information about QA-MISRA and Cantata, visit qa-systems.com.     © 2025 QA Systems. Published by JORAL Technologies.

Accelerating IEC 62304 Compliance: How Cantata and QA-MISRA Simplify Safe Medical Device Software Development

Developing software for medical devices is one of the most demanding engineering challenges. Whether powering a drug delivery pump, patient monitor, medical robot, or diagnostic imaging system, embedded C and C++ software must be demonstrably safe, predictable, and fully compliant with international regulations. There is no room for error when patient safety is at stake.   To meet these expectations, medical device manufacturers increasingly rely on certified software testing and static analysis tools. Solutions such as Cantata and QA-MISRA from QA Systems provide the automation, traceability, and compliance evidence required to accelerate IEC 62304, FDA, MDR, and other regulatory submissions, while improving software reliability and reducing development risk.   Why Certified Tools Matter in Medical Device Software Development   Medical devices operate under tight regulatory controls due to their direct impact on patient health. IEC 62304, the key international standard for medical device software development and lifecycle processes, requires:   rigorous coding-standard compliance comprehensive verification and validation traceable test evidence documented proof of defect prevention classification-dependent safety activities   Without a certified toolchain, manufacturers face major challenges in demonstrating compliance and providing defensible evidence that software is safe, reliable, and maintainable. Certified tools dramatically reduce this burden.   Testing Across the Entire IEC 62304 Verification Spectrum   IEC 62304 demands a complete, traceable testing strategy: from isolated components to full device behavior. Cantata supports each of these layers.   Unit Testing: Verifying Critical Logic in Isolation Unit testing ensures individual functions or modules behave as intended, long before integration.   Cantata strengthens this phase by providing:   automated test framework and harness generation white-box testing with instrumentation simulation of boundary cases and failure modes bi-directional traceability to clinical safety requirements This is essential for Class B and Class C medical devices, where regulators expect proof that each safety-critical software unit has been independently verified.   Integration Testing: Ensuring Modules Work Together Safely As modules combine, integration testing ensures that interfaces exchange data correctly. Cantata enables: testing on both host and embedded target hardware detection of boundary and communications faults validation of timing, state transitions & condition responses simulation of hardware behaviours and dependencies This prevents dangerous interaction failures that could harm patients.   System-Level Testing: Verifying Full Medical Device Behaviour System testing validates the completed device under realistic conditions.   This includes verifying: safety interlocks alarm logic real-time responsiveness error recovery behaviour end-to-end functional flows Cantata’s automation and coverage metrics provide the traceable evidence needed to demonstrate safe system performance in regulatory submissions.   The Critical Role of Code Coverage in Medical Devices    For medical devices (especially Class III-equivalent systems) code coverage is not optional. Regulators expect evidence that all software paths critical to patient safety have been exercised. With integrated coverage tools, Cantata helps teams:   identify untested logic eliminate dead or unreachable code prevent hazardous behaviour in edge scenarios validate functional safety requirements with measurable evidence This reduces late-stage risk and strengthens the safety case.   Application Areas: Why It’s Essential   Drug Delivery Systems: Incorrect calculations or timing software bugs could overdose or underdose a patient. Code must be provably correct under all Application Areas: Where Testing Quality Directly Affects Patient Safety Drug Delivery Systems Even small software defects can cause incorrect dosage. Cantata ensures dosing algorithms and timing logic behave safely under all conditions. Patient Monitoring Devices Alarm prioritisation, sensor interpretation, and real-time responsiveness must be validated against clinical scenarios. Diagnostic Scanning Systems Software managing imaging timing, safety interlocks, and calibration routines must be tested thoroughly to avoid dangerous misinterpretation. Medical Robotics High-integrity control logic managing motion, force, and navigation requires robust integration testing and coding-standard compliance to protect patients in close proximity to robotic systems. Compliance, Safety, and Reputation   QA-MISRA and Cantata deliver automated enforcement of MISRA standards, traceability, detailed diagnostics, and code reports, all needed for IEC 62304, FDA, and other regulatory submissions. Beyond compliance, rigorous testing and demonstrable code coverage help prevent costly recalls, safeguard patients, and ensure long-term brand trust within this highly scrutinized sector.   In summary, deploying QA-MISRA and Cantata in the medical devices domain is not just a regulatory necessity; it is a competitive advantage and a core pillar of patient safety, clinical effectiveness, and enduring product success.   Cantata and QA-MISRA: A Certified Toolchain for IEC 62304 Compliance   Together, Cantata and QA-MISRA form a powerful ecosystem for medical device software development.   Cantata: Dynamic Testing Built for Safety-Critical Medical Software   Cantata provides: automated unit & integration testing MC/DC, branch, decision & statement coverage error and boundary-condition simulation Code Change Analysis for efficient regression execution on host and embedded target platforms certified reporting for IEC 62304 evidence Cantata’s Wrapping Technology offers unmatched call control, enabling deep verification of interactions within medical software without altering production code.   QA-MISRA: High-Performance Static Analysis for MISRA Compliance   QA-MISRA delivers: automated enforcement of MISRA C/C++, AUTOSAR, CERT, CWE 5× faster analysis than comparable tools zero false positives and zero false negatives on syntactic rules highly accurate semantic analysis (with AbsInt integration) detailed diagnostics, visualisations, and compliance reports seamless CI/CD automation certification & qualification kits for IEC 62304, FDA, MDR   This enables continuous detection of unsafe code patterns and eliminates undefined behaviour, a fundamental requirement for safety-critical software.   Why Certification Bodies Trust Cantata and QA-MISRA   Cantata and QA-MISRA offer unique advantages: certified for use in IEC 62304 compliant development robust traceability linking requirements, tests, and code paths extensive automated reporting to support FDA, EU MDR, UKCA reduced tool qualification burden thanks to TÜV certification consistent, defendable evidence for safety cases This significantly accelerates regulatory approval while reducing risk and engineering overhead.   Impact on Patient Safety, Reliability, and Clinical Outcomes Stronger testing and static analysis directly improve clinical care:   fewer device malfunctions → safer patient outcomes reduced downtime → better diagnostic and treatment continuity earlier bug detection → lower development and recall costs faster certifications → quicker deployment of life-saving technologies higher software quality → easier clinician training and confidence Patient safety improves when software reliability improves, and that reliability is built on strong tooling.   Conclusion Accelerating IEC 62304 compliance requires automated, certified, and traceable tools designed specifically for safety-critical embedded software. Cantata and QA-MISRA deliver exactly that. They enable medical device manufacturers to: enforce coding standards reliably automate dynamic testing and coverage generate defendable regulatory evidence reduce certification effort protect patients with safer, more predictable devices For modern medical device software developers, using Cantata and QA-MISRA is not just a compliance requirement; it is a strategic advantage and a core component of delivering safe, effective, and clinically trusted technologies. For more information about QA-MISRA and Cantata, visit qa-systems.com.   © 2025 QA Systems. Published by JORAL Technologies.

Have you covered *this* when testing C and C++ Software?

The ability to produce reliable technologies that rapidly follow market trends creates a competitive advantage in the digital world.     Part of being a technology company is about producing reliable technology at a rapid pace. At the same time, we cannot sacrifice code quality just to deliver slightly faster. One of the primary tools for ensuring code quality while maintaining a rapid release schedule is writing good tests. Like any other skill, test writing is best developed through practice and experience. Monitoring development performance and knowing when you have tested enough are very valuable things to consider in any software development project.   Many software developers are surprised when the customer reports an error. We spend countless hours defining requirements, testing code and reviewing the final product. Despite this time investment how is it that mistakes find their way into the deliverable unnoticed?   Assuming that the customer is reporting valid concerns, we can answer the question with one of the following statements:   > The customer has executed part of the application that has never been tested. Incomplete testing could be deliberate due to time or cost constraints.   > The order or process in which a customer has used the software is different from the use anticipated by the development team or, more likely, the testing team. This actual usage was not built into the test suite.   > A combination of inputs were received by the application that were never tested. Software is rarely tested with every possible input value. It is the job of the tester to select a reduced set of typical input conditions that reproduce real-world usage. If the assumptions of the tester are wrong, errors slip through.   > The environment in which the software is being used differs between the develop/test teams and the customer. Typical discrepancies can be a different operating system version or hardware. Perhaps the real-world environment was not available to the test team at all, and it had to be simulated or assumed.   Just Test It Software is almost never 100% tested. Unfortunately, this even applies to the more rigorously tested safety-critical embedded applications.     Consider a piece of control software which processes up to 30 different input variables. If we wanted to test all possible input combinations and prove that there were no unwanted interrelations between the inputs, we would have to test for 20 years, even if we could create and run 100 test cases per second.   Various measurements of coverage can be used to set and monitor testing progress and performance to help minimise the occurrence of errors in the field.   Consider a piece of control software which processes up to 30 different input variables.   If we wanted to test all possible input combinations and prove that there were no unwanted interrelations between the inputs, we would have to test for 20 years, even if we could create and run 100 test cases per second.   Various measurements of coverage can be used to set and monitor testing progress and performance to help minimise the occurrence of errors in the field.   Coverage Concepts   Throughout the software industry, many commonly used terms have no concrete definition. The meaning of technical terms fluctuates depending on who you are talking to. Software testing is an essential activity in the software development and maintenance life cycles. It is a practice often used to decide and improve software quality. When it comes to measuring software testing performance and progress, it is therefore essential that everyone has the same understanding of the measurement terms (metrics) used.   ‘Coverage’ is a broad umbrella term that encompasses a number of useful numerical measures for developers of robust software systems. These measures, when used effectively, can be used both to define quality goals for your end product and track your progress towards achieving them.   In software testing, there are 3 basic types of items to which coverage measurements can be applied:   > Requirements — various levels of detail defining e.g. functional, safety or non-functional (such as performance or usability) what the software should do, and sometimes what it should not do.   > Code — implementation in software (and sometimes hardware or firmware) to meet the requirements.   Tests — a means to verify that the software does what it should do (and sometimes what it should not do — often called robustness tests).   The 3 different uses of the term ‘coverage’ should not be confused. Requirements coverage measures the proportion of requirements which have been verified by requirements-based tests. Structural Code coverage measures the proportion of the code which has been executed by tests. Test coverage measures the proportion of tests which have been run and passed.   Working to standards   If you are working in a safety-critical industry, it is likely that you will be working toward achieving certification in the relevant international software standard. The standard and integrity level within it that you are working towards, will determine the coverage metrics and target coverage values that you should achieve in your project.   Safety-critical software standards, such as DO-178C and ISO 26262, recommend the use of requirements coverage, structural code coverage and test coverage. Correct use of these concepts can also help developers outside of the safety-critical arena. Appreciation of the terms and their use will help deliver a more reliable and robust application.     Link to Requirements   Well-defined requirements at the start of the project, or at the start of an agile sprint, will make the technical teams’ jobs easier and more measurable. It is unlikely that requirements supplied by the customer will be complete enough to ensure project success. Usually, there will be some degree of interpretation, and an upfront process of adding detail to initial high-level requirements, to help shape the architectural design and implementation of the requirements in code. Situations where requirements are not documented, or where initial requirements are not final, will mandate additional study phases with the team and agreement with the customer.   Monitor Code Coverage   Measurement of structural coverage of code is an objective means of assessing the thoroughness of testing. There are various industry-standard metrics available for measuring structural coverage, these can be gathered easily with support from software tools. Such metrics do not constitute testing techniques, but a measure of the effectiveness of testing techniques.   Different code coverage metrics measure the execution of different syntax constructs within the code. The most common code coverage metrics are:   > Function / Method Entry Points   > Function / Method Calls (and their Returns)   > Lines (of executable code)   > Statements   > Basic Blocks (of sequential Statements)   > Decisions   > Conditions (Boolean operands)   > Relational Operators   > Loops   > MC/DC (Modified Condition / Decision Coverage), both Masking & Unique Cause forms   The fundamental strategic question of how much testing you should do is generally driven by available resources, both time and budget.   Dynamic Test Results   Test coverage measures the proportion of your tests have run successfully (i.e. been executed and pass) on the code. While having tests which verify the requirements can be measured using requirements coverage, and the amount of the code executed by the test can be measured using structural code coverage, whether or not these tests are actually run and pass is the third critical thing to measure for software testing. Requirements coverage and code coverage only have meaning when the status of the tests which those metrics measure is itself measured.     Set Some Goals   Setting project goals around defined metrics, such as coverage, has several benefits to project success.   > Optimise the use of resources   There are never enough resources to do everything, so setting coverage goals can help you to prioritise. By allocating most time and budget to test what is most important you can help focus testing efforts. If you want to better manage your time on testing, a simple solution is to stop doing what doesn’t need to be done.   > Add clarity to project meetings   Knowing what you are trying to achieve means that you can tackle the question: “does this activity get me closer to my goal?” Setting goals enables you to clarify with other developers and testers what you are trying to do, and therefore what they need to do to contribute or support.   > Easier measurement of project status   Setting coverage goals allows you to measure how effectively you are moving towards completion.   An important consideration is knowing when to stop testing. For those working towards standards, the coverage goals will be mandated. For others, an important first step is defining the targets of coverage to aim for.   If you reach the end of your project and have missed or not properly completed one of the three critical components of your coverage criteria, you risk delivering code that:   > Has not been verified to meet the requirements   > Has not passed all its tests   > Has not been exercised by any tests   Take away   Obtaining coverage metrics is not a final task, but rather a constant effort towards a reliable system. The easier coverage is to monitor and report, the more useful it is to development teams. Use of coverage can guide the creation of tests cases, help optimise a set of tests and provide an empirical measure of testing sufficiency. Without measuring how much of the code is tested, verification activity always risks shipping untested code. While there are some hurdles to overcome by using coverage software in an embedded or continuous integration environment, the use of suitable tools and testing framework can solve the problems in almost all instances.   © 2025 QA Systems. Published by JORAL Technologies.

Software Drives Advances in Medical Technology

Software Drives Advances in Medical Technology   Over the last few years, medicine has been a catalyst for driving progress in the innovation of medical devices and treatment plans. There is an emphasis on the extension of lifespans and improving the lives of humans. As there continues to be advances in breakthrough technologies, the introduction of leading-edge medical equipment continues.   There is an emphasis on products that deliver less expensive, faster, more efficient patient care. Digital technology is becoming embedded in every area of healthcare delivery. Medical devices are becoming more and more complex and the benefits of technology innovation to patients and providers is immeasurable.   Health technologies are a key part of the healthcare experience. Artificial intelligence and medical machine learning are assisting medical teams to streamline how patients are treated. Ingestible medical devices with circuits and sensors, have shown to be technologically relevant, in the delivery of drugs and optical imaging for diagnosis of diseases. This extends to both the diagnosis and treating of diseases. Robots are assisting humans in surgery and are assisting doctors in examining and treating patients, transporting medical supplies, and disinfecting hospital rooms. They are also target therapy to specific areas of the body in the case of tumors or bacterial infections.     Machine vision is being utilized for medical diagnostics, viewing of scans and medical images. Neurological and cardiovascular illnesses are widely viewed using computers and resultant diagnosis are made. Virtual reality and augmented reality are beneficial for surgery simulation and training. This also provides education for medical professionals and patients to understand their conditions and plans for ongoing treatments.   The 5G network capability increases the speed to share large imaging files so specialists can view and recommend proper care scenarios. Artificial intelligence, Augmented and Virtual Reality, provides the abilities for remote monitoring of patients.    Medical devices are becoming more complex as the needs for patient treatment solutions increases. It is software embedded in these devices that is increasingly the driver for differentiation and added value. Medical devices are only licensed for use after strict regulatory approvals, and that of course includes the software within them.   IEC 62304:2006 ‘Medical Device Software – Software Life-cycle processes’ is an international harmonized standard for medical devices which contain software, accessories to medical devices that contain software, and “standalone software” that meets the definition of a device or accessory.   In the European Union compliance with IEC 62304 satisfies the Medical Devices Directive 93/42/EEC (MDD) with amendment M5 (2007/47/EC) as related to software development. In the United States, the US FDA will also accept IEC 62304 as evidence that medical device software has been designed to an acceptable standard, and covers following regulatory processes: 510(k), IDE, PMA, HDE, Software Validation (FDA Recognition List Number: 020).   Within IEC 62304 there are requirements for software testing to the highest standards based on the critical nature (Class) of the medical device. So for medical device developers undertaking this software testing it is helpful if they can leverage the existing tools utilized in a development environment to support efficient assemblage of code, and the CI/CD process.   For the unit and integration testing stages in particular, test automation during development is also the most efficient means to meet the verification requirements of the IEC 62304 standard. The thoroughness of these tests also needs to be demonstrated using code coverage. For example, for a Class II (or Class B) device this means achieving 100% coverage of all the decisions in the code. of the code.   Code coverage is not just about demonstrating enough testing but can also lead to code optimization, in removing code that is not required, making the code execute more efficiently.   Project Design and Development Considerations    Control – Medical devices that are software based have a high risk of issues arising later in development or during device validation.   Reduce Uncertainty – With complexity of software development, there needs to be diligence at both the requirements and design phases and throughout the device’s evolution.   Software Tools   – A robust set of software testing and certification tools is important to verify that the code will work properly and to eliminate the issues and monetary losses/damages, and warranty costs associated with faulty equipment operation and patient expiration. – Support the ability for companies to continue to sell their products to the market without the interruptions from lawsuits and product issues in the field. – The tool must provide advanced technical capabilities for: automatic test case generation, control of function calls (e.g., mocking/stubbing), intuitive code coverage and certification evidence and ready results reporting. – A more process-oriented objective is important to ‘shift-left’ software verification activities, finding them early in the project. – Ensures that software tests are created to the required standard, and follow the tool’s Safety Manual guidance for their development and execution. – The Graphical User Interface (GUI) should support a tree view which is vital for assessing test case values with the ability to edit test cases in the user interface to save time with typing.   Summary   Advances in medical equipment are happening every second in every day. There is a need to support the operational aspects of this equipment utilizing fully tested C and C++ code that is verified to the IEC 62304 standard. This is important in support of the diagnosis of illnesses, and saving patient’s lives, taking advantage of the innovative technology available today, which includes vision and artificial intelligence. The depth and robustness of testing capabilities within Cantata the unit & integration testing tool from QA Systems, make it a logical choice, to be part of the medical device software development process. The ever-increasing demands of technology and the importance of quality software, dictates the requirement for a higher and deeper level of testing. Cantata supports these requirements is pre-certified as a class T2 tool for use under IEC 62304 up to Safety Class III (C) and provides the evidence to achieve the required level of software safety certification for medical devices.   © 2025 QA Systems. Published by JORAL Technologies.

Powering the Future: IEC 60880 Compliance in Nuclear Systems and Software Safety

Powering the Future: IEC 60880 Compliance in Nuclear Systems and Software Safety   Why the Nuclear Industry Can’t Afford Software Mistakes   In Nuclear Software, Trust Is Measured in Verification   In the control room of a nuclear plant, quiet confidence is built not on chance but on evidence. Every signal monitored and every line of code executed has a direct link to safety, reliability, and public trust.For decades, the nuclear and energy sectors have operated under one unwavering principle: there can be no margin for error.   Today, however, software, not steel, has become the true guardian of this principle. Reactors, turbines, and redundant control systems all rely on millions of lines of embedded C and C++ code, each of which is a potential point of failure. As regulations tighten and scrutiny deepens, the question is no longer “Can we automate this system?” but “How can we prove that it’s safe?”   That’s where engineered assurance tools like Cantata and QA-MISRA step in, bridging the gap between complex software design and demonstrable functional safety compliance in nuclear systems.   Testing What Matters Most with Cantata   Cantata does more than test code, it tests integrity.Purpose-built for unit and integration testing of embedded C and C++ software, Cantata automates test generation and execution directly at the source level. Each function, decision, and safety path can be verified against its expected behaviour, helping engineers satisfy IEC 60880, IEC 61508, and ISO 26262 standards.   Instead of treating testing as a late-stage hurdle, QA Systems empowers teams to embed verification within the development workflow. When a Cantata test passes, it validates not only the code but also the safety case behind it.   Key capabilities: - Automated unit and integration test generation - Rigorous code coverage analysis (statement, branch, MC/DC) - Full requirements traceability and auditable reporting - Independent TÜV certification for use in nuclear-grade applications   From Compliance in Nuclear Systems to Confidence with QA-MISRA   Compliance is non-negotiable in safety-classified software. Beyond functional correctness, every line of code must behave predictably under all conditions.QA-MISRA enforces MISRA C, MISRA C++, AUTOSAR C++14, and CERT C/C++ standards through automated static analysis, ensuring that unsafe constructs are detected and eliminated long before execution.   Key advantages: - Rapid static analysis across MISRA, AUTOSAR, CERT, and CWE rulesets - Near-zero false positives for syntactic rules - Certified by SGS TÜV for use in IEC 60880 environments - Detailed compliance reports, metrics, and visualisations - Seamless integration into Eclipse IDE and modern CI/CD pipelines With QA-MISRA, software quality becomes measurable, traceable, and certifiable — the foundation of safety-critical integrity.   A Unified Workflow for Functional Safety By combining QA-MISRA (for static analysis and coding-standard compliance) with Cantata (for dynamic testing and code coverage), engineering teams deliver a unified verification workflow that links coding-standard enforcement with automated test validation for full traceability, moving from reactive testing to proactive software assurance, where safety and reliability are built into design, not added at the end.   Specific Support for IEC 60880 Certification The IEC 60880 standard defines the functional safety requirements for software used in nuclear power-plant instrumentation and control systems. QA Systems’ tools provide certification-ready support tailored to these requirements.   Dedicated IEC 60880 toolkits include: - Qualification and certification evidence kits for both Cantata and QA-MISRA - Automated test suites and documentation for audit support - Sequential verification flow: static analysis first (QA-MISRA), then dynamic testing (Cantata) - Direct integration into safety lifecycle processes Both tools are independently certified and designed for the highest Safety Integrity Levels (SILs) demanded by nuclear and high-energy systems.   A Future Built on Proven Integrity As new-generation reactors, small modular systems, and hydrogen-based power emerge, the software controlling them must evolve, but never at the expense of safety.QA Systems provides a verified foundation of trust, giving regulators verifiable evidence, engineers confidence to innovate, and the public assurance that the systems powering their world are as safe as they are sophisticated. In a domain where milliseconds and microcodes separate stability from catastrophe, QA Systems ensures that trust is not a promise, it’s verified, certified, and proven line by line. For more information about QA-MISRA and Cantata, visit qa-systems.com. Author: Dylan Llewellyn   © 2025 QA Systems. Published by JORAL Technologies.

From EN 50128 to EN 50716: The new Era of Railway Software Compliance

From EN 50128 to EN 50716: The New Era of Railway Software Compliance   The railway software compliance landscape has fundamentally shifted.   If your organization still works under EN 50128 or EN 50657, it’s time to adapt to EN 50716:2023, the new unified standard that governs all railway software development and verification activities. Replacing both EN 50128:2011 (control & signalling) and EN 50657:2017 (on-board rolling stock), EN 50716 establishes one comprehensive framework for the entire railway domain. Both predecessor standards were withdrawn in November 2023. While EN 50716 isn’t retrospective, all upgrades and maintenance activities initiated after its publication should align with its requirements In consequence, teams must balance maintaining legacy systems with developing new projects under tighter, better-defined compliance expectations.   Key Requirements That Redefine Railway Software Testing   Section 6.7Support Tools and Languages EN 50716 increases the emphasis on tool qualification and justification. Verification and validation tools must be classified as T1, T2, or T3 based on their potential to introduce undetected faults. T2 Tools (e.g. Cantata) support verification of executable code and therefore require documented justification when used for SW-SIL 1–4. Clause 6.7.4.2 states clearly: “The selection of the tools in classes T2 used for SIL 1 to SIL 4 and T3 used for SIL 1 to SIL 4 shall be justified.”   Table A.5Software Component Analysis and Testing At SW-SIL 4, dynamic testing with comprehensive coverage is mandatory. The table explicitly lists combinations of techniques that must be applied to achieve full confidence in safety-critical behaviour.   Section 6.5.4.14Traceability Traceability must extend from requirements to design, implementation, and all testing phases. Verification evidence should show complete bi-directional links between requirements, design artefacts, and executed tests.   Section 9.2Software Maintenance Regression testing is not optional. Requirements 9.2.4.8 and 9.2.4.10 demand documentation of test re-execution and reuse of updated tests during re-validation. Given that railway systems often operate for more than 20 years, this lifecycle view is essential. Cantata’s Certified Advantage Independently certified by SGS-TÜV GmbH, Cantata is officially recognised as: Class T2 tool meeting EN 50716 sub-clause 6.7 Qualified for use up to SW-SIL 4, the highest Safety Integrity Level Each version of Cantata undergoes independent assessment, with defined behaviour, documented constraints, and mitigation strategies for potential failure modes.   Certification vs Qualification: The Cost Reality Self-qualifying a T2 tool under 6.7.4.5 requires extensive documentation: validation records, tool manual versions, test cases, pass/fail results, and discrepancy analyses. This often translates into weeks of engineering effort per release. With pre-certified Cantata, justification is immediate: Independent TÜV certificate Tool Certification Kit supplied Zero qualification overhead Traceability and Regression. Assurance That Scales Cantata Trace enables full bi-directional requirements traceability: Import from Excel, DOORS, PTC Integrity, Polarion, or Visure Requirements ALM Link requirements directly to Cantata test cases and coverage data Export verification status back to your requirements management tool (RM) for audit readiness When auditors ask for evidence of “REQ-123”, teams can deliver linked test results, execution status, and coverage metrics in minutes, not days. Cantata Code Change Analysis automates regression impact detection: Identifies modified functions Maps affected tests Suggests updates and refactors scripts automatically Supports push-button re-execution through Cantata Makefiles This aligns directly with EN 50716 §9.2.4.8 requirements for test re-execution and artefact control. Why Cantata for EN 50716 Certification Confidence TÜV-certified tool for EN 50716 up to SW-SIL 4 Eliminates tool-qualification burden (§6.7.4.5) Each release is independently certified Complete Technical Coverage Supports all Table A.5 component-testing techniques Addresses Table A.6 integration requirements Meets Table A.21 coverage criteria Enables deep white-box verification Cantata Hybrid option for teams using GoogleTest/GoogleMock who need EN 50716 compliance Lifecycle Support CLI automation for modern DevOps workflows (including VSCode, Jenkins, GitLab CI/CD) Automated regression testing for 20+ year maintenance cycles Bi-directional traceability and audit evidence on demand The Risk Mitigation Reality Section 6.7 is unambiguous: verification tools can introduce latent defects, and their qualification status is critical to certification schedules. Using Cantata means: Tool justification in days, not months Certification body acceptance through SGS-TÜV credentials Straightforward audit defence: “We used an independently certified tool per 6.7.4.2.” Attempting self-qualification adds cost, risk, and schedule uncertainty to every project. As the industry moves from fragmented frameworks to unified assurance, EN 50716 marks a new era of integrated railway software compliance.   Conclusion EN 50716:2023 redefines what safety means in railway software. Tool certification, dynamic testing, traceability, and regression are no longer optional, they are the foundation of compliance. Manual verification simply cannot keep pace with the technical and administrative demands of SW-SIL 3 and 4 projects. With Cantata, engineering teams can bridge modern development practices with the rigorous assurance required by the new standard, achieving compliance without compromising productivity. For railway software teams navigating the EN 50716 transition, the question has shifted: it’s no longer whether to automate verification and validation; it’s whether you can meet certification deadlines without it. For more information about QA-MISRA and Cantata, visit qa-systems.com. Author: Praveen Melepurath   © 2025 QA Systems. Published by JORAL Technologies.