Medical Device Link.

Automating development

The past few decades have witnessed a progressive shift towards the use of software as a major element in system design. The move away from customised electronic designs has been driven by the increasing cost-effectiveness and reliability of non-dedicated programmable devices such as microcontrollers. The switch is not without its difficulties. Just as the mainstream IT industry went through growing pains in the 1960s, 1970s and 1980s, a similar form of software crisis may be recognised in much current practice. Software development paradigms in widespread use have overlooked a simple fact: software design is essentially engineering. In most disciplines, engineers have built up a thorough understanding of what works.

A recent industry article1 notes that the United States Food and Drug Administration (FDA) is paying increasing attention to software quality issues and suggests a number of practical measures that go some way to clarifying how to ensure the necessary information is gathered for compliance purposes. The article emphasises that FDA may undertake a forensic audit following device recall and that this may use static analysis of the software. However, the article does not evaluate the major benefits that can accrue from the use of modern tools and techniques that have widespread application elsewhere in the software development industry. A number of the basic measures are examined here that may be undertaken to automate development and thereby make it significantly faster and more reliable.

Compliance requires a defined process

When first proposed, software development processes were radically different from those applied in other engineering disciplines such as electronic or mechanical engineering. They assumed that a new design could be created as a linear activity, with a beginning, a middle and an end flowing smoothly into each other. This failed to address two major issues. First, experience and experimentation must be built into a development process. These features can be incorporated by ensuring that there are proper points in the development cycle for reflection. Second, the linear flow, often termed a “waterfall” process, ignores the creative human aspect of design. Complicated problems need to be broken down into orderly chunks.

A strong development process helps to ensure that there is proper recognition of where difficulties or even impossibilities may lie. Business risk may be reduced by timely review. Early creation of the essential architecture of a solution provides a necessary framework for design. The process must recognise that it may not be possible to define a product fully at its inception and without careful experimentation. Medical device regulation requires that the development process is documented and followed.

In other engineering fields practitioners have long been able to benefit from the experience of others by the reuse of “classic” designs and from the use of tools such as CAD for electronic circuit design. These practices are now applied to software engineering. Tools are available that do far more than translate a program from a computing language into runnable code. They are able to assist in analysing a specification and experimenting with models that directly correspond with the specification. These enable early validation of a specification and rapid prototyping of a solution, which allows it to be trialled by end users from the outset. Table I shows just some of the software development tools that are on the market. They range from free software to sophisticated tools that find their main application in specific sectors. It is beyond the scope of this article to provide detailed comparisons or to indicate which of these tools are able to work together satisfactorily.

The critical parts of a development process are enforced and documented through the use of change management tools, which may also feature in gathering information from end users during postmarket surveillance. These activities may be thoroughly audit-trailed and subject to electronic signatures. Above all, the tools should be able to work co-operatively: it is necessary to invoke a change management tool during the process of modelling and generating software and important to ensure that the implementation artefacts remain in line with associated requirements (Figure 1).

Advantages of model driven development

The application of current best practice is of particular importance to the medical device sector, where the emphasis is on minimising product risk and maximising reliability cost-effectively. Best practice is demanded by regulators and by the need to defend against potential litigation. It also results in a more reliable product being delivered on time and without the need for late expensive changes or, at worst, product recall. Model driven development (MDD) can deliver these benefits effectively. In addition to the advantages of speed of design and development, MDD provides the mechanisms that can relieve the effort involved in producing the documentation required for compliance. Design inputs may be comprehensively traced to design outputs and reports generated automatically.

MDD enables the design engineer to trace well-structured requirements directly to modelled scenarios (Figure 2). This crucial early step ensures that the transition from specification to design is made completely and accurately. It is an essential part of the design’s quality assurance. The scenarios may be run dynamically in a simulated environment provided by the modelling tool, which permits experimentation with end users and validates that the requirements have been correctly captured in the system and meet the users’ needs. This stage may be reached quickly in an MDD environment.

The model driven environment builds on previous iterations through the design life cycle to help the designer visualise and build a robust, thoroughly documented design. Best in class tools enable a large proportion of the code for embedded systems to be created reliably through automation.

Verification and validation

Standards require that a medical device is completely specified. The users’ needs must trace to specifications that define the system required to satisfy those needs. The way a user interacts with the system may be defined in a Use Case. These various levels of requirements must be traceable. Nothing should have been added or omitted. Requirements management tools allow this traceability to be established; furthermore, by helping to manage linked risk assessments and test cases, they add value and enhance the rigour of the development lifecycle. Requirements may be traced using reliable tools to MDD-based designs without the tedious overhead of paper based methods.

For systems that cannot be completely specified mathematically (this currently covers most), tracing represents the state of the art in validating that a product meets its users’ requirements. Tracing ensures that nothing has been added during the implementation phase nor anything left out. It is crucial that tracing is undertaken using a specialist tool that is sensitive to the nature of the development artefacts that it is linking (Figure 3). Using spreadsheets for this task is unsatisfactory because they do not detect when a link has broken or moved. Comprehensive tracing identifies design completeness and the potential addition of uncontrolled features.

Testing should be an inherent part of any software development process at all levels from requirements to code. Requirements management tools help to manage requirements-based testing. Models may be exercised to ensure correct functionality. At code level, a testing tool should perform static analysis, create test harnesses and manage suites of tests. It should also verify that, for a real time system, all time critical responses are made within the required timing window. Coverage (including branch coverage), timing, performance and memory leakage should be monitored. Testing is typically defined as a sampled evaluation of the input space of a software program. The sampling process is necessarily incomplete; it does not validate correctness but instead may indicate where a fault lies.

Making the change

There are clearly costs associated with technological change. The cost of software licences for the tools themselves is generally insignificant, because the gains in productivity afforded by their use are so large. Time savings in excess of 50% have been made through the application of MDD using best in class tools. The reason for lack of uptake to date is that their relative novelty leads to apprehension and distrust. The fear is understandable, but the advantages are real: by their essence, development tools automate tasks by recycling tried and trusted work and design patterns. The outcome is therefore more reliable and quicker to realise. There is also a period of reduced productivity that skilled engineers must work through to achieve good levels of proficiency with new techniques. Experience shows that the brief interruption is worthwhile; it has been adopted in many fields where embedded software is used such as defence, transport and communications.

Innovate for increased efficiency

The medical device market must be prepared to innovate to remain competitive whilst continuing to meet the developing demands of regulatory compliance and avoid potential allegations of negligence. Late, uncontrolled changes to software are a major reason why products are recalled.2 An automated system tailored to fit and extend a company’s quality control process will help increase return on investment, accelerate time to market and avoid expensive recall. Medical devices must clearly adhere to generic quality standards. The application of MDD with the best tools available can greatly reduce the cost of regulatory overheads.

Dr Dave Jennings is Director of Trosolwg Systems and Software, Trosolwg, Llansaint, UK, tel. +44 1267 267 068, e-mail: info@trosolwg.co.uk, www.trosolwg.co.uk