3   Software Design Study for the Heart Rate Monitor

Author:Mario Tambos

3.1   Change Record

2013.06.28 - Document created.

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

3.2   Introduction

3.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.

3.2.2   Applicable Documents

3.2.3   Glossary

AD
Anomaly Detection
API
Application Programming Interface
ERAS
European Mars Analog Station
IMS
Italian Mars Society
HRM
Heart Rate Monitor
TBC
To Be Confirmed
TBD
To Be Defined

3.3   Design Considerations

As stated in [5], the approach to the problem of monitoring the crew’s heart rate,is to use AD techniques. Said techniques are however not unique; nor has a priori search for heart rate AD returned any directly applicable results. Therefore several other methods were investigated. After several tests, using data from [2] (see also [8] and [9]), and analysis of their results, the method described in [10] was selected. The objective of the design was nevertheless to encapsulate the anomaly detector itself in a single class, so it can both be used elsewere if necessary and be replaced if some better method is discovered.

3.3.1   Assumptions and dependencies

The HRM is to be programmed as a TANGO server, in the Python language. As such its primary dependencies are:

  • The Python language.
  • The TANGO distributed control system (see [6]).
  • The PyTango bindings (see [7]).
  • NumPy and Pandas, respectively a scientific computation and a data analysis library for Python, to perform the AD on the data.
  • SqlAlchemy, a ORM for Python.

3.3.2   General Constraints

  • Guidelines defined in [3].
  • Requirements described in [5].

3.3.3   Objectives

  • Provide some meaningful measure of the anormality level of a sequence of heart rate and acceleration readings, with respect to historic readings.
  • Provide some measure of fault tolerance in the face of sensor errors.
  • Keep the modules simple and easy to maintain.

3.4   Software Architecture

The HRM will be divided into two main modules: a TANGO Server, named HRMonitor, and an Anomaly Detector, named AssumptionFreeAA.

In order to test the HRM – and avoid the current problems with the Aouda.X suit – an additional TANGO Server will be built, named Aouda, from which the HRMonitor will get the simulated heart rate and accelerometer data (in turn taken from [2] (see also [8] and [9])).

Use case and sequence diagrams showing the hig level interactions between the modules can be seen in section 2.6. of [5].

3.5   Software Design

A high level class diagram outlining the components can be seen below.

../../../_images/CLSHighLevel.png

3.5.1   hr_monitor

../../../_images/CLSHRMonitor.png

3.5.1.1   Classification

Package, Class, Tango’s DeviceServer implementation.

3.5.1.2   Responsibilities

Is in charge of interacting with the Aouda Server, implementing all necessary interfaces to integrate itself with the rest of the C3 Prototype and acquiring the heart rate and accelerometer data. It does not make any computation by itself, it only acts as a proxy between the external world and the hr_monitor.py.

3.5.1.3   Constraints

Retrieves data from aouda with format:

[
      [hr1, acc_x1, acc_y1, acc_z1,
       hr2, acc_x2, acc_y2, acc_z2,
       ...
       hrN, acc_xN, acc_yN, acc_zN],
      [timestamp1, timestamp1, timestamp1, timestamp1,
       timestamp2, timestamp2, timestamp2, timestamp2,
       ...
       timestampN, timestampN, timestampN, timestampN],
]

Returns alarms data with format:

[[alarm_lvl1, ..., alarm_lvlN], [timestamp1, ..., timestampN]]

3.5.1.4   Composition

The package’s subcomponents are described below:

  • PyDsExpClass
    • Type: class.
    • Function: defines DeviceServer’s attributes and commands.
  • PyDsExp
    • Type: class.
    • Function: implements interface defined in PyDsExpClass.

3.5.1.5   Uses/Interactions

  • hr_monitor.py: hr_monitor forwards its requests to this package for processing.
  • aouda: hr_monitor requests the suits’ data from this package.

3.5.2   hr_monitor.py

../../../_images/CLSHRMonitorController.png

3.5.2.2   Responsibilities

Interacts with data storage and assumption_free.py.

3.5.2.3   Constraints

The response times should be keept in all cases at a minimum to avoid timeouts. As minimum we will consider here the timeout time of Tango synchronous requests.

3.5.2.4   Composition

The package’s subcomponents are described below:

  • HRMonitor
    • Type: class.
    • Function: takes charge of package’s responsibilities.

3.5.2.5   Uses/Interactions

  • data_model.py: hr_monitor.py uses it to model the data, both suit’s heart rate and acceleration redings and anomaly analysis results, and store it in a database.
  • assumption_free.py: hr_monitor.py sends to it newly acquired data for analysis and receives back the analysis results.
  • hr_monitor: hr_monitor.py receives from it forwarded requests and newly acquired data.

3.5.3   assumption_free.py

../../../_images/CLSAssumptionFree.png

3.5.3.2   Responsibilities

Is in charge of applying the method described in [10] to the data provided by hr_monitor.py.

3.5.3.3   Constraints

  • Each datapoint is a single dimensional vector.
  • The analysis should contain both an anomaly score and its timestamp.

3.5.3.4   Composition

The package’s subcomponents are described below:

  • AssumptionFreeAA
    • Type: class.
    • Function: takes charge of package’s responsibilities.
  • AssumptionFreeAA.Analysis
    • Type: named tuple.
    • Function: encapsulates the analysis result.

3.5.3.5   Uses/Interactions

  • hr_monitor.py: assumption_free.py receives from it newly acquired data for analysis and sends back the analysis results.

3.5.4   aouda

../../../_images/CLSAouda.png

3.5.4.1   Classification

Package, Class, Tango’s DeviceServer implementation.

3.5.4.2   Responsibilities

Is in charge of simmulating data generated by the Aouda Suit and implementing all necessary interfaces to integrate itself with the rest of the C3 Prototype. It does not make any computation by itself, it only acts as a proxy between the external world and the aouda.py.

3.5.4.3   Constraints

Returns heart rate and acceleration data with format:

[
      [hr1, acc_x1, acc_y1, acc_z1,
       hr2, acc_x2, acc_y2, acc_z2,
       ...
       hrN, acc_xN, acc_yN, acc_zN],
      [timestamp1, timestamp1, timestamp1, timestamp1,
       timestamp2, timestamp2, timestamp2, timestamp2,
       ...
       timestampN, timestampN, timestampN, timestampN],
]

3.5.4.4   Composition

The package’s subcomponents are described below:

  • PyDsExpClass
    • Type: class.
    • Function: defines DeviceServer’s attributes and commands.
  • PyDsExp
    • Type: class.
    • Function: implements interface defined in PyDsExpClass.

3.5.4.5   Uses/Interactions

  • hr_monitor: aouda receives requests for the suits’ data from it.
  • aouda.py: aouda forwards its requests to this package for processing.

3.5.5   aouda.py

../../../_images/CLSAoudaController.png

3.5.5.2   Responsibilities

Is in charge of simulating the heart rate and accelerometer data generation of the Aouda.X suit.

3.5.5.3   Constraints

The response times should be keept in all cases at a minimum to avoid timeouts. As minimum we will consider here the timeout time of Tango synchronous requests.

3.5.5.4   Composition

The package’s subcomponents are described below:

  • Aouda
    • Type: class.
    • Function: takes charge of package’s responsibilities.
  • Aouda.DP
    • Type: named tuple.
    • Function: encapsulates the heart rate and acceleration data.

3.5.5.5   Uses/Interactions

  • aouda: aouda.py receives from it forwarded requests for simmulated data.

3.5.6   data_model.py

../../../_images/CLSDataModel.png

3.5.6.2   Responsibilities

Is in charge of modeling the hear rate, acceleration and anomaly analysis data, and of managing its storage.

3.5.6.4   Composition

The package’s subcomponents are described below:

  • Datapoint
    • Type: class.
    • Function: models a heart rate-acceleration datapoint.
  • Alarm
    • Type: class.
    • Function: models a single anomaly analysis result.

3.5.6.5   Uses/Interactions

  • hr_monitor.py: data_model.py provides to it the classes necessary to model the data used.