2 Software Architecture Document for the Habitat Monitoring and Alarming Interface¶

Author:	Ambar Mehrotra

2.1 Change Record¶

25th May, 2015 - Document Created

2.2 Introduction¶

2.2.1 Purpose¶

The purpose of Alarming and Monitoring interface is to manage all the relevant information. The GUI will give the user a complete overview of the entire habitat and how all the instruments are functioning.

The Health Monitor GUI will be dedicated to provide information about health of the astronauts performing EVA through biosensors (ECG, air flow sensor , etc.).

2.2.2 Scope¶

Describes the scope of this requirements specification.

2.2.3 Applicable Documents¶

2.2.4 Reference Documents¶

[1] – C3 Prototype document v.4
[2] – Software Engineering Practices Guidelines for the ERAS Project
[3] – Tango Setup
[4] – Adding a new server in Tango
[5] – Extending Alarm Handling in Tango

2.2.5 Glossary¶

IMS: Italian Mars Society
ERAS: European MaRs Analogue Station for Advanced Technologies Integration
V-ERAS: Virtual-ERAS
GUI: Graphic User Interface
API: Application Programming Interface
PANIC: Package for Alarms and Notification of Incidences from Controls
TBD: To be defined
TBC: To be confirmed

2.2.6 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¶

Implementation Constraints
1. Language
  
  The application should be written in python.
2. Operating System
  
  The application should be run on Ubuntu distributions.
3. Software
  
  PyQt Library PyTango Library Tango server(pyTango), Python 2.x, Pep8,
Supportability
1. Ease of Installation
  
  System requires installation of PyQt and Tango server.

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 entire habitat. A GUI will request the data from the database using the PANIC API, summarize it and present it to an overseer in a way that allows him/her to detect problems at a glance.

2.3.2.1 Request for sensor data¶

The Client requests a Network Device Server for the sensor data of the last T seconds.

2.3.2.1.1 Actors¶

Client: Habitat Monitoring GUI.
Server: the Device 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 Tango host for the alarm data of the last T seconds.

2.3.2.2.1 Actors¶

Client: Habitat Monitoring GUI.
Server: The Tango host responsible for collecting alarm data.

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 User requests to add new device¶

The user wants to add a new Tango Device on the network to monitor using the GUI.

2.3.2.3.1 Actors¶

User: The user who wants to add a new Device.
Client: the Habitat Monitor TANGO client.
Device Server: Tango server running on the network.

2.3.2.3.2 Priority¶

High

2.3.2.3.3 Preconditions¶

The Server is running and its DevState is ON. The GUI is running.

2.3.2.3.4 Basic Course¶

The user requests the GUI to add a new Device.
The GUI asks the user for the internal Tango Device address.
The user responds with the device address.
The GUI queries the device for attributes.
The device returns the required attributes.
The GUI starts showing its data.

2.3.2.3.5 Alternate Course¶

None

2.3.2.3.6 Exception Course¶

None

2.3.2.3.7 Postconditions¶

The Device data is shown on the screen or GUI shows an error message if the device is not found on the given address.

2.3.2.4 A User requests a device’s detailed data¶

A user requests the detailed data for a given device and the GUI complies.

2.3.2.4.1 Actors¶

User: a user of the GUI.
GUI: a GUI with an embedded TANGO client.

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 User clicks on the icon of device.
The GUI hides the summarized view for device.
The GUI shows the detailed view for device.

2.3.2.4.5 Alternate Course¶

None

2.3.2.4.6 Exception Course¶

None

2.3.2.4.7 Postconditions¶

The selected device’s detailed view is shown on the GUI.

2.4 Interface Requirements¶

2.4.1 User Interfaces¶

Describes how this product interfaces with the user.

Bellow are two mockups that cover the two current Use Cases that concern the GUI.

2.4.1.1 Graphical User Interface¶

2.4.1.1.1 Overview¶

2.4.1.1.2 Detailed View¶

2.4.2 Software validation and verification¶

The GUI will be implemented as a Tango Client that will fetch data from the varios device servers and show it in a concise manner.

2.4.3 Planning¶

The development of the GUI will be done in primarily the following phases.

Building the skeleton for the GUI. This is the primary portion of the project

and will require the work on the following areas.

Allowing the GUI to add additional data channels.

Integration with the Tango Alarms System

Integrating the monitoring system with the plottings coming in from the

various biometric devices using a generic mechanism.

Development of the Health Monitoring module as a sub-GUI of the habitat

monitoring interface.