IN
DEGREE PROJECT MEDICAL ENGINEERING, SECOND CYCLE, 30 CREDITS
STOCKHOLM SWEDEN 2016,
Development of a Flexible
Software Framework for Biosignal PI
AN OPEN-SOURCE BIOSIGNAL ACQUISITION AND PROCESSING SYSTEM
MARTIN RÖSTIN
Development of a Flexible Software Framework for Biosignal PI,
An Open-Source Biosignal Acquisition and Processing System
Utveckling av ett Flexibelt Mjukvaruramverk för Biosignal PI,
ett system för insamling och bearbetning av biomedicinska signaler med öppen källkod
Martin Röstin
Master of Science Thesis in Medical Engineering Advanced level (second cycle), 30 credits Supervisor at KTH: Farhad Abtahi Examiner: Mats Nilsson School of Technology and Health TRITA-STH, EX 2016:10 Royal Institute of Technology KTH STH
Abstract
As the world population ages, the healthcare system is facing new challenges in treating more patients at a lower cost than today. One trend in addressing this problem is to increase the opportunities of in-home care. To achieve this there is a need for safe and cost-effective monitoring systems. Biosignal PI is an ongoing open-source project created to develop a flexible and affordable platform for development of stand-alone devices able to measure and process physiological signals.
This master thesis project, performed at the department of Medical Sensors, Signals and System at the School of Technology and Health, aimed at further develop the Biosignal PI software by constructing a new flexible software framework architecture that could be used for measurement and processing of different types of biosignals. The project also aimed at implementing features for Heart Rate Variability(HRV) Analysis in the Biosignal PI software as well as developing a graphical user interface(GUI) for the Raspberry PI hardware module PiFace Control and Display.
The project developed a new flexible abstract software framework for the Biosignal PI. The new framework was constructed to abstract all hardware specifics into smaller interchangeable modules, with the idea of the modules being independent in handling their specific task making it possible to make changes in the Biosignal PI software without having to rewrite all of the core. The new developed Biosignal PI software framework was implemented into the existing hardware setup consisting of an Raspberry PI, a small and affordable single-board computer, connected to ADAS1000, a low power analog front end capable of recording an Electrocardiography(ECG).
To control the Biosignal PI software two different GUIs were implemented. One GUI extending the original software GUI with the added feature of making it able to perform HRV-Analysis on the Raspberry PI. This GUI requires a mouse and computer screen to function. To be able to control the Biosignal PI without mouse the project also created a GUI for the PiFace Control and Display. The PiFace GUI enables the user to collect and store ECG signals without the need of an big computer screen, increasing the mobility of the Biosignal PI device.
To help with the development process and also to make the project more compliant with the Medical Device Directive a couple of development tools were implemented such as a CMake build system, integrating the project with the Googletest testing framework for automated testing and the implementation of the document generator software Doxygen to be able to create an Software Documentation.
Keywords: Biosignal PI, Software Framework, Raspberry PI, PiFace Control and Display, Electrocardiography(ECG), Heart Rate Variability(HRV), Open-Source, Medical Device De- velopment, Medical Device Software
Sammanfattning
Allt eftersom världens befolkning åldras, ställs sjukvården inför nya utmaningar i att behandla fler patienter till en lägre kostnad än idag. En trend för att lösa detta problem är att utöka möjligheterna till vård i hemmet. För att kunna göra detta finns det ett ökande behov av säkra och kostnadseffektiva patientövervakningssystem. Biosignal PI är ett pågående projekt med öppen källkod som skapats för att utveckla en flexibel och prisvärd plattform för utveckling av fristående enheter som kan mäta och bearbeta olika fysiologiska signaler.
Detta examensarbete genomfördes vid institutionen för medicinska sensorer, signaler och sys- tem vid Skolan för Teknik och Hälsa. Projektet syftade till att vidareutveckla den befintliga mjukvaran för Biosignal PI genom att skapa ett nytt flexibelt mjukvaruramverk som kan an- vändas för mätning och bearbetning av olika typer av biosignaler. Projektet syftade också till att utvidga mjukvaran och lägga till funktioner för att kunna genomföra hjärtfrekvensvari- abilitets(HRV) analys i Biosignal PIs mjukvara, samt att utveckla ett grafiskt användargränss- nitt(GUI) för hårdvarumodulen PiFace Control and Display.
Projektet har skapat ett nytt flexibelt mjukvaruramverk för Biosignal PI. Det nya ramverket konstruerades för att abstrahera alla hårdvaruspecifika delar in i mindre utbytbara moduler, med tanken att modulerna ska vara oberoende i hur de hanterar sin specifika uppgift. På så sätt ska det vara möjligt att göra ändringar i Biosignal PIs programvara utan att behöva skriva om hela mjukvaran. Det nyutvecklade Biosignal PI ramverket implementerades i det befintliga hårdvaru systemet, som består av en Raspberry PI, liten och prisvärd enkortsdator, ansluten till ADAS1000, en analog hårdvarumodul med möjlighet att registrera ett elektrokar- diografi(EKG/ECG).
För att kontrollera Biosignal PI programmet har två olika grafiska användargränssnitt skapats.
Det ena gränssnitt är en utvidgning av original programvaran med tillagd funktionalitet för att kunna göra HRV-Analys på Raspberry PI, detta gränssnitt kräver dock mus och dataskärm för att kunna användas. För att kunna styra Biosignal PI utan mus och skärm skapades det även ett gränssnitt för PiFace Control and Display. PiFace gränssnittet gör det möjligt för användaren att samla in och lagra EKG-signaler utan att behöva en stor datorskärm, på så sätt kan man öka Biosignal PI systemets mobilitet.
För att underlätta utvecklingsprocessen, samt göra projektet mer förenligt med det medicin- tekniska regelverket, har ett par utvecklingsverktyg integrerats till Biosignal PI projektet såsom CMake för kontroll av kompileringsprocessen, test ramverket Googletest för automatiserad testning samt integrering med dokumentations generatorn Doxygen för att kunna skapa en dokumentation av mjukvaran.
Nyckelord: Biosignal PI, Software Framework, Raspberry PI, PiFace Control and Display, Electrocardiography(ECG), Heart Rate Variability(HRV), open-source, Medical device devel- opment, Medical Device Software
Acknowledgements
First and foremost I would like to thank my supervisor Farhad Abtahi for giving me the opportunity to work on this project. I am also thankful for your invaluable support and feedback throughout the project.
I would also like to thank Anna Larsson, Cecilia Löwgren and Stefano Zappalà for your helpful feedback and discussions during our meetings.
Last, but not least, I would like to thank my family for your constant love and support.
Martin Röstin Stockholm, January 2016
Contents
List of Figures ix
List of Tables ix
Nomenclature xi
1 Introduction 1
1.1 Background . . . 1
1.2 Objective . . . 2
1.3 Outline . . . 2
2 Method 3 2.1 Biosignal PI Framework . . . 3
2.1.1 Software Requirements and Specifications . . . 3
2.1.2 Developing Methodology . . . 4
2.1.3 Design Patterns . . . 4
2.1.4 Cross-compilation and Implementing a Build System . . . 5
2.1.5 Software Testing . . . 5
2.2 Heart Rate Variability Analysis . . . 6
2.2.1 QRS-Detection . . . 6
2.2.2 Converting MATLAB Code into C++ Code . . . 7
2.3 Bluetooth . . . 9
2.4 Using PiFace Control and Display . . . 9
2.5 Documenting the Created Software . . . 9
3 Results 11 3.1 Biosignal PI Framework . . . 11
3.1.1 Device Facade . . . 11
3.1.2 Data Model and Logging . . . 11
3.1.3 Application Wide Settings . . . 12
3.1.4 CMake integration . . . 12
3.1.5 Automated Testing . . . 13
3.2 Heart Rate Variability Analysis Widget . . . 13
3.3 Bluetooth Transfer Widget . . . 13
3.4 PiFace Graphical User Interface . . . 13
3.5 Software Documentation . . . 17
4 Discussion 19 4.1 Biosignal PI Framework and software . . . 19 4.2 Biosignal PI as a Medical Device . . . 20
5 Conclusion 21
6 Future Work 23
Bibliography 25
Appendix A Literature Study 29
viii
List of Figures
2.1 Workflow for the development sprints . . . 5
2.2 QRS-Detection, From ECG-File to IBI-file . . . 6
2.3 Flowchart transforming MATLAB code to C++ . . . 8
2.4 RPI with connected PiFace, PiRack and ADAS . . . 10
3.1 Biosignal PI Framework Architecture . . . 12
3.2 Flowchart describing the HRV-Process . . . 14
3.3 Screenshot HrvWidget . . . 15
3.4 Screenshot Bluetooth Transfer Widget . . . 16
3.5 PiFace CAD with numbered switches . . . 16
3.6 Screenshot Biosignal PI documentation Homepage . . . 17
3.7 Screenshot BioSignal PI Documentation DeviceManager Class . . . 18
A.1 Illustration of typical ECG trace . . . 30
A.2 Raspberry PI 2 model B . . . 33
A.3 PiFace Control and Display . . . 34
List of Tables
A.1 Metrics for Time-Domain Analysis of HRV[22] . . . 31A.2 Metrics for Frequency-Domain Analysis of HRV[22] . . . 31
Nomenclature
ADAS Analog to Digital converter used for capturing biosignals ANS Autonomous Nervous System
ECG ElectroCardioGraphy
GPIO General- Purpose Input/Output GUI Graphical User Interface
HR Heart Rate
HRV Heart Rate Variability IBI Inter Beat Interval MDD Medical Device Directive OSS Open Source Software QT C++ software framework RPI Raspberry PI
SCM Source Control Management Software
Chapter 1
Introduction
1.1 Background
Healthcare is facing new challenges as the world population ages. According to the UN the proportion of people over 60 years in the world are projected to double over the next half century from 10% (2000) to 21% (2050)[1]. This aging will increase the spread of a wide range of non-communicable diseases such as heart-diseases, cancer, stroke and diabetes, while the proportion of working people per person older than 65 years is projected to be halved over the next 50 years. This forces the future healthcare to treat more patients while the cost needs to be lowered.[2]
To address these problems, there is a trend to increase the opportunities for in-home care.
An important step in providing effective home care is the availability of safe and cost-effective monitoring systems. Through the use of devices that can detect different biomedical signals, for example Electrocardiography(ECG), patients can be monitored from home without having to travel to the hospital as often. Studies conducted on patients with chronic conditions have shown that homecare systems can help patients to better handle their diseases[3], [4].
Biosignal PI is an on-going open source project that was started to create a flexible and afford- able platform for development of standalone devices for measurement of different biomedical signals. This thesis will be a continuation of the existing software created in a previous project.
The earlier developed software was designed to run on the Raspberry PI which is a small and affordable computer. This framework is primarily intended for research and educational use.
To allow for changes based on the needs of a specific project, the framework aims at being modular with interchangeable parts.[5]
2 Chapter 1. Introduction
1.2 Objective
The main objective of this project was to create a modular software framework architecture.
To test this new Biosignal PI framework new features was added to the Biosignal PI software.
In order to achieve this the objective was divided into four objectives.
• A modular software framework with equal functionality as original software for Biosignal PI
• Software with Heart Rate Variability analysis and Bluetooth functions implemented
• A Graphical User Interface for the hardware module PiFace Control and Display, making it possible to run the Biosignal PI without mouse, keyboard and computer monitor.
• Written documentation regarding the software design
1.3 Outline
A theoretical background to most of the concepts used in this thesis can be found in the Literature Study in Appendix A. Chapter 2 Methodology contains a description of the different methods used and how they have been used in the project. Chapter 3 Results describes the produced software and Chapter 4 Discussion covers a discussion of the different parts of both the produced framework and the Biosignal PI software as a whole. The Discussion also covers a part about how the Biosignal PI software complies with the Medical Device Directive regulating what is required for medical software.
Chapter 2
Method
The method chapter will cover a summary of how the different parts of the Biosignal PI software has been developed and the underlying process concerning the development of the different parts. More information about software development in general and an introduction to the different software and methods used can be found in section A.3 of the Literature Study in Appendix A.
2.1 Biosignal PI Framework
The main task of this project concerns modifications of the original software for the Biosig- nal PI in order of improving the modularity, interchangeability and ease of deployment for the software. The modularity and interchangeability was improved through the creation of a new Architectural Software Framework. The ease of deployment was simplified through implementation of a build system.
2.1.1 Software Requirements and Specifications
In the beginning of the project the original Biosignal PI software was analyzed to determine how the original software worked and also to establish a specification on what sort of require- ments the new framework would have to satisfy. The old GUI was found sufficient and the new implementations could build upon the existing core GUI. The specification were divided into general and functional requirements. The general requirements were important for developing software in general and Medical Device Software and the requirements set by the Software Development Life Cycle. For more information regarding Medical Device Software see section A.4 of the Literature Study in Appendix A. The general requirements were.
• Interchangeable
• Extendable
• Hardware independence
• Ease of Deployment
4 Chapter 2. Method
• Testable classes, dependency reduction
• Open-Source solutions
• Understandable code
The functional requirements were more target for the needs of this specific project with regards taken to the requirements specifications from the old Biosignal PI software[6]. The functional requirements for the Biosignal PI framework were.
• Capture physiological data/signal from an attached device
• Store captured data to file
• Visualize sampled data in real time and from file
• Process physiological data
2.1.2 Developing Methodology
After creating the requirements list for the framework, a small skeleton was developed with minimal functionality to act as the backbone for further developments. After completing the main skeleton framework and implementation of the build system mentioned in section 2.1.4, the development of the whole framework was divided into shorter sprints with a concrete re- quirement list stating what the sprint should implement into the main skeleton. To help with managing the development process the project used Git and Github for source code manage- ment and task tracking. For every new sprint a list of requirements and a new development branch was created in Git. When the sprint was finished and the developed software had been compiled and tested the current development branch was merged into the main branch. After completion of a sprint a new sprint was planned from the remaining list of things needed to implement. An illustration of the workflow for the software development can be seen in figure 2.1.
During the software development process the author of this thesis has strived to follow the Google C++ Style Guide[7] concerning naming, structure, functionality and convention for the developed software. The main reason for trying to follow a specific coding convention has been to simplify the code and making it easier to understand for future developers. Following a coding convention can also help with upholding a higher consistency through out the software.
2.1.3 Design Patterns
In order to make the project more general and easier to comprehend for someone not involved in the developing process, the author of this thesis has tried to implement widely established patterns and solutions during the software design. For example the DeviceManager, which is the module responsible for the connection and communication with the attached biomedical sensors, has been implemented according to the Facade pattern. Where one base class acts to
Chapter 2. Method 5
Figure 2.1: Workflow describing the Software Development Sprints
simplify the interface for the rest of the application. More information about design patterns in general can be found in section A.3.4 of Appendix A.
2.1.4 Cross-compilation and Implementing a Build System
The software have been developed and built from workstations using Ubuntu and Linux Mint.
In order for the software to run on the Raspberry PI the software has been cross-compiled with Raspbian as the intended host. To handle the cross-compilation and simplify the dependency tracking the build system CMake has been used. Through the creation of specific CMake configuration and toolchain files the same CMakeLists.txt has be used to build the software for different systems. The configuration and toolchain files specifies were to look for the needed dependencies. To further simplify building the Biosignal PI on different computers, some BASH scripts were created to build and install all the different software and dependencies needed for building and developing the Biosignal PI from a Linux computer.
2.1.5 Software Testing
6 Chapter 2. Method
handled through the creation of a CMake configuration file specific for the testing framework.
The written tests were automatically built together with the rest of the software when CMake and Make was called. The tests were there after called to verify that the new build did not break any of the rules set by the tests.
2.2 Heart Rate Variability Analysis
Besides the main objective of developing the Biosignal PI framework this projects also aimed at implementing functionality for performing Heart Rate Variability Analysis with the Biosignal PI software. Since there already existed functioning open-source software for HRV-Analysis the HRV functions used in this project were adopted from the MATLAB application HRVAS written by John T. Ramshur[9]. The HRVAS software uses Interbeat Intervall(IBI) data as input which made it necessary to process ECG-Data obtained from the Biosignal PI into an IBI-file, which was performed through QRS-detection. More information about general use and physiological origin of HRV can be found in section A.1.2 of Appendix A.
2.2.1 QRS-Detection
To be able to create an IBI-file from the information in the ECG-file the data has to be sent through a QRS-Detection algorithm. The QRS-detection algorithm used in this project was implemented from a modified version of the Hamilton-Tompkins Algorithm[10]. The modified algorithm was extracted from the QRS-detector used in an ECG-Analysis software written in C by Patrick S. Hamilton[11]. A flowchart describing the detection process can be seen in figure 2.2, the different steps of the flowchart are explained below[10].
Figure 2.2: Flowchart describing the steps necessary for QRS-Detection of an ECG-File into an IBI-File
• Preprocessing, in order to prepare the ECG-file for QRS-detection the file needs to undergo a number of steps transforming the original signal according to the needs of the QRS-detection part.
– Filtering, the ECG file is passed through both a low-pass filter and a high-pass filter. The filtering part is adopted from the Pan-Tompkins Algorithm[12].
Chapter 2. Method 7
– Differentiation and Time-averaging, the filtered signal is divided into two sig- nals y(n) and z(n). y(n) is saved as a referencing signal for use in the the Fidu- cial mark locator the other filtered signal z(n) is differentiated, squared and time- averaged.
– Peak Detection. the signal z(n) is used to detect the peaks located in the inves- tigated signal.
– Fiducial Mark Locator, for the peaks found in the time-averaged z(n) signal the corresponding filtered peak is located in the reference signal y(n). The correspond- ing peak is chosen as the highest peak in the filtered signal y(n) in an interval 125ms to 225 ms preceding the peak in the time-averaged signal z(n)[10].
• Event Vector, is a two column vector containing the results from the Preprocessing stage.
• QRS Detection Decision, all the peaks detected in the preprocessing stage is com- pared to a couple of rules in order to decide if the detected peak was a QRS complex.
The different rules for deciding whether to accept or reject a peak is based on a combi- nation of information regarding the previous peaks as well as the height of the specific peak.
After the QRS-detector had been implemented into the Biosignal PI software the functionality of the beat detector was tested through the use of example ECG-data from the MIT-BIH databases[13] available through the online database collection PhysioBank Automated Teller Machine at physionet.org[14]. The MIT-BIH databases consists of different ECG-recordings that have accompanying IBI-files. In that way it was possible to compare the Biosignal PI generated IBI-files with the MIT-BIH reference IBI-files to see that the implemented algorithm performed as wanted.
2.2.2 Converting MATLAB Code into C++ Code
The MATLAB code was converted into C++ code through the use of MATLAB Coder. Which is a module that comes with Mathworks MATLAB, the coder was able to convert most parts of the original MATLAB code into C++ but in some functions part of the MATLAB code had to be partially rewritten before converting it into C++ code. A flowchart describing how the conversion was performed from MATLAB code into C++ code can be seen in figure 2.3.
To be able to use the generated C++ code with the Biosignal PI software it was necessary to write so called initiation functions that could convert the data from the type used in Biosig- nal PI into the data-type used by the converted HRV-functions. Before the HRV-functions converted from MATLAB could be called they needed to be initiated with the [Converted Func-
8 Chapter 2. Method
Figure 2.3: Flowchart describing the steps necessary to transform MATLAB code into C++ using MATLAB Coder
Chapter 2. Method 9
2.3 Bluetooth
To enable file transfer between Biosignal PI and a workstation the Biosignal PI has been im- plemented with support for transferring files using Bluetooth. The Raspberry PI was given Bluetooth functionallity through the use of a Bluetooth usb-dongle from Deltaco. The Blue- tooth functionality was implemented from code examples available with the Qt installation as a blueprint for how to create the connection[15].
2.4 Using PiFace Control and Display
One of the objectives of the project was to implement support for the hardware module PiFace Control and Display(CAD). Implementation of PiFace CAD allows for usage of the system without the need of a screen, mouse and keyboard for controlling the Biosignal PI. The PiFace CAD GUI was implemented through the use of the static C library libpifacecad written by Thomas Preston [16] which was used for communication between the created software and the PiFace. In order to use the PiFace screen and buttons for controlling the Biosignal PI framework an abstract menu class was created that was implemented for all the menus needed for using the PiFace CAD.
The PiFace CAD was connected to the RPI through the use of a PiFace PiRack as seen in figure 2.4, the usage of the PiRack was necessary since the RPI only have space for one GPIO device at the time without the PiRack.
2.5 Documenting the Created Software
To help with creating a software documentation the software Doxygen were used, more in- formation on Doxygen can be found in section A.3.2.4 of Appendix A. For a function or a parameter to turn up in the documentation it was given Doxygen formatted comments inside the source code, the comments will there after be extracted by Doxygen. How and what to
10 Chapter 2. Method
Figure 2.4: PiFace(top) connected to the Raspberry PI(bottom) using PiRack(left), the ADAS board(middle connected with brown cable) is also con-
nected in the picture
Chapter 3
Results
The results section will cover description and figures explaining the created Biosignal PI frame- work as well as the expansions made for the Biosignals PI. Adding features for HRV analysis, Bluetooth file transfer and creation of a graphical user interface for the PiFace hardware module.
3.1 Biosignal PI Framework
The created framework is meant to be modular with a high level of interchangeability regarding what sort of signal to capture, how to capture the signal and also how to store and visualize the captured signals. To achieve this level of modularity the software has been developed into different abstract parts. The main thought is to limit the dependency between the different parts which has been achieved by adding abstract interfaces for all the different modules. The interface states how the communication should be performed for future new classes, this way changing the capturing device or changing the type of data to store would not interfere with other parts of the software. The main layout of the Biosignal PI Framework can be seen in figure 3.1.
3.1.1 Device Facade
The class DeviceManager is created to work according to the Facade pattern handling all the communication between the used devices and the classes lying outside of the Device cluster.
DeviceManager inherits from the QThread class making it possible having the DeviceManager running in its own thread. To connect a certain device to the DeviceManager one need to write a device specific class implementing the DeviceInterface class to be able to connect it to DeviceManager.
3.1.2 Data Model and Logging
The DataStream QObject is an abstract interface that specifies the functionality available when using a DataStream, which is the Data Model used for all connected devices to store and access
12 Chapter 3. Results
Figure 3.1: Specification of the different modules and parts of the Biosignal PI Framework
captured data. For saving the data into a file the DataLogger class is called. The DataLogger is created to allow for more file types in the future, depending on the needs of the project its being used in.
3.1.3 Application Wide Settings
The class SettingsSingleton is created according to the singleton pattern, meaning in broad terms that it cannot be copied, it can only be initialized by itsself and there can only exist one singleton per application. The SettingsSingleton keeps all settings and options that are meant to be accessible for all classes in the application. The parameters stored in SettingsSingleton are set and accessed through the use of get and set functions in SettingsSingleton. By concealing the actual parameters it is possible to implement validation functions for all parameters in a latter stage.
3.1.4 CMake integration
To simplify the process of compiling and building the Biosignal PI on different RPI this project has integrated support for building the Biosignal PI software with CMake. If any of Biosignal PI’s external dependencies are located on other locations then the default paths specified
Chapter 3. Results 13
by the operating system, the path to this dependency has to be set manually in a CMake- configuration file. Example configuration files are included with the Biosignal PI source code.
3.1.5 Automated Testing
To allow for automated testing the testing framework Googletest has been integrated into the CMake build system. By having the test framework integrated in the build system the tests are being compiled and built for every new build of the Biosignal PI software. In this way the tests can catch any new error in an early stage.
3.2 Heart Rate Variability Analysis Widget
To perform and display HRV Analysis a new QWidget HrvWidget was created and imple- mented as a QStackedWidget of MainWindow. HrvWidget lets the user choose the file to perform HRV-analysis on. After the chosen file have been double clicked it is processed ac- cording to the flowchart in figure 3.2 through the use of hrvanalysis.h, which contains all the functions needed for the different processing steps. The final result of the HRV-Analysis is displayed in HrvWidget as shown in figure 3.3.
3.3 Bluetooth Transfer Widget
To allow for file transfer with Bluetooth a new QWidget was added as a QStackedWidget to MainWindow. The Bluetooth widget utilizes the Qt module QtBluetooth which depends on bluez for the bluetooth functionality. For the file transfer the widget is using Obex Object Push, enabling it to send the chosen file to a connected computer or phone. A screenshot of the Bluetooth widget can be seen in figure 3.4. The implemented bluetooth file transfer function is currently not working due to an unknown RPI problem with the Obex Object Push protocol.
The Bluetooth functionality is however working as planned for the Ubuntu and Linux Mint builds of the Biosignal PI software.
3.4 PiFace Graphical User Interface
To run the Biosignal PI software with PiFace CAD a new GUI was created specialized for the PiFace CAD. The new PiFace GUI is implemented as a simple QCoreApplication consisting of a loop checking the status of PiFace CAD switches(buttons), an illustration of the numbering of the different switches on the PiFace CAD can be seen in figure 3.5 for this implementation
14 Chapter 3. Results
ECG-Data
QRS Detection
IBI-Data
Ectopic Interval Detection and
Correction
Normalized IBI-Data
Time Domain
HRV-Analysis Detrending
Detrended and Normalized
IBI-Data
Frequency Domain HRV-Analysis
Display HRV-Analysis
Figure 3.2: Flowchart describing the different processing steps necessary to perform HRV-Analysis of the ECG-file chosen by the user
Chapter 3. Results 15
16 Chapter 3. Results
Figure 3.4: Screenshot showing the Bluetooth Transfer Widget
Figure 3.5: PiFace Control and Display with the different switches numbered as they are in the used C-library libpifacecad
Chapter 3. Results 17
The different menu objects utilizes the Biosignal PI framework for capturing of ECG-signals from the ADAS. The captured signal is saved through the DataLogger after the data acquisition is stopped. To allow for the RPI to be started with the PiFace CAD without a monitor and keyboard the RPI can be set up to boot directly to the Biosignal PI PiFace GUI if the PiFace is connected. If the PiFace is not connected the RPI will boot to the terminal instead.
3.5 Software Documentation
Through the use of Doxygen, software documentation has been created in two versions. One web version created in html and also a PDF version of the complete software documentation.
The homepage(index.html ) is shown in figure 3.6. To show an example of how the different class pages looks like for a specific class figure 3.7 shows the webpage generated for the De- viceManager class. The figure only shows the top view, more information is available for the DeviceManager further down the webpage. The PDF version is generated from a makefile using LaTeX.
18 Chapter 3. Results
Figure 3.7: Screenshot showing the top of the Documentation for the Device- Manager
Chapter 4
Discussion
4.1 Biosignal PI Framework and software
The main objective of this project was the creation of the Biosignal PI software framework described in section 3.1. The framework has been created to allow for future changes and additions within the different modules without the need of changing other modules. One priority when constructing the framework was to try and prepare for future expansions, which may have made some parts more complex then necessary. The added complexity has been regarded as acceptable given that is will simplify for further development.
When designing the Biosignal PI framework it was regarded important to create a software architecture that could be implemented into different sorts of projects concerning acquisition of physiological signals from some sort of hardware device. For that reason the hardware specific parts were abstracted into a DeviceInterface object connected to the DeviceManager class. For the DataLogger the hardware dependent parts were abstracted through the use of the Qt framework.
To simplify and save time during the implementation of different features, the author of this thesis has searched for existing open-source solutions and libraries to solve the needed tasks that have appeared during the software development phase. Both the HRV-analysis and Blue- tooth connectivity is implemented from existing coding made available by other developers.
The developed framework was implemented into an extended version of the original Qt GUI.
It was also implemented in a new GUI for the PiFace Control and Display hardware module.
The PiFace GUI was implemented with a more simplified functionality then the Qt GUI. If needed in future projects the PiFace GUI can be extended using the same abstract menu class as it is implemented with now.
The produced HrvWidget takes an ECG-file as input and performs an HRV-analysis of the file. In order for this to work the ECG-file has to pass through a QRS-detector. Detecting the QRS-peaks has proven to be a somewhat resource demanding tasks taking about 10 minutes for a 1-hour ECG-file on the RPI. This process is moved to another thread to avoid locking the Qt-GUI but it still takes a lot of time to transform from ECG to IBI-file. The implemented QRS-detection algorithm has not been optimized for the application. Trying to optimize the used QRS-detection algorithm might significantly speed up the HRV-Analysis process. For
20 Chapter 4. Discussion
this reason the IBI is saved as a txt file that the software will use if one wants to analyse the same file again latter, making the second HRV-Analysis of a HRV-file much faster.
4.2 Biosignal PI as a Medical Device
As described in section A.4 in Appendix A concerning the Medical Device Directive(MDD), there is a lot of demands for software used with and as a Medical Device. During the develop- ment of the software in this project a couple of steps has been taking moving the Biosignal PI closer to the different demands. Creating a description of the general software architecture, as done in this project, is one of the requirements for the MDD classification.
To simplify with dependency tracking and deployment of the developed software, the project was implemented with CMake for managing the build process. Implementing a build system was also important because it is a way of maintaining a correct and secure correct deployment for the chosen target environment, which is necessary according to the MDD.
Adding the Googletest framework is also a important preparation for the future. This project has only implemented a couple unit tests but more unit tests can be added in the future. The same testing framework can also be used for implementing integration and system testing. All three types of tests are necessary according to the MDD.
Another important aspect in software in general and medical software specifically is the need for proper documentation. The chosen document generation tool Doxygen can be used not only to provide comments regarding functions and classes. But it is also possible to utilize Doxygen as a way of organizing different sort of functional lists as for example bug and todo lists, and also creating UML-diagrams describing the dependencies and relations between different classes and functions.
Chapter 5
Conclusion
A software framework capable of capturing and storing bio-signals in a hardware independent manner has been created. The newly created framework has thereafter been implemented into the Biosignal PI software. The original Biosignal PI software was developed in an earlier project[6]. The Biosignal PI software has also been extended with an GUI created for the hardware module PiFace Control and Display. The PiFace GUI allows the Biosignal PI to be run without keyboard, mouse and screen connection. Features for performing HRV-Analysis has been added to the Biosignal PI application. To simplify for further development and understanding of the Biosignal PI an html-documentation has been created. This thesis project has also integrated the Googletest testing framework and CMake build system to further simplify for future development of the Biosignal PI project.
Even if some of the steps necessary for medical device software has been taken there still remains some requirements that need to be attended. The Biosignal PI software is not to be regarded as a Medical Device, but rather as Software of Unknown Provenance(SOUP) for mainly educational and research purposes.
The Biosignal PI software developed in this thesis is available through Github at https:
//github.com/biosignalpi/Version-A1-Rapsberry-PI.
Chapter 6
Future Work
To further develop the Biosignal PI system it would be interesting to try to optimize the developed software. Especially the QRS-detection and the HRV-Analysis functions might be able to work faster after optimization, lowering the waiting time for the HRV-Analysis. It would also be interesting to implement communication with some sort of database connected to a web interface making it easier to access the collected information. An easier access could open up new opportunities and making it possible to use the Biosignal PI system from a distance e.g. user having it at home collecting data that someone else e.g. doctor/researcher could access. To continue on possible applications the Biosignal PI could also be extended to feature some sort of heart beat detection. The ECG-Analysis software used for the QRS- detection also features functions for beat classification which could be implemented into the Biosignal PI software as a way of detecting arrhythmias.
In the future it would be interesting to see the Biosignal PI framework implemented together with another acquisition hardware module then the ADAS1000 to further test the flexibility of the produced framework. Regarding hardware changes it would also be interesting to test the possibility of using the Biosignal PI with an battery pack. Combining the battery pack with WiFi or Bluetooth connection would be a way of possibly using the Biosignal PI system as a telemonitoring system.
If the Biosignal PI someday are supposed to be classified as a medical device it would be necessary performing a thorough investigation of the steps needed for that. This project has only started on the documentation and testing required for certification. Among other things a Risk Management Process is a clear requirement according to the Medical Device Directive.
However a thorough evaluation would be needed to clarify exactly what has to be done if one wants to use the Biosignal PI as a medical device, instead of using it primarily for research and education as it is intended now.
Bibliography
[1] United Nations, “World Population Ageing 1950-2050: 2013”, United Nations, Depart- ment of Economic and Social Affairs Population Division, Report, 2013.
[2] WHO, “Good health adds life to years, Global brief for World Health Day 2012”, World Health Organization, Report, 2012.
[3] S. Koch, “Home telehealth—Current state and future trends”, International Journal of Medical Informatics, vol. 75, no. 8, pp. 565–576, 2006, issn: 1386-5056. doi: 10.1016/
j.ijmedinf.2005.09.002.
[4] T. Botsis and G. Hartvigsen, “Current status and future perspectives in telecare for elderly people suffering from chronic diseases”, Journal of Telemedicine and Telecare, vol. 14, no. 4, pp. 195–203, 2008. doi: 10.1258/jtt.2008.070905.
[5] F. Abtahi, J. Snall, B. Aslamy, S. Abtahi, F. Seoane, and K. Lindecrantz, “Biosignal PI, an Affordable Open-Source ECG and Respiration Measurement System”, Sensors, vol.
15, no. 1, pp. 93–109, 2015, issn: 1424-8220. doi: 10.3390/s150100093.
[6] J. Snäll, “Software Development of Biosignal PI: An affordable open source platform for monitoring ECG and respiration”, Master Thesis, Royal Institute of Technology, 2014.
[7] Google. (2015). Google C++ Style Guide, [Online]. Available: http://google.github.
io/styleguide/cppguide.html (visited on 10/05/2015).
[8] GoogleTest. (2013). Getting started with Google C++ Testing Framework, [Online].
Available: https://code.google.com/p/googletest/wiki/V1_7_Primer (visited on 10/07/2015).
[9] J. T. Ramshur, “Design, evaluation, and application of heart rate variability software (HRVAS)”, The University of Memphis, Memphis, TN, 2010.
[10] P. S. Hamilton and W. J. Tompkins, “Quantitative investigation of QRS detection rules using the MIT/BIH arrhythmia database”, Biomedical Engineering, IEEE Transactions on, no. 12, pp. 1157–1165, 1986.
[11] EP Limited. (2003). EP Limited: Open Source ECG Analysis Software, [Online]. Avail- able: http://www.eplimited.com/confirmation.htm (visited on 01/06/2016).
[12] J. Pan and W. J. Tompkins, “A real-time QRS detection algorithm”, Biomedical Engi- neering, IEEE Transactions on, no. 3, pp. 230–236, 1985.
[13] G. B. Moody and R. G. Mark, “The impact of the MIT-BIH arrhythmia database”, Engineering in Medicine and Biology Magazine, IEEE, vol. 20, no. 3, pp. 45–50, 2001.
26 BIBLIOGRAPHY
[14] A. L. Goldberger, L. A. Amaral, L. Glass, J. M. Hausdorff, P. C. Ivanov, R. G. Mark, J. E. Mietus, G. B. Moody, C.-K. Peng, and H. E. Stanley, “Physiobank, Physiotoolkit, and Physionet components of a new research resource for complex physiologic signals”, Circulation, vol. 101, no. 23, e215–e220, 2000.
[15] Qt Company. (2015). Qt Bluetooth Overview | Qt Bluetooth 5.5, [Online]. Available:
http://doc.qt.io/qt-5/qtbluetooth-overview.html (visited on 01/01/2016).
[16] P. Thomas Preston. (2014). Piface/libpifacecad, [Online]. Available: https://github.
com/piface/libpifacecad (visited on 01/01/2016).
[17] G. Pocock and C. D. Richards, Human Physiology, The basis of medicine, 3rd. 2006, ch. 15, pp. 262–279, isbn: 0-19-856878-9.
[18] A. Atkielski. (2007). QRS-complex, [Online]. Available: https://commons.wikimedia.
org/wiki/File:SinusRhythmLabels.svg (visited on 10/15/2015).
[19] U. R. Acharya, K. P. Joseph, N. Kannathal, C. M. Lim, and J. S. Suri, “Heart rate variability: a review”, MEDICAL & BIOLOGICAL ENGINEERING & COMPUTING, vol. 44, no. 12, 1031–1051, 2006, issn: 0140-0118. doi: 10.1007/s11517-006-0119-0.
[20] K. Lindskog, “Development and evaluation of a HRV Biofeedback System”, 2014.
[21] M. P. Tarvainen, J.-P. Niskanen, J. A. Lipponen, P. O. Ranta-aho, and P. A. Kar- jalainen, “Kubios HRV - Heart rate variability analysis software”, English, COMPUTER METHODS AND PROGRAMS IN BIOMEDICINE, vol. 113, no. 1, 210–220, 2014, issn:
0169-2607. doi: 10.1016/j.cmpb.2013.07.024.
[22] A. Camm, M Malik, J. Bigger, G Breithardt, S Cerutti, R. Cohen, P Coumel, E. Fallen, H. Kennedy, R. Kleiger, F Lombardi, A Malliani, A. Moss, J. Rottman, G Schmidt, P.
Schwartz, and D. Singer, “Heart rate variability. Standards of measurement, physiological interpretation, and clinical use”, EUROPEAN HEART JOURNAL, vol. 17, no. 3, 354–
381, 1996, issn: 0195-668X.
[23] F. Abtahi, A. Berndtsson, S. Abtahi, F. Seoane, and K. Lindecrantz, “Development and preliminary evaluation of an Android based heart rate variability biofeedback system”, in Engineering in Medicine and Biology Society (EMBC), 2014 36th Annual International Conference of the IEEE, IEEE, 2014, pp. 3382–3385.
[24] G. Tan, T. Dao, L. Farmer, R. Sutherland, and R. Gevirtz, “Heart Rate Variability (HRV) and Posttraumatic Stress Disorder (PTSD): A Pilot Study”, English, Applied Psychophysiology and Biofeedback, vol. 36, no. 1, pp. 27–35, 2011, issn: 1090-0586. doi:
10 . 1007 / s10484 - 010 - 9141 - y. [Online]. Available: http : / / dx . doi . org / 10 . 1007 / s10484-010-9141-y.
[25] A. L. Hassett, D. C. Radvanski, E. G. Vaschillo, B. Vaschillo, L. H. Sigal, M. K. Karavi- das, S. Buyske, and P. M. Lehrer, “A pilot study of the efficacy of heart rate variability (HRV) biofeedback in patients with fibromyalgia”, Applied psychophysiology and biofeed- back, vol. 32, no. 1, pp. 1–10, 2007.
[26] R. P. Nolan, M. V. Kamath, J. S. Floras, J. Stanley, C. Pang, P. Picton, and Q. R.
Young, “Heart Rate Variability Biofeedback as a behavioral neurocardiac intervention
BIBLIOGRAPHY 27
to enhance vagal heart rate control”, American heart journal, vol. 149, no. 6, 1137–e1, 2005.
[27] L. Rodriguez-Linares, M. J. Lado, X. A. Vila, A. J. Mendez, and P. Cuesta, “gHRV:
Heart rate variability analysis made easy”, English, COMPUTER METHODS AND PROGRAMS IN BIOMEDICINE, vol. 116, no. 1, 26–38, 2014, issn: 0169-2607. doi:
10.1016/j.cmpb.2014.04.007.
[28] The Raspberry Pi Fundation. (2015). The Raspberry Pi Fundation | About us, [Online].
Available: https://www.raspberrypi.org/about/ (visited on 09/29/2015).
[29] The Register. (2015). Raspberry Pi 2, [Online]. Available: http://www.theregister.
co.uk/2015/02/02/raspberry_pi_model_2/ (visited on 09/30/2015).
[30] The Raspberry Pi Fundation. (2015). Raspberry Pi 2 Model B, [Online]. Available:
https : / / www . raspberrypi . org / products / raspberry - pi - 2 - model - b/ (visited on 09/29/2015).
[31] Raspbian. (2015). Raspbian, [Online]. Available: https://www.raspbian.org/ (visited on 09/29/2015).
[32] The Raspberry Pi Fundation. (2015). GPIO: Models A+, B+ and Raspberry PI 2, [Online]. Available: https : / / www . raspberrypi . org / documentation / usage / gpio - plus-and-raspi2/ (visited on 09/29/2015).
[33] P. M. Encyclopedia. (2015). SPI Bus Definition, [Online]. Available: http://www.pcmag.
com/encyclopedia/term/59605/spi-bus (visited on 10/15/2015).
[34] PiFace. (2015). PiFace Control and Display, [Online]. Available: http://www.piface.
org.uk/products/piface_control_and_display/ (visited on 10/15/2015).
[35] Analog Devices. (2015). ADAS 1000. datasheet and product info, [Online]. Available:
http : / / www . analog . com / en / products / analog - to - digital - converters / ad - converters/adas1000.html (visited on 09/30/2015).
[36] B. Janamanchi, E. Katsamakas, W. Raghupathi, and W. Gao, “The State and Profile of Open Source Software Projects in health and medical informatics”, English, INTER- NATIONAL JOURNAL OF MEDICAL INFORMATICS, vol. 78, no. 7, 457–472, 2009, issn: 1386-5056. doi: 10.1016/j.ijmedinf.2009.02.006.
[37] A. Enquobahrie, P. Cheng, K. Gary, L. Ibanez, D. Gobbi, F. Lindseth, Z. Yaniv, S.
Aylward, J. Jomier, and K. Cleary, “The image-guided surgery toolkit IGSTK: An open source C++ software toolkit”, English, JOURNAL OF DIGITAL IMAGING, vol. 20, no. 1, 21–33, 2007, issn: 0897-1889. doi: 10.1007/s10278-007-9054-3.
[38] Kitware. (2015). Overview | CMake, [Online]. Available: https://cmake.org/overview/
(visited on 10/05/2015).
[39] S. Chacon, Pro Git. Apress, 2009.
28 BIBLIOGRAPHY
[41] Doxygen. (2015). Doxygen: main page, [Online]. Available: http://doxygen.org (visited on 12/07/2015).
[42] A. Pham and P.-V. Pham, Scrum in Action, Agile Software Project Management and Development. Course Technology PTR, 2012, isbn: 978-1-4354-5919-7.
[43] Monroe, Robert T and Kompanek, Andrew and Melton, Ralph and Garlan, David B,
“Architectural styles, design patterns, and objects”, IEEE software, p. 43, 1996.
[44] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Pearson Education, 1994, isbn: 9780321700698.
[45] N. Hrgarek, “Certification and regulatory challenges in medical device software devel- opment”, in Proceedings of the 4th International Workshop on Software Engineering in Health Care, IEEE Press, 2012, pp. 40–43.
[46] C. Becchetti and A. Neri, Medical instrument design and development: from requirements to market placements. John Wiley & Sons, 2013, ch. 6, pp. 359–418.
[47] European Commisson, Directive 93/42/ECC, 2010.
Appendix A
Literature Study
A.1 Electrophysiology of the Human Heart
This chapter will give a brief description of the medical background behind electrocardiography and heart rate variability. It will also include a short introduction of what metrics a heart rate variability analysis can consist of.
A.1.1 Electrocardiography
The human heart works like a pump because the cardiac muscles dilate and constrict. In this way the heart is filled with blood during dilation which is then pushed out of the heart into the blood vessels during contraction. For this process to work properly each part of the myocardium needs to be synchronized with the rest of the heart. This synchronization is achieved with the help of conducting tissue and small electrical currents sent from the sinoatrial node in the left upper quadrant of the heart. When the current spreads through the heart small potential differences occur and these potential differences can be measured with Electrocardiography(ECG). ECG is a well established tool for diagnosing and monitoring cardiac activity. A typical ECG consists of three main parts; the P-wave resulting due to the atrial depolarization, QRS-complex resulting from the ventricular depolarization and a T-wave resulting from repolarization of the ventricles as shown in figure A.1. The ECG can be used in a wide variety of diagnostic and monitoring purposes for instance detecting cardiac arrhythmia and cardiac abnormalities.[17]
A.1.2 Heart Rate Variability
Heart Rate Variability(HRV) is the time alterations between two consecutive heartbeats. Even for a steady heart rate there exist variation in time between two heartbeats, this phenomena is controlled by the autonomous nervous system(ANS). The ANS consists of sympathetic and parasympathetic activity. The sympathetic activity tends to increase the heart rate and lower the HRV while parasympathetic activity has the opposite effect.[19]–[21]
30 Appendix A. Literature Study
Figure A.1: Illustration of typical ECG trace [18]
A new heartbeat typically start with the P-wave of the ECG-trace as seen in figure A.1.
HRV is however often calculated as the time between consecutive R-peaks since it is much simpler to recognize R-peaks in an ECG compared to P-waves, the time between two regular R-peaks is called the R-R interval. R-R intervals triggered by the sinoatrial node are called N-N interval.[21]
A.1.2.1 Clinical Use of Heart Rate Variability
HRV has a lot of different possible clinical applications. One area where HRV has shown success is in risk prediction of sudden cardiac death following an acute myocardial infarction.[19], [22].
HRV can also be used as a way of detecting diabetic neuropathy[19], [21], [22]. There is also a connection between HRV and a lot of different neurological, cardiac and renal diseases[19].
Another way HRV can be used clinically is Biofeedback, which is a way of using HRV for behavioral training for patients in order to increase their HRV. There are several methods for Biofeedback, one of the more common ones are resonant frequency training (RFT), where the training is performed by making the patient breath in a certain frequency[23]. Biofeedback has shown promises with a variety of diseases eg. Posttraumatic stress disorder(PTSD)[24], Fibromyalgia[25] and treatment of stress in patients with coronary heart disease(CHD)[26].
Appendix A. Literature Study 31
A.1.3 Methods for Heart Rate Variability Analysis
In order to study the HRV it is necessary to perform some sort of HRV Analysis Software. The analysis can consists of information obtained through different types of analysis of the HRV.
The three main categories of computational methods commonly used are Time-domain meth- ods, Frequency-domain methods and nonlinear methods. The nonlinear methods include meth- ods such as for example Poincare plot, approximate entropy(ApEn), sample entropy(SampEn) and detrended fluctuation analysis(DFA).[21], [27]
A.1.3.1 Time-domain Methods
Some common time-domain metrics for measuring HRV are listed in table A.1.[21]
Variable Unit Description
SDNN ms standard deviation of all N-N intervals
NN50 # number of adjacent N-N intervals that differ more than 50ms pNN50 % percentage of NN50 of all the N-N intervals
RR ms mean value of R-R intervals
Table A.1: Metrics for Time-Domain Analysis of HRV[22]
A.1.3.2 Frequency-domain Methods
The frequency domain methods are calculated from power spectral density(PSD) analysis of the signal. The PSD is generally divided into three groups very low frequency(VLF), low frequency(LF) and high frequency(HF). Some common metrics for Frequency-domain are listed in table A.2.[21]
Variable Unit Description
Total Power ms2 The variance of NN intervals VLF ms2 Power in VLF-range (<0.04Hz) LF ms2 Power in LF-range (0.04-0.15Hz) HF ms2 Power in HF-range (0.15-0.4Hz)
32 Appendix A. Literature Study
Appendix A. Literature Study 33
A.2 Hardware
This chapter will go into the hardware necessary to be able to collect ECG-signal and also display and analyze the signals collected.
A.2.1 Raspberry PI
The Raspberry PI(RPI) is an affordable credit-card sized single-board personal-computer cre- ated by the Raspberry PI foundation which is an educational charity founded in order to promote the education of children and adults in the field of computers and computer science.
The RPI can be used in education and research as an electronics prototyping platform for smaller projects.[28]
The current RPI model is named Raspberry PI 2 Model B seen in figure A.2 and was released in February 2015 it is a upgrade of the older RPI 1 Model B+ (previously called RPI Model B+).
Figure A.2: Raspberry PI 2 model B [29]
The main difference between RPI 1 B+ and RPI 2 B is a new multicore processor and a larger memory. The RPI can be installed with a variety of different operating systems but the recommended one is Raspbian, a free operating system based on the Linux distribution Debian optimized for the RPI.[30], [31]
A.2.1.1 General-Purpose Input/Output
One of the things that makes RPI well suited for use in small projects is its ability to easily con- nect and control analog and digital hardware through its general-purpose input/output(GPIO) pins. The RPI is equipped with a 40-pin connector header. Out of the 40 pins, 26 of them
34 Appendix A. Literature Study
communication protocol used to enable communication between different devices. The SPI setup consists of a master device, for example a RPI, that control the communication to one or more slave devices. A digital pathway is established between the devices with one line for input and one line that handles output.[32], [33]
A.2.1.2 PiFace Control and Display
PiFace Control and Display(CAD) is a hardware module that can connect to the header of the RPI and communicate with the RPI through SPI. By connecting a PiFace CAD to the RPI it is possible to replace the need of keyboard and screen in order to control the RPI. The PiFace CAD consists of a small backlight LCD display with the ability to show a total of 32 character divided into two lines. It also has 5 tactile buttons and a three-way navigational switch. As seen in figure A.3
Figure A.3: PiFace Control and Display [34]
Through the help of library files written in Python it is possible to program the display and the function of all the buttons and switch in order for the PiFace CAD to fit the need of any given software project.[34]
A.2.2 ADAS1000
The ADAS1000(ADAS) is an analog to digital converter(AD converter) designed for use in a wide-variety of applications were there exits a need for acquisition of high quality 5-lead ECG with built in noise filtering and pace detection. The ADAS converts bio-potential signals acquired from the chest of a patient into a digital signal that can be used for analyzing and monitoring in a software application. The ADAS also features functions for lead on/off detection and test-signals for verification of new applications. The ADAS can be connected to the GPIO of the RPI. SPI communication is used for the link between RPI and ADAS.[35]
Appendix A. Literature Study 35
A.3 Software Development
This chapter will give an introduction to open source development in general as well as some information about different concepts in software engineering useful for the development of software able to run on the Raspberry Pi.
A.3.1 Open Source Development
The development of open source software(OSS) is a rising trend within the healthcare industry.
The reason for the increase of OSS might be that it is seen as a way of getting working soft- ware for a lower development cost when one can utilize collaboration between developers and researchers from different part of the world. Open source software should not be confused with free software. Free software usually only provide free executable program while open source provides the source code, enabling users to be able to change how the program works.[36], [37]
The foundation of OSS is the Open Source Model which uses internet and communities as a way of collaboration and leverage ideas, creativity and contributions from both the academic as well as the commercial world through its common software base. With an open source code anyone interested can be a part of the project and contribute with what they have to offer. Open source software can be used as a valuable educational tool since it is possible for a student to study the source code that others have developed and even try to improve the code.
Through the use of open source software it is possible to share algorithms between project preventing the need of reinventing the wheel.[36], [37]
A.3.2 Development Environment
In order for a software project to be successful and well structured one might utilize a lot of different tools that can help move the project forward as well as simplify for other participants of the project to keep track of the current status. Below is a description of some types of tools that may be useful to implement in a software project.
A.3.2.1 Dependency Tracking
In projects where the developed software are supposed to be run and developed on different systems it maybe necessary to utilize some sort of software that can track all the dependencies needed to build the software successfully. One of the most common ways of keep track of dependencies is the software CMake. CMake is an open source program that generates build files that can be used by the native build environment. Through the use of CMakeLists.txt files
36 Appendix A. Literature Study
A.3.2.2 Source Code Management
Source Code Management(SCM) is used to keep track of changes in software projects. SCM can be a useful tool for both small one-man projects on a single computer as well as larger projects with many contributors from different computers. Through the use of SCM it is possible to keep the source in-sync between different computers.[39]
One of the most common SCM is Git, which is a open source product that let the user work on a project by keeping both a local copy of the current project tree and a remote copy online available to other collaborators. To store a git repository online it is common to use some sort of online repository hosting service, one of the must used hosting services for git are Github.com which also has features for Wiki creation and project management. Through the use of branches it is possible to work on new features without the risk of overwriting the original source code.[39]
A.3.2.3 Application Framework
Qt is a cross-platform application framework used for application development in C++. An application framework is used to simplify certain task in the development process. Cross- platform means that applications developed with Qt are able to be run on different platforms eg. ubuntu and Raspbian without the need of rewriting the code for the specific platform.
Qt was launched in 1995 as a Graphical User Interface(GUI) framework but has over time evolved to include features for a wide variety of functions beside GUI, which can be used in the development of a new program such as for example database communication, thread handling and event handling.[40]
A.3.2.4 Software Documentation Generator
An important part of making the software development process understandable for others then the programmer of the code fragment is documentation. Documentation can be constructed and organised with the help of Document Generator software. The free software Doxygen is a documentation generator that are able to generate either html or latex documentation from the programmers comments inside the source code of a software project. Doxygen interprets how different classes and functions are related and uses this information together with the user- specified code comments to generate a complete description of the software project. What type of information to generate and how deep Doxygen is supposed to document is controlled through the use of a user written configuration file containing all information needed for Doxygen.[41]
A.3.2.5 Testing Framework
For a software product to be successful it needs to work as specified. The only way of being certain of the functionality is through testing. Testing can either be made by hand through
Appendix A. Literature Study 37
the use of a debugger or by automated testing which consists of constructing test cases that verifies the functionality of the software. To simplify automated testing there are Testing Frameworks designed to run user created tests. Automated Test should be performed after all forms of changes to the software to verify that the changes did not cause any problems with the functionality.[8], [42]
A.3.2.6 Coding Convention
When writing code, it is important that the code is easy to understand. One way of making the code more understandable and easier to interpret is through consistency. In order to achieve consistency, it is good to set up clear rules for how the program should be written and how decisions are to be made. These sort of rules or guidelines are usually called either coding style or coding convention. Larger software projects usually have their own style guide while smaller software projects, with only a couple of participants, either lack a specific convention or implement a style guide created by someone else.[7]
A.3.3 Software Architecture
Software Architecture is sort of the blueprint for a software program. The architecture de- scribes the system structure and behaviour in a general way specifying what functionality a system will have. Through abstraction the software is divided into different components. The functionality of the components and how they interact with other components lies in the ar- chitecture while the specific implementation details of the components is not relevant for the architecture.[43]
A.3.4 Design Patterns
The use of design patterns in software engineering is a way of simplifying development through the use of already established solutions to general problems. Many of the design patterns used today stem from the book "Design Patterns, Elements of Reusable Object-Oriented Software"
by Gamma et al published in 1994, this book is considered as the start of a more common use of design patterns in software engineering. A pattern usually has four major elements that are described:[44]
• Pattern Name
• Problem Description, short explanation on what the pattern can be used for
• Solution, abstract explanation on how the pattern should be implemented
• Consequences, short summary on the results and trade-offs made by implementing a specific pattern
38 Appendix A. Literature Study
solution. The use of design patterns makes the code easier to follow for people who have seen the pattern before and knows what the pattern does and which classes are used. For people not familiar with the specific pattern they can search for more information on the pattern through the pattern name.[44]
Appendix A. Literature Study 39
A.4 Medical Device Certification
In order for a medical device to be used in a clinical setting the device needs to be certified according to the regulations specified for the country where the device are to be used. This chapter will give a brief overview of the regulatory demands. Within the European Union everything in the medical device area is regulated by three European Union directives. These three directives constitute the Medical Device Directive(MDD) which is a harmonized directive that all EU and EEA countries have to implement in their own national legislation. The directive sets out requirements on quality, testing and verification of a medical device. The directives use a couple of harmonized standards such as ISO/EN 14971(risk management), ISO/EN13485(quality management system) and IEC/EN 60601-1(electrical safety) as a way of specifying how to handle development of a medical device regarding these requirements.
[45], [46]
"For devices which incorporate software or which are medical software in them- selves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification" Section 9, European Commission Directive 93/42/EEC [47]
A.4.1 Software Requirements
As medical software becomes more and more advanced, the need for regulations of how these should be treated increases. To simplify the ability to ensure the quality and promote safe development of medical device software, the new harmonized standard CEI/IEC 62304 has been developed.[45]
The CEI/IEC 62304 provides a lot of requirements to be fulfilled in order for a development process to be regarded as safe. The standard specifies the need for a risk management sys- tem(ISO 14971) and a quality management system(ISO 13485).[45], [46]
A.4.1.1 Software Development Life Cycle
The specific requirements for a certain software varies depending on the safety classification of the software. The safety classification depends on the possible side effect of a error in the software.[45] A medical device can be classified as either I, II or III(I being least risk) in the EU classification system which is equivalent to the FDA classes A, B and C. It is recommended that medical software is classified as at least B(II)[46]. Chapter 5 of the CEI/IEC 62304 sets a couple of requirements for class B(II) and C(III) medical software.[45], [46]
• Development Planning a plan is required the extent depends on class B or C.
• Requirements Analysis has to be performed and documented.
• Detailed Design only required for class C.
• Unit implementation and verification all units needs to be documented and also unit tested.
• Integration and integration testing needs to be implemented fully.
• System testing required.
• Release documentation regarding software anomalies as well as operator usage and human factors.
A.4.1.2 Risk Management Process
For all class B and C devices chapter 7,8,9 of the CEI/IEC 62304 specifies the need of a risk management process. Which is a strategy on how to eliminate risks and how to resolve later problems with the software. The risk management system is usually adopted from ISO 14791. A correct risk management process includes a lot of control measures to ensure that the software can work safely. The need for proper documentation is high since documentation is regarded as a way for a third person to review whether all risks have been considered.[45], [46]
A.4.2 Software of Unknown Provenance
Software of Unknown Provenance(SOUP) is a term used for software lacking one or more important parts needed for certification. The SOUP definition does not say anything about the quality of the software and it can work correctly, however there is no way of being sure that the software is working correctly. SOUP can eventually turn into a medical device if the appropriate steps are taken regarding Software Development Life Cycle and Risk Management Process.[46]
TRITA 2016:10
www.kth.se
