2   Software Requirements Specification for the Heart Rate Monitor

Author:Mario Tambos

2.1   Change Record

2013.06.18 - Document created.

2013.06.26 - Fixed typos and formatting.

2013.06.26 - Removed unused sections.

2013.06.26 - Added Use Cases and Sequence diagrams.

2013.09.18 - Updated to reflect current requirements. Some formatting changes.

2.2   Introduction

2.2.1   Scope

This document describes the top level requirements for the Heart Rate Monitor module, which in turn is part of the Crew Mission Assistant system.

2.2.2   Reference Documents

2.2.3   Glossary

ERAS
European Mars Analog Station
IMS
Italian Mars Society
EVA
Extra-Vehicular Activity
TBD
To Be Defined
TBC
To Be confirmed

2.3   General Description

2.3.1   Problem Statement

Monitoring of the crew’s health is a critical part of any mission. Said monitoring includes, among other things, overseeing the heart rate of the crew members, in order to take preventive actions if it takes on abnormal values. However, this task can prove difficult to accomplish, due to the fact that a persons heart rate not only hasn’t a constant “normal” value, but also depends on a number of factors, for instance the level of physical stress that the person endures at the moment. In [1] it is stated that the current approach to solve this problem is the use of a Feed-Forward Neural Network to predict the heart rate from the body acceleration reported by the Aouda.X suit. This can prove troublesome, given that regression techniques have difficulties achieving high recall when the training set is skew, as in this case (there are going to be far more normal than abnormal datapoints).

I believe using Anomaly Detection techniques would prove a more reliable method of alert for this use, because these techniques are specifically designed for the purpose, i.e. are not affected by imbalances in the cardinality of the datapoint classes.

2.3.2   Functional Description

The goal of this module is to oversee the heart rate and physical activity of each crew member performing EVA, in order to raise alarms if the reported crew member’s heart rate is abnormal for his or her current physical stress level.

2.3.3   Constraints

As described in [1], the available heart rate and accelerometer data from the Aouda.X suit is too unreliable to be of any use for this module prototype. Therefore the data found in [2] will be used instead as a way to simulate a reliable data stream from the suit.

2.4   Interface Requirements

2.4.1   Software Interfaces

2.4.1.1   Communication Interfaces

This module will be implemented as a Python TANGO server, which will expose methods to request the heart rate, level of physical activity and heart rate alarms, if they exist. Moreover the alarms should be optionally declared as events, to enable push request from the server to the clients.

2.5   Development and Test Factors

2.5.1   Standards Compliance

The guidelines defined in [3] should be followed.

2.5.2   Planning

The schedule is as defined in [4], with deliverables as follows:

  • TANGO server that implements the anomaly detector.

  • Test environment to help diagnose the server’s accuracy.
    • Train and test data sets.
  • Documentation.
    • User requirements (this document).
    • Design Study document.
    • User Manual.

2.6   Use-Cases

2.6.1   Request for current average Heart Rate

The Client request the Server the average Heart Rate over the last T seconds.

../../../_images/UCRequestforcurrentavgheartrate.png

2.6.1.1   Actors

Client: a TANGO client that makes the request. Server: the Heart Rate Monitor TANGO server.

2.6.1.2   Priority

Normal

2.6.1.3   Preconditions

The Server is running and its DevState is ON.

2.6.1.4   Basic Course

  1. The Client calls the appropriate method on the Server, passing T as argument.
  2. The Server calculates the average heart rate over the last T seconds.
  3. The Server returns the calculated value.

2.6.1.5   Alternate Course

None

2.6.1.6   Exception Course

  1. The Client calls the appropriate method on the Server, passing T as argument.
  2. The Server tries calculates the average heart rate.
  3. No data is available.
  4. The Server returns an error.

2.6.1.7   Postconditions

None

2.6.1.8   Sequence diagram

../../../_images/SeqRequestforcurrentavgheartrate.png

2.6.2   Request for current average acceleration

The Client request the Server the average level of physical activity over the last T seconds.

../../../_images/UCRequestforcurrentavgacceleration.png

2.6.2.1   Actors

Client: a TANGO client that makes the request. Server: the Heart Rate Monitor TANGO server.

2.6.2.2   Priority

Normal

2.6.2.3   Preconditions

The Server is running and its DevState is ON.

2.6.2.4   Basic Course

  1. The Client calls the appropriate method on the Server, passing T as argument.
  2. The Server calculates the average level of physical activity over the last T seconds, based on accelerometer data.
  3. The Server returns the calculated value.

2.6.2.5   Alternate Course

None

2.6.2.6   Exception Course

  1. The Client calls the appropriate method on the Server, passing T as argument.
  2. The Server tries calculates the average level of physical activity.
  3. No data is available.
  4. The Server returns an error.

2.6.2.7   Postconditions

None

2.6.2.8   Sequence diagram

../../../_images/SeqRequestforcurrentavgacceleration.png

2.6.3   Request for current alarms

The Client request the Server the list of alarms raised over the last T seconds.

../../../_images/UCRequestforcurrentalarms.png

2.6.3.1   Actors

Client: a TANGO client that makes the request. Server: the Heart Rate Monitor TANGO server.

2.6.3.2   Priority

High

2.6.3.3   Preconditions

The Server is running and its DevState is ON.

2.6.3.4   Basic Course

  1. The Client calls the appropriate method on the Server, passing T as argument.
  2. The Server returns the list of alarms raised over the last T seconds.

2.6.3.5   Alternate Course

None

2.6.3.6   Exception Course

None

2.6.3.7   Postconditions

None

2.6.3.8   Sequence diagram

../../../_images/SeqRequestforcurrentalarms.png

2.6.4   Server requests new data

The Server reads new data from the Framework Software Bus, ands sends it to the Anomaly Detector for analysis.

../../../_images/UCServerrequestsnewdata.png

2.6.4.1   Actors

Server: the Heart Rate Monitor TANGO server. Anomaly Detector: the module in charge of detecting anomalies. Aouda Server: Tango server that provides the Aouda Suit simmulated data.

2.6.4.2   Priority

High

2.6.4.3   Preconditions

The Server is running and its DevState is ON.

2.6.4.4   Basic Course

  1. The Server request new data from the Aouda Server.
  2. The Aouda Server returns the data available.
  3. The Server sends the new heart rate and accelerometer data to the Anomaly Detector.
  4. The Anomaly Detector has enough data to build an anomaly analysis and returns the anomalies scores to the Server.

2.6.4.5   Alternate Course

None

2.6.4.6   Exception Course

  1. The Server request new data from the Aouda Server.
  2. The Aouda Server returns the data available.
  3. The Server sends the new heart rate and accelerometer data to the Anomaly Detector.
  4. The Anomaly Detector has not enough data to build an anomaly analysis and returns nothing to the Server.

2.6.4.7   Postconditions

None

2.6.4.8   Sequence diagram

../../../_images/SeqServerrequestsnewdata.png