ArchitecturalDocumentV2.docx embeded

7/28/2019 ArchitecturalDocumentV2.docx embeded

1/31

Local Monitor System. Product documentation.

Embedded Real-Time Systems

Spring 2010

Torben Helligs [email protected] 20097659Jos Antonio Esparza [email protected] 20097706

Amos Hoste [email protected]
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/31

System/product architecture document System/product

Version 0.92 27.11.2002 side 0 af 13

Table of Contents

1. INTRODUCTION................................................................................................................ 31.1 Purpose and Scope ........................................................................................................... 31.2 References ........................................................................................................................ 3

1.3 Definitions and acronyms ................................................................................................ 31.4 Document structure and reading guide ............................................................................ 41.5 Document role in an iterative development process ........................................................ 4

2. SYSTEM OVERVIEW ....................................................................................................... 52.1 System introduction ......................................................................................................... 52.2 System context ................................................................................................................. 6

3. SYSTEM INTERFACES .................................................................................................... 73.1 Interface to human actors ................................................................................................. 73.2 Interface to external system actors ................................................................................... 7

3.3 Interface to hardware actors ............................................................................................. 7

4. USE CASE VIEW ................................................................................................................ 84.1 Overview of architecture significant Use cases ............................................................... 84.2 Display readings ............................................................................................................... 8

4.2.1 Use case goal ............................................................................................................ 84.2.2 Use case scenario ...................................................................................................... 8

4.3 Configure Display ............................................................................................................ 94.3.1 Use case goal ............................................................................................................ 94.3.2 Use case scenario ...................................................................................................... 9

4.4 Control I-PUMP ............................................................................................................... 9

4.4.1 Use case goal ............................................................................................................ 94.4.2 Use case scenario .................................................................................................... 10

4.5 Manage Inputs ................................................................................................................ 104.5.1 Use case goal .......................................................................................................... 104.5.2 Use case scenario .................................................................................................... 10

4.6 Setup Alarms .................................................................................................................. 104.6.1 Use case goal .......................................................................................................... 104.6.2 Use case scenario .................................................................................................... 11

4.7 Generate Alarm .............................................................................................................. 114.7.1 Use case goal .......................................................................................................... 114.7.2 Use case scenario .................................................................................................... 11

5. LOGICAL VIEW............................................................................................................... 125.1 Overview ........................................................................................................................ 125.2 Use case realizations ...................................................................................................... 12

5.2.1 Monitor Patient realization. .................................................................................... 125.2.2 System setup realization. ........................................................................................ 13

6. PROCESS/TASK VIEW ................................................................................................... 146.1 Process/task overview .................................................................................................... 146.2 Process/task implementation .......................................................................................... 146.3 Process/task communication and synchronization ......................................................... 156.4 Main thread .................................................................................................................... 15


3/31


Version 0.92 27.11.2002 side 1 af 13

6.5 Data Acquisition thread.................................................................................................. 156.6 Data presentation ............................................................................................................ 156.7 Alarm monitoring ........................................................................................................... 156.8 IPUMP controlling ......................................................................................................... 16

7. DEPLOYMENT VIEW ..................................................................................................... 177.1 System configurations .................................................................................................... 17

7.1.1 Full deployment ...................................................................................................... 177.1.2 Testing configuration with physical devices. ......................................................... 187.1.3 Testing configuration with counting devices. ......................................................... 18

7.2 Node descriptions ........................................................................................................... 187.2.1 Serial port nodes description. .................................................................................. 187.2.2 ADC nodes description. .......................................................................................... 187.2.3 Signal generator node description. .......................................................................... 197.2.4 Dev-kit 8000 node description ................................................................................ 19

8. IMPLEMENTATION VIEW ........................................................................................... 208.1 The 5-layer architecture pattern ..................................................................................... 20

8.1.1 Abstract hardware component ................................................................................ 208.1.2 Abstract hardware domain ...................................................................................... 218.1.3 Communication domain .......................................................................................... 228.1.4 User interface domain ............................................................................................. 228.1.5 Application domain ................................................................................................. 22

8.2 State machine ................................................................................................................. 228.2.1 State machine implementation ................................................................................ 238.2.2 Sigleton pattern for instantiating the concrete states. ............................................. 238.2.3 Faade pattern for accessing the MonitorPatient classes. ....................................... 24

8.3 Alarm monitoring ........................................................................................................... 249. GENEREL DESIGN DECISIONS ................................................................................... 26

9.1 Architectural goals and constraints ................................................................................ 269.2 Architectural patterns ..................................................................................................... 269.3 General user interface design rules ................................................................................ 269.4 Exception and error handling ......................................................................................... 269.5 Implementation languages and tools .............................................................................. 269.6 Implementation libraries ................................................................................................ 26

10. COMPILATION AND LINKING.................................................................................. 2710.1 Compilation-software ................................................................................................... 27

10.1.1 Building environment ........................................................................................... 2710.2 Compilation and linking process .................................................................................. 27

10.2.1 How to build a executable for the virtual machine ............................................... 2710.2.2 How to build a executable for the target ............................................................... 27

11. INSTALLATION AND EXECUTING .......................................................................... 2811.1 Target setup .................................................................................................................. 2811.2 Executing-software ...................................................................................................... 2811.3 Execution-control (start, stop and restart) .................................................................... 28

12. REFERENCES ................................................................................................................. 2912.1 Related documents ....................................................................................................... 29


4/31


Version 0.92 27.11.2002 side 2 af 13

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


5/31


Version 0.92 27.11.2002 side 3 af 13

1.INTRODUCTION

1.1Purpose 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 displaysvital signals such as Electrocardiographic signal, pulse or oximetry, that are relevant tosupervise the patient state.

The system will be developed as an academic project for the course Embedded Real TimeSystem, taking place at the Engineering College of Aarhus.

1.2References

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.3Definitions and acronyms

A/D Analog to Digital Converter. Electronical device responsiblefor sampling and scaling an analog continuous signal in orderto convert it into a digital one.

Electrocardiograph Continuous signal representing the electrical activity of theheart

Ethernet Standard for network communications GUI Graphical User Interface. Software responsible for user

interaction through elements such as buttons, windows, textareas...

I-PUMP Infusion Pump. Electromechanical device responsible forautomatic drug delivery.

Linux Open-source operating system LMON Local Monitor. Device introduce in this paper, able to monitor

patient vital signs

mmHg Millimeter of mercury, pressure unit Oximetry Continuous signal representing the patients hemoglobin

oxygenation

P-SIM Patient Simulator. Electromechanical device able to reproduce


6/31


Version 0.92 27.11.2002 side 4 af 13

human vital signals. Used in medical training.

QT Open-source libraries used to create Graphical User Interfaces RS232 Serial communication standard Transducer Electromechanical device able to convert a mechanical signal

into an electrical one.

1.4Document structure and reading guide

This document is composed by twelve main chapters. The introduction part gives a generaloverview of the document, detailing purpose and most relevant concepts. In the secondchapter, System Overview, the product is contextualized and its main features andfunctionalities are described. In the System Interfaces chapter, the different communicationmechanisms 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 showshow the system is used by the external actors. The Logical view chapter introduces thesoftware logical structure, focused on presenting the different entities and its representation inthe system. The Process Task view, introduced in chapter 6, details how the system isorganized in run time, introduction the actives objects of the system and the synchronizationmechanisms. In the Deployment View chapter, the possible system configurations and

physical deployment schemes are shown. The Implementation view chapter gives a moredetailed insight on the technical aspects, showing additional UML diagrams focused on theimplementation.

The Data view chapter presents how data abstractions have been applied, and somediscussion on the persistence layer. The general design decisions chapter explainsarchitectural constrains, general design rules that have been followed and which technologieshave been applied.

The two last chapters, Compilation and linking and Installation and Executing, presents themandatory procedures to reproduce the work that have been done in this project, taking as a

base the existing hardware and software.

1.5Document role in an iterative development process

The core ideas behind this document have been iteratively and incrementally refined andimproved. 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 andSystem Intefaces) were generated at the very beginning of the project.

Other parts have been created during project development like, for example, the differentarchitectural views of the system.

At the end specific guidelines about software compilation, deployment and installation havebeen detailed.


7/31


Version 0.92 27.11.2002 side 5 af 13

2.SYSTEM OVERVIEW

2.1System introduction

The LOCAL monitor system is an electronic device that is able to display a set of vital signsto allow constant patient monitoring. This system is intended to be used in combination withspecial transducers, able to transform human variables like pulse, oximetry or temperatureinto 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 LCDtouch screen display, allowing direct access to the current measurements through a window-

based friendly user interface.

Depending on patient state, several alarms can be configured and automatically triggered ifthere is a potential threat to the patient health, displaying a message on the screen and playingan alarm sound.

Figure 1: System Overview Diagram. The Patient vital signs are measured by using theappropriate 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 standalonemode or connected to an Infusion Pump, in order to control the medicine flow to the patientdepending on current patient conditions.


8/31


Version 0.92 27.11.2002 side 6 af 13

2.2System context

The following diagram contextualizes the system by showing the main actors involved withthe Local Monitor Operation. Each actor represents a single role that one or several users canhold at a single time. In the following sections the involved actors will be described in detail.

Figure 3: Actorcontext diagram of the system.


9/31


Version 0.92 27.11.2002 side 7 af 13

3.SYSTEM INTERFACESThe LMON system is supposed to be running on the Embest Devkit8000 hardware with anIHA addon board. The addon board among other things adds a touchscreen, RS232 interfacesand D/A and A/D converters.

The Devkit 8000 board is running the ngstrm GPE linux distribution set up with ssh/scp, aserial USB connection.

Qt Everywhere Open Source 4.6.2 is used for implementing the GUI.

3.1Interface to human actors

The operator interacts with the system using the touchscreen. The technician will downloadnew versions of the software using the serial USB connection and scp.

3.2Interface to external system actors

The system interacts with the IPUMP system with commands as described in [3].

3.3Interface to hardware actorsECG 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 detailson 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.


10/31


Version 0.92 27.11.2002 side 8 af 13

4.USE CASE VIEWThis section introduces the use cases and the use case scenarios that were detected in the usecase analysis stage of the project. For additional details consult the Requirement specificationdocument.

4.1Overview of architecture significant Use cases

Since the Local Monitor project is not presenting many use cases, all of them are detailed inthis section.

Figure 4: LMON use cases.

4.2Display readings

4.2.1Use case goal

To update the display with new data read from an input.

4.2.2Use case scenario


11/31


Version 0.92 27.11.2002 side 9 af 13

Figure 5: Display readings scenario

4.3Configure Display

4.3.1Use case goal

Change how samples from an input are presented on the display


Figure 6: Configure Display

4.4Control I-PUMP

4.4.1Use case goal

Send commands to the I-PUMP


12/31


Version 0.92 27.11.2002 side 10 af 13


Figure 7: Control I-PUMP scenario

4.5Manage Inputs

4.5.1Use case goal

Show samples from an additional input


Figure 8: Manage inputs scenario.

4.6Setup Alarms

4.6.1Use case goal

To setup a signal alarm in the system


13/31


Version 0.92 27.11.2002 side 11 af 13


Figure 9: Setup alarms scenario.

4.7Generate Alarm

4.7.1Use case goal

To give the operator visual and sound feedback when an alarm is raised.


Figure 10: Generate alarm scenario.


14/31


Version 0.92 27.11.2002 side 12 af 13

5.LOGICAL VIEWThe logical view of the architecture describes the software structure and helps to identify themain classes.

5.1Overview

The logical view of the system is mainly composed by two class diagrams that shows the howthe use cases are satisfied by the application architecture.

In this design the Model Controller Boundary structure has been applied. For furtherdetails on this structure reference [12] can be consulted. One of the key ideas was to associatea 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 theintroduced controller classes in these designs. For each first level use case there is anassociated controller class. For each extended use case there is one more associated controllerclass implementing the business logic.

5.2Use case realizations

5.2.1Monitor Patient realization.

The monitor patient use case is controlled by the class MonitorPatient. This class isimplementing the necessary business logic to carry out the associated functionalities.

Figure 11: The monitor patient logical model.


15/31


Version 0.92 27.11.2002 side 13 af 13

Since the monitor patient use case extends the use cases display Readings, Control IPUMPand generate alarm, additional controller classes have been added. This helps to decouple thefunctionality and to separate the responsibilities in the system. As secondary controllers, thesystem 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.2System setup realization.

The business logic of the use case Setup system is implemented in the class SystemConfiguration. This Setup system use case extends the use cases Configure Display, SetupAlarm and Manage inputs. As in the previous case, this secondary use cases are implementedin 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


16/31


Version 0.92 27.11.2002 side 14 af 13

6.PROCESS/TASK VIEWThis section describes the considerations taken on threads and communication between themas well as timing issues. Furthermore, it is described how the threads, semaphores and timersare used and implemented in the system.

6.1Process/task overview

The system should be able to acquire value from the various input signals, show them on thescreen, as well as reacting to a user's inputs through the touch screen. These goals are fulfilledwith the process design shown in the diagram below.

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

6.2Process/task implementation

Threads are implemented by deriving from the abstract OS class Thread. This class implentsthe interface described in Abstrakt OO OS-API [2] The interface defines a virtual functionrun, in which the thread loop has to be defined. The thread loop is started by invoking theThread class' start() method.


17/31


Version 0.92 27.11.2002 side 15 af 13

The Thread class uses POSIX threads to implement threading, a way of making the codeportable to any POSIX compliant operating system. If one was to build the code for anothernon-POSIX compliant platform, one could easily reimplement the Thread class, still using thesame interface. By using the abstract OS classes, the code is made less dependent on theactual target OS used.

The thread frequency is implemented by sleeping for a specific number of milliseconds. Thesleeping functionality is implemented using an abstract OS class Sleeptimer with an interfaceas defined in [10.]

6.3Process/task communication and synchronization

Data that should be shared between threads is protected using semaphores. Again thesemaphores are implemented with an abstract OS class CountingSemaphore with an interfaceas described in [10]. The semaphore class is implemented with POSIX semaphores.

The data aquisition and data presentation threads is an example of the classicproducer/consumer problem, with the History acting as a buffer between the producer and theconsumer. In our case, however, data are not removed from the buffer by the consumer, onlya specific number of data items are read from the end of the History. The reason for this isthat it should be possible to save historic data to disk. The history is thougt to be implementedwith 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 theCountingSemaphore class, with an initial count of one, making the semaphore act as a binarysemaphore.

6.4Main threadThe main thread's responsiblity is construction of vital classes and starting the GUI. It runsuntil the user of the program exits it by clicking the display's close button.

6.5Data Acquisition thread

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

6.6Data presentation

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

6.7Alarm monitoring

The system has one thread responsible for raising an alarm whenever a signal crosses its

defined limits.


18/31


Version 0.92 27.11.2002 side 16 af 13

6.8IPUMP controlling

The system has one thread for each IPUMP defined in the system. It's responsibility is handlecommunication with an IPUMP.


19/31


Version 0.92 27.11.2002 side 17 af 13

7.DEPLOYMENT VIEW

7.1System 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.1Full deployment

Figure 14: Deployment diagram of configuration 1. The system deployment with the externalsystem actors Intelligent PUMP and Patient Simulator.


20/31


Version 0.92 27.11.2002 side 18 af 13

7.1.2Testing 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.3Testing configuration with counting devices.

Figure 16: Tesing deployment configuration.

7.2Node descriptions

7.2.1Serial port nodes description.

The serial port node refers to the serial port level adapter that is used in the system, moredocumentation about this device can be found at [7]

7.2.2ADC nodes description.

The ADC converter is a physical device that performs sampling, quantification, andcodification of an analog signal in order to obtain a discrete value. This device iscommunicated through the SPI bus with the OMAP processor. More documentation about

this device can be found at [8].


21/31


Version 0.92 27.11.2002 side 19 af 13

7.2.3Signal generator node description.

The signal generator is an

Figure 17: The Hameg signal generator used in the prototype deployment

7.2.4Dev-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 foundat [9].

Figure 18: Dev-kit 8000.


22/31


Version 0.92 27.11.2002 side 20 af 13

8.IMPLEMENTATION VIEWThis 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 patternsfrom [GOF] used in the design of the system.

8.1The 5-layer architecture pattern

The five layer architectural pattern can be used in order to give the system a better structuredepending on the functionality the different classes are performing. If the application designhas been properly done, this separation should come as a natural concept. An overall view ofthe five layers that have been introduced in the system can be seen in the following packagediagram.

The direction of the arrows means the dependency between the packages. Taking for examplethe User Interfaces Package, it can be seen that it depends on the Application and theAbstractOS package. This can be explained due to the fact that it is using mechanisms likethe thread or semaphore mechanisms defined and implemented in the AbstractOS or thehistory class, defined and implemented in the Application package. The same reasoning isapplied 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 thefunctionalities can be easily ported to other platforms due to function separation(functionality is decoupled). Apart from this, this pattern is considered as a highly efficientone, because of the small number of layers it is introducing (page 150 at [1]).

8.1.1Abstract hardware component

The diagram below shows the Abstract OS component.


23/31


Version 0.92 27.11.2002 side 21 af 13

Figure 20: Abstract OS layer.

The purpose of this domain is to provide an abstraction layer above the operating system inorder to make the design less OS type specific and improve portability. In this domain OS-specific classes exist that encapsulates OS objects such as threads, semaphores and timers. Ascan 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 theclasses in the abstract OS domain had to be re-implemented.

8.1.2Abstract hardware domain

As in the layer just described, the purpose of this layer is to provide an abstraction layer, thistime 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 signalcomes 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.


24/31


Version 0.92 27.11.2002 side 22 af 13

Figure 21: Abstract HW layer.

8.1.3Communication domain

In this domain classes exists which implements communicion with external systems. In theLMON system this first an foremost means classes for implementing the protocol forcontrolling the IPUMP.

8.1.4User interface domain

In this domain classes exist for interacting with the user. Here classes for the user interfacelibrary used exist, that is, the Qt classes, but also classes defined by us such as MainWindowand ContinuousDisplay.

8.1.5Application domain

This domain holds the entity classes and business logic of the system.

8.2State machine

The MonitorPatient is controlled as explained in the following state machine. Once thesystem is powered on, it can be either calibrated or run a test stage. The calibration will entera nested state as it is shown in the diagram, while the run test state will allow the operator tostart monitoring the patient if the tests are run successfully.


25/31


Version 0.92 27.11.2002 side 23 af 13

Figure 22: State machine that specifies the system operation for the use case MonitorPatient.

8.2.1State machine implementation

There are several ways to implement a state machine like, for example use a switchstatement, create an adjacent matrix to regulate the transitions or apply the state pattern. Thislast 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 thefunctionalities that are carried out inside the different states.

The implementation of the state pattern in the monitor patient case can be seen in the nextclass diagram. The monitor patient class acts as a context class, which has a one to oneaggregation with the state superclass. The state superclass is the one from which the rest ofthe concrete states are inheriting from. As a result of this, the normal s tates Start, Stopand 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 theconcrete states CalibrationFinished, ComparingReference, WaitingSignals and

Adjusting.

8.2.2Sigleton pattern for instantiating the concrete states.Since it is not desirable to face a situation in which several instances of a class exist withinthe 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 staticmethod Instance. In the case that it has not been previously instantiated, object creation willtake place, and a pointer will be assigned in the state _instance attribute of the class. Ifinstance already exists, a pointer will be returned.


26/31


Version 0.92 27.11.2002 side 24 af 13

8.2.3Faade pattern for accessing the MonitorPatient classes.

The Faade pattern provides a high level interface between a to the rest of the monitorpatient subsystem. The intent is to have a common point to access the classes that implementthe 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 machinecan control the whole monitor patient controller and the results from system operation can befeedback to the state machine through the defined signals.

Figure 23: State machine implementation. The state machine has been implemented by usingthe state pattern in combination with the singleton and facade pattern.

8.3Alarm monitoring

The observer pattern is applied in order to supervise the different signal readings thesystem is monitoring. The observer pattern is suitable in this context due to severalreasons:

There are two dependent aspects in the used abstractions, the actual values and theattached alarms.

A change on the actual value could lead to alarm triggering, that means that a changeto one object requires changing others.

According to the Observer pattern structure, a Subject and an Observer must beidentified:

Subject: The history class, which contains a set of samples provided by the signalclass.

Observer: The alarm manager, responsible for keeping track on the values containedat the history class and comparing them with the Alarm Manager associated alarms.


27/31


Version 0.92 27.11.2002 side 25 af 13

By applying the observer pattern the supervising functionality is decoupled. Thisallows the History not to care about how the alarms should be checked or which limitsthey should present.

Figure 24: Application of the observer pattern in the SignalAlarm supervision.

Whenever the history class is updated with new readings, these will be added with themethod store (the setState equivalence). The NotifyObservers function will be executed so allthe attached observers to the history subject will by updated by using a push scheme. Theinformation flow is shown in the sequence diagram below:

Figure 25: Sequence diagram showing the information flow in the observer pattern applied tothe historyalarm manager case.


28/31


Version 0.92 27.11.2002 side 26 af 13

9.GENEREL DESIGN DECISIONS

9.1Architectural goals and constraints

9.2Architectural patterns

9.3General user interface design rules

9.4Exception and error handling

9.5Implementation languages and tools

9.6Implementation libraries


29/31


Version 0.92 27.11.2002 side 27 af 13

10.COMPILATION AND LINKINGThis section describes compilation, linking and execution of prototype.

10.1Compilation-software

10.1.1Building environmentThe 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 og IKT\3.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-51toolchain 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 Source4.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

10.2Compilation and linking process

10.2.1How to build a executable for the virtual machine

qmake project; # create a Qt project file from the .cpp and .h

#files in the current directory

qmake; #create a makefile from the qt project file

make; #compile and link into an executable

For programs not using Qt, g++ can be invoked directly from a terminal. When POSIXthreads, semaphores or timers is used, it is necessary to link with the rt library:

g++ History.cpp -lrt -o History

10.2.2How to build a executable for the targetIn order to build Qt executables for the target, the same three steps as before is necessary, thistime instead of using the standard qmake, which will produce makefiles for the x86architecture, a special version of qmake is used, which will produce makefiles for the ARMarchitecture.

In the following, Qt everywhere is assumed to be installed in in the directory ~/qt-everywhere-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


30/31


Version 0.92 27.11.2002 side 28 af 13

For program non-GUI programs, the CodeSourcery C++ tool chain is used by invoking arm-none-linux-gnueabi-g++ in place of regular g++.

11.INSTALLATION AND EXECUTING

11.1Target 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 thetarget Qt library files must be copied to the target as described in [2]. The touchscreen iscalibrated by invoking ts_calibrate on target.

In order to use the A/D converters, the kernel module ads7890.ko must be loaded an devicescreated 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.2Executing-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 iscallibrated by executing ts_callibrate on the target.

11.3Execution-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.


31/31


12.REFERENCES

12.1Related 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 speficifactiondocument 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.2On-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\DevKit8000Golden Image\goldenSdImage_v2_512.tar.gz

[6]Getting started with QT. A manual describing the required steps to get the QT libraries upan running on the dev-kit 8000http://devkit8000.wikispaces.com/file/view/Getting+Started+with+Qt.pdf

[7]Serial port level adapter MAX232http://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/
http://home10.iha.dk/common/staff2stud/EIT-elektro%20og%20IKT/3.%20Semester/MUP1/DevKit8000%20Golden%20Image/goldenSdImage_v2_512.tar.gzhttp://home10.iha.dk/common/staff2stud/EIT-elektro%20og%20IKT/3.%20Semester/MUP1/DevKit8000%20Golden%20Image/goldenSdImage_v2_512.tar.gzhttp://home10.iha.dk/common/staff2stud/EIT-elektro%20og%20IKT/3.%20Semester/MUP1/DevKit8000%20Golden%20Image/goldenSdImage_v2_512.tar.gzhttp://devkit8000.wikispaces.com/file/view/Getting+Started+with+Qt.pdfhttp://devkit8000.wikispaces.com/file/view/Getting+Started+with+Qt.pdfhttp://focus.ti.com/lit/ds/slls410i/slls410i.pdfhttp://focus.ti.com/lit/ds/slls410i/slls410i.pdfhttp://focus.ti.com/lit/ds/slls410i/slls410i.pdfhttp://focus.ti.com/lit/ds/slls410i/slls410i.pdfhttp://focus.ti.com/lit/ds/slls410i/slls410i.pdfhttp://www.embedinfo.com/English/Product/devkit8000.asphttp://www.embedinfo.com/English/Product/devkit8000.asphttp://www.embedinfo.com/English/Product/devkit8000.asphttp://kurser.iha.dk/eit/tiirts/Exercises/Specifikation%20af%20OS%20API.pdfhttp://kurser.iha.dk/eit/tiirts/Exercises/Specifikation%20af%20OS%20API.pdfhttp://devkit8000addon.wikispaces.com/http://devkit8000addon.wikispaces.com/http://devkit8000addon.wikispaces.com/http://devkit8000addon.wikispaces.com/http://kurser.iha.dk/eit/tiirts/Exercises/Specifikation%20af%20OS%20API.pdfhttp://www.embedinfo.com/English/Product/devkit8000.asphttp://focus.ti.com/lit/ds/slls410i/slls410i.pdfhttp://focus.ti.com/lit/ds/slls410i/slls410i.pdfhttp://devkit8000.wikispaces.com/file/view/Getting+Started+with+Qt.pdfhttp://home10.iha.dk/common/staff2stud/EIT-elektro%20og%20IKT/3.%20Semester/MUP1/DevKit8000%20Golden%20Image/goldenSdImage_v2_512.tar.gzhttp://home10.iha.dk/common/staff2stud/EIT-elektro%20og%20IKT/3.%20Semester/MUP1/DevKit8000%20Golden%20Image/goldenSdImage_v2_512.tar.gz

ArchitecturalDocumentV2.docx embeded

Documents

Transcript of ArchitecturalDocumentV2.docx embeded