Updated 06.03.2017 – 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:
- The Input or Measurement Technology containing all sensor devices
- The Controlling covering the evaluation for automatic or requested intervention
- The 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 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 sensoric devices are smaller, cheaper and easier to use. Computers have a much higher 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.
Example: Cortana by Microsoft
Quite a long time ago I had the idea to give the system a face that looks a bit like the thumbnail at the beginning of this post. It was a nice surprise that Microsoft had a similar idea 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 face of our system shows different expressions according to the state of the habitat. Every threat to its integrity will be reflected in these Mimics of the Operational System.
Example: Baxter by Rethink Robotics
Another surprise was the implementation of a emotional aspect at the Baxter Collaborative Robot of Rethink Robotics in Boston. 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)
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
The idea was not to bother 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 or clearly demanded by the aquanauts (via voice recognition/verification?). 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
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.
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
- Audio files for the different alert levels
- Designs/proposals for the User Interface visuals (standard, alert, supervisor)