Local Monitor System Product Doc

Local Monitor System. Product documentation.
Embedded Real-Time Systems

Spring 2010
Torben Helligs thel@gmx.com - 20097659 Jos Antonio Esparza - jaesparza@gmail.com - 20097706 Amos Hoste a_hoste@hotmail.com
System/product architecture document
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
Version 0.92 27.11.2002
side 0 af 13
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
12.2 On-line resources ......................................................................................................... 29
Version 0.92 27.11.2002
side 2 af 13
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.
1.3 Definitions and acronyms

A/D Analog to Digital Converter. Electronical device responsible for sampling and scaling an analog continuous signal in order to convert it into a digital one. Continuous signal representing the electrical activity of the heart Standard for network communications Graphical User Interface. Software responsible for user interaction through elements such as buttons, windows, text areas... Infusion Pump. Electromechanical device responsible for automatic drug delivery. Open-source operating system Local Monitor. Device introduce in this paper, able to monitor patient vital signs Millimeter of mercury, pressure unit Continuous signal representing the patients hemoglobin oxygenation Patient Simulator. Electromechanical device able to reproduce side 3 af 13
Electrocardiograph
Ethernet GUI
I-PUMP
Linux LMON
mmHg Oximetry
P-SIM
Version 0.92 27.11.2002
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.
1.4 Document structure and reading guide

This document is composed by twelve main chapters. The introduction part gives a general overview of the document, detailing purpose and most relevant concepts. In the second chapter, System Overview, the product is contextualized and its main features and functionalities are described. In the System Interfaces chapter, the different communication mechanisms the system uses to interact with the outside environment are described. The use case view outlines the analyzed use cases and scenarios of use. This chapter shows how the system is used by the external actors. The Logical view chapter introduces the software logical structure, focused on presenting the different entities and its representation in the system. The Process Task view, introduced in chapter 6, details how the system is organized in run time, introduction the actives objects of the system and the synchronization mechanisms. In the Deployment View chapter, the possible system configurations and physical deployment schemes are shown. The Implementation view chapter gives a more detailed insight on the technical aspects, showing additional UML diagrams focused on the implementation. The Data view chapter presents how data abstractions have been applied, and some discussion on the persistence layer. The general design decisions chapter explains architectural constrains, general design rules that have been followed and which technologies have been applied. The two last chapters, Compilation and linking and Installation and Executing, presents the mandatory procedures to reproduce the work that have been done in this project, taking as a base the existing hardware and software.
1.5 Document role in an iterative development process

The core ideas behind this document have been iteratively and incrementally refined and improved. What it is presented here is a compilation of all the design documents that have been created during the iterations. The contents for the first three chapters of this document (Introduction, System Overview and System Intefaces) were generated at the very beginning of the project. Other parts have been created during project development like, for example, the different architectural views of the system. At the end specific guidelines about software compilation, deployment and installation have been detailed.
Version 0.92 27.11.2002
side 4 af 13
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.
Version 0.92 27.11.2002
side 5 af 13
2.2 System context

The following diagram contextualizes the system by showing the main actors involved with the Local Monitor Operation. Each actor represents a single role that one or several users can hold at a single time. In the following sections the involved actors will be described in detail.
Figure 3: Actor context diagram of the system.
Version 0.92 27.11.2002
side 6 af 13
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.
3.1 Interface to human actors

The operator interacts with the system using the touchscreen. The technician will download new versions of the software using the serial USB connection and scp.
3.2 Interface to external system actors

The system interacts with the IPUMP system with commands as described in [3].
3.3 Interface to hardware actors

ECG signal, a continuous 12 bit analogue value 0-2 V is read from ADC0. EDR signal, a continuous 12 bit analogue value 0-2 V is read from ADC1. For more details on hardware setup consult reference [11]. Pulse, a discrete 8 bit digital value is 0-250 beats/minute is read from the Serial Port 1. The system interacts with the IPUMP on Serial Port 2.
Version 0.92 27.11.2002
side 7 af 13
4. USE CASE VIEW

This section introduces the use cases and the use case scenarios that were detected in the use case analysis stage of the project. For additional details consult the Requirement specification document.
4.1 Overview of architecture significant Use cases

Since the Local Monitor project is not presenting many use cases, all of them are detailed in this section.
Figure 4: LMON use cases.
4.2 Display readings

4.2.1 Use case goal To update the display with new data read from an input. 4.2.2 Use case scenario
Version 0.92 27.11.2002
side 8 af 13
Figure 5: Display readings scenario
4.3 Configure Display

4.3.1 Use case goal Change how samples from an input are presented on the display 4.3.2 Use case scenario
Figure 6: Configure Display
4.4 Control I-PUMP

4.4.1 Use case goal Send commands to the I-PUMP
Version 0.92 27.11.2002
side 9 af 13
4.4.2 Use case scenario
Figure 7: Control I-PUMP scenario
4.5 Manage Inputs

4.5.1 Use case goal Show samples from an additional input 4.5.2 Use case scenario
Figure 8: Manage inputs scenario.
4.6 Setup Alarms

4.6.1 Use case goal To setup a signal alarm in the system
Version 0.92 27.11.2002
side 10 af 13
4.6.2 Use case scenario
Figure 9: Setup alarms scenario.
4.7 Generate Alarm

4.7.1 Use case goal To give the operator visual and sound feedback when an alarm is raised. 4.7.2 Use case scenario
Figure 10: Generate alarm scenario.
Version 0.92 27.11.2002
side 11 af 13
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.
5.2 Use case realizations

5.2.1 Monitor Patient realization. The monitor patient use case is controlled by the class MonitorPatient. This class is implementing the necessary business logic to carry out the associated functionalities.
Figure 11: The monitor patient logical model.
Version 0.92 27.11.2002
side 12 af 13
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.
Figure 12: The system configuration logical model
Version 0.92 27.11.2002
side 13 af 13
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.
6.1 Process/task overview

The system should be able to acquire value from the various input signals, show them on the screen, as well as reacting to a user's inputs through the touch screen. These goals are fulfilled with the process design shown in the diagram below.
Figure 13: Process view of the system shown by a class diagram.
6.2 Process/task implementation

Threads are implemented by deriving from the abstract OS class Thread. This class implents the interface described in Abstrakt OO OS-API [2] The interface defines a virtual function run, in which the thread loop has to be defined. The thread loop is started by invoking the Thread class' start() method.
Version 0.92 27.11.2002
side 14 af 13
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.]
6.3 Process/task communication and synchronization

Data that should be shared between threads is protected using semaphores. Again the semaphores are implemented with an abstract OS class CountingSemaphore with an interface as described in [10]. The semaphore class is implemented with POSIX semaphores. The data aquisition and data presentation threads is an example of the classic producer/consumer problem, with the History acting as a buffer between the producer and the consumer. In our case, however, data are not removed from the buffer by the consumer, only a specific number of data items are read from the end of the History. The reason for this is that it should be possible to save historic data to disk. The history is thougt to be implemented with a circular buffer so that too old data is discarded, when the circular buffer is full. Storing and retrieving values from the history class is protected using the CountingSemaphore class, with an initial count of one, making the semaphore act as a binary semaphore.
6.4 Main thread

The main thread's responsiblity is construction of vital classes and starting the GUI. It runs until the user of the program exits it by clicking the display's close button.
6.5 Data Acquisition thread

The system has a thread for each signal defined. The thread is responsible for reading new values into a signal input's history. Each signal input defined in the system has its own thread in order to allow different data aquisition frequencies.
6.6 Data presentation

This thread is reponsible for updating the GUI with new values. It does this by retrieving the latest n readings from each defined signal's history and drawing it on screen. Note that there is only one thread in the system with this responsibility as opposed to one for each defined signal as with the data aquisistion.
6.7 Alarm monitoring

The system has one thread responsible for raising an alarm whenever a signal crosses its defined limits.
Version 0.92 27.11.2002
side 15 af 13
6.8 IPUMP controlling

The system has one thread for each IPUMP defined in the system. It's responsibility is handle communication with an IPUMP.
Version 0.92 27.11.2002
side 16 af 13
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.
Version 0.92 27.11.2002
side 17 af 13
7.1.2 Testing configuration with physical devices.
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.
Figure 16: Tesing deployment configuration.
7.2 Node descriptions

7.2.1 Serial port nodes description. The serial port node refers to the serial port level adapter that is used in the system, more documentation about this device can be found at [7] 7.2.2 ADC nodes description. The ADC converter is a physical device that performs sampling, quantification, and codification of an analog signal in order to obtain a discrete value. This device is communicated through the SPI bus with the OMAP processor. More documentation about this device can be found at [8].
Version 0.92 27.11.2002
side 18 af 13
7.2.3 Signal generator node description. The signal generator is an
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].
Figure 18: Dev-kit 8000.
Version 0.92 27.11.2002
side 19 af 13
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.
8.1 The 5-layer architecture pattern

The five layer architectural pattern can be used in order to give the system a better structure depending on the functionality the different classes are performing. If the application design has been properly done, this separation should come as a natural concept. An overall view of the five layers that have been introduced in the system can be seen in the following package diagram. The direction of the arrows means the dependency between the packages. Taking for example the User Interfaces Package, it can be seen that it depends on the Application and the AbstractOS package. This can be explained due to the fact that it is using mechanisms like the thread or semaphore mechanisms defined and implemented in the AbstractOS or the history class, defined and implemented in the Application package. The same reasoning is applied in the rest of the relationships between the rest of the packages.
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.
Version 0.92 27.11.2002
side 20 af 13
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.
Version 0.92 27.11.2002
side 21 af 13
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.
8.2 State machine

The MonitorPatient is controlled as explained in the following state machine. Once the system is powered on, it can be either calibrated or run a test stage. The calibration will enter a nested state as it is shown in the diagram, while the run test state will allow the operator to start monitoring the patient if the tests are run successfully.
Version 0.92 27.11.2002
side 22 af 13
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.
Version 0.92 27.11.2002
side 23 af 13
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.
8.3 Alarm monitoring

The observer pattern is applied in order to supervise the different signal readings the system is monitoring. The observer pattern is suitable in this context due to several reasons: There are two dependent aspects in the used abstractions, the actual values and the attached alarms. A change on the actual value could lead to alarm triggering, that means that a change to one object requires changing others. According to the Observer pattern structure, a Subject and an Observer must be identified: Subject: The history class, which contains a set of samples provided by the signal class. Observer: The alarm manager, responsible for keeping track on the values contained at the history class and comparing them with the Alarm Manager associated alarms.
Version 0.92 27.11.2002
side 24 af 13
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.
Version 0.92 27.11.2002
side 25 af 13
9. GENEREL DESIGN DECISIONS

9.1 Architectural goals and constraints 9.2 Architectural patterns 9.3 General user interface design rules 9.4 Exception and error handling 9.5 Implementation languages and tools 9.6 Implementation libraries
Version 0.92 27.11.2002
side 26 af 13
10. COMPILATION AND LINKING

This section describes compilation, linking and execution of prototype.
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.
10.2 Compilation and linking process

10.2.1 How to build a executable for the virtual machine
qmake project; qmake; make; # create a Qt project file from the .cpp and .h #files in the current directory #create a makefile from the qt project file #compile and link into an executable
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
Version 0.92 27.11.2002
side 27 af 13
For program non-GUI programs, the CodeSourcery C++ tool chain is used by invoking armnone-linux-gnueabi-g++ in place of regular g++.
11. INSTALLATION AND EXECUTING

11.1 Target setup
The target is set up with IP 192.168.0.2, and the build environment with IP 192.168.0.1.
ifconfig usb0 192.168.0.1
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.
11.3 Execution-control (start, stop and restart)

The executable is invoked with
./mainwindow -qws 1
which will invoke the regular confiraration using the AD converters, or

./mainwindow -qws 2
which will invoke the test mode configuration.
Version 0.92 27.11.2002
side 28 af 13
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).
12.2 On-line resources

[5] SD image with a precompiled version of linux for the dev-kit 8000. \\Home10.iha.dk\common\staff2stud\EIT-elektro og IKT\3. Semester\MUP1\DevKit8000 Golden Image\goldenSdImage_v2_512.tar.gz [6] Getting started with QT. A manual describing the required steps to get the QT libraries up an running on the dev-kit 8000 http://devkit8000.wikispaces.com/file/view/Getting+Started+with+Qt.pdf [7] Serial port level adapter MAX232 http://focus.ti.com/lit/ds/slls410i/slls410i.pdf [8] ADC converter ADS78070 http://focus.ti.com/lit/ds/slls410i/slls410i.pdf [9] Dev-kit 8000 retailer. http://www.embedinfo.com/English/Product/devkit8000.asp [10] Specification of Abstract OS http://kurser.iha.dk/eit/tiirts/Exercises/Specifikation%20af%20OS%20API.pdf [11] Dev-kit 8000 Wikispaces documentation. http://devkit8000addon.wikispaces.com/
Version 0.92 27.11.2002
side 29 af 13

Local Monitor System Product Doc

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Local Monitor System Product Doc

Hochgeladen von

Copyright:

Verfügbare Formate

Local Monitor System. Product documentation.

Embedded Real-Time Systems

System/product architecture document

Version 0.92 27.11.2002

System/product architecture document

System/product architecture document

12.2 On-line resources ......................................................................................................... 29

Version 0.92 27.11.2002

System/product architecture document

1.3 Definitions and acronyms

Version 0.92 27.11.2002

System/product architecture document

1.4 Document structure and reading guide

1.5 Document role in an iterative development process

Version 0.92 27.11.2002

System/product architecture document

Version 0.92 27.11.2002

System/product architecture document

2.2 System context

Figure 3: Actor context diagram of the system.

Version 0.92 27.11.2002

System/product architecture document

3.1 Interface to human actors

3.2 Interface to external system actors

3.3 Interface to hardware actors

Version 0.92 27.11.2002

System/product architecture document

4. USE CASE VIEW

4.1 Overview of architecture significant Use cases

Figure 4: LMON use cases.

4.2 Display readings

Version 0.92 27.11.2002

System/product architecture document

Figure 5: Display readings scenario

4.3 Configure Display

Figure 6: Configure Display

4.4 Control I-PUMP

Version 0.92 27.11.2002

System/product architecture document

4.4.2 Use case scenario

Figure 7: Control I-PUMP scenario

4.5 Manage Inputs

Figure 8: Manage inputs scenario.

4.6 Setup Alarms

Version 0.92 27.11.2002

System/product architecture document

4.6.2 Use case scenario

Figure 9: Setup alarms scenario.

4.7 Generate Alarm

Figure 10: Generate alarm scenario.

Version 0.92 27.11.2002

System/product architecture document

5.2 Use case realizations

Figure 11: The monitor patient logical model.

Version 0.92 27.11.2002

System/product architecture document

Figure 12: The system configuration logical model

Version 0.92 27.11.2002

System/product architecture document

6.1 Process/task overview

Figure 13: Process view of the system shown by a class diagram.

6.2 Process/task implementation

Version 0.92 27.11.2002