Undersea Station: Data Processing

(Updated 15.01.2021 – complete re-edit of post; updated concept map) The Digital Data Processing of the station will be of major importance. Beside the conventional functions of the IT systems we should use the opportunity to establish a completely new approach concerning the User Interface (UI) and the system’s interaction with the aquanauts. (click here for the pdf-Version of this chapter)

General Considerations

An information management system must

  • Be easy to use
  • Provide data with relevance, timeliness, and accuracy to the user as needed
  • Allow easy updating of, transmittal of, and access to data
  • Reduce or eliminate the need for supplementary materials (such as hardcopy data for procedures), management material (e.g., document restraints, paper filing systems), and associated office supplies (e.g., paper, markers)
  • Use standard nomenclature
  • Have a logical and easily navigated system for accessing information
  • Be compatible with all potential user demographics (considering a range of user skill levels, user knowledge, etc.)
  • Be operable under all conditions of potential workplace environment
  • Integrate well with input and display equipment

Crew Operability

The system must provide methods and tools for the crew to perform information management functions. Information management functions may need to be performed at times when only the crew can perform them, for example when there may be a lack of communication with the land base. Examples of information management functions include graphing system trend information, composing and sending electronic mail, searching for and within procedures, and viewing training materials. The system should be designed for high usability under a variety of scenarios, including the range of environmental conditions in which the user may need access to the data, such as emergency conditions (e.g., poor lighting, power failure).

Data Rate

The system must acquire and provide data at a rate that enables the crew to perform tasks effectively and efficiently (including monitoring system status). Different classes of data must be gathered at different minimum rates to be useful to the crew. For example, air data might be gathered once per second, habitat data once per minute, and routine medical data once per day. Data display rates must not exceed the user’s ability to perceive and act on the information being conveyed.

Data Fidelity

Data fidelity (accuracy, precision, reliability, latency, resolution) is essential for proper habitat functioning and for the crew to make timely and correct decisions, particularly in critical operations. The data must have an appropriate level of fidelity for the crew to perform tasks.

Locations of Data

The crew may choose to perform information management functions (both entry and retrieval) at various locations throughout the vehicle. For example, a crewmember reading an online maintenance schematic may choose to move away from a crewmember having a private medical conference. The system must provide the crew with data to perform tasks at each workstation where those tasks can be performed.

ISS and Shuttle Program history has shown that wireless connectivity is desirable, since it reduces clutter within the vehicle and improves mobility and productivity.

The ISS and Shuttle programs have also shown that wireless connections can be unreliable and hard to troubleshoot; therefore, they are not desired as the sole option for critical functions. It is important to have a backup wired distribution system.

Information Capture and Transfer

The system must provide a method for the crew to capture and transfer information from any display in a format that provides mobility and the ability to annotate. The use of alternative technologies such as digital paper, personal digital assistants, and tablet computers would allow annotations to be shared more easily with Mission Systems, but this requirement does not necessarily preclude the use of printed/laminated material.

Data Backup

Form of Backup Data

Since information management systems operate on electronic hardware, the system must provide a mechanism for backing up data on a regular or periodic basis. Data may be backed up within the system but on another data storage device (such as another hard drive or storage device on the system), transmitted to remotely located storage devices (e.g., land-based systems), or printed/laminated as a way of having hardcopy backup.

Printed and laminated data backups are recommended for highly critical information that might be needed in the event of a total systems power failure. Alternative electronic storage mechanisms may be used for data that might be needed at some later date, but that is not needed immediately or does not need to be accessed during a power failure. Remote data backup is recommended for all data but should be used only for data that would not be needed immediately.

Automated Backup

Backup functions are best automated to prevent inadvertent loss of critical data and the unnecessary expenditure of time. The system must provide an automatic backup function for safety-critical data.

Manual Data Restore

Backup data must be able to be restored to support emergency and critical operations independent of external support (e.g., loss of communication). The system must provide a “data restore” function.

Electronic Information Management

Workstations and portable devices containing accessible electronic information must provide the following:

  • Security
    • General protection against malware of any kind
    • Protection of sensitive data (e.g., password protection, encryption)
    • Electronic privacy – a secure viewing environment for electronically displayed private information such as medical data and e-mails
    • Transmission security
    • Sender verification – ability to add digital signatures to all database traffic between habitat and with the land base, to allow the receiving system to verify the sender’s authenticity
  • Portable data storage – portable data storage devices for transporting data between information access locations and points of use
  • Remote management – land base access to perform all onboard database functions without crew intervention

Electronic Communications

The information management system should provide the following capabilities for communicating electronically:

  • Messaging – the ability to exchange information electronically (e.g., by e-mail, messenger) with the land base
  • Attachments – the ability to attach electronic files (e.g., documents, photos, video, sound files) to communications
  • Encryption – to prevent security breaches, eavesdropping, and tampering with sensitive or private data
  • Sender verification – the ability to add digital signatures to all electronic communications between habitat and with the land base, to allow the receiver to verify the sender’s authenticity
  • Private personal communications – the ability of crewmembers to exchange information of a personal nature (e.g., medical information or family communications) in such a way that only the intended recipients (e.g., surgeon or family member) can read the message or view any attachments

Architecture

Besides the hardware the IT Architecture consists of the following components:

  • Hardware: types, installation, protection
  • Input or Measurement Technology containing all sensor devices
  • Controlling covering the evaluation for automatic or manual intervention
  • Output into different User Interfaces and corresponding audiovisual designs
  • Storage of data, its formats (harddiscs, SSD…), locations and media
  • Transmission of data between habitat and land base (telemetry, mail etc.)

See the following concept map to clarify the structure:

Hardware

The IT system will be located at the highest possible point of the habitat, namely at the apex of the interior ceiling. This area runs like the spine along the entire length of the facility and remains dry even in the event of massive water ingress (see Safety Zone). All connections to the living and working areas lead down from this spine. The IT compartment is air-conditioned and sound and vibration damped. Hardware should provide pressure resistance, and low noise and gas emissions.

Onboard Server

The onboard server will have to contain the following sections:

  • Operational procedures
  • Contingency procedures
  • Safety hazard data (hazard sources, special procedures for safe operations and hazard recovery, and hazard incident log)
  • System maintenance and troubleshooting procedures (e.g., replacement and repair log and procedures)
  • System maintenance log
  • Environmental status and trend data
  • Crew medical histories
  • Inventory management data
  • Video and still imagery
  • Entertainment media (e.g., movies, photographs, books)
  • Habitat system operational health and performance and trend data

Additional data provided may include

  • Schematics
  • Mission event log (including system maintenance history)
  • Recent onboard video and still imagery
  • Training materials and records
  • Hardcopies of critical procedural information – hardcopy backup materials for all emergency procedures of the spacecraft for continued crew safety, rescue, or escape, particularly for scenarioswhere the system’s operation may be degraded due to low power or loss of power

Input

Technology has changed very much since Sealab and Tektite. Most sensor devices are smaller, cheaper and easier to use. Computers have a much higher data processing capacity, are easier to be maintained and much cheaper. Instead of cables to shore and radio communication there are low cost GSM modems available transmitting video, audio, data and communication in high definition simultaneously.  Of course, it will be a challenge to overcome some difficulties, but still our advantages today are incomparable to the analogue ages.

Controlling

Controlling is consisting of routines and limitations. Routines are continuous reading values from the input devices (loop, deutsch: Schleife), compare them with the limit values for low and high alert as well as trend limits stated in the Limitation Value Table. In this table there will also be commands, that allow the Operational System to act automatically (conditional branch, deutsch: konditionale Verzweigung) before manual override. For example: if there is a minor breech in the shell and water is rising from the moonpool then there should be more air pumped from the reserve tanks into the habitat (without waiting for confirmation), medium alert should be given to habitat, surface and land base.

The Limitation Value Table should therefore contain the following columns:

  • Name and position of the input device
  • standard value (no alert), e.g. 28 ± 2 °C interior temperature
  • Low alert for minor negative/positive values, e.g. slight temperature drop/rise
  • Medium alert for medium negative/positive values, e.g. medium temperature drop/rise
  • High alert for major negative/positive values, e.g. major temperature drop/rise
  • Low, medium and high alert for minor, medium or major changes, e.g. in temperature trends, e.g. extraordinary difference in day and night temperature
  • Commands for automated intervention
  • Recommendations for immediate actions, e.g. preparation or urgent conduct of evacuation

Output

This list shows that there is nearly no aspect of the station that is not reviewed by the IT system. All parts of the habitable atmosphere will be maintained by it. Maybe it is not exaggerated to compare the structure with an organism that has sensory, analytical and active regulation abilities as well as a capability of interacting with the aquanauts.

Imparting information (Informationsvermittlung)

As long as not proposed counterwise there will be four different User Interfaces:

  • Habitat Standard UI, for no and low alerts
  • Habitat Alert UI, for medium and high alerts
  • Habitat Supervisor UI, for all information on request
  • The full informative Landbase UI

there might be a point in not bothering the aquanauts with all kinds of data if not necessary and thereby to keep the stress level as low as possible. The necessary information should pop up only if certain limits/trends are exceeded, clearly demanded by the aquanauts (via voice recognition/verification?) or regarded as appropriate by the land base.

Proposal for an Emotional Interface

Since there is no urgency right now we are able to discuss very different approaches for displaying necessary information to the inhabitants of the station. There was a proposal for an emotional interface, consisting of a human face, that represents the IT structure (see thumbnail at the beginning of this post). Already there are several examples available.

Microsoft used a human face for its Cortana system. There a digital image of a female face is used for the user interface as shown on TWCN Tech News.

The Baxter Collaborative Robot of Rethink Robotics in Boston also implemented an emotional aspect. Baxter interacts with the co-workers by being touch sensitive and he/she has a ‘face’ in form of a tablet computer that shows two drawn eyes. And most important: it tries not to look like a human, but like a being of his own type only imitating some interaction routines. That does not make him a scary robot, but a sensible colleague. Visit Baxter’s webpage (english/deutsch) to get an impression what it is all about. (Hier ein Artikel aus Die Zeit)

The face of the Emotional Interface proposal could show different expressions according to the state of the habitat. Every threat to its integrity will be reflected in these Mimics of the Operational System. Roughly it might look like this:

  • All functions within the limits: Face’s eyes are closed, screen background is light green, no particular data displayed inside the habitat, but full information on the supervisors screen (land base)
  • Trends are exceeded: Face’s eyes are open, screen background turns to light orange, corresponding data is displayed, low acoustic notification
  • Limits are exceeded: Face’s expression turns to higher attention, screen becomes light red, corresponding data is displayed, significant acoustic notification

Supervisors Screen (full 3D simulation)

Instead of a numbers-only screen we should also think of an implemented 3D model view of the habitat for the full informative Supervisors Screen of the land base (or the habitat on request) showing the exact position of the determined values.

OS for Administrative Terminals

There are three major IT architectures available: iOS (Apple), Microsoft and Linux.

After using Linux for several years on office computers there are many advantages to be noted:

  • stability
  • independence
  • low popularity (<2%) resulting in a low number of malware
  • sufficient variety of software
  • no cost for purchase or annual usage
  • huge community

The disadvantage of a Linux system for us could be finding one of the rare system administrators and substitute.

To be added

  • off-the-shelf SCADA solutions
  • IT security
  • preferred messaging apps
  • appropriate number of devices (screens, laptops, desktops, NAS,  etc.)
  • backup concepts
  • conference software
  • office suites
  • evaluation of acoustic inputs (sounds and noises) inclusive machine learning of different sound sources, their combination with other inputs and categorizing them to different alarm levels
  • In case of alert: deactivate the overwrite rule (3 days?) and keep records all processes (cams, comm…) until manually released.
  • In case of alert: Interrupt all power lines other than the IT spine location
  • AR alternatives

Participate

If you would like to help us to develop the IT Architecture we would be very thankful for the following contributions:

  • General suggestions and proposals for data processing
  • Audio files for the different alert levels
  • Designs/proposals for the User Interface visuals (standard, alert, supervisor)
  • A short introduction about the available OS (iOS, MS, Linux), comparison and recommendations

This article contains adaptations from the NASA Human Integration Handbook (HIDH), NASA/SP-2010-3407. NASA copyright policy states that “NASA material is not protected by copyright unless noted”. (See NASA copyright policy page or JPL Image Use Policy.)

Support by Sharing
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

6 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Miguel
Miguel
5 years ago

Hi Mart,
what do you think of applying to the Linux community to let evolve the IT architecture. There are many enthusiastic people with great ideas.

Nursel
Nursel
Admin
4 years ago

Could somewhat AI be of any use at this point? Or am I completely missing it?