Meditech: Inter-process control

Introduction

Meditech should be something simple. Simple to use, addressed to non-expert IT users, possibly as much autonomous as possible, possibly able to help the operator, possibly usable with few buttons (=NO KEYBOARD REQUIRED) and much more. This is a must over all the possible features that should have.

The equation is simple: the user should see Meditech like a tool, despite what it contains. Power on the device until the devices says Ready then his skill and knowledge should be focused - maybe exclusively focused - on the use of the probes. This means set the body temperature sensor in the right place, set the ECG electrodes in the right place, know if the data are indicating a possible disease or not.

Every user simplification, as any developer knows, will correspond to a meaningful complexity increase in the back of the system. But this is the only way that Meditech can be really usable in the non-conventional operating conditions it is expected to be used. This means that there are no excuses

Resuming the architectural simplifications applied we can focus:

• Simple numeric IR controller (like the TV controller) manages the entire system
• TTS (Text-To-Speech) audio feedback avoid the user to read status changes, confirmations and usage guides
• No Keyboard is needed for the normal usage
• Screen display shows only the essential information: no inactive windows, no long messages to read, no floating windows
• Desktop and menu bars from the Linux are hidden on startup

The main controller strategy

One of the key-concept of Meditech is modular system; this goal is reached because every component works as a vertical, independent task solver: if a component is not detected or stop responding for some reason its features are excluded. As a matter of fact are sufficient two of the three internal Raspberry PI devices to keep the system running. This obviously includes the essential peripherals: audio card, networ switch, control panel and LCD display. So, ignore the question "what happens if it explode" and similar.

The "glue" keeping all together and distributing the tasks correctly, depending on the user requests is the main controller, a sort of semaphore component created in Python. So what is the better place where this application can reside? on the background. Not running in background but on the background graphic component that is the minimal view shown on the screen while the system is powered-on.

So, the image above shows the just powered-on Meditech face. As the entire system is controlled through the Infrared Controller until the system is not put in maintenance mode and connected with a mouse and keyboard there is no way to enter in a deeper level of the system. And there is no reason.

The actual developing version of the prototype, for obvious reasons does not start automatically on boot but the application version will start directly with the standard interface.

Controlling the system behaviour

At this point there is another important question to be answered: how to manage the Meditech architecture data flow?

As the user interface manager is the nearest task to the user interaction this is also the best candidate to manage the entire data flow and task execution. When Meditech is powered-on this is the process that is started automatically together with the infrared controller appplication. The interaction module send commands and requests directly to the process controller that shows the background main User Interface. At this point the system is ready to manage all the parts from a single asynchronous controller.

Note that the graphic view for every status, informational window, graphic etc. is actuated by independent Python widgets launched and blocked by the process control as well as the activation of the probes. But the other side the background processes are ready to receive the probes information, collect data and store them on the database. As the remote access is to the information is under the user control also the activation of the Internet transmission to the remote server over a dependent MySQL database is managed by the process controller.

The following scheme illustrates how starting from the User Interaction and direct feedback the system works and react to the requests.

Controlling processes with Python in practice

As occur in almost any language al sin Python it is possible to launch external tasks, i.e. bash scripts, programs or other Python scripts. The problem arise when the Python process control application should act as a semaphore (also intended in the traditional IT way). The choice of Python - should be remarked - instead of something more low-level depends on the graphic performances of the language; in this way it is possible to integrate both the main UI visualisation and the process control saving one more task running inside the RPI master device.

The approach in Python is almost simple: there are three different instructions enabled to launch external programs. The first (and probably more immediate) approach is the use of the os.system() call to deal for another process with the operating system; no matter how this command is done, C++ or any other compiled language, java or bash. So, for example:

import os
print(os.popen('command').readline())
x = _
print(x)

This is the first method to be avoided, due the complexity managing the return values. The other potential issue is that with os.system() call Python pass the control of the entire process - that we want to control - to the operating system.

What has demonstrated the right approach instead is the use of the subprocess call. Just like the Python multiprocessing can do managing internal multi-threading, in a similar way subprocess can spawn different processes giving more control to the calling application, in a simpler way. So it is possible - that is our case - manage the following architecture:

1. Start the main UI + process control
2. Start the IR controller that send back to the controller the user requests, commands etc.
3. At this point the process is full operational

All the other processes launched by the controller start something in the system by launching a bash script or a C++ command. Every process follows a double-data exchange with the controller enabled to decide what is working in a certain moment and what it is not. A typical procedural approach can be the following:

Every process is launched keeping direct control of its stdin, stdout, stderr while the widget visualisation are graphic objects developed in Python script.

For subprocess details in Python, this link is a good starting point.

For the full explanation of the subprocess, this is the Python link manual