Jonathan Jacky

Specifying a safety-critical control system in Z

The paper presents a formal specification in the Z notation for a safety-critical control system. It describes a particular medical device but is quite generic and should be widely applicable. The specification emphasizes safety interlocking and other discontinuous features that are not considered in classical control theory. A method for calculating interlock conditions for particular operations from system safety assertions is proposed; it is similar to ordinary Z precondition calculation, but usually results in stronger preconditions. The specification is presented as a partially complete framework that can be edited and filled in with the specific features of a particular control system. Our system is large but the specification is concise. It is built up from components, subsystems, conditions and modes that are developed separately, but also accounts for behaviors that emerge at the system level. The specification illustrates several useful idioms of the Z notation, and demonstrates that an object-oriented specification style can be expressed in ordinary Z. >

Testing a 3-D radiation therapy planning program.

This report describes a systematic effort to test all functions of a large 3-D radiation therapy planning program, including graphics and user interaction. Previous studies in quality assurance for radiation therapy programs do not adequately address the problem of programming errors. They compare dose estimates calculated by planning programs to actual doses measured in phantoms, so they cannot distinguish programming errors from measurement errors or physical unsoundness of the beam model. Moreover, they fail to exercise graphics and user interaction functions. This report describes a different methodology: test cases are derived from the program specification, results are calculated by an independent technique, and compared to program output. Derivation of test cases is described in detail. Effectiveness of testing is assessed by reporting the number of errors revealed by testing and comparing to the number of errors discovered during routine use in five successive program versions. The size of the test set is related to the total program size, and the effort devoted to deriving and performing tests is compared to the total program development effort. We conclude that systematic testing can reveal errors that are not found by informal testing, routine program use, or comparison with measurements. However, additional errors remain that are only discovered during use. This study suggests that a typical large planning system may include more than 100 errors when it is released for clinical use. Methods for increasing testing effectiveness are recommended.

An object-oriented programming discipline for standard Pascal

A successful application, using standard Pascal in a large medical application program, demonstrates that benefits similar to those of specialized languages are possible in object-oriented programming.

Model-Based Testing of Web Applications Using NModel

We show how model-based on-the-fly testing can be applied in the context of web applications using the NModel toolkit. The concrete case study is a commercial web-based positioning system called WorkForce Management (WFM) which interacts with a number of other services, such as billing and positioning, through a mobile operator. We describe the application and the testing, and discuss the test results.

Experience with Z Developing a Control Program for a Radiation Therapy Machine

We are developing a control program for a unique radiation therapy machine. The program is safety-critical, executes several concurrent tasks, and must meet real-time deadlines. Development employs both formal and traditional methods: we produce an informal specification in prose (supplemented by tables, diagrams and a few formulas) and a formal description in Z. The Z description includes an abstract level that expresses overall safety requirements and a concrete level that serves as a detailed design, where Z paragraphs correspond to data structures, functions and procedures in the code. We validate the Z texts against the prose specification by inspection. We derive most of the code from the Z texts by intuition and verify it by inspection but a small amount of code is derived and verified more formally. We have produced about 250 pages of informal specification and design description, about 1200 lines of Z and about 6000 lines of code. Experiences developing a large Z specification and writing the program are reported, and some errors we discovered and corrected are described.

A research-oriented treatment planning program system.

The function of a treatment planning program is to graphically simulate radiation dose distribution from proposed radiation therapy treatments. While many such programs are available which provide this much-needed service, none addresses the question of how to compare calculation and display techniques. This paper describes a program system described for support of research efforts, particularly development and testing of new calculation algorithms. The system emphasizes a modular flexible structure, enabling programs to be developed somewhat as interchangeable parts. Thus multiple variants of a calculation algorithm can be compared without undue software overhead or additional data management. Unusual features of the system include extensive use of command procedures, logical names and a structured language (PASCAL). These features are described along with other implementation details. Obstacles, limitations and future applications are also discussed.

An object-oriented approach to a large scientific application

We used an object-oriented design to build a large scientific application: simulation of radiation therapy treatments for cancer. We provide features familiar in the graphics workstation world, including graphic editing of the proposed treatment, multiple views of the treatment in different windows, and computations which proceed concurrently as the input data are being edited. To make our system practical for the typical clinic we used a popular minicomputer and the vendors operating system and compiler. This paper describes how we implemented objects, inheritance, message passing, windows, and concurrency in (almost) standard Pascal on a VAX under VMS.

A declarative implementation of the DICOM-3 network protocol

We describe a new design for programs using the Digital Imaging and Communications in Medicine (DICOM) protocol, which we have implemented in a DICOM image storage server and a radiation treatment plan transfer facility for our locally developed radiation treatment planning system, Prism. This design is declarative, representing DICOM as a language for describing messages and sequencing of messages. The coding involved implementing an interpreter for this language. The DICOM protocol specifies messages, message formats, and sequencing. In our design, the specification translates almost directly into computer-readable declarative expressions that closely resemble the relevant tabulated DICOM specifications. The resulting programs are small, simple, and extensible, because most of the details of the DICOM protocol are not coded in the procedural control statements but are in the expressions and state table that the interpreter uses to perform all its functions. This approach provides a way to validate the consistency of a specification and the correctness of the implementation. The same method can be generalized to other such protocols. It may also be used to assist the design of new protocols.

Integration of radiotherapy planning systems and radiotherapy treatment equipment: 11 years experience

PURPOSE We have investigated the requirements, design, implementation, and operation of a computer-controlled medical accelerator with multileaf collimator (MLC), integrated with a radiation treatment-planning system (RTPS), and we report on the performance, benefits, and lessons learned from this experience. METHODS AND MATERIALS In 1984 the University of Washington installed a computer-controlled radiation therapy machine (the Clinical Neutron Therapy System, or CNTS) with a multileaf collimator. Since the beginning of operation the control system computer has been connected by commercially available network hardware and software to three generations of radiation treatment-planning systems. Semiautomated setup and completely computerized check and confirm were incorporated into the system from the beginning of clinical operation in 1984. The system cannot deliver a patient treatment without a computer-prepared treatment plan. RESULTS The CNTS has been in use for routine patient treatments for over 11 years. The cost of the network connection and software was an insignificant fraction of the facility cost. Operation has been efficient and reliable. Of the 441 machine-related session reschedulings (out of 18,432 sessions total) during the past 9 years, only 20 were due to problems with data transfer between the RTPS and CNTS, associated primarily with two incidents. Close integration with the treatment-planning system allows complex treatments to be delivered. Dramatic evolution of the departmental treatment-planning system has not required any changes or redesign of either the accelerator control system or the network connection. CONCLUSIONS Our experience shows that a large degree of automation is possible with reasonable effort, by using well-known software and hardware design strategies. The lessons we have learned from this can be carried over into photon therapy now that photon accelerators with MLC facilities are commercially available.

Formal Specification and Development of Control System Input/Output

This paper presents a formal specification in the Z notation for computations that calculate control system state variables from input / output device register contents (and vice-versa). The specification is motivated by a particular medical device but is quite generic and should be widely applicable. The specification is parameterised so that an implementation can be adapted to different control systems by providing tables of configuration data, rather than changing executable code. Specified behaviours include detection of errors (where clients invoke operations with invalid parameters) and faults (where input / output devices report invalid data). The specification is not merely descriptive, but is also used in the formal development (or “refinement”) of a detailed design. From an initial specification which naturally expresses the requirements, but is abstract and non-constructive, we derive a functionally equivalent specification (also in Z), which suggests a straightforward and efficient implementation in an imperative programming language. Formal justification is provided for each step in the derivation. Theorems are stated that formalise claims such as “All inputs are handled properly.” Proving the theorems checks for errors in the derivation, and provides confidence that the formal specification expresses the intended requirements.