Oasis – Open architecture for Accessible Services Integration and Standardization



Download 1.2 Mb.
Page13/21
Date19.10.2016
Size1.2 Mb.
#5047
1   ...   9   10   11   12   13   14   15   16   ...   21

Driver telematic support

          1. SP3-23 Driver/passenger health assistant in critical conditions




  1. Context of use (aim)

The purpose is to monitor the health status of the elderly driver or passenger(s), using a set of wearable sensors, and to take necessary countermeasures if any anomalous conditions are detected. This is done by means of an in-vehicle system, depending on the following situation:

  • In case of actual safety risk, the vehicle system calls an external emergency centre (autonomous operation), or

  • In case of potential safety risk, the vehicle system alerts the driver about the altered health status and suggests him/her to ask for help (semi-autonomous operation) or undertake other actions, depending on the potential risk level. If the driver asks for external help, the emergency centre is contacted.

  1. Primary actor

Young elderly (ages 55-65)

Elderly (ages 65-75)

Old elderly (ages 75+)


  1. Secondary actor(s)

Service Centre

Health care and emergency support service providers

Telematic service providers


  1. Connected UCs

Personal mobility UC3, Driver/passenger health monitoring on demand (system architecture is analogous)

  1. Priority Level

Essential

  1. Scenario(s)

The user wears some sensors measuring his/her vital signs (e.g.: heart rate, blood pressure, body temperature, etc.). The sensors are connected to a control unit hat collects the data. This unit will be generically called “in-vehicle system”, and it could be the vehicle’s own telematic unit, or the unit + a PDA, etc.

Autonomous operation:

The user has a sudden disease and is in safety risk.



Semi-autonomous operation:

The user is not in safety risk, but one or more of the parameters measuring the health status of the user are out of the safeguard control limits.



  1. System output

Autonomous operation

The system automatically starts an emergency call, contacting a nearby first-aid centre.



Semi-autonomous operation:

The in-vehicle system alerts the user about altered health conditions, suggesting him/her to take countermeasures (e.g. take a break) or ask for assistance (preventive action). The type of suggestion depends on the actual health conditions. If the driver asks for external help, the in-vehicle system contacts the service centre.



  1. Relevant OASIS WP

WP3.4, WP2.6

  1. Services involved

Driver telematic support

Health monitoring



  1. Devices & restrictions

11a. User Interaction devices & restrictions

Portable device (tablet PC, mobile phone, tbd) Vehicle Telematic Unit

11b. Sensor devices & restrictions

Health monitoring wearable sensors; localization module



  1. Critical success parameters



Services

Success parameters

Driver telematic support

Efficiency and reliability of data transfer and communication system (i.e.: transmissions from the vehicle to the emergency centre or service provider and vice-versa).

User friendliness of the peripherals/HMI system.



Health monitoring

Accuracy and reliability of the sensor acquisitions.



  1. Environmental restrictions

Potential problems concerning data transmissions, based upon the GSM/UMTS network (i.e.: lack of coverage within certain areas, for example in tunnels).

  1. Interaction level

Step 1 – there is a problem concerning the user’s health status, related to one or more vital parameters measured by the sensor system/structure.

Step 2 – depending on the (estimated) gravity of the situation, the system decides whether to



  • autonomously call an emergency centre => step 4

or to

  • warn the user3 => Step 3

Step 3 – the user receives the warning and decides to undertake the suggested action.

  • Take autonomous countermeasures

(e.g. stop and take a break )

=> end of the UC



  • Ask for help

=> step4

Step 4 – a call is started by the system and the user is put in contact with the service centre. Details will be clarified during the project.



  1. Personalisation/ adaptation level

Yes:

static parameters: static user profile (i.e.: name, date of birth, etc.)

semi-dynamic parameters: user’s case history and medical data (i.e.: known pathologies, allergies, etc.)

dynamic parameters: current values of the user’s health parameters acquired by the wearable sensors

environmental parameters/context of use: driving

  1. Quality of service indicators

For the QoS, we will refer to the recommendations of the Driving Group eCall, concerning:

  • percentage of the triggered emergency calls that reach the mobile network operator;

  • percentage of the activated emergency calls that reach the emergency centre (forwarded by the network operator);

  • latency of intervention.

Another QoS indicator that must be considered is the reliability of sensor data acquisitions.

  1. Potential input needed from other UCs (what input and which UCs?)



  1. Important accessibility attributes (per UG)

The HMI structure, including connected peripherals, must be designed taking into account the elderly user needs.

The health monitoring and alerting/emergency functions must be always available and working.

User’s profile and medical profile must be considered in order not to trigger warnings unnecessarily.


  1. Background info/ reason on selection and on assigning the priority level

Monitoring the health status of elderly drivers/passengers, in order to supply them with efficient emergency services and warning indicators for prevention, is crucial to avoid dangerous situations, especially those in which the driver/passenger illness sums to the road hazard.

  1. References

Driving Group eCall recommendations.

  1. Comments

The approach based on wearable sensors and on data fusion of various sensor inputs, combined with user’s personalized information, is considered the most significant innovation in OASIS.




Figure 85: SP3-23 Driver/passenger health assistant in critical conditions
          1. SP3-24 Emergency call for road accidents




  1. Context of use (aim)

The objective is to start an emergency call automatically or manually whenever a car accident has occurred, providing the rescue centre information on personal and medical data of the elderly driver/passenger(s), as well as vehicle information.

The Use Case is considered successful if at least the Minimum Set of Data (MSD) foreseen in the emergency call standardization is sent.

The device managing the call generation and transmission is an on-board telematic unit, connected to the vehicle CAN and GPS, which also provides information about the localization of the vehicle.


  1. Primary actor

Υoung elderly (ages 55-65)

Elderly (ages 65-75)

Old elderly (ages 75+)


  1. Secondary actor(s)

Public / private Social security service providers and insurance companies

Service Centre

Health care and emergency support service providers

Telematic service providers

National, local and regional authorities


  1. Connected UCs

Personal mobility UC1 – Driver/passenger health assistant in critical conditions (emergency intervention/management is similar)

  1. Priority Level

Essential

  1. Scenario(s)

The user is involved in a car accident and needs help. The emergency authorities must be contacted and informed about the event, to organize the rescue.

  1. System output

An emergency call is started automatically by the in-vehicle system or triggered manually by the user, contacting a first aid centre nearby, or, if possible, connected to an eCall service. Detailed medical and customized data about the user are automatically sent to the centre.

  1. Relevant OASIS WP

WP3.4

  1. Services involved

Driver telematic support

  1. Devices & restrictions

11a. User Interaction devices & restrictions

Portable device (tablet PC, mobile phone, tbd); Vehicle Telematic Unit

11b. Sensor devices & restrictions

Vehicular sensors; localization module



  1. Critical success parameters



Services

Success parameters

Driver telematic support

Efficiency and reliability of data transfer and communication system (i.e.: transmissions from the vehicle to the emergency centre or service provider and vice-versa).

Accuracy and reliability of vehicle positioning.

User friendliness of the peripherals/HMI system.




  1. Environmental restrictions

Potential problems concerning data transmissions, based upon the GSM/UMTS network (i.e.: lack of coverage within certain areas, for example in tunnels).

  1. Interaction level

Step 1 – the user is involved in a car crash.

Step 2 – an emergency call, contacting the nearest service centre, is activated:



  • autonomously by the in-vehicle system (alerted by the sensing module);

or

  • manually by the user.

Details will be clarified during the project development.

Step 3 – a connection between the user and the service centre is established.



  1. Personalisation/ adaptation level

Yes:

static parameters: static user profile (i.e.: name, date of birth, etc.)

semi-dynamic parameters: user’s case history and medical data (i.e.: known pathologies, allergies, etc.)

dynamic parameters: vehicle data acquired by the sensor module (positioning and other vehicle data, e.g. odometer, rear crash, front crash, airbag sensors)

environmental parameters/context of use: driving

  1. Quality of service indicators

For the QoS, we will refer to the recommendations of the Driving Group eCall, concerning:

  • percentage of the triggered emergency calls that reach the mobile network operator;

  • percentage of the activated emergency calls that reach the emergency centre (forwarded by the network operator);

  • latency of intervention.

Another QoS indicator that must be considered is the reliability of the vehicle positioning module.

  1. Potential input needed from other UCs (what input and which UCs?)

Information on the user’s vital parameters acquired by the body sensor system of Personal mobility UC1 (Driver/passenger health assistant in critical conditions) could be sent together with the data pertaining to the present UC to the emergency centre.

  1. Important accessibility attributes (per UG)

The HMI structure, including connected peripherals, must be user-friendly to elderly drivers/passengers.

  1. Background info/ reason on selection and on assigning the priority level

The necessity and importance of providing an efficient emergency call service for drivers is proved and universally accepted (refer to the eCall initiative development and standardization process, promoted by the European Commission).

In OASIS, the idea is that of providing an ‘improved’ version of the eCall service, taking into particular account the elderly user needs.



  1. References

Driving Group eCall recommendations.

  1. Comments

This Use Case is based on the standard Emergency Call and should therefore be compliant with it. In the basic version the health monitoring sensors do not enter in the Use Case; they may be seen as optional input (mentioned in 17).




Figure 86: SP3-24 Emergency call for road accidents
          1. SP3-25 Driver/passenger health monitoring on demand




  1. Context of use (aim)

The purpose is to give the possibility to the elderly driver or passenger(s) to receive medical assistance at any time during the travel.

The user wears a set of sensors measuring his/her vital signs; then, by means of an in-vehicle telematic device, he/she can make a request for support to the health care centre, which will evaluate the situation, based on these parameters, and give a medical response.



  1. Primary actor

Young elderly (ages 55-65)

Elderly (ages 65-75)

Old elderly (ages 75+)


  1. Secondary actor(s)

Service Centre

Health care and emergency support service providers

Telematic service providers


  1. Connected UCs

- Personal mobility UC1, Driver/passenger health assistant in critical conditions (system architecture is analogous)

  1. Priority Level

Essential

  1. Scenario(s)

The user wears dedicated sensors measuring his/her vital signs (e.g.: heart rate, blood pressure, body temperature, etc.). The sensors are connected to a control unit that collects the data. This unit will be generically called “in-vehicle system”, and it could be the vehicle own telematic unit, or the unit + a PDA, etc.

At a certain time during the travel, the user is sick or wants to check his/her own health status. Through a dedicated in-vehicle HMI, he/she sends a health monitoring request to the service centre.



  1. System output

The data measured by the wearable sensing system are collected by the called in-vehicle system and transmitted to the health care centre.

The latter evaluates the received information and sends an answer back to the called in-vehicle system. The response is delivered to the user, for instance by means of the vehicle HMI. An example of such service could be the establishment of a voice connection with the medical assistant.

The main difference between a standard phone call and the present service is that the current health data are provided in advance with respect to the call.


  1. Relevant OASIS WP

WP3.4, WP2.6

  1. Services involved

Driver telematic support

Health monitoring



  1. Devices & restrictions



11a. User Interaction devices & restrictions

Portable device (tablet PC, mobile phone, tbd) Vehicle Telematic Unit

11b. Sensor devices & restrictions

Health monitoring wearable sensors



  1. Critical success parameters



Services

Success parameters

Driver telematic support

Efficiency and reliability of data transfer and communication system (i.e.: transmissions from the vehicle to the emergency centre or service provider and vice-versa).

User friendliness of the peripherals/HMI system.



Health monitoring

Accuracy and reliability of the sensor acquisitions.



  1. Environmental restrictions

Potential problems concerning data transmissions, based upon the GSM/UMTS network (i.e.: lack of coverage within certain areas, for example in tunnels).

  1. Interaction level

Step 1 – The user feels ill or simply would like to check his/her own health conditions.

Step 2 – The user asks the system for help. This could be done in a very simple way, with one single command

Step 3 – The in-vehicle system transmits the data read from the sensors worn by the driver to the health care centre.

Step 4 – The health care centre sends a response to the in-vehicle system.

Step 5 – The service centre delivers the response to the user, for example through the establishment of a voice link with the medical assistant.


  1. Personalisation/ adaptation level

Yes:

static parameters: static user profile (i.e.: name, date of birth, etc.)

semi-dynamic parameters: user’s case history and medical data (i.e.: known pathologies, allergies, etc.)

dynamic parameters: current values of the user’s health parameters acquired by the wearable sensors

environmental parameters/context of use: driving

  1. Quality of service indicators

We shall refer to the performance criteria discussed in Personal mobility UC1 (Driver/passenger health assistant in critical conditions), and consider them as an upper bound to the QoS indicators of the present UC, which is less safety critical than UC1.

  1. Potential input needed from other UCs (what input and which UCs?)



  1. Important accessibility attributes (per UG)

The design of the HMI structure, including connected peripherals, must take into account the elderly user needs.

The health monitoring and assistance request functions must be always available and working.



  1. Background info/ reason on selection and on assigning the priority level

For elderly people, being aware of the presence of a medical assistance service, which can easily and rapidly be accessed while driving, is a factor that can guarantee an improved safety and confidence level. For example, the service could encourage them to undertake trips that they would not do without remote assistance.

  1. References



  1. Comments

Within OASIS, the approach based on wearable sensors and on data fusion of various sensor inputs, combined with user’s personalized information, is considered the most significant innovation.




Figure 87: SP3-25 Driver/passenger health monitoring on demand


        1. Download 1.2 Mb.

          Share with your friends:
1   ...   9   10   11   12   13   14   15   16   ...   21




The database is protected by copyright ©ininet.org 2024
send message

    Main page