The following methodology describes the IHF solution for the Edinburgh trams Driver Innovation Safety Challenge (DISC).
The whole DISC system (Figure 1) consists of 3 physical elements;
- the tram cab (data source);
- the control room web portal; and
- the server.
Figure 1, The concept of DISC system and its data flow
Figure 2, The concept of COVID system and its data flow
For the data source, a microcomputer will be placed in each tram cab for connecting sensors, actuator and feedback devices.
Data collected from the driver using sensors will be initially processed locally in order to display run-time information in the tram cab. The data will then be transmitted to the server for further data processing and storage at the server. The server will be able to understand the behaviour of tram drivers and set an individual personal baseline for the driver. This will enable the system to predict more accurate information and give earlier warnings.
At the control room side, operators will be able to use web browsers to get the run-time information of all operating tram cabs. Human readable and meaningful information will be shown on the web portal alongside with the “Driver Conscious” warning level as this data has been processed at the server. Bi-directional data channel will be ready for transmitting commands from the control room to corresponding tram cabs. These commands are designed to give haptic feedback to the driver.
As a first stage, a simplified version of the DISC concept is being developed to detect COVID-19 symptoms (Figure 2). It will allow a more rapid deployment of the system for testing and implementation. In this system, IoT sensors will directly send data to the server to analyse whether the driver has been infected. The web portal will only show “warning level” information for making a further decision and detail information will be provided only when drivers are referred to the clinic or hospital.
For the second stage, the framework of the COVID-19 system will be expanded for both the cyber and the physical aspects. During the development process, the IHF team will, again, review the range of physiological data with advice from medical experts in order to broaden the monitoring capabilities of the solution. The system will then be tested and modified in a lab environment during development before trials ‘in the field’.
For the third stage, sensors, haptic devices and battery will be embedded into the wearable design. Prototype product will be integrated into the whole system and go into the stage of testing with the real-world scenario before deployment. For testing the system, the IHF team will formulate a set of test protocols to ensure the system will be deployed with no errors.
Hardware and Software (wearable, in-cab hub and cloud server). Booting order:
- the cloud server
- in-cab hub
The cloud server shall always be ‘on’ and ready for connections, and it is not supposed to be turned off anytime.
The wearable embedded system shall start-up and join the system automatically when it connects to the power source. Tests will ensure the wearable embedded system can communicate to the local hub during its work cycle.
The in-cab hub shall also start and connect automatically when powered. This hub may require more time to boot up than the wearable system, so should be ready before the wearable embedded system starts.
All hardware should be able to detect other hardware’s work status. They can rebuild connection if the connection lost, or display “warning” when the connection is not able to be re-established in the event of loss of power or similar.
The system shall be extendable anytime. The end user should be able to connect their wearable devices whenever they like, and the web portal shall display corresponding information to represent the run-time situation.
Stress tests will be performed to ensure the whole system is stable and reliable for the real-world scenario. The system will be tested with extreme cases within the lab environment. At this stage, the system will be tested with real devices, virtual devices, reasonable data and illogical data which could let the IHF team measure the performance of the system, whether it can detect faulty or irrelevant devices and protect itself. This performance will be recorded for further system improvement.