Tools and techniques

~ ~ ~~ ~~ ~ ~

continuous control systems protection systems (emergency shutdown systems)

safety integrity level dangerous failures per hour probability of failure on demand

4 2 10-9t0 < 104 2 1 0 5 t 0 < 1 0 4

3 2 i o a t o c 107 2 10-4 to < I O 3

2 z 1 0 ’ t O < 1 0 6 2 1 0 5 t o < 1 0 ’

1 2 10-eto< 1 0 5 2 1 0 * t o < I O ’

for the testing of safewcritical software by W. J. Cullyer and N. Storey

As a result of the DTI/SERC research initiative on safety-critical systems a major study has been conducted into the benefits and shortcomings of the available tools and techniques for computer- aided testing of high-integrity software. The work described in this article forms part of the CONTESSE project, which is concerned with various aspects of software testing. Working from experience and knowledge accumulated by a number of leading UK companies it has been possible to assemble data that should prove valuable to all organisations engaged in the development or licensing of safety-critical computer-based systems. Both strengths and weaknesses of current methods are discussed. This article is an integral part of the DTI/SERC initiative to disseminate such knowledge to a wider audience.

Introduction he Department of Trade & Industry (DTI) and the Science T & Engineering Research Council

(SERC) have provided substantial financial support for research on the specification, design, verification and validation of software to be used in safety-critical control applications. In the UK the proven market for such software is some €400 million per annum, and about 15 medium to large companies are deeply involved in this discipline.

One of the DTliSERC funded research contracts is a major study known as ‘CONTESSE’, which is being conducted by a Consortium formed from leading UK companies in the high-integrity control sector, with support from universities. The precise constitution of the Consortium is documented in the Acknowledgments Section of this article. The purpose of the CONTESSE work is to provide authoritative advice on the tools and techniques needed when conducting computer-aided testing of software in safety-critical real-time control systems. On the basis of the first 18 months of study, some preliminary conclusions are presented in this article.

As part of the above objective, surveys have been carried out to

ascertain the methods favoured currently in industry and the requirements for and availability of test tools. It is important to note from the outset that the tools in current use support programming and testing in a wide range of commercial environments and are not designed and built for any specific industrial sector. The market for safety-critical systems is not large enough for vendors to supply tools configured specifically for the analysis and testing of high-integrity software.

Obviously the full results of these surveys cannot be reproduced in this article, since the conclusions will fill a substantial handbook, which is being written at present as part of the CONTESSE project. This article is intended to provide an overview for senior managers and to suggest key

topics which industry may consider whenever safety-critical software is being developed.

Definition of integrity levels he subject of specifying, designing and testing safety- T critical control and shutdown

systems is rooted in the concepts of hazard analysis and the determination of risk. Loss of human life is one major concern, but the destruction of costly vehicles or production plant is a collateral issue. Many different scales exist for rating the consequences of failure and their probability of occurrence. Draft International Standard IEC65A123 differentiates between these levels by allocating an acceptable failure rate to each category, as shown in Table 1.

senior managers may prefer to use definitions of the integrity levels based on the possible financial consequences of failure. Suitable definitions might be

Level 4 Catastrophic

Chief Executive Officers and other

Failure of the computer-based system will cause exceptionally large loss of human lives and complete destruction of plant or vehicles, resulting in large financial liabilities.

An incident or accident will result in the loss of some lives, plus

Level 3 Critical

Table 1 System integrity levels from IEC65A123

COMPUTING & CONTROL ENGINEERING JOURNAL OCTOBER 1994 239

serious injuries and a substantial loss of parts of a production facility, with significant financial liabilities.

Malfunction will result in some injuries and limited loss of revenue-earning plant or vehicles.

The system plays little or no part in ensuring safety, even though it is important for the conduct of company business.

Level 2 Major

Level 1 Minor

These simplistic divisions serve to illuminate corporate debate, but it is appreciated that a mass of underlying scientific and engineering evidence is needed to categorise an individual system or subsystem and hence fix an integrity level.

Impact of UK defence standards ecent standards produced by the UK MOD, Interim Defence R Standards 00-55 and 00-56,

require that any tools used for automated verification and validation of safety-critical software shall themselves be subjected to proper validation and verification. Clauses 36.1 and 36.2 of the Interim Defence Standard 00-55 [part 1 ) are reproduced below:

Clause 36. I : ‘All tools and support software used in the development of the safety-critical software shall have sufficient safety integrity to ensure that they do not jeopardise the safety integrity of the SCS.’ Clause 36.2: ‘The safety integrity requirements of the tools and the support software shall be established by a hazard analysis and safety risk assessment implemented by the systematic application of Def Stan 00-56. This analysis shall define the safety integrity required of each tool in view of the role of the tool in the project. Criteria shall be defined for the assurance and evaluation of tools and support software for each level of safety integrity used in the project, either by direct definition or by reference to existing standards.’

At present few, if any, of the tools available meet the above requirements. These Defence Standards do not provide any guidelines on the conduct of hazard analysis on the tools that are bought as ‘off the shelf’ packages.

Clause 36.2 indicates that the safety integrity requirement for tools is dependent on the integrity of the

240

system under development. On the basis of the CONTESSE studies it is proposed that a tool must have an integrity level which, at worst, is one lower than the level assigned to the product under development. Therefore, a tool developed to integrity level 2 , on the scale presented in the previous section, could be used for developing software with integrity levels 1 , 2 and 3, but should not be used for systems where hazard analysis and commercial considerations suggest a level 4 rating for the product.

Even though civil procurement processes do not have to follow these Defence Standards, the rule of thumb given above for the integrity of the tools used is observed widely in UK industry. There is an informal consensus that ‘one level lower than the product’ is a wise discipline. It will be realised that this implies that few, if any, tools will be developed to the standards and protocols of level 3 or level 4 . Also, few tools currently conform to the integrity requirements of level 2.

Current industrial practice Data collected

y sending carefully structured questionnaires to a wide range B of companies, information.was

gathered on the techniques currently being used in the development of safety-critical systems. This data may be classified under the following headings:

1 Customer requirements 2 Hazard analysis 3 Top-level specification 4 Formal specifications 5 Architectural design 6 Design-hardware 7 Design-software 8 Module construction and

testing-hardware 9 Module coding and testing-

software

10 Integration and testing-

1 1 Integration and testing-software 12 System integration and testing 13 Simulation of the environment

(closed-loop testing) 14 System validation and

certification,

hardware

Although the CONTESSE project has looked at all aspects of the development lifecycle, within this article we will consider only those activities related to software testing techniques. We will therefore consider only categories 9 and 1 1 of the above list, with the integrity level of the product being regarded as the primary parameter that guides the choice of techniques.

Module coding and testing At all levels and across all

industries, software is developed following rigorous quality assurance techniques, conforming to BS 5750 and related standards. However, the special demands of high-integrity software result in the use of additional methods that are not common in less critical applications. In all cases these additional development techniques represent increased costs and so they are introduced judiciously where economic considerations, including possible legal liabilities, make them justifiable. Certain very expensive methods, such as mathematical proofs of correctness are restricted to a handful of application areas, at levels 3 and 4 . In the subsections that follow such techniques are outlined at the integrity level at which they are normally introduced.

(a) Level 1 At this lowest level code

‘walkthroughs’ and reviews are widely used t o ensure that there is peer review of the code amongst members of the design team. Generally, all members of the team have access to the software listings and there is no attempt to achieve ‘independent’ verification and validation. Companies in the process control sector often simulate the environment in which the system will operate, using plant inputioutput models written in high-level languages. In the defence sector, software modules are often produced from low-level design documents, sometimes using automated tools to keep track of the state of each component. At integrity level 1 , testing is ge-erally carried out by conventional dynamic testing with little or no use of techniques such as automated static code analysis.

COMPUTING & CONTROL ENGINEERING JOURNAL OCTOBER 1994

(b] Level 2 The increased need to

demonstrate safety in level 2 applications results in the use of test harnesses which emulate the inputs and outputs of the individual modules. Careful records are kept of the outcome of all such tests. There is little evidence of a formalised approach to the derivation of the test harness software. In most companies one or two members of the design team are delegated to produce the necessary test stubs and test data, working in some high- level language. The results of this module level testing are archived and ultimately form part of the safety case, which precedes the decision to deliver the product software as 'fit for use'.

(c) Levels 3 and 4 At these most critical levels

substantial use is made of automated static code analysis, alongside schedules of dynamic testing which are more intensive than those reported for level 2 above. Dynamic testing of modules is done by 'black box' means, with the test team having no access to the source text of the software itself. In the defence sector, emulation on a host computer is done typically using Ada and the DEC VAX Test Manager, whereas in civil procurement the test harnesses are often written in C. Such testing is done by teams which have a degree of managerial independence from the designers. The use of static code analysis is delegated t o an independent team, which may be working at some geographically separate site, under subcontract to the software contractor. Some companies in the process-control sector have substantial software-based configurable plant simulators which are employed throughout the software life cycle to enhance the white and black box testing and produce correlation with the results of static code analysis.

Software integration and test The use of additional and

sometimes costly development methods to increase system integrity is also apparent in the software integration phase of the life cycle.

[a) Level 1 At the lowest level, integration of

the individual modules may be carried out on the target hardware, or using a hardware emulator in the event that the production hardware is not yet available. This phase becomes a simple extension of the module coding and test phase and is

well understood by industry. Realistic timing tests are possible from an early stage of integration. There is widespread use of 1/0 hardware test rigs and operator emulation. For example, in the transport sector, specialised communication packages are used to emulate the responses of traffic lights and other roadside- signs.

[b) Level 2

defence sector simulate long sequences of real-world events,

A number of companies in the

together with the associated messages from low-level controllers. Special-purpose software written in a wide variety of languages is used to derive realistic sequences. Initially. integration is performed on a host computer, rather than on the target hardware, and many contractors make use of multi-tasking operating systems in this phase. It is common for switches, LEDs and other hardware items to be coupled to the host computer to simulate a wide range of operator inputs and outputs. In the civil world, commercial limits on contract price usually mean that these techniques cannot be adopted with such rigour.

(c) Levels 3 and 4

are heavily instrumented when carrying out level 3 or 4 integration tests. When working on a host workstation, the operational software will often be 'instrumented' with function and procedure calls to a test library, with the detailed conduct of the integration tests being defined in a so-called 'test script'. Both white box and black box testing are used, with independent teams carrying out some of this work and providing an audit function. Host and target emulations are widely used, and bus emulation is performed routinely.

Both host and target environments

Bus simulators written in-house as level 2 software are in use in some companies and usually follow the requirements of standards such as MIL-STD-1533. Although this is a US military standard it has found a number of other applications, notably in civil spacecraft. Once the integration testing has moved to the final (target) hardware the object code in use is more representative of the operational regime, with much of the software instrumentation removed. The need to make accurate timing measurements means that the amount of alien code must be kept to a minimum.

Survey of tools rmed with data on the methods being used for the A development of safety critical

systems within industry, the CONTESSE project moved on to investigate the requirements for tools in this area. A study was performed to define the requirements for test and support tools. This was followed by a survey of the tools available in an attempt to identify not only the tools which are suitable for the various aspects of the development lifecycle listed in the previous main section, but also to identify those requirements not met by available tools.

Test tool requirements The CONTESSE project has

studied the requirements for automated tools to support the testing of safety-critical systems throughout the various phases of its development. The work has identified a number of specific requirement areas in which tool support can make a definite contribution to a product's safety case. These areas are:

0 Mapping of hazard analysis results to test cases Generation of test cases and documentation from design specifications Test result recording and analysis Impact of post-development

Simulation during dynamic testing Test coverage analysis Quality issues for support tools.

Within each of these areas specific tool requirements have been identified and the integration of the tools within a single development environment considered.

article to describe in detail the findings of this aspect of the CONTESSE project. Full details of this work will be clublished within the

design changes

It is not within the scope of this

COMPUTING & CONTROL ENGINEERING JOURNAL OCTOBER 1994 24 1

CONTESSE Handbook in due course. In this article we concentrate on the techniques used for evaluating and selecting tools, and on some of the global results obtained from the survey.

Tool evaluation methods At present there are no accepted

methods for evaluating to01s.~ Some research is under way and a project named DESMET is running under the supervision of the National Computing Centre (NCC). DESMET (Determining and Evaluation Methodology for Software Methods and Tools) is a study of the state of the art in evaluating the methods and automated aids used in the development and maintenance of software-based systems. .The NCC study is based on the use of qualitative and quantitative techniques, with the emphasis being on quantitative aspects.

Since the late 1970s there has been an intensive search for satisfactory tool evaluation methods Qualitative arid the quantitative techniques have been pursued in parallel and usually at a distance from each other. The DESMET report confirms that there is still no 'best' way of performing an evaluation, each approach having advantages and disadvantages.

Managers in the real-time software industry recognise that automated testing tools facilitate higher quality and more productive testing; but acquiring such tools is a complicated process. A successful tool survey requires a degree of collaboration between tool vendors and surveyors that seldom exists. The information packages produced by tool vendors are basically for marketing purposes. Surveying the information within these glO!;Sy

brochures tells industry very little about the manner in which these tools can increase productivity and assist in producing reliable, safe software.

Data collection Vendors are reluctant to supply

detailed technical information unless one is buying their tools. Setting up a database and devising questionnaires that can extract the desired information from tool vendors can therefore be very time consuming. The data collection system must be carefully devised and this requires substantial human re~ources.~

guidelines on the interconnection of tools and how this interconnection can affect organisational behaviour and the sharing of information with other tools.G The standard recommends that evaluators record information only once and offers protection against redundant and overlapped data. It addresses issues such as functionality, performance and ease of use, as well as environment dependent information, such as how the tool affects the organisation of the design team. The IEEE 1175 Standard recommends this information should be recorded in a structured format using templates given in the standard.

Establishing selection criteria

IEEE Standard 1175 gives

Fie. 1 illustrates the orocesses

1 General criteria The main objectives when

introducing new test tools are to increase development productivity and software quality. Obviously the tool itself must be developed to high standards. Results from the CONTESSE survey show that most tool vendors have incorporated quality assurance procedures within their own organisation that are compliant with the I S 0 9000 Ticklt or BS5750 Standards.

Unfortunately, selecting a vendor certified by an appropriate standards organisation does not guarantee that the tools will meet the buyer's quality requirements. Many sectors have specific quality requirements that are derived from parliamentary statutes and regulations, for example the civil aviation and the nuclear power industries.

2 Environment-dependent criteria Within this category are issues

such as the cost of the tool, staff training, and the integration of packages. A project can run into difficulty if a company tries to incorporate a new method or tool without allocating time and resources for training. The results of the CONTESSE survey show that most of the tools provide graphical user interfaces, as required b y many industrial teams. A major- problem for industry is the lack of standards for the transfer of data between disoarate tools. Manv translator and

involted in selecting a tbol. Selection conversion programiexist but it is criteria can be divided into four still a challenging task to purchase groups: sets of tools which integrate

smoothly in an industrial 1 General environment. 2 Environment-dependent 3 Tool-dependent 3 Tool-dependent criteria 4 Human-computer interface. This group of criteria includes the

I Fig. 1 Selection of tools

selection

lifecycle

database Of tools

242 COMPUTING & CONTROL ENGINEERING JOURNAL OCTOBER 1994

L Common user interface

Vertical tools

Static Design Coding Testing Simu- Audit analysis tools tools tools lation tools

tools tools

Requirements traceability tools

Horizontal Configuration management tools

Project management tools

Documentation tools

primary functions required from a tool. The precise decisions on functionality depend mainly on the degree of automation required and the organisation of a given project. Current industrial environments are based on a judicious mix of manual and automated procedures. The concept of software being produced automatically from specifications seems a distant hope.

4 Human-computer interface The performance of a tool is often

measured in response time and attributes such as ease of use. Terms such as ‘user friendly’ can be ambiguous. If a tool has a highly acceptable user interface this does not necessarily mean higher productivity. There are many different kinds of user, who may for example be frequent, casual or professional. Most of the tools in this survey were found to have graphical user interfaces (CUI). These CUI based tools operate in a complex environment which can affect the way human beings interact with the computer aid. In the worst case the seductive graphical interface may result in undue trust being placed in a single technique.

Results from survey of tools very equipment supplier and tool vendor questioned in this E survey described some form of

rigorous life cycle for the development of safety-critical systems. Inevitably the life cycles in use place substantial emphasis on verification and validation of the operational software.

keen to promote integrated development environments. This enables them to sell a set of tools

At present most tool vendors are

that can be used throughout the life cycle, for example by marketing test tools that interface with front end computer-aided software engineering (CASE) tools.

There is a consensus amongst the systems and equipment companies that integrated project support environments (IPSEs) do not live up to their potential.’ The main problem with existing IPSEs is that ‘integration’ is ill defined. An IPSE is not just a collection of tools and an operating system. The main objective of an integrated environment is to increase productivity. Companies distinguish between ‘horizontal’ tools, which cover many phases of the life cycle and ‘vertical’ tools which are applicable in only one or two phases, as illustrated in Fig. 2.

The survey suggests that human beings can do better than any automated tool, when conducting a hazard analysis or a code inspection. These tasks require a great deal of human intellectual input and existing tools can only provide a limited degree of assistance. Conversely,

Fig. 2 Conceptual view of classes of tools

when developing safety-critical software there are a number of processes that are automated to a substantial degree, including:

1 Document generation 2 Setting up tests 3 Managing and planning test

It may be concluded that the tools available for these largely managerial processes are well developed but that there are gaps in scientific and engineering capabilities, as discussed in the next Section.

Deficiencies in support provided by tools Testing in host and target environments

here are substantial differences between the conduct of testing T on host computers or testing

of the software using the target hardware.8 Before the production of the target hardware is complete, testing is often performed on a workstation. Here the emphasis is on functionality and correspondence with the non-temporal aspects of the specification. Once pre-production electronic hardware is available, attention can shift to the dynamic testing of the software in its operational environment. Then the designers have to cope with the harsh realities of real-time operation, using either real or simulated sensors and actuators.

There appears to be some confusion in the advertising literature for software development and testing tools. Often the distinction between host and target testing explained in the paragraph above is not made clear. As a result, those choosing tools may be under the

activities.

243 COMPUTING 6( CONTROL ENGINEERING JOURNAL OCTOBER 1994

mistaken impression that they are buying at least a limited capability for 'real-time' testing.

The meaning of 'real-time' Jensen defines a computing

system or operating system to be real-time if and only i f 9

1 Time, either physical or logical, absolute or relative, is part of the customer requirement ancl hence implicit in the system logic.

2 Resources are managed explicitly to satisfy the completion time constraints of the applications computations, whether statically or dynamically.

Time constraints are introduced by natural laws which govern the application domain, for example the laws of thermodynamics or aerodynamics. According to Jensen's definition operating systems such as MS-DOS and UNlX are not real-time systems, because they do not employ or obey time constraints.

There do not appear to be any 'real-time test tools' available, since no vendor offers visibility or measurements within a target computing system that satisfies the above definition. The best that can be done at present is to make substantial use of commercial tools on a workstation, which will provide only a partial view of the temporal behaviour of the software. Once the software is integrated on the target hardware, then the scope for using existing tools becomes very limited.

Instrumenting the source text A number of test tools work by

adding extra function and procedure calls to the software produced by the design team, as a basis for instrumentation and testing. In an extreme case the instrumented software may be 8 to 10 times larger than the parent text. Then the augmented software is compiled and linked with routines from a test library and with some form of 'test script' which defines the coverage required. By running the resulting object code the testing is carried out semi-automatically, with very good data capture and logging facilities. Such analysis is done on a workstation, rather than using the production (target) hardware.

When developing safety-critical software this type of testing may be acceptable to certification authorities, provided that it is backed up by exhaustive testing using the production software, free from any instrumentation or other such enhancements. It is not feasible to fully satisfy international and

244

national standards for high-integrity systems solely by demonstrations of instrumented software, since such testing does not reveal the true temporal behaviour.

Integrity of took This is one of the troubling

aspects of the present scene. Many of the testing tools available were designed and sold before the advent of the IEC Draft Standard referred to earlier. Few if any vendors have assessed the integrity level of their tools and it is left t o the purchaser to make this determination.

From the point of view of the senior staff responsible for creating a sound environment for the development of safety-critical software the position is unsatisfactory. Software licences are costly, ranging up to $50 000 for a complex tool. Yet the determination of the integrity of such a tool is hard and relies partly on the reputation of the tool vendor and partly on the extent to which that vendor can produce objective evidence of their own in-house development practices.

In summary, virtually all the tools available are 'integrity level 1 ' at best. There are one or two tools that may rank as 'level 2'. There do not appear to be any tools or packages that themselves have been developed to 'level 3 or 4' safety requirements.

Conclusions rom the survey of the techniques in use, it is clear F that computer-based control

systems of high integrity are being developed successfully by UK companies, despite the shortcomings of existing tools to aid real-time testing. Design teams are using a combination of general-purpose commercial tools, which are not integrated into a common environment, plus in-house software which is specific to the application regime. Most verification is done on host machines, which results in confidence in the algorithmic properties of the software, with respect to the original specification. Temporal behaviour has to be established on the target (pre- production) hardware and in this latter phase there is little support from the tools available on the open market.

Following from this survey, the subsequent collection of data on testing tools proved to be difficult, since vendors' brochures lack many of the relevant technical details. In particular, it is hard to deduce the integrity of the tool itself, since such packages are not developed using

the disciplines of critical control software. The best that can be said for most products is that their development has been governed by BS 5750. Instrumentation of source text with calls to test routines is a common technique, but it must be realised that this is only partial solution to the difficult problem of testing high-integrity software. There is confusion among both tool vendors and users over the definition of 'real-time' testing, and care should be taken to explore this issue thoroughly before purchasing new testing aids.

Acknowledgments he authors gratefully acknowledge the support and T assistance of the members of

the CONTESSE Consortium in the preparation of this article. These are BAeSEMA, GPE Electronic Systems, Lloyd's Register, Lucas Aerospace, NE1 Control Systems, Nuclear Electric, Rolls-Royce Aerospace, Scottish Nuclear, and their colleagues in the Uriivenity of Warwick.

References 1 'Software for the computers in the

application of industrial safety-related systems', IEC65-WC9. draft paper, 1989 (BS89133005DCl 'Functional safety of programmable electronic systems: Generic aspects', IEC65-WG10, draft paper, 1989 [BS89/33005DC] X guide to methods and software tools for the construction of large real- time systems' (DTI & NCC, 1987, Vol. 1 , 2nd Edn.) POSTON. M. P . and SEXTON, M. I?: 'Evaluating and selecting testing tools'. /€E€ Software, May 1992, pp. 33-4 2 MOSLEY, V.: 'How to assess tools efficiently and quantitatively', /EE€ Software, May 1992, pp.29-32 IEEE Std 1175/1991, 'A trial-use standard reference model for computing system tool interconnections'. IEEE, Standards Office, PO Box 13151, Piscataway, NJ, USA BROWN, A. W.. and McDERMID, J. A.: 'Learning from IPSE'S mistakes', E€€ Software, March 1992.

VOAS. J.. MORELL. L.. and MILLER, K.: 'Predicting where faults can hide from testing', /E€€ Software March 1992, pp.41-48 JENSEN, D. E.: 'Asynchronous decentralised real-time computer systems', Proceedings of NATO AS1 on Real-Time Computing, October 1992

pp.23-28

0 IEE: 1994

The authors are with the Department of Engineering, Universit.y of Warwick, Coventry CV4 8AL. UK. Prof. Cullyer is Lucas Professor of Electronics and an IEE Fellow.

COMPUTING 6( CONTROL ENGINEERING JOURNAL OCTOBER 1994