Compliance to IEC 62304 with the LDRA tool suite®
Overview
The extensive use of electronic devices in medical industry and as these electronic products has become more and more dependent on embedded software. The reliability and the associated risk of the embedded software's used within the device have become important.
As a result the IEC 62304 standard has emerged as a global benchmark for management of the software development lifecycle. The IEC 62304 standard provides a framework of software development lifecycle processes with activities and tasks necessary for the safe design and maintenance of medical device software.
This standard applies to the development and maintenance of medical device software when:
- Software is itself a medical device
- Software used as a component, part, or accessory of a medical device
- Software used in the production of a device
The IEC 62304 standard expects the manufacturer to assign a safety class to the software system as a whole. This classification is based on the potential to create a hazard that could result in an injury to the user, the patient or other people. The software is classified into three classes, as follows:
- Class A: No injury or damage to health is possible
- Class B: Non serious injury is possible
- Class C: Death or serious injury is possible
The safety classification has a tremendous impact on the code development process.
This classification also determines the effort and the cost involved in developing the medical device, the effort and expense of producing a Class C medical device is much higher than required for developing Class A medical device.
 |
It is therefore in the interests of medical device manufacturers to get this right the first time to avoid expensive and time-consuming rework late in a project.
The medical device manufacturers should follow rigorous software development lifecycle processes in accordance to IEC 62304, which include requirements traceability, software design, coding and software validation and verification.
Both software analysis and requirements traceability tools are essential for cost conscious projects. LDRA has extensive experience in this specialised area with the LDRA tool suite® which provides the most comprehensive requirements traceability, source code analysis and testing facilities for assisting companies to meet IEC 62304 software development and verification requirements. As the application of IEC 62304 becomes more widespread it is essential that the choice of tools is based on known expertise.
IEC 62304 Compliance
Ensuring compliance with the LDRA tool suite®
IEC 62304 is derived from state-of-the-art software engineering knowledge and best practices recommended in current safety standards like IEC 61508-3. The IEC 61508 standard was designed for use as the foundation for other industry specific standards for safety, the example includes CENELEC prEN 50128 standard in the rail industry, the IEC 61511 standard in the process industry and the IEC 61513 (IEC 68808) standard in nuclear industry.
 |
The LDRA tool suite has a long, proven track record of ensuring compliance to such standards, and is therefore the logical choice for working in accordance with IEC 62304.
The LDRA tool suite will provide the major part of the quality management system as well as requirements engineering facility. The LDRA tool suite is the tool of choice for both risk based standards such as DO-178B/C and software integrity based standards such as IEC 61508.
The use of traceability and analysis tools for medical devices that meet IEC 62304 standard offers significant productivity and cost benefits. Tools make compliance checking easier, less error prone and more cost effective. In addition, they make the creation, management, maintenance and documentation of requirements traceability straightforward and cost effective. When selecting a test tool to assist in achieving compliance to IEC 62304 the following criteria should be considered:
- Does the tool provide a complete Requirements Traceability capability to enable linkage and documentation from all levels to the source code and associated test cases?
- Does the tool have comprehensive fault and coding standards checking capability?
- Does the tool enable analysis for all Structural Coverage Analysis requirements?
- Is there tool availability for all the languages required in your project?
- Has the tool been utilised in this manner successfully already?
- Is tool support both flexible and extensive enough to meet changing requirements?
- Is the tool designed to support embedded systems?
- Can the tool support on target testing?
- Is the tool easy to use?
(The LDRA tool suite meets all of these criteria.)
LDRA tool suite highlights
IEC 62304 Clause 5 details the software development process of the product. It specifically addresses:
- 5.1 Software development planning
- 5.2 Software requirements analysis
- 5.3 Software architectural design
- 5.4 Software detailed design
- 5.5 Software unit implementation and verification
- 5.6 Software integration and integration testing
- 5.7 Software system testing
- 5.8 Software release
IEC 62304 Clause 6 details the software maintenance process as follows:
- 6.1 Establish software maintenance plan
- 6.2 Problem and modification analysis
- 6.3 Modification implementation
Additionally, IEC 62304 Clause 7 details the software risk management process as follows:
- 7.1 Analysis of software contributing to hazardous situations
- 7.2 RISK CONTROL measures
- 7.3 VERIFICATION of RISK CONTROL measures
- 7.4 RISK MANAGEMENT of software changes
As these themes are developed in this part of the standard, it becomes clear that irrespective of the device Class A, B and C, assistance is available from the LDRA tool suite for every step of the way.
The following V diagram illustrates how LDRA tool suite can help through software development process described by IEC 62304:
 |
Mapping the capabilities of the LDRA tool suite to the guidelines of IEC 62304 |
5.1 Software Development Planning
This ACTIVITY calls for software verification planning, TBreq /TBmanager assists here through TBmanager where detailed software verification plan can be generated for the software requirements; the software verification plan includes tasks to be performed during software verification and assigning them to a specific user. To assist the verification planning process the tool suite provides various planners for example LCSAJ test case planner.
5.2 Software Requirements Analysis
This activity requires the software requirements for the medical device software to be verified. All software requirements should be identified in such a way as to make it possible to demonstrate traceability between the requirement and software system testing.
TBreq/TBmanager assists here through its requirements engineering and traceability features which support the authoring of requirements and traceability between the design documents at the various design and development phases through the project.
 |
A visual representation of a requirements traceability matrix via TBreq |
TBreq/TBmanager automatically manages any changes in the associated documents or software code, such that any tests which are required to be revisited as a result of these changes are automatically highlighted and can be dealt with accordingly.
This traceability is equally significant between the higher level specifications, as it is between the specifications and the source code. The LDRA tool suite will show where revisions on one document highlight a need to revisit others.
5.4 Software Detailed Design
The standard mentions that the design has to be verified. The graphical artifacts generated by the LDRA tool suite are ideally suited to review the implemented design against the design artifacts either by walkthroughs or inspections. It will also help to find the anomalies in the design. This support requires that the software architecture be prototyped in a programming language (Java, C, C++ or Ada).
LDRA Testbed can perform design review and generate dataflow reports which provide information on the Interface specification, Variable anomalies and Procedure call information.
Based on the design review, Unit/Integration test can be performed for functionality or structural coverage analysis.
LDRA tool suite generates graphical artifacts like call graph, flow graph, bar charts and kiviat diagrams which are suited to review the implemented design through visual inspection.
5.5 Software Unit Implementation and Verification
This activity calls for the usage of coding standards during the implementation of software units. The code for each unit should be verified to ensure that it functions as specified by the detailed design and that it complies with the specified coding standards.
LDRA Testbed and TBvision both have extensive standards checking capability, including industry leading compliance to the MISRA C and C++, HIS, CERT C and more.
The static analysis capability is able to apply nearly 100 special coding rules, based on formal methods, which detect the sort of faults which occur primarily at software integration.
 |
Visual representation of TBvision displaying compliance to the MISRA C++:2008 standard |
The standard also calls for establishing strategies, methods and procedures for verifying each software unit. Where verification is done by testing and the test procedures shall be evaluated for correctness. The acceptance criteria shall include data and control flow, memory overflows detection and checking of all software boundary conditions.
TBrun provides a graphical user interface for unit test specification, to create tests according to the defined specification, boundary condition values, and to present a list of all defined test cases with appropriate pass/fail status. It provides graphical presentation of control flow graphs.
Automatic creation of the test harness stubbed functions and even test vectors (if desired) mean that unit test execution becomes a quick and easy process, requiring a minimum of specialist knowledge.
The Static Data Flow Analyser reports the information like Procedure Call Information, Data Flow Anomalies, Procedure Interface Analysis and Data Flow Standards Violations. Dynamic Data Flow Coverage produces a cross reference list of variables, which documents where they are utilised within the source file(s) or system under test and their type. The module then maps coverage information onto each variable entry in the table for Current and Combined datasets.
5.6 Software Integration and Integration Testing & 5.7 Software System Testing
Software integration testing focuses on the transfer of data and control across a software item's internal and external interfaces. Integration testing demonstrates program behaviour at the boundaries of its input and output domains and confirms program responses to invalid, unexpected, and special inputs.
Software system testing demonstrates that the specified functionality exists. This testing verifies the functionality and performance of the program as built with respect to the requirements for the software.
The structural coverage metric like Statement, branch, condition, procedures/function call, LCSAJ and data flow coverage are provided by both the unit test and system test facilities within the LDRA tool suite. These packages can also operate in tandem, so that (for instance) coverage can be generated for most of the source code through a dynamic system test, and that can be complemented using unit tests to exercise defensive code and other aspects. TBrun generates a Test Case Pass Fail Report which contains a detailed description of the newest test case in the Sequence prior to storage. The file, unit and values for inputs and outputs will be detailed for the test cases. It also documents Actual and Expected results and gives a regression Pass/Fail between them.
The LDRA tool suite maintains all test sequence and test cases such that they can repeated, the tool automatically performs regression analysis and generates a regression report which documents the Pass/Fail criterion for the regression tests performed.
IEC 62304 Clause 6 details the Software Maintenance Process
As many incidents in the field are related to service or maintenance of medical device systems including inappropriate software updates and upgrades, the software maintenance process is considered to be as important as the software development process. This is due to that fact that a high percentage of medical device software defects are introduced after product release (i.e., during software maintenance). The software maintenance process is very similar to the software development process.
The specific requirements for the Software Maintenance Plan can be authored in TBmanager. The stated requirements can then be used to automatically generate a document with a specified format using the report generation capabilities of TBmanager.
The LDRA tool suite stores many of the assets (requirements, code, tests, etc) produced during the software development process and make them available for modification. Moreover, the LDRA tool suite provides extensive regression test facilities to help ensure consistency with requirements.
IEC 62304 Clause 7 details the Software Risk Analysis Process
This standard requires the use of a RISK MANAGEMENT PROCESS that is compliant with ISO 14971. RISK MANAGEMENT as defined in ISO 14971 deals specifically with a framework for effective management of the RISKS associated with the use of MEDICAL DEVICES.
The LDRA tool suite supports a systematic and comprehensive approach to risk assessment and risk management by incorporating risk management objectives into a verifiable requirements model. In this model, regulatory requirements can be directly incorporated into the requirements specification and risk mitigation activities can be specified.
The risk mitigation activities can be delineated and categorized to meet specific criteria. User defined risk management techniques can be employed in the Risk Management Model.
The analysis and test capabilities of the LDRA tool suite can be used to verify risk control measures implemented in software. The automated traceability features of TBmanager will help to document and assure traceability of software hazards.
The LDRA tool suite and TBmanager can help determine the impact of changed software through the potential introduction of hazardous faults. This impact can be determined by the Design Review analysis in LDRA Testbed and the application of safety critical coding rules also in LDRA Testbed, The LDRA tool suite will also assist with the overall impact of proposed changes on existing risk management measures. This is achieved by maintaining multiple traceability matrixes across the following assets (as depicted in Figure 4, Risk Management Model above).
- User requirements (URS)
- Functional specifications (FS)
- Design specifications (DS)
- Traceability matrix URS-FS and URS-DS
- Risk factors associated to FS or URS (bottom-up risk analysis)
- System risk factors (top-down risk analysis)
- IQ test catalogue
- OQ test catalogue
- PQ test catalogue PQ
- Traceability of OQ/PQ to URS/FS tests.
