2 Software Architecture Document for the Health Monitor¶
| Author: | Mario Tambos |
|---|
2.1 Change Record¶
2014.05.18 - Document created. 2014.08.20 - Updated document to reflect implementation.
2.2 Introduction¶
2.2.1 Purpose¶
Crew monitoring is an integral part of any manned mission. Since automated diagnosis tools are as yet not advanced enough, there is the problem of providing a human overseer with enough information to allow her to spot possible health problems as soon as possible.
Taking this into account this project is divided in three parts:
- Investigation of consumer-level biomedic devices available in the market.
- The implementation of a service to gather health metrics of all the crew. A priori this project will focus on the crew performing EVA, since, through their suits, their health information is readily available.
- The implementation of a GUI, where the collected data shall be summarized and presented to an overseer for evaluation.
2.2.2 Scope¶
Describes the scope of this requirements specification.
2.2.4 Glossary¶
ERAS- European Mars Analog Station
GUI- Graphic User Interface
IMS- Italian Mars Society
EVA- Extra-Vehicular Activity
TBD- To Be Defined
TBC- To Be confirmed
2.2.5 Overview¶
Make an overview in which you describe the rest of this document the and which chapter is primarily of interest for which reader.
2.3 Architectural Requirements¶
This section describes the requirements which are important for developing the software architecture.
2.3.1 Non-functional requirements¶
As mentioned before, it should be possible to view the developed GUI from inside a virtual environment.
The framework selected for the GUI development should be multiplatform. It should also have as few prerequisites as possible.
- Biometric devices:
- Their cost should not exceed us$200.
- They should be easy to integrate with TANGO.
- Tey should not be cumbersome.
- If possible each device should integrate several functions.
The data collector should gather data from any device deemed relevant. Any relevant device not available should be simulated.
2.3.2 Use Case View (functional requirements)¶
The goal of this project is to build a service that allows the central monitoring of the crew’s health. It will do this by collecting, processing and presenting data from the crew space suits. A data collector, implemented as a TANGO server, should gather the data from all available space suits and store it in a database. A GUI should then request the latest data from the database, summarize it and present it to an overseer in a way that allows him/her to detect problems at a glance. The GUI should also be able to be viewed from inside a VR-environment. At the moment a possible solution to this is to stream a computer screen/window to a surface texture in Blender, as shown in this video.
Additionally, it will be investigated what biometrics devices could be used in VR-simulations to monitor the crew participating in it. For selected devices a Tango server will be developed, from which then the collector will also gather data.
2.3.2.1 Request for biometric data¶
The Client request the Server the biometric data of the last T seconds.
2.3.2.1.1 Actors¶
Client: a TANGO client that makes the request. Server: the Aouda TANGO server.
2.3.2.1.2 Priority¶
High
2.3.2.1.3 Preconditions¶
The Server is running and its DevState is ON.
2.3.2.1.4 Basic Course¶
- The Client calls the appropriate method on the Server, passing T as argument.
- The Server searchs its buffer for the appropriate records.
- The Server returns the records found.
2.3.2.1.5 Alternate Course¶
None
2.3.2.1.6 Postconditions¶
The server returns the data requested or an empty array if no data is available.
2.3.2.2 Request for alarms¶
The Client request the Server the biometric data of the last T seconds.
2.3.2.2.1 Actors¶
Client: a TANGO client that makes the request. Server: the Health Monitor TANGO server.
2.3.2.2.2 Priority¶
High
2.3.2.2.3 Preconditions¶
The Server is running and its DevState is ON.
2.3.2.2.4 Basic Course¶
- The Client calls the appropriate method on the Server, passing T as argument.
- The Server searchs the database for the appropriate records.
- The Server returns the records found.
2.3.2.2.5 Alternate Course¶
None
2.3.2.2.6 Postconditions¶
The server returns the data requested or an empty array if no data is available.
2.3.2.3 Server requests new data¶
The Server reads the data of each available Aouda suit from the Framework Software Bus, ands stores it in the database.
2.3.2.3.1 Actors¶
Server: the Health Monitor TANGO server. Aouda Server: Tango server that provides the Aouda Suit simmulated data.
2.3.2.3.2 Priority¶
High
2.3.2.3.3 Preconditions¶
The Server is running and its DevState is ON.
2.3.2.3.4 Basic Course¶
- The Server request new data from each available Aouda Server.
- The Aouda Servers returns the data available.
- The Server stores the data of each suit.
2.3.2.3.5 Alternate Course¶
None
2.3.2.3.6 Exception Course¶
None
2.3.2.3.7 Postconditions¶
The data from the suits is stored in the database.
2.3.2.4 The GUI shows overview of crew’s biometrics¶
The GUI gets all data from the previos T seconds, summarizes it and displays it.
2.3.2.4.1 Actors¶
GUI: a GUI with an embedded TANGO client. Server: the Health Monitor TANGO server.
2.3.2.4.2 Priority¶
High
2.3.2.4.3 Preconditions¶
The Server is running and its DevState is ON.
2.3.2.4.4 Basic Course¶
- The GUI calls the appropriate method on the Server, passing T as argument.
- The Server searchs the database for the appropriate records.
- The Server returns the records found.
- For each available suit s:
- The GUI calls the appropriate method on itself, in order to summarize the biometrics of s.
- The GUI calls the appropriate method on itself, in order to display the summarized biometrics of s.
2.3.2.4.5 Alternate Course¶
None
2.3.2.4.6 Exception Course¶
None
2.3.2.4.7 Postconditions¶
The crew biometric’s overview is shown on the GUI.
2.3.2.5 A User requests a crewmember’s detailed biometrics¶
A user requests the detailed biometrics for a given crewmember and the GUI complies.
2.3.2.5.1 Actors¶
User: a user of the GUI. GUI: a GUI with an embedded TANGO client.
2.3.2.5.2 Priority¶
High
2.3.2.5.3 Preconditions¶
The Server is running and its DevState is ON.
2.3.2.5.4 Basic Course¶
- The User clicks on the icon of crewmember c.
- The GUI hides the summarized view for c.
- The GUI shows the detailed view for c.
2.3.2.5.5 Alternate Course¶
None
2.3.2.5.6 Exception Course¶
None
2.3.2.5.7 Postconditions¶
The selected crewmember biometric’s detailed view is shown on the GUI.
2.4 Interface Requirements¶
2.4.1 User Interfaces¶
2.4.2 Hardware Interfaces¶
Here should be referenced the hardware interfaces of the biometric devices. Specifics are TBD.
2.4.3 Software Interfaces¶
The data collector module will be implemented as a Python TANGO server, which will expose methods to request raw as well as summarized data.
2.5 Performance Requirements¶
The software should allow the monitoring of health metrics in real-time, therefore any preparation of the data should be quick enough as to be non-noticeable.
Furthermore, the suit simulator should be able to run in a RasperryPi or similar.
Specifics are TBD.
2.9 Development and Test Factors¶
2.9.1 Standards Compliance¶
The guidelines defined in [2] should be followed.
2.9.2 Planning¶
The high-level schedule is defined in [3], with deliverables as follows:
A TANGO server that implements the data collector.
A GUI that presents summarized and detailed data of the crew’s biometrics.
A document describing the biometric devices selected for the project.
A space suit simulator that integrates the real devices.
Testing
- Test environment to help diagnose the server’s work.
- A set of integration tests between the collector and the GUI.
- A set of interface tests for the GUI.
Documentation.
- User requirements (this document).
- Design Study document.
- User Manual.
The time for this particular project is devided as follows:
|
1/2 week |
|
1 weeks |
|
3 weeks |
|
3 weeks |
|
2 weeks |
|
1 week |
|
1 week |
|