Undersea Station: Data Processing

Calamar Park UIUpdated 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:

chart of the IT architecture for data processing
Concept for IT Architecture, contact Mart for the original XMind file

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.

The 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

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

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

Supervisors Screen

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.

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)
Support by Sharing

4 Replies to “Undersea Station: Data Processing”

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

    1. Hi Miguel,
      why not, let’s keep it in mind. I also started to use Linux in 2014. After using an Ubuntu version which made me a little disappointed I installed the Mint version. Nearly two years passed until now, but these lines are written on a Linux Mint 17 system. I have to admit that I am good with computers, but far from being an IT professional. The Linux Mint system worked very stable on two Laptops and it has a very intuitive UI.
      It might be a good idea to ask the community. The system would then be transparent and independent. I do not have any details if this idea has the potential to work, but would be very glad about comments on that subject.

  2. I got a mail by Mike asking me why we plan to develop the whole system from scratch.

    Well, I actually meant the User Interface. If there are ready solutions for the measuring devices, of course we will use them. But I can not imagine that there are ready solutions for the User Interface of an undersea station. This also might be an opportunity to create a new approach for it combining all input data and presenting them to the Aquanauts as intuitive and useful as possible.

Leave a Reply