Beruflich Dokumente
Kultur Dokumente
Torben Helligs thel@gmx.com - 20097659 Jos Antonio Esparza - jaesparza@gmail.com - 20097706 Amos Hoste a_hoste@hotmail.com
System/product <name>
Table of Contents
1. INTRODUCTION................................................................................................................ 3 1.1 Purpose and Scope ........................................................................................................... 3 1.2 References ........................................................................................................................ 3 1.3 Definitions and acronyms ................................................................................................ 3 1.4 Document structure and reading guide ............................................................................ 4 1.5 Document role in an iterative development process ........................................................ 4 2. SYSTEM OVERVIEW ....................................................................................................... 5 2.1 System introduction ......................................................................................................... 5 2.2 System context ................................................................................................................. 6 3. SYSTEM INTERFACES .................................................................................................... 7 3.1 Interface to human actors ................................................................................................. 7 3.2 Interface to external system actors ................................................................................... 7 3.3 Interface to hardware actors ............................................................................................. 7 4. USE CASE VIEW ................................................................................................................ 8 4.1 Overview of architecture significant Use cases ............................................................... 8 4.2 Display readings ............................................................................................................... 8 4.2.1 Use case goal ............................................................................................................ 8 4.2.2 Use case scenario ...................................................................................................... 8 4.3 Configure Display ............................................................................................................ 9 4.3.1 Use case goal ............................................................................................................ 9 4.3.2 Use case scenario ...................................................................................................... 9 4.4 Control I-PUMP ............................................................................................................... 9 4.4.1 Use case goal ............................................................................................................ 9 4.4.2 Use case scenario .................................................................................................... 10 4.5 Manage Inputs ................................................................................................................ 10 4.5.1 Use case goal .......................................................................................................... 10 4.5.2 Use case scenario .................................................................................................... 10 4.6 Setup Alarms .................................................................................................................. 10 4.6.1 Use case goal .......................................................................................................... 10 4.6.2 Use case scenario .................................................................................................... 11 4.7 Generate Alarm .............................................................................................................. 11 4.7.1 Use case goal .......................................................................................................... 11 4.7.2 Use case scenario .................................................................................................... 11 5. LOGICAL VIEW............................................................................................................... 12 5.1 Overview ........................................................................................................................ 12 5.2 Use case realizations ...................................................................................................... 12 5.2.1 Monitor Patient realization. .................................................................................... 12 5.2.2 System setup realization. ........................................................................................ 13 6. PROCESS/TASK VIEW ................................................................................................... 14 6.1 Process/task overview .................................................................................................... 14 6.2 Process/task implementation .......................................................................................... 14 6.3 Process/task communication and synchronization ......................................................... 15 6.4 Main thread .................................................................................................................... 15
side 0 af 13
System/product <name>
6.5 Data Acquisition thread.................................................................................................. 15 6.6 Data presentation ............................................................................................................ 15 6.7 Alarm monitoring ........................................................................................................... 15 6.8 IPUMP controlling ......................................................................................................... 16 7. DEPLOYMENT VIEW ..................................................................................................... 17 7.1 System configurations .................................................................................................... 17 7.1.1 Full deployment ...................................................................................................... 17 7.1.2 Testing configuration with physical devices. ......................................................... 18 7.1.3 Testing configuration with counting devices. ......................................................... 18 7.2 Node descriptions ........................................................................................................... 18 7.2.1 Serial port nodes description................................................................................... 18 7.2.2 ADC nodes description. .......................................................................................... 18 7.2.3 Signal generator node description. .......................................................................... 19 7.2.4 Dev-kit 8000 node description ................................................................................ 19 8. IMPLEMENTATION VIEW ........................................................................................... 20 8.1 The 5-layer architecture pattern ..................................................................................... 20 8.1.1 Abstract hardware component ................................................................................ 20 8.1.2 Abstract hardware domain ...................................................................................... 21 8.1.3 Communication domain .......................................................................................... 22 8.1.4 User interface domain ............................................................................................. 22 8.1.5 Application domain................................................................................................. 22 8.2 State machine ................................................................................................................. 22 8.2.1 State machine implementation ................................................................................ 23 8.2.2 Sigleton pattern for instantiating the concrete states. ............................................. 23 8.2.3 Faade pattern for accessing the MonitorPatient classes. ....................................... 24 8.3 Alarm monitoring ........................................................................................................... 24 9. GENEREL DESIGN DECISIONS................................................................................... 26 9.1 Architectural goals and constraints ................................................................................ 26 9.2 Architectural patterns ..................................................................................................... 26 9.3 General user interface design rules ................................................................................ 26 9.4 Exception and error handling ......................................................................................... 26 9.5 Implementation languages and tools .............................................................................. 26 9.6 Implementation libraries ................................................................................................ 26 10. COMPILATION AND LINKING.................................................................................. 27 10.1 Compilation-software................................................................................................... 27 10.1.1 Building environment ........................................................................................... 27 10.2 Compilation and linking process .................................................................................. 27 10.2.1 How to build a executable for the virtual machine ............................................... 27 10.2.2 How to build a executable for the target ............................................................... 27 11. INSTALLATION AND EXECUTING .......................................................................... 28 11.1 Target setup .................................................................................................................. 28 11.2 Executing-software ...................................................................................................... 28 11.3 Execution-control (start, stop and restart) .................................................................... 28 12. REFERENCES ................................................................................................................. 29 12.1 Related documents ....................................................................................................... 29
Version 0.92 27.11.2002
side 1 af 13
System/product <name>
side 2 af 13
System/product <name>
1. INTRODUCTION
1.1 Purpose and Scope
The following pages describe the developed system architecture for the product Local MONitor system (LMON system). The Local Monitoring System is a device that displays vital signals such as Electrocardiographic signal, pulse or oximetry, that are relevant to supervise the patient state. The system will be developed as an academic project for the course Embedded Real Time System, taking place at the Engineering College of Aarhus.
1.2 References
This architectural description docucment is based upon the following documents: TI-IRTS Project Interface Specification (version 16.02.2004). Project description for Local Monitor System (LMON). Requirements Specification document. Project Report.
Electrocardiograph
Ethernet GUI
I-PUMP
Linux LMON
mmHg Oximetry
P-SIM
System/product <name>
human vital signals. Used in medical training. QT RS232 Transducer Open-source libraries used to create Graphical User Interfaces Serial communication standard Electromechanical device able to convert a mechanical signal into an electrical one.
side 4 af 13
System/product <name>
2. SYSTEM OVERVIEW
2.1 System introduction
The LOCAL monitor system is an electronic device that is able to display a set of vital signs to allow constant patient monitoring. This system is intended to be used in combination with special transducers, able to transform human variables like pulse, oximetry or temperature into electrical signals, which will be provided as direct inputs to the system. Patients associated readings will be directly presented to the sanitary personal by a LCD touch screen display, allowing direct access to the current measurements through a windowbased friendly user interface. Depending on patient state, several alarms can be configured and automatically triggered if there is a potential threat to the patient health, displaying a message on the screen and playing an alarm sound.
Figure 1: System Overview Diagram. The Patient vital signs are measured by using the appropriate transducers and sent to the LMON patient monitor system.
Figure 2: Infusion pump device (left) and ECG transducers (right). The system will be portable and compact, and it will be possible to operate it in a standalone mode or connected to an Infusion Pump, in order to control the medicine flow to the patient depending on current patient conditions.
side 5 af 13
System/product <name>
side 6 af 13
System/product <name>
3. SYSTEM INTERFACES
The LMON system is supposed to be running on the Embest Devkit8000 hardware with an IHA addon board. The addon board among other things adds a touchscreen, RS232 interfaces and D/A and A/D converters. The Devkit 8000 board is running the ngstrm GPE linux distribution set up with ssh/scp, a serial USB connection. Qt Everywhere Open Source 4.6.2 is used for implementing the GUI.
side 7 af 13
System/product <name>
side 8 af 13
System/product <name>
side 9 af 13
System/product <name>
side 10 af 13
System/product <name>
side 11 af 13
System/product <name>
5. LOGICAL VIEW
The logical view of the architecture describes the software structure and helps to identify the main classes.
5.1 Overview
The logical view of the system is mainly composed by two class diagrams that shows the how the use cases are satisfied by the application architecture. In this design the Model Controller Boundary structure has been applied. For further details on this structure reference [12] can be consulted. One of the key ideas was to associate a controller class per use case introduced in the system. There is a straightforward connection between the use cases presented in the requirements specification document and the introduced controller classes in these designs. For each first level use case there is an associated controller class. For each extended use case there is one more associated controller class implementing the business logic.
side 12 af 13
System/product <name>
Since the monitor patient use case extends the use cases display Readings, Control IPUMP and generate alarm, additional controller classes have been added. This helps to decouple the functionality and to separate the responsibilities in the system. As secondary controllers, the system is presenting the following ones: Display Controller class: responsible for implementing the Display readings case. Alarm manager class: responsible for implementing the Generate alarm use case. Infusion controller class: responsible for implementing the Control IPUMP use case. 5.2.2 System setup realization. The business logic of the use case Setup system is implemented in the class System Configuration. This Setup system use case extends the use cases Configure Display, Setup Alarm and Manage inputs. As in the previous case, this secondary use cases are implemented in separate controller classes as follows: Alarm manager class: responsible for implementing the setup alarm use case. Signal manager class: responsible for implementing the Manage inputs use case. Display controller class: responsible for implementing the Configure display use case.
side 13 af 13
System/product <name>
6. PROCESS/TASK VIEW
This section describes the considerations taken on threads and communication between them as well as timing issues. Furthermore, it is described how the threads, semaphores and timers are used and implemented in the system.
side 14 af 13
System/product <name>
The Thread class uses POSIX threads to implement threading, a way of making the code portable to any POSIX compliant operating system. If one was to build the code for another non-POSIX compliant platform, one could easily reimplement the Thread class, still using the same interface. By using the abstract OS classes, the code is made less dependent on the actual target OS used. The thread frequency is implemented by sleeping for a specific number of milliseconds. The sleeping functionality is implemented using an abstract OS class Sleeptimer with an interface as defined in [10.]
side 15 af 13
System/product <name>
side 16 af 13
System/product <name>
7. DEPLOYMENT VIEW
7.1 System configurations
The system can be deployed in three different ways: Full deployment: the system is deployed in combination with a Patient Simulator System and an Intelligent PUMP system. Testing configuration with physical devices: the system is deployed connected to a signal generator Testing configuration with counting devices: no additional hardware is required. Virtual signals will be generated by a mock object. 7.1.1 Full deployment
Figure 14: Deployment diagram of configuration 1. The system deployment with the external system actors Intelligent PUMP and Patient Simulator.
side 17 af 13
System/product <name>
Figure 15: Deployment diagram of configuration 2. The LMON system is used in combination with a signal generator as a substitute for the Patient Simulator. 7.1.3 Testing configuration with counting devices.
side 18 af 13
System/product <name>
Figure 17: The Hameg signal generator used in the prototype deployment 7.2.4 Dev-kit 8000 node description The development kit 8000 is featuring an OMAP processor from Texas Instruments, capable of running a linux distribution. More information about this platform can be found at [9].
side 19 af 13
System/product <name>
8. IMPLEMENTATION VIEW
This section provides a description of the architecture with regards to the 5-layer architecture pattern as described in [BPD, p. 148]. In addition it describes some of the design patterns from [GOF] used in the design of the system.
Figure 19: 5-Layer architecture pattern By using the five layer architecture the portability of the system is increased, and the functionalities can be easily ported to other platforms due to function separation (functionality is decoupled). Apart from this, this pattern is considered as a highly efficient one, because of the small number of layers it is introducing (page 150 at [1]). 8.1.1 Abstract hardware component The diagram below shows the Abstract OS component.
side 20 af 13
System/product <name>
Figure 20: Abstract OS layer. The purpose of this domain is to provide an abstraction layer above the operating system in order to make the design less OS type specific and improve portability. In this domain OSspecific classes exist that encapsulates OS objects such as threads, semaphores and timers. As can be seen in the diagram these classes make use of an API to access OS specific features. If one was to port the system to another target, most of the code could be reused, and only the classes in the abstract OS domain had to be re-implemented. 8.1.2 Abstract hardware domain As in the layer just described, the purpose of this layer is to provide an abstraction layer, this time towards the hardware. Each signal input is modelled with a common interface, which provides simple operations which are common for the signal input regardless if the signal comes from a ADC, serial or parallel port. Again this abstraction layer improves portability, because if for instance, the type of A/D converter was changed, and this new A/D converter was accessed in another way, modifications would be limited to the ADC class. The abstract hardware layer is shown in the next diagram.
side 21 af 13
System/product <name>
Figure 21: Abstract HW layer. 8.1.3 Communication domain In this domain classes exists which implements communicion with external systems. In the LMON system this first an foremost means classes for implementing the protocol for controlling the IPUMP. 8.1.4 User interface domain In this domain classes exist for interacting with the user. Here classes for the user interface library used exist, that is, the Qt classes, but also classes defined by us such as MainWindow and ContinuousDisplay. 8.1.5 Application domain This domain holds the entity classes and business logic of the system.
side 22 af 13
System/product <name>
Figure 22: State machine that specifies the system operation for the use case MonitorPatient.
8.2.1 State machine implementation There are several ways to implement a state machine like, for example use a switch statement, create an adjacent matrix to regulate the transitions or apply the state pattern. This last option is the one that has been adopted, since it scales much better than the previous ones and exist a clear separation between the logic that regulates the transitions and the functionalities that are carried out inside the different states. The implementation of the state pattern in the monitor patient case can be seen in the next class diagram. The monitor patient class acts as a context class, which has a one to one aggregation with the state superclass. The state superclass is the one from which the rest of the concrete states are inheriting from. As a result of this, the normal states Start, Stop and RunTest can be found. In case a nested state is used the state pattern is applied in a recursive way, as can be seen with the calibration state, that is subclassed again from the concrete states CalibrationFinished, ComparingReference, WaitingSignals and Adjusting. 8.2.2 Sigleton pattern for instantiating the concrete states. Since it is not desirable to face a situation in which several instances of a class exist within the same state machine, the singleton pattern is introduced. By applying the singleton pattern, each time an instance of a certain concrete state is requested, it will be done through the static method Instance. In the case that it has not been previously instantiated, object creation will take place, and a pointer will be assigned in the state _instance attribute of the class. If instance already exists, a pointer will be returned.
side 23 af 13
System/product <name>
8.2.3 Faade pattern for accessing the MonitorPatient classes. The Faade pattern provides a high level interface between a to the rest of the monitor patient subsystem. The intent is to have a common point to access the classes that implement the monitor patient functionality, from the state machine that regulates the system operation. The faade is provided by the MonitorPatient controller class. In this sense, the state machine can control the whole monitor patient controller and the results from system operation can be feedback to the state machine through the defined signals.
Figure 23: State machine implementation. The state machine has been implemented by using the state pattern in combination with the singleton and facade pattern.
side 24 af 13
System/product <name>
By applying the observer pattern the supervising functionality is decoupled. This allows the History not to care about how the alarms should be checked or which limits they should present.
Figure 24: Application of the observer pattern in the Signal Alarm supervision. Whenever the history class is updated with new readings, these will be added with the method store (the setState equivalence). The NotifyObservers function will be executed so all the attached observers to the history subject will by updated by using a push scheme. The information flow is shown in the sequence diagram below:
Figure 25: Sequence diagram showing the information flow in the observer pattern applied to the history alarm manager case.
side 25 af 13
System/product <name>
side 26 af 13
System/product <name>
10.1 Compilation-software
10.1.1 Building environment The prototype has been build in a Ubuntu 9.10 environment running in a virtual machine. The virtual machine disk image is virtal disk image [\\Home10.iha.dk\common\staff2stud\EIT-elektro Semester\MUP1\VMWare Golden Image\Golden Image.zip] For running this image VMware Player 3.0.1 is used For cross compiling towards the target the CodeSourcery Sourcery G++ Lite 2007q3-51 toolchain is used For compiling for the Ubuntu environment the GNU gcc compiler suite version 4.4.1 is used. For Qt development, the Qt libraries for embedded Linux (Qt Everywhere Open Source 4.6.2) has been downloaded and installed as described as described in [2]. For Qt development, Qt SDK for Open Source C++ development on Linux/X11 32-bit, version 2010.02 has been downloaded and installed as described in [2]. For the build process GNU Make 3.0.1 is used og IKT\3.
For programs not using Qt, g++ can be invoked directly from a terminal. When POSIX threads, semaphores or timers is used, it is necessary to link with the rt library:
g++ History.cpp -lrt -o History
10.2.2 How to build a executable for the target In order to build Qt executables for the target, the same three steps as before is necessary, this time instead of using the standard qmake, which will produce makefiles for the x86 architecture, a special version of qmake is used, which will produce makefiles for the ARM architecture. In the following, Qt everywhere is assumed to be installed in in the directory ~/qteverywhere-opensource-src-4.6.2
~/qt-everywhere-opensource-src-4.6.2/bin/qmake -project ~/qt-everywhere-opensource-src-4.6.2/bin/qmake make
side 27 af 13
System/product <name>
For program non-GUI programs, the CodeSourcery C++ tool chain is used by invoking armnone-linux-gnueabi-g++ in place of regular g++.
With this setup, files can be transfered with scp. In order to run Qt GUI programs on the target Qt library files must be copied to the target as described in [2]. The touchscreen is calibrated by invoking ts_calibrate on target. In order to use the A/D converters, the kernel module ads7890.ko must be loaded an devices created as described on [11]
insmod ads7870mod.ko mknod /dev/adc0 c 64 0 mknod /dev/adc1 c 64 1
And of course, the executable must be copied to the device. This can be done using scp.
11.2 Executing-software
The system boots from an SD card initially loaded with the goldenSdImage_v2_512.img image. [5]. For installation of Qt libraries and touchscreen libraries, refer to [6]. The touchscreen is callibrated by executing ts_callibrate on the target.
side 28 af 13
System/product <name>
12. REFERENCES
12.1 Related documents
[1] Helligs, Torben. Esparza, Jos Antonio and Hoste, Amos. Local Monitor System. Project Report. Embedded Real Time Systems. Spring 2010 [2] Helligs, Torben. Esparza, Jos Antonio and Hoste, Amos. Requirements speficifaction document for the LMON system.. [3] Overgaard Hansen, Finn. TI-IRTS Project Interface Specification (version 16.02.2004). [4] Overgaard Hansen, Finn. Project description for Local Monitor System (LMON).
side 29 af 13