Introduction
After the two first phases, creating an initial beta version of the Meditech hardware including a first series of probes it is time to move the project to the software side consolidating the architecture.
One of the difficulties defining the software architecture is to identify the correct development areas for the different parts: different programming languages and development environments, almost strong hardware interaction, human interface, data collection and management, Internet and remote server data exchange and more. All these parts should be harmonised creating a unique operating device where most of the features are automated processes.
Internal hardware organisation
The image below shows the Meditech components how they are organised in the device architecture, the network connection (WiFi and ethernet wired in violet), the acquisition data flow (red), the control-panel autonomous subsystem (green and the Raspberry PI connected peripherals (blue)
Networking
Networking approach involves all the Raspberry PI modules of the system; three units are wired through an ethernet 10/100 switch while the fourth device accesses the system via WiFi connection, as it should operate in mobility near the patient. The settings of this base network connection requires mostly linux commands and special settings, depending on the way every Meditech internal unit should connect with the master unit (RPI master) For every network connection / protocol it is reported the adopted software strategy.]
The most important protocol used are the following: NFS, SSH, HTTP & HTTPS, MySQL, NTP
- NTP server - To grant synchronised date and time with every collected data and event the RPI slave1 act as a NTP server based on the real time clock. RPI slave1 accesses the Internet every boot time (if available) to synch its internal clock device. As the RPI slave3 is connected through the WiFi (on a different network than the other units) the main unit RPI master act as a secondary NTP server for wireless connected devices time synchronisation. [Requires server settings for date and time synchronisation through bash scripting]
- Network mounted folders - The 120 Gb storage device is directly connected to the RPI master device. All the data produced by the other devices (usually preprocessed locally then send to the master for post-processing and integration) are stored on folders of the RPI master permanently mounted at system startup. [Requires server permanent settings at startup through bash scripting]
- Raw data streaming - Using differentiated protocols and methods both the audio data from the RPI slave2 unit and video and camera data from the RPI slave3 unit when the probes are active are streamed internally to the RPI master unit while the data that requires storage are saved on the central storage system via network folders. [Requires streaming protocol settings (Linux) and bash scripting for preset]
- GPS and Accelerometer - The current coordinates position and bearing and orientation data are managed by the RPI slave1 unit that stream continuously the updated information, available by the RPI master unit to attach these information when needed to the collected data from the probes as well as date and time information retrieval. [Requires streaming protocol settings (Linux) and bash scripting for preset]
- Printing - The Bluetooth printer is managed by the RPI slave1 unit; all the units - depending on some specific conditions are enabled to send printable data to the the RPI slave1 that manages the information using printing templates. [Requires Python scripting for the printer control and the protocol control characters settings, Linux settings and some bash scripting]
- Remote accessibility - To make remote assistance and support as simple as possible and accessible by potentially any kind of device, the RPI master exposes almost any information that will be available on the local LCD display to remote user through the intermediate server and a set of APIs, the Meditech Remote API. Remote users will access remotely the Meditech device with any browser through the dedicated domain http://meditech.balearicdynamics.com
Languages and application contexts
C++ under MPIDE for ChipKit PI
All the control panel features are managed as an autonomous system. The ChipKit PI that controls these features hosts a firmware developed in C++ including a dedicated serial communication protocol to enable the board receiving requests from the RPI master unit.
C++ for Linux command line
Two class of commands will be available on the system: command line programs to launch the execution of specific tasks, e.g. processing some information from probes and a set of commands that should run independently by the condition or user interaction running under Linux at startup as services. It is the case of the IR receiver to control the TV controller and the integrated wireless Bluetooth device Keyboard+mouse.
The TV IR controller will be the main controlling device and the choices and menu are shown on the control pane LCD display; this is the reason that the ChipKit PI board should exchange commands with the RPI master unit via TTL serial connection.
Another important C++ service application is the ChipKit PI receiver including the notifications of alert and error conditions, e.g. the lid open or excessive internal heating.
Qt environment
Some of the internal probes related to the blood and heart conditions are acquired through the BitScope micro device. The real-time data processed by the BitScope librarie are managed through C++ classes to show these images on a Qt-based interface .
As a matter of fact, the LCD Display that is part of the Meditech device in its normal use will show a set of customised areas accordingly with the used probes, the kind of analysis and other data. This display environment shows over the standard Linux X-Server desktop so that only during some maintenance operations (managed by a special authorised user) the standard desktop, commands and Linux applications are visibile.
The graphic design for the Qt environment is developed using the Qt C++ libraries.
Python
Python language is used mostly for testing and in some cases to manage low-priority tasks, like the printable data exchange. All where it is possible it is used Python3 while in some cases, where only Python 2.x libraries are available it is used Python 2.7.
The actually python tasks that is expected to be used are: PiFaceCAD, some simple task for data exchange between the Meditech Raspberry PI units and few other.
Java
Due to a huge number of classes already available developed to work under the Android environment but simple to port to any other environment Java should be used for some of the printing features (especially the graphic data conversion and the special Esc/POS printers protocol management) and the access to the remote Internet server APIs.
The choice to use Java for the remote access has conditioned by two key factors: the first is that it is my opinion that this language is the better choice to manage JSOON packets, that is the standard adopted to exchange data with the remote server. The second factor is that I can reuse a certain number of classes for parsing and protocol management that are strategical to enable the full printing features instead of a bare text-only printout.
SQL
The SQL language is involved locally as all the data sets history is stored in a local SQL database. This means that several scripts and bash linux commands, including queries, SQL data backups and so on, should be provided in the RPI main module for this function.
PHP
PHP is the core language of the remote server. The meditech.balearicdynamics.com will expose a number of PHP APIs to the Meditech device connection for many different kind of data exchange. The remote server makes available a page to the remote user assistance showing all the Meditech information in a single graphic page kept updated continuously.
Top Comments