T1 physiological wearable sensor
From SoftwarePractice.org
Project Team Members
Project Introduction
Project Objectives
The following information is provided by the client for the development of the system:
The medical profession are interested in a wearable device that can measure and record physiological parameters of the human body. They hope that data collected in this way can be useful for medical diagnosis and provide clues to a person’s physiological state over time.
The device will be carried on their body in some way. It will consist of an assortment of software and hardware components. Three hardware sensors will provide data readings of skin temperature, pulse and galvanic skin response. You need to read up on the hardware sensors and include your working assumptions about them on your Wiki documentation. This is primarily so you know what kind of data will be travelling across the interfaces between software and hardware components. You will need to provide software simulation of the input components. Include a sketch of the various hardware and software components, clearly showing the interfaces.
The device will present a dynamically updated graph(s) of sensor readings. The sensor data are time-stamped and can be stored to file. The historical data can be retrieved and displayed over a selected timeframe. The historical data can also be downloaded to an external device.The user can enter their personal data. The user interface must support all the above features.
It is up to you how you design the graphical user interface (GUI) and what features you provide, as long as you comply with the following constraint. A constraint on the design of the GUI is that the screen must be of the scale appropriate for a wearable device.
Project Scope
The Wearable Physiological Sensor system is an easy-to-use, wearable device able to take readings of biological signals for presentation via a graph or export to an external source. The device is able to store user data and also uses time-date information to log data. The scope of the project includes the software component of the device (with the implementation of realistic simulated physiological input), any assumptions as to hardware requirements for the device, as well as the following forms of documentation: 1. Initial Design 2. Software Development Wiki
Objective tree for a wearable physiological device
This is the hierarchical representation of the needs based on the functional similarity of the needs identified by our group.
Functionality
- Add, delete, store and retrieve sensor readings and user profiles
- Display graphs
- User friendly and uncomplicated user interface.
System Inputs and Outputs
Miniature Unified Process
The project is to follow the Miniature Unified Process model of development and has been broken down into the subsequent sections :
1. Inception
2. Elaboration
3. Construction
4. Transition
Each section has been broken up and allocated weeks according to the projected effort required for each section as well as the due dates for the project deliverables. The following table (Table 1) gives an indication as to the estimated hours of effort for each section for each week. The proceeding graph (Figure 1) compares the effort hours for each section across the entire project period.
Table 1: Miniature Unified Process Table
Figure 1: Miniature Unified Process Graph
Research
Temperature Sensors
Any form of temperature variant device will work for this hardware component. The most common, compact, cheapest and most robust form of device suitable for this purpose is the thermistor. A device which varies it's resistivity in proportion to it's temperature. When placed up against the skin, the thermistor quickly (can be as quick as 10 seconds in open air) reaches a resistance which can, through the application of a small current and the manufacturer's specification, track back to the temperature of the skin to an error of as little as 0.05%. Resistance temperature detectors (RTDs) might also be used, but provide an excessively broad range of temperature values compared to thermistors.
Measuring Temperature - The Thermistor
RTD's
Pulse Sensors
There are a number of methods useful for measuring a pulse, some of which include optical, pressure and electrical. For obtaining a person's heart rate whilst in motion, the most reliable method is through electrical measurements. Current pulse measurement devices either require the use of a separate strap across the users chest or they require the user to create a circuit by pressing against a metal sensor on the device with their non-device hand. The second option is not viable considering our requirements, however, a number of users have complained of the discomfort of the strap across the chest. Therefore, in our design, we consider that the most optimal place for a strap (with sensor) would be on the wrist opposing the device. The use of short range wireless transmission will be used in conveying the result back to the device.
Galvanic Skin Response (GSR) Sensors
GSR is effectively the resistance across the surface of the skin. As such, very little hardware is needed in the case of this sensor component, merely a very small voltage difference applied across two nodes mounted close together and flush against the skin and a capacitor attached to one of those nodes. The time taken for the capacitor to charge gives an indication as to the GSR of the user. Biomapping.net
Inception
Key Stakeholders
During the lectures and tutorials this semester, our group has gained an understanding that it is essential to identify the user requirements of the software, prior to initiating the design and development. Stakeholders Analysis is one way to discover who are the stakeholders of the project and hence the final product, i.e. Physiological sensor, and interpret their needs and demands.
The following have been identified as key stakeholders in the development of this project:
Challenges
- User Interface:
-Illogical screen layout
-Difficult to read the screens
- Program Execution:
-System response is slow
-System as coded may not work in a way intended
- Data storage:
-Data is lost
-Outputs are inaccurate
System Maintainence
- The software is documented adequately so that updating and maintaining is as easy as possible.
- The program is completed by the due date.
- The program is tested so that it runs efficiently.
Key Risks
As in every project, we identified number of risks that could cause the project to be delayed or to minimize its functionality. For this project identified risks as follows:
- Acknowledged user requirements are not met.
- Analysis is carried out incorrectly
- Poor project control
- Poor software implementation
- Design is not user-friendly
- Essential functions may not be included
- Insufficient time allocated for each aspect of the project
Elaboration
Usage Scenarios
Scenario 1 John has fitness goals, he has gone for a run and wants to know how his heart rate, skin temperature and galvanic skin response. He uses his device to track these aspects on a graph over the last hour during which he ran and also while he is still running. He also checks his current levels of output as he goes. He notes the parallel between this information and the various levels of effort he produced during his run.
Scenario 2 Julie has been ill. Her doctor has requested she wear the device in order to monitor her heart rate and the other aspects of her health in order to greater understand how her health has been fluctuating and to monitor her progress towards health. She provides her doctor with data from the device once a week by retrieving it from her device and emailing it to him. She doesn’t want her workmates to know she is having health problems and is therefore grateful that the device is so innocuous.
Scenario 3 Steven likes to keep track of his health and the progress in his fitness levels. To that effect, he purchased the device a few months back. He consistently uploads the data from the device onto his computer, but also likes to consider the progress he has made in 6 month blocks, he compares his data over the last month to that of the month before by scrolling through the data with a month’s worth of data displayed on the screen.
Scenario 4 Jane has just purchased the device. She starts the device and creates a new profile. She enters all of her pertinent details; these include her name, age, sex, current weight, as well as her desired target levels for her heart rate. Separate to these personal details, she sets the time and date in the device.
Scenario 5 Peter has had his device for months now, he has tracked his health information and now only wants to track his information during specific periods. To that end, he now only collects his data before and during his morning cycling session.
Scenario 6 Gemma has had the device for 3 years now and wants to sell her old one and purchase a new device. She accesses the device and clears her user information, this includes all of her personal details and all of her personal data collected on the device over the past 3 years prior to listing it on Ebay.
Scenario 7 Jessica is getting on in years and has experienced some pain in her chest and along her left arm. The nurse who stops by every week to look after her asked her to use the device. After the pain has passed, she looks at her device and notes that the pulse readings became erratic during this period. She calls her nurse and notifies her who comes and verifies the result before taking her to consult her doctor.
Scenario 8 Jason has high blood pressure due to stress. He has recently applied for a study and the researcher would like him to try to pinpoint events of stress in his everyday life so as to later measure how his response to these events change and whether he is able to lower his stress-related GSR and pulse responses.
Use Case: Scenario 1
* The choice of verbs for the system is misleading. For example, "display" graphs is better than "view" graphs. Viewing is something the user does.
Use Case: Scenario 4
Use Case: Scenario 6
Use Case: Scenario 7
Use Case Diagrams
Review 1: Initial Use Case Diagram
* This diagram is useful for showing the main components (mostly hardware) in the system, but be careful, it is not a "use case diagram".
Review 2: Initial Use Case Diagram
* Same applies for this diagram.
Review 3: Final Use Case Diagram
Class Diagrams
Review 1: Initial Class Diagram
Review 2: Initial Class Diagram
Review 3: Final Class Diagram
Collaboration Diagram
Review 1: Initial Collaboration Diagram
CRC Cards
Initial CRC Cards
| Class Name:GSR sensor | |
|---|---|
| Responsibilities | Collaboration |
| Calculate GSR | GUI |
| Receive the GSR | User |
| Request storage of data | Alarm |
| Class Name:Temperature sensor | |
|---|---|
| Responsibilities | Collaboration |
| receives body/skin temperature | GUI |
| calculate the temperature | Alarm |
| request to store data | User |
| Class Name:GUI | |
|---|---|
| Responsibilities | Collaboration |
| display graph | user |
| display average | data |
| display time (duration) | clock |
| display alarm | |
| Class Name:Alarm | |
|---|---|
| Responsibilities | Collaboration |
| Specify rate of heartbeats | |
| Temperature/emotions | |
| Class Name:Clock | |
|---|---|
| Responsibilities | Collaboration |
| Gives time | Alarm |
| Gives date | |
| Class Name:User | |
|---|---|
| Responsibilities | Collaboration |
| Add new user (name & age) | GUI |
| Delete users | Pulse |
| Select user | Temperature |
| Emotions | |
Final CRC Cards
Class Specification will represent our CRC cards as well as class specifications.
Sequence Diagram
Review 1: Initial Sequence Diagram
Review 2: Initial Sequence Diagram
Review 3: Final Sequence Diagram
* Why is :Log updating the clock??
The notation for the message between :Sensors and :Log should be a plain arrow, not dashed. Dashed is for data returned.
Proposed GUI Design
Please note that the black squares surrounding the screen of the device represent touch sensor buttons that may be mounted around the periphery of the screen (on the rim of the watch) for more input options.
Front Screen
Menu Screen
Graph Screen
Name Screen
Construction Phase
This phase emphasises the maturation of the program and the construction of the software. The unit tests and system tests are incorporated to display how the system was tested during its creation. Detailed clarification of these is mentioned below. The next phase we entered was the transition phase.
Unit Tests: Class Specification
* Class specifications should be presented before unit tests. They are not the same thing.
* Despite using the template, you have not presented the operation specifications properly. Each operation should be defined separately, with its signature and contract (pre/post conditions). Otherwise, it is not clear at all, what goes with what.
Test Cases Design
Transition Phase
The transition phase is the final phase of the project and deals with the product set up and presentation. This final phase highlights the end product and demonstrates its capabilities. The test - cases highlight what the program can do and its success rate. The further developments of the product are discussed in further detail below. These show how the program can be improved and the reasons for doing so. Thus, the transition phase concludes the project and the project documentation itself.
Polished GUI Designs
The interface that was created for the program, as well as all the input and message dialogs are shown below. This GUI and its corresponding dialogs were exactly what we were aiming for and it mimic’s our initial proposed user interface.
Conclusion
Our device provides a real-time collection and analysis of physiological states of the users. It is a big time opportunity for constantly monitoring the health states of the users, providing them with real-time feedback, finding correlations between lifestyle and health/wellness and also to research new applications and services.
It will thus have a high impact on the society by improving the quality of life of the users and help with ageing, chronic disease management, wellness, disease prevention, pro-active medicine and stress reduction.
Useful References
Instructor comments
I have added some comments in red throughout the document. These supplement the comments provided on the marking sheet. Lian 6th Nov 2008.
