(Updated 15.05.2020 – Added noise recognition to Concept Map, improved article structure etc.) 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.
The targeted IT Architecture can be divided into three major sections:
- Input or Measurement Technology containing all sensor devices
- Controlling covering the evaluation for automatic or requested intervention
- Output into different User Interfaces and corresponding audiovisual designs; this section also contains the onboard server
See the following concept map to clarify the structure:
It is very important to note that this is a concept for the final stage of the station, which means that all these functions of data processing do not have to be fully working in the first stages especially those who are only required for longer stays. Since the main intention in the beginning is to build a station for very short visits only, we should start with creating the necessary IT architecture and the most vital functions. The only requirement on this architecture will be the ability to add more and more of the functions listed above.
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 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
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. Mart had the 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:
- 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
- IT security
- 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
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