• Keine Ergebnisse gefunden

1.4 About this thesis

1.4.3 Case study: MED overview

To demonstrate our approach, we worked with an industrial partner for design, development and maintenance of a Medical Embedded Device (MED). The MED is a monitoring and control unit of a mechanical heart support system developed by our industrial partner. An overview of the heart supporting device is shown in Figure 1.4. Particularly, this diagram represents a broad view of this device which includes MED, as a controlling and monitoring unit. The functionalities of this device are controlled by a control unit which is referred to as Controller and is shown at the lower part of the Figure 1.4. This part of the MED is designed to monitor and control the human heart depending on the health of the patient. The scope of our project was restricted with the configuration and monitoring of MED by different mechanisms. Being a safety critical system, the importance of data should be precisely considered before any data related activities are carried out.

Data integrity is a major concern, particularly for the transmission of patient’s data. To achieve the above requirements of this safety critical system, we propose to use a formal method to design and develop this Medical Embedded Device.

We demonstrate our research activities with a small part of the MED, which is particularly concerned with the communication interface of the MED with other devices. The function of the communication interface is divided into two parts:

configuration and monitoring. Being a safety critical system, access and manipu-lation of patient’s data must be handled with appropriate care. With this consid-eration, the first version, (Basic MED) provided a configuration and monitoring facility with a serial interface of the computer. The Basic MED is developed in such a way that patient’s data is sent with appropriate encryption to the respec-tive departments (such as hospitals, monitoring centers, doctors) for the analysis, monitoring and controlling of a patient’s health.

Heart Supporting System

Controller (Embedded Device) Backup Battery

Main Battery

Figure 1.4: Overview of heart supporting device

Basic MED: To ensure data integrity, a customized encryption algorithm must be developed for the exchange of patient’s data. Any communication with the MED should start with an acknowledgment of a reliable connection with connected device. The developed communication protocol should assure that patient’s data is always transmitted in an encrypted format. In this device, communication with any computer should only be possible through a serial interface.

Enhanced MED: However, technological developments and patient’s needs have been incorporated with the evolution of MEDs. In the first advanced version of the Enhanced MED, various types of connections were proposed. Particularly, due to the advancement in web technologies, the Enhanced MED was incorporated with additional connection possibilities of ethernet and dial up connections. A brief overview of the MED is shown in the Figure 1.5.

In the Basic MED, communication was only possible via a serial interface. This means, the patient had to be in hospital for the controlling and monitoring of her or his health. This restriction was waved off, in the Enhanced MED, by incor-poration of different connection mechanisms. Figure 1.5 shows an architectural overview of MED. This self-explanatory figure shows details of MED communica-tion possibilities. In further chapters we shall elaborate the development of this MED using our proposed framework.

Hospital

Monitoring center

Doctors Communication

mechanism MED

*Medical Embedded Device (Med)

MED

Figure 1.5: Medical Embedded Device (MED) architecture

Preliminaries and related work

Research work is always based on existing foundational researches. However, the citation of all related work is nearly impossible. This chapter includes references to the existing researches which are related to the context of this thesis. In the first part of this chapter; the contributions of formal methods to the software engi-neering domain is elaborated. Particularly, the syntax and semantics of algebraic and process algebraic specification languages are briefly explained.

Further, some known process improvement models are briefly discussed. This part of the chapter is concluded by conceptualizing a relation between formal method and the process improvement model. A pictorial view of this relationship is presented to give a general understanding of this concept. For the next part of this chapter, we describe related research work and their state of art. Especially, software refinement, software enhancement, software product and process quality related researches are elaborated within the confinement of this research. Addi-tional details of related research work are cited whenever they are used within thesis.

2.1 Formal methods

Formal methods have been a focus of software engineering research for many years and they have established advantages in various stages of the software development life cycle. Formal methods are based on mathematical techniques of specifying and verifying software systems. They are better known for specifying complexity of

16

software systems in a well-defined, complete, consistent, precise and unambigu-ous manner. In particular, formal methods have been applied at variunambigu-ous stages of software development life cycle. Generally, they are well known for specifica-tion, development, verificaspecifica-tion, semi-automatic and automatic proofs. The uses of formal methods can be categorized into three levels: [8][23]

• Level 0 - Formal specification

• Level 1 - Formal development and formal verification

• Level 2 - Theorem proving

A formal specification of a software system is expressed in a language made of three components: rules for determining the grammatical well-formedness of sentences (syntax), rules for interpreting sentences in a precise, meaningful way within the domain considered (semantics) and rules for inferring useful information from the specification (proofs) [1]. In specific terms, a formal specification is a mathematical description of the software system that can be used to develop an implementation.

This is fundamental (level 0) use of the formal method. At level 1, the formal method is used for the formal verification techniques to demonstrate that system design is correct with respect to the given formal specification. A formal develop-ment of a software system starts from initial formal specification (level 0) and all future design steps until the implementation are validated with the formal methods based techniques (level 1 and 2).

The formal methods can be classified according to their approach of software sys-tem specifications. This research related approaches to software specifications are algebraic specification [7], model-based specification and process algebraic spec-ification. In an algebraic specification approach, first operations of specifying system are identified; further their behaviors are captured by describing relation-ships among these operations. The description of software system behaviors are referred to as axioms. Examples of algebraic specification languages are Larch, Obj, CASL.

Another approach of specification is model-based specification, which is often con-sidered to be a more concise specification approach. A model-based specification provides a model of system’s state as a system’s state model. The state model is

constructed using mathematical entities such as sets and functions. System’s op-erations are defined in terms of how they modify the state model: pre-conditions define valid input and the start state for an operation and post-condition defines output and state of system after operation execution. Some widely used notions for developing model based specifications[24] are VDM[25], Z[8]. The formal method of this group is further divided for the specification of sequential and concurrent systems. Process algebra is a formal description technique for complex software systems, especially those involving communicating, concurrently executing com-ponents. Well known examples of process algebra are CSP [8], CCS [23], ACP[26] , and LOTOS [27]. This thesis evolves around the features of algebraic specification language CASL and process algebra CSP. This combined language has been found most suitable for elaboration of our research concept. Particularly, this combined language gives opportunity to investigate our research in the broad spectrum of formal methods from data type development to the concurrent process evaluations.