Sage Journals: Discover world-class research

Abstract

Various sensors have achieved large-scale deployment as important data sources in intelligent transportation systems, and abundant data are generated and processed into useful information and new services. The means by which to make effective use of this information and these services to benefit the driver and improve road safety is very important in an intelligent transportation system. This research aims to describe the design and implementation of a context-aware service system for perceiving the driving situation and providing the most appropriate function or information services to address the actual needs in a driving assistance environment. To describe various hazardous situations, the status-emphasized context model and reasoning rules are proposed to abstract the context information and facilitate better understanding the driver’s context. The approach of customized service invocation is proposed by the retrieval of the service configuration model, which builds the relationship between the driver’s status and appropriate business services. In addition, to address the situations with multiple hazards, a priority- and severity-based invocation control algorithm is proposed; through this algorithm, the invocation procedure can be determined based on the priority and severity of the hazards. An evaluation based on computational experiments is conducted to verify the availability and validity of the service system.

Keywords

Context-aware service intelligent service system intelligent transportation systems mobile information system context reasoning

Introduction

With the development of sensing technology, communication technology, and information technology, intelligent transportation systems (ITSs) have been greatly enhanced in recent years. Emerging sensor technologies are improving the ability of ITSs to acquire abundant information from the driver, the vehicle, and the environment. Various information business services, including route planning and vehicle tracking and monitoring, have been implemented to provide useful and crucial information for the driver and safety surveillance center staff to facilitate disaster prevention and emergency management. Seamless integration between data aggregation and business service invocation can improve the efficiency of the traffic system. Accidents may happen because of driver errors, vehicle failure, and hazardous environment in which many hazardous factors are involved. In 2014, according to the report of road casualties from National Bureau of Statistics of China, nearly 136,386 accidents occurred with 42,847 killed and 141,718 injured; all these statistics are slightly higher than those in 2013.¹ The lack of awareness of dangerous conditions that affecting the driver and the vehicle contributes to these accidents and cannot be ignored.

As a core feature of ubiquitous and pervasive computing systems, context-aware computing has proven to be successful in analyzing, interpreting, and understanding the sensory data.² Using various sensors deployed in vehicles and environment, huge amounts of data can be generated constantly. Context-aware services have emerged as applications to constantly observe the driver and the surrounding environment, and provide necessary and appropriate services for drivers. According to the trigger condition of the services, which is often based on the service object and concerned service scenarios, context-aware services can be divided into location (environment)-aware services and object-aware services. The location-aware services are triggered by changes in the user’s location (or environment), such as the vehicle entering a work zone on the highway or an area affected by heavy rain. The trigger condition of the object-aware services depends on the altered status of the service object, for example, the vehicle runs out of oil or the driver gets a fever. When context-aware services are triggered, the complementary context information of the service object will be collected, gathered, and fused to produce a better understanding of the observed situation. Then, the appropriate business services will be invoked for the service object to meet the demands of the drivers in the current situation.

Safety applications allow vehicles to constantly observe the surrounding environment (specifically, the status of other cars or road conditions) and, if necessary, avoid accidents by taking proper actions in time.³ In the transportation area, current researches focuses on the observation phase by monitoring the driver (status),^4–6 vehicle (condition),^7–11 and environment (situation).^4,12–14 Various sensors are involved in the observation, including location detection sensors (e.g. global positioning system (GPS), radar, and infrared sensors), vision sensors (cameras), biosensors (e.g. alcohol sensors and electrocardiogram (ECG)/electrogastrogram (EGG)), controller area network (CAN)-Bus-based On-Board Diagnostics (OBD), and other roadside infrastructure (or data resources). During driving, abnormal situations can be detected and triggers an alarm onboard. Many researchers have been working in the area of transportation service systems, including transportation management services, traveler information services, business vehicle management services, and public transportation services. By collecting large amounts of data from various resources, useful information and corresponding services can be made and interactively accessed by the driver (e.g. route planning and navigation, dynamic parking, and vehicle monitoring and diagnostics). However, no comprehensive design of a context-aware service system exists that combines situation perception and business service invocation to provide the driver-appropriate business services based on the driver’s current situation to meet his individual needs effectively and accurately.

In this article, we propose a context-aware intelligent service system designed based on the collection and deduction of the driver’s context information to provide the driver with customized business services according to the current situations. Based on context modeling, the driver’s context information is represented in a context model including five main entities: sensor, driver, vehicle, location (environment), and status. To perceive the situation of the service object, a number of reasoning rules are designed. A priority- and severity-based invocation control algorithm is proposed to handle abnormal situations with multiple hazards based on the priority and severity of the hazards. Furthermore, a context-aware service, the Smart in-Car Healthcare Service (SCHS), is presented to illustrate the process of context-aware service.

The rest of the article is organized as follows: Section “Background and related work” introduces the background and related work. Section “System architecture” describes the architecture of the context-aware service system. The implementation of the service system, including context modeling, context reasoning, business service invocation, and a demonstration of the context-aware service, is presented in section “Implementation of context-aware services.” Section “Experiment and evaluation” discusses the availability and validity of the proposed service system based on the computational experiment. We conclude this article in section “Conclusion.”

Background and related work

Context-aware service

By aggregating various contexts, a context-aware service adapts itself to changes in the environment dynamically and automatically.¹⁵ The goal of context-aware services is to provide the requisite services automatically based on the context information of the service object.¹⁶ In this article, the collected raw context of the service object can be expressed as follows

$A = {a_{1}, a_{2}, \dots, a_{n}}$ (1)

where A is the raw context of the object, and a_i indicates the acquired context value (<obj, dataProperty, values>) or attached relationship to other entities (<obj, objectProperty, obj>).

The reasoning process is the mapping between pre-conditions (set A) and post-conditions (inferred context). Suppose B is the set of inferred context, where b_i indicates the value of the deduced context. The reasoning rule $φ$ represents the mapping between set A and set B. For each rule in $φ$ , only when all the conditions in A_i are satisfied can we acquire the high-level context B_i. Thus, the process of context reasoning can be represented as follows

$B = {b_{1}, b_{2}, \dots, b_{m}}$ (2)

$B_{i} = φ (A_{i})$ (3)

in which $A = ⋃_{i = 1}^{k} A_{i}, B = ⋃_{i = 1}^{k} B_{i}$ .

The goal of the context-aware service system is to provide the service object with services based on the situations composed of raw context and high-level context. The selection of these services is the result of a mapping between the situation and the services. Assuming S denotes the set of candidate services, $S_{i}$ is the selected service composition for each situation, and $Se r_{j}$ is the atomic service provided by the service system. Let $τ$ denote the set of mapping rules from the context information (i.e. the raw context and deduced context) to the set of selected business services. For every mapping rule in $τ$ , only when all the conditions in both A_i and B_i are satisfied can the services $S_{i}$ be matched. Thus, the selection of services can be represented as follows

$S = {S_{1}, S_{2}, \dots, S_{q}}$ (4)

$S_{i} = τ (A_{i}, B_{i}) = {Se r_{1}, Se r_{2}, \dots, Se r_{u}}$ (5)

Related work

As a complex, stochastic, and human-centric control procedure, many factors affect safe driving. To identify the status of the driver, several studies have focused on the detection or awareness of abnormal situations (e.g. hazardous driving behavior and morbid health status) during driving using various sensor technologies. In Al-Sultan et al.,⁴ a five-layer context-aware architecture was proposed, and four types of driving behavior during real-time driving were identified, including normal, fatigued, drunk, and reckless driving. With the support of physical sensors and virtual sensors, the environment context (i.e. noise and temperature), vehicle context (i.e. position, speed, and acceleration), and driver context (e.g. status of the driver’s eyes and amount of alcohol in the driver’s blood) were collected. Then, the driver’s behavior can be observed using the Dynamic Bayesian Network (DBN) as the information fusion method. The driver’s health condition and other physical indicators are critical factors for safe driving; they are very useful in identifying potential hazards to prevent the incoming accident. The measurement of vital signals (including ECG, EEG, and eye activities) has been widely used to monitor the health status of drivers by means of intrusive⁵ or non-intrusive⁶ approaches. Based on the nonintrusive monitoring of vital signals (including ECG, EEG, and eye activities), the health status of the driver (i.e. alertness and drowsiness) and driver fatigue were detected by analyzing the EEG spectrum, heart rate variability (HRV) features, and eye features.⁶

With the support of the CAN-Bus signal and embedded OBD, various information on the vehicle, including speed, position, acceleration, oil status, and activity input from the driver, can be monitored. Indeed, this has become a conventional method used to recognize maneuvers, diagnose vehicles, and detect whether drivers are distracted.^7–9 In Sathyanarayana et al.,⁷ by collecting vehicle speed, steering wheel angle, and gas and brake inputs from the driver, left turn, right turn, and lane change maneuvers were recognized based on the utilization of the Gaussian Mixture Model (GMM)/Universal Background Model (UBM). In addition to traditional physical sensors, virtual sensors, such as cameras, can be employed as a primary or assistant method to acquire the driver’s context and achieve comprehensive representation of the situation.^7,10,11

In Sathe and Deshmukh,¹² by taking the acceleration sensors embedded in smart phones as the sensing device, a vehicle–road interaction and vehicle monitoring system were proposed to evaluate real-time road conditions (i.e. accident zones) based on the vehicle’s position and abnormal acceleration. With the support of scanning technology (e.g. radar and light detection and ranging (LiDAR) sensors) and image processing technology, the collision probability and number of nearby vehicles (or pedestrians) can be sensed to assist safe driving.^13,14 Through the integration of external data sources (e.g. traffic management centers), much more road condition–related context can also be acquired (i.e. road congestion, weather, and accidents).^4,17

Large amounts of data collected from various resources have facilitated interactive data utilization through convenient and reliable services to improve the performance of transportation systems.¹⁸ Up-level information services can be achieved to provide useful information to assist driving through the integration of various information technologies, including the data mining model, the service-oriented architecture (SOA) paradigm, and data fusion techniques. In He et al.,¹⁹ a vehicular data cloud platform was proposed by taking advantage of cloud-computing and Internet of Things (IOT) technologies. The given platform provided and connected transportation-related information services (e.g. traffic management, car location tracking and monitoring, and road conditions). The adoption of the SOA paradigm can afford the organization, aggregation, and encapsulation of enterprise application integration. Furthermore, an intelligent parking cloud service and mining vehicular maintenance data service and their corresponding models were proposed.

A context-aware service is a network service that uses various contexts and adapts itself to the changing environment dynamically and automatically.¹⁵ To meet the needs of the driver in different situations, various context-aware services have been proposed to benefit the driver in particular situations (e.g. onboard alerting, dynamic parking, dynamic routing, and remote maintenance). In Wan et al.,¹⁷ by collecting the context information, including road conditions, parking garage status, and expected driving duration, a context-aware dynamic parking service was proposed to optimize the best parking locations for the drivers. Approaches for the context-aware safety hazard prediction and the dynamic vehicle routing were also proposed based on the analysis of temporal position relationships and spatial–temporal traffic data. Other context-aware services, such as onboard alerting, nearby vehicle alerting, and driving recommendations, have also been mentioned in some researches.^4,20 Ontology-based context modeling has been adopted in building the context models for vehicle context-aware services.^14,21 Based on the situation described by the context model, high-level context can be deduced by various reasoning methods, such as fuzzy logic–based reasoning, ontology-based reasoning, and probabilistic logic–based reasoning.²

Current context-aware services for driving assistance mainly focus on specific safety applications, such as dynamic parking or behavior detection. However, the integration of existing business services and the utilization of these services to tackle hazardous situations have not been deeply discussed. In the current researches, the context information with regard to the drivers, vehicles, and the environment has not been fully considered to identify the hazards and analysis of the actual needs of the drivers. Moreover, the relationship between the driving context and various business services has not been clearly established. It is hard to provide the driver with timely and effective information from the existing business services. In addition, in the current researches, there still do not exist a service call control method based on the status of the hazards. Therefore, it is hard to fulfill the driver’s demands in complex driving context with multi-hazards involved.

In this article, a systematic architecture and specific methods (including context modeling, context reasoning, and service configuration and invocation) are proposed to build a context-aware service system from the acquisition of context information to the provision of the configurable customized business services. Unlike the related work, this article not only considers the acquisition of context information to identify the driver status in various hazardous situations but also takes advantage of the existing business services to provide accurate services for the driver to guarantee safe driving.

System architecture

The context-aware service system is divided into three layers based on hierarchical spatial regions: context acquisition, data transmission, and business service provision. As shown in Figure 1, the bottom layer of the architecture is the collection of the context information, in which the contexts of the driver, the vehicle, and the environmental can be acquired from sensors or other data sources. The collected data can be transmitted over heterogeneous communication routes, including Transmission Control Protocol/Internet Protocol (TCP/IP) and other low-power wireless protocols, to the middle layer (i.e. the data transmission layer). Further fine analysis of the collected data and the selection of business services are performed in the top layer of the system.

Figure 1.

Example process of context-aware service system.

Context acquisition

The context information of the system mainly includes the context information of the driver, vehicle, and environment. This information can be acquired from physical sensors or virtual sensors (e.g. legacy information systems and various web services). Sensory data can be generated and aggregated with the support of sensor technology and wireless sensor network (WSN) technology. For the driver’s context, information can be obtained from all types of wearable sensors attached to the driver. With the rapid development of sensor technology, many sensors are available to monitor various human vital signals, including body temperature (BT), heartbeat, blood pressure (BP), and blood sugar (BS). The deployment of these sensors can facilitate the continuous monitoring of the driver. The vehicle’s context information includes the vehicle’s speed, residual gasoline volume, in-car temperature, in-car carbon monoxide (CO) concentration, and in-car oxygen concentration. The road context information, including vehicle flow, temperature, and water stage, is acquired from roadside infrastructure or sensors deployed around the road. The data acquired by the sensors are transmitted to the sink nodes deployed on the vehicle through a WSN inside the vehicle. These sink nodes upload the gathered information to the service platform frequently. In addition to the direct sensory context, other information, such as the driver’s speed preference, weather, restricted vehicle plate number, road blockage, road accident, and disaster information, can be acquired from a wide variety of data sources. For example, the driver’s speed preferences on different types of road can be calculated from his speed history, and the daily-restricted plate number or road construction progress can be directly acquired from the information services provided by the traffic management bureau.

Data transmission

When the data are acquired, they are transmitted to the service system for further analysis. The sensor data collected from the driver and vehicle can be transmitted through General Packet Radio Service (GPRS)/3G/4G cellular mobile communications to the IP-based core network. As a core component of the ITS, vehicular ad hoc networks (VANETs) can also be used as a communication method during the transmission of context data. VANETs have emerged as an application of mobile ad hoc networks (MANETs) that use dedicated short-range communication (DSRC) to allow nearby vehicles to communicate either with each other or with roadside equipment.⁴ With Internet integration, VANETs can provide efficient data transmission for the service system.

Business service provision

When the service system has acquired all the necessary data, the complete contexts of the drivers and vehicles can be established through context reasoning. Then, the situation can be identified, such as abnormal driver vital signs (e.g. BT too high or heartbeat too slow) or abnormal vehicle conditions. To react to the identified abnormal situation, the service system will provide the driver with appropriate business services by querying the service configuration model, thereby eliminating or reducing the potential hazards during driving. Examples of business services are shown in Table 1. Business services can be invoked to assist the driver in different situations, such as checking the residual oil for the rest of the trip, selecting an appropriate nearby hospital for the drivers who are in danger, or giving appropriate recommendations about the road conditions (e.g. icy roads or extreme weather). As more varieties of sensors or data sources are used, the service system will be able to handle more kinds of hazardous situations and provide more services to meet the driver’s needs.

Table 1.

Examples of business services.

Services	Abbreviations
Onboard Alarming Service	OAS
Short Messaging Service for Drivers	SMSD
Short Messaging Service for Relatives	SMSR
Route Selection Service	RSS
Supervision Center Alarming Service	SCAS
Vehicle Outside Assistant Alarming Service	VOAAS
Emergency Rescue Service	ERS
Nearby Area Alarming Service	NAAS
Restricted Plate Number Reminder Service	RPNRS
Oil Calculation Service	OCS
Garage Selection Service	GSS
Gas Station Selection Service	GSSS
Hospital Selection Service	HSS

Implementation of context-aware services

The collected raw data are transformed into knowledge (high-level information) by collecting, modeling, and reasoning on the context. Once we have knowledge, it can assist the provision of business services with more intelligent interaction and communication. In this section, the key parts of the context-aware service system are presented with detailed methods.

Context modeling

The context information can be classified into low-level, direct context (raw context) and high-level, indirect context (deduced context).¹⁵ The raw context information is obtained directly from various types of sensors or web services. The raw context includes the location of the vehicle, the temperature of the driver, and the weather in the location. The indirect context information is acquired via context reasoning based on the raw context information, such as the BT status of the driver, the speed status of the vehicle, or the weather status of the area. For example, the health condition of the driver can be deduced from the sensor value of his BT, heartbeat, or BP, which can be acquired directly from sensors attached to the driver. Moreover, the road status, including the water stage or weather-related road conditions, can be deduced from sensory data or other data resources (e.g. road management systems and weather information services).

Currently, a popular method for describing context information is ontology modeling, which can depict the context information easily and aptly.² Ontology technology has many advantages, including strong expressive capability, support for logical reasoning, easy understanding, and convenience for knowledge reuse and sharing. Therefore, ontology modeling is suitable for the description and definition of context and its relations, and is convenient for context reasoning. This article adopts Web Ontology Language 2 (OWL 2) to describe context information; OWL 2 is the current version recommended by the World Wide Web Consortium (W3C).²² As an expressive context modeling mechanism, OWL 2 supports high-level inference and is suitable for ontological reasoning.² The ontologies are built with Protégé, which was developed by Stanford University.²³

The context model mainly includes the entities of the driver, vehicle, location, sensor, and status. These entities are the most fundamental context for expressing context information and identifying various situations during driving. Figure 2 depicts the upper-level entities and the relationships among them. The lines in Figure 2 represent the properties between the entities. There may be two properties (the solid line and the dashed line) between some of the entities (e.g. observe and isObservedBy). These two properties can be defined as inverse property, and each of these two properties is the inverse property of another. The inverse property is one of the OWL property characteristics, which can increase the flexibility of the reasoning process (OWL reasoning). For example, if isObservedBy property is the inverse property of the Observe and Sensor_01 Observe Vehicle_02, then the reasoning module can deduce that Vehicle_02 isObservedBy Sensor_01.

Figure 2.

Partial illustration of the context model.

The context model is structured by a set of abstract entities; each of them describes a physical object or conceptual object. These entities are Driver, Vehicle, Environment, Sensor, and Status.

Driver. The Driver entity is the concept of the drivers, which can be specified by a driver’s age, such as young, middle-aged, and old. The driving action is indicated by the hasDriver property, which establishes the relationship between the driver and the vehicle. The other information on the driver (e.g. ID, age, mobile phone number, and speed preference on different types of roads) can be presented by the data properties (e.g. hasID, hasAge, hasPhoneNumber, and hasSpeedPreference). The driver’s health condition is observed by sensors deployed around the body. The isObservedBy property associates the driver with the attached vital sensors. The hasStatus property describes the deduced status of the driver, which has sub-properties indicating, for example, BP status and BT status.

Vehicle. Vehicles can be divided into groups according to actual needs (e.g. size, function, and energy type). The location of the vehicle is expressed by the hasLocation property. The vehicle is associated with the sensors according to the isObservedBy property, which describes the observation of the vehicle’s speed, residual oil, engine status, and in-car environment.

Environment. The Environment entity includes location (e.g. road, buildings, and parking areas), weather conditions (e.g. temperature, snow, or rain), and road conditions (e.g. accidents, road construction, or ice/snow-covered roads).

Sensor. As a critical input of the service system, sensors are responsible for producing the raw context data of the observed object (e.g. the driver’s health condition, the environmental condition in the vehicle, and the driving condition of the vehicle). To better understand and express the relationship and hierarchy of the ontology, the Sensor entity is divided into onBody, Onboard, and External based on the location where the sensor deployed. Each sensor has an observing object (i.e. driver, vehicle, or location), and the relation is indicated with the observe property. The observation value collected by the sensor is presented as the data value of the data property hasObservationValue, and the data type of the observation value can be decimal or float based on the sensors. Information services can be further encapsulated as virtual sensors to collect context information, such as weather or road conditions.

Status. Status is the most important entity for the intelligent service system. As a high-level context of the system, the status of the driver and the vehicle is obtained from the reasoning process based on the reasoning rules and the raw sensory data acquired from the sensors. The Status entity is divided into three sub-entities: DriverStatus, VehicleStatus, and EnvironmentStatus. The DriverStatus is further divided into HealthStatus (e.g. BT status and BP status) and inCarEnvironmentStatus (e.g. CO or oxygen concentration status). The VehicleStatus indicates the current condition of the vehicle (e.g. whether the restricted speed is exceeded, whether the residual oil is sufficient for the rest of the trip, and whether there is a passenger inside). EnvironmentStatus includes roadStatus (e.g. waterlogged, construction, or ice) and WeatherStatus (e.g. temperature, rain, snow, or fog).

Context reasoning

Based on reasoning on the collected raw context, the high-level context can be acquired to complete the whole context of the driver and vehicle. The reasoning on context information is implemented with the Jena2 Semantic Web Toolkit, which includes OWL-based reasoning with description logic and user-defined reasoning using forward-chaining logic.²⁴

Based on the proposed ontology context model and the axioms of the model (e.g. class expression axioms, object property axioms, and data property axioms), the context information can be inferred and represented based on the OWL ontology reasoning rules (e.g. subClassOf, subPropertyOf, and disjointWith).

More abundant context information can be deduced via user-defined reasoning. By acquiring the raw context of the driver, vehicle, and environment (including the road), the statuses of the driver, vehicle, and environment can be deduced through reasoning based on the pre-defined rules (e.g. health status rules, in-car environment rules, vehicle speed status rules, and road condition rules).

Taking the rules of driver status as an example, “driver” is the main service object of the service system, and his status is affected by his health condition (e.g. heartbeat, temperature, and BP) and the environment in the vehicle he is driving (e.g. temperature and concentrations of CO and oxygen). Taking the driver’s BT as an example, after acquiring the raw context data of the driver (e.g. the value of driver’s BT (39°C)), the driver’s health status can be deduced as “BT-danger” according to the pre-defined health status rules in which the range of BT status “danger” is defined from 39°C to 40°C. Examples of reasoning rules and reasoning instances are shown in Table 2. The reasoning instances in Table 2 are organized according to the specification of Jena rule language. The question mark in the rules defines the character behind as the variables of the rule instances. Thus, the context information can be coordinated with the rules according to these variables to acquire the reasoning results.

Table 2.

Examples of reasoning rules and reasoning instances.

Reasoning rules	Reasoning instances
[Health_Temp_Warning_HighFever: (?a hasDriver ?b) (?b isObservedBy ?c) (?c rdf:type BodyTemperature) (?c hasObservationValue ?d) ge(?d, 38) lessThan(?d, 39) → (?b hasBTStatus Warning)]	a = Car_187614, b = Driver_017549, c = Car_187614_BT, d = 38.8→ (Driver_017549 hasBTStatus Warning)
[InCarEnvironment_CO_Warning: (?a hasDriver ?b) (?a isObservedBy ?c) (?c rdf:type InCarCO) (?c hasObservationValue ?d) ge(?d, 8) lessThan(?d, 30) → (?b hasCOStatus Warning)]	a = Car_121331, b = Driver_017501, c = Car_121331_CO, d = 14→ (Driver_017501 hasCOStatus Warning)
[SpeedState_Warning: (?a hasDriver ?b) (?a hasLocation ?c) (?c rdf:type ?d) (?d hasRestrictedSpeed ?e) (?a isObservedBy ?f) (?f rdf:type SpeedMonitor)(?f hasObservationValue ?g) difference (?g, ?e, ?h) greaterThan(?h, 0) lessThan(?h, 20) → (?b hasSpeedState Warning)]	a = Car_121331, b = Driver_000212, c = BJ_N3_UE_05, d = UrbanExpressway, e = 70, f = Car_121331_Speed, g = 85→ (Car_121331 hasSpeedState Warning)
[Health_Temp_Diagnose: (?a hasDriver ?b) (?b isObservedBy ?c) (?c rdf:type BodyTemperature) (?c hasObservationValue ?d) lessThan(?d, 20) → (?b hasBTStatus Fault)]	a = Car_020012, b = Driver_001753, c = Car_020012_BT, d = 14→ (Driver_001753 hasBTStatus Fault)

Business service invocation

The status of the vehicle and the driver is critical to the safety of the whole traffic system. After determining the status of the driver, vehicle, and environment through context reasoning, the service system can select and invoke appropriate business services or service compositions to meet the needs of the situation. For the driving situations, when a blockage happens in the planned route, the route selection service can be invoked to choose another route for the driver. Different hazardous situations result in demand for different services. For example, if a driver is conscious, the situation is still controllable; thus, helpful information or a recommendation may be sufficient to allow the driver to take further appropriate action. In contrast, additional information is required in a dangerous situation, and the driver may need outside help (e.g. route information for a nearby hospital or instruction to wait for a rescue) because he may be unconscious or lose control of himself (e.g. CO poisoning or sudden illness). The provided services should be appropriate and have a validity period because the driving context continuously changes. In addition, inappropriate services or delayed services that are not suitable for the current situation may distract the driver and pose a threat to security. The demonstration of customized service invocation is shown in Figure 3.

Figure 3.

Demonstration of customized service invocation.

Due to the limitations of the reasoning efficiency, applying ontology-based reasoning as the only way to acquire the appropriate services or service compositions is not adequate. Indeed, the service system will encounter difficulty in handling huge amounts of context information and choosing appropriate business services in time. In this article, the whole process of service invocation is divided into two stages: the situation-recognition stage and the service-matching stage. The situation-recognition stage is responsible for identifying the situation of the driver or the vehicle through ontology-based reasoning (e.g. BT-Warning and BP-Danger). The reasoning rules for service selection are transformed into a service configuration model, as shown in Table 3. For each situation, there is a corresponding service composition that could be configured to handle the current situation. At the service-matching stage, by comparing the current situation with the service configuration model, the corresponding service composition for further invocation can be determined. At this stage, by querying the service configuration model in database tables instead of using ontology-based reasoning for service selection and service matching, the cost and time consumption could be reduced significantly.

Table 3.

Example of a service configuration model.

Hazards	Range	Situations	Degree	Service composition
CO	>2000 ppm	<CO, Fault>	1	OAS
	8–30 ppm	<CO, Warning>	2	OAS→SMSD
	30–80 ppm	<CO, Danger>	3	OAS→(SMSD, SMSR, SCAS)→VOAAS
	80–2000 ppm	<CO, ExtremeDanger>	4	OAS→(SMSD, SMSR, SCAS)→(ERS, VOAAS)
Oxygen	>21% or <6%	<Oxy, Fault>	1	OAS
	19.5%–20.5%	<Oxy, Warning >	2	OAS→SMSD→VOAAS
	15%–19.5%	<Oxy, Danger >	3	OAS→(SMSD, SMSR, SCAS)→VOAAS
	6%–15%	<Oxy, ExtremeDanger >	4	OAS→(SMSD, SMSR, SCAS)→(ERS, VOAAS)
Temperature	>85°C	<Temp, Fault>	1	OAS
	40°C–50°C	<Temp, Warning >	2	OAS→SMSD→VOAAS
	50°C–65°C	<Temp, Danger >	3	OAS→(SMSD, SMSR, SCAS)→VOAAS
	65°C–85°C	<Temp, ExtremeDanger >	4	OAS→(SMSD, SMSR, SCAS)→(ERS, VOAAS)
Heartbeat	>250 or <10 bpm	<Heartbeat, Fault>	1	OAS
	140–160 bpm or30–40 bpm	<Heartbeat, Warning>	2	OAS→SMSD→VOAAS
	160–200 bpm or20–30 bpm	<Heartbeat, Danger>	3	OAS→(SMSD, SMSR, SCAS)→VOAAS→HSS→RSS→NAAS
	200–250 bpm or10–20 bpm	<Heartbeat, ExtremeDanger>	4	OAS→(SMSD, SMSR, SCAS)→(ERS, VOAAS, HSS→RSS)→NAAS
BT	>47°C or <20°C	<BT, Fault>	1	OAS
	38°C –39°C or30°C –35°C	<BT, Warning>	2	OAS→SMSD→VOAAS
	39°C –42°C or25°C –30°C	<BT, Danger>	3	OAS→(SMSD, SMSR, SCAS)→VOAAS→HSS→RSS→NAAS
	42°C–47°C or20°C –25°C	<BT, ExtremeDanger>	4	OAS→(SMSD, SMSR, SCAS)→(ERS, VOAAS, HSS→RSS)→NAAS
Blood pressure(systolic; SBP)	<20 or >300 mmHg	<BP, Fault>	1	OAS
	160–170 mmHg	<BP, Warning>	2	OAS→SMSD→VOAAS
	170–230 mmHg	<BP, Danger>	3	OAS→(SMSD, SMSR, SCAS)→VOAAS→HSS→RSS→NAAS
	230–300 mmHg	<BP, ExtremeDanger>	4	OAS→(SMSD, SMSR, SCAS)→(ERS, VOAAS, HSS→RSS)→NAAS
Speed ( $Δ V$ )	0–20 km/h	<SS, Warning>	2	OAS
	20–40 km/h	<SS, Danger>	3	OAS→VOAAS→SCAS
	>40 km/h	<SS, ExtremeDanger>	4	OAS→VOAAS→SCAS→NAAS
Preference speed ( $Δ V'$ )	20–40 km/h	<PS, Warning>	2	OAS
	40–60 km/h	<PS, Danger>	3	OAS→VOAAS→SCAS
	>60 km/h	<PS, ExtremeDanger>	4	OAS→VOAAS→SCAS→NAAS
Water stage	15–25 cm	<WS, Warning>	2	OAS
	25–40 cm	<WS, Danger>	3	OAS→VOAAS→RSS
	>40 cm	<WS, ExtremeDanger>	4	OAS→VOAAS→SCAS→RSS→NAAS

In the “degree” column, 0 represents “Normal” (not listed); 1 represents “Device failure”; 2 represents “Alert, but under control”; 3 represents “Dangerous, out of control”; and 4 represents “Extreme danger, death.” In the “service composition” column, the services in the brackets are invoked in parallel; → indicates the order of service invocation.

We designed the threshold of each situation according to the criteria, policies, and clinical data from hospitals.^25–27 The context value of each hazard must be discretized for further context reasoning (e.g. CO and oxygen concentrations and BT). More hazards can be added to enrich the configuration model and driving situations.

The changes in the context data (i.e. the deduced status) may trigger the service invocation. When all the conditions of a situation are satisfied, the service system will invoke the corresponding services as the response to the situation. The service composition is a series of services with a priority order based on the functionality and parameter constraints of each service. When the candidate services are equally important and have the same input constraint (or no input parameter), these services may be triggered in parallel. Taking SCHS as an example, when the BT exceeds the lower limit of “BT-danger” situation, the related service objects are the driver, his relatives, and the safety supervision center; then, the services (SMSD, SMSR, and SCAS) will be invoked in parallel to give an alarm.

The pseudocode of the polling-calling-based service call control algorithm for business service invocation is shown in Algorithm 1. The inputs include a raw context set R collected from the service object and a cached reasoning result set C acquired from the last time. When the onboard terminal is activated, the raw context values of the vehicle and driver (in R) are gathered and sent to the service center periodically. Then, using equation (3), the available raw context acquired in a valid time is transformed into discrete values (set D) based on the reasoning rules ( $φ$ ). In line 12, we check whether the status of hazards has changed through the comparison between the acquired status and the cached one in set C. If the context has changed, it will be inserted into set T, and the corresponding cache value will be updated. Subsequently, the changed context collected in T will be sorted based on the priority order of hazards by the priority order algorithm. Then, via equation (5), by querying the service configuration model, the service composition is selected and executed in priority order.

Algorithm 1. The polling-calling-based service call control algorithm.
1: Input (R, C)
2: Output (S)
3: Initialize R′, D, T, T′, S
4: for (i = 0 to n) do
5: /* Raw context with invalid time will be filtered out */
6: if ((currentTime−r_i.time) < limit) then
7: R′←r_i
8: end if
9: end for
10: for (j = 0 to n) do
11: d_j = discretization(r′_j)
12: /* Only if the status changes that the corresponding services calling can be triggered. */
13: if (d_j ! = c_j) then
14: T←d_j
15: c_j = d_j
16: end if
17: end for
18: if (T is not null) then
19: /* The set of changed contexts should be sorted according to the priority order of hazards.*/
20: T′←priorityOrder(T)
21: else
22: Return 0
23: end if
24: for (k = 0 to n) do
25: s_i = queryConfigurationModel(t′_k)
26: execute(s_i)
27: end for

Various hazards exist around the driver and vehicle that can critically affect safe driving. These hazards are associated with the outside environment, the in-car environment, and the driver himself.

The context-aware service system identifies the status of the driver by dividing the collected sensory data into several degrees (from 1 to 4) representing the severity of the hazards. The higher the severity of the hazard, the higher the probability of the occurrence of dangerous situation. Taking BP as an example, a systolic blood pressure (SBP) >180 mm Hg or a diastolic blood pressure (DBP) >120 mm Hg is considered a “hypertensive crisis” and has a high probability of severe symptoms (e.g. headache, shortness of breath, and unconsciousness) that can seriously affect safe driving and pose a significant threat to lives.²⁸ However, extensive experimentation with large amounts of statistical data is required to quantify the probability of the occurrence of dangerous situations with regard to different hazard severities. When a situation occurs with several hazards, the service system must decide which hazard should be responded to first. In this article, we take the basic priority as a factor when determining the response order in multi-hazard situations. When all the hazard situations occur with the same severity, the basic priority can be configured with regard to the attributes of these situations (e.g. symptoms, duration, and extent of the damage). The driver’s health context as the direct hazard affects safe driving and may be a response to a change in the in-car environment. Therefore, the priority of the driver’s health (e.g. driver’s heartbeat and BP) is higher than that of the in-car context (e.g. oxygen and CO concentrations). Here, we assume the following priority order: Driver (Heartbeat > BP > BS > BT) > Vehicle (Oxygen > CO > Temperature > Speed > Preference Speed) > Environment (Road > Weather). According to the designed reasoning rules, each of these hazards has five different severity statuses with their respective degrees. Therefore, the priority order of the service invocation in response with the acquired context can be determined based on the basic priority (e.g. from 7 to 1) and severity (e.g. from 4 to 1) of the hazards. Here, we use the impact value impact to assess the order of the occurred hazards, which can be given as

$impact = α \times priority + (1 - α) \times severity$ (6)

where $α \in {0, 1}$ defines the preference of the assessment process. Larger α values can increase the impact of the priority on the determination of the impact value and decrease that of the severity, and vice versa. The main goal of the impact value is to determine the execution order of the concurrent hazardous situations with regard to the priority and severity of the situation.

We improved our original call control method by integrating it with the execution order algorithm. The pseudocode of the method is shown in Algorithm 2. The idea is to sort the hazardous situations based on the basic priority and severity of the situation. In line 6, the impact value of each hazard is calculated based on the priority and severity of the hazard. Then, the set T is sorted based on the impact value. Because of the computational method for the hazard impact value, some of the hazards may have the same impact value in the context set. Therefore, lines 9–13 reorder the altered context based on the basic priorities of the hazards.

Algorithm 2. The execution order algorithm.
1: Input (T)
2: Output (T′)
3: Initialize Q, Q′
4: /* Each of the hazards has an overall impact value according to the basic priority and severity of hazard.*/
5: for (i = 0 to n) do
6: t_i.impact = α × t_i.priority + (1 −α) × t_i.severity
7: end for
8: /* Sorting the hazards by impact value.*/
9: Q←impactOrder(T)
10: /* The hazards with same impact value are grouped and sorted according to the basic priority.*/
11: Q′←group(Q)
12: for (j = 0 to m) do
13: T′ = T′priorityDESC(Q′_i)
14: end for
15: Return T′

SCHS

This section takes the context-aware service SCHS as an example to demonstrate the service system. The driver’s health condition may directly impact his driving behavior and is critical for safe driving, especially for vocational or aged drivers. Indeed, these drivers are responsible for the safety of the passengers. Due to the long-time driving or the growing age, these drivers are at high risk of poor physical status because of occupational or chronic diseases. Drivers are more easily to be disturbed by their health condition or the environment when they are lacking of rest or with chronic/acute disease (e.g. hypertension or heart disease). The environment in the vehicle, such as the oxygen and CO concentrations and temperature, could also affect the driver negatively. These hazards could lead to oxygen deprivation, CO poisoning, or heatstroke, which could threaten the life of the driver. Therefore, providing context-aware services for aged drivers or drivers engaged in critical tasks (e.g. bus drivers and truck drivers) is necessary.

The main business of the SCHS is to identify the health status of the driver and provide him with necessary healthcare services. SCHS collects the driver’s vital signs and environmental indicators in the vehicle to identify the health status of the driver. Then, SCHS selects and executes the appropriate business service for the driver when his health status is not good for safe driving. The raw contexts of the driver and vehicle are acquired from the sensors deployed on the driver or the vehicle; these contexts are used for deducing the driver’s status based on the reasoning rules. The related business services include HSS (select a nearby hospital), RSS (select the optimal path for the destination), and ERS (find the appropriate rescue team for the driver).

Assume that Tom is driving a school bus, and his health-related context is collected every 10 s. His current BP is 165 mmHg, whereas his BP value collected last time was 140 mmHg. His health status (BP-Warning) can be determined through the reasoning on the current BP value. Then, by comparing his current BP status with the former one (BP, Normal), the service system recognizes the alteration of the BP status and queries the configuration model for this changed context. As the result, the service composition (OAS→SMSD→VOAAS) is selected and executed for the driver. The onboard terminal will be activated to alert him to the abnormal BP (OAS). Subsequently, his mobile phone will receive a message with a further warning (SMSD). Finally, the outside emergency flasher or buzzer alarm will be triggered to notify nearby vehicles (VOAAS). The driver may take some action to prevent accidents (e.g. take a rest or drive to the recommended hospital) or optimize his trip (e.g. change his route). When the driver takes an action, some sensor information may be affected. For example, when the driver receives the BP alert from the onboard alarming service, he may park his car as soon as possible to rest or take his medicine, and his BP value may be improved or back to a normal stage.

Experiment and evaluation

An ITS is a fast-acting and continual system that involves huge numbers of vehicles. Accidents often cause heavy damage to life and property. Therefore, the context-aware service system needs high validity and availability in service invocation. This section presents an evaluation of this service system based on computational experiments involving various controllable and repeatable situations. Figure 4 shows the interface with the experimental platform. To simulate real-world situations, abnormal situation instances, including transient instances (e.g. a non-pathological health condition that lasts for only a certain period) and sustained instances (serious situations that must be handled with outside help), are injected into the platform. The life cycle of every injected situation and the invoked services is audited to verify the validity and availability of the service invocation. As one of the most important context-aware services, “healthcare service” is taken as an example to verify whether the service system can react to these instances correctly.

Figure 4.

Interface with the experimental platform.

In this experiment, a laptop PC (Intel Core i7-6700HQ, 2.60 GHz, 16 GB memory) is used as the server of the context-aware service system. The sensory data of the vehicle and driver are generated from a client PC on a local area network and sent to the context service server every 30 s. Then, the context service server converts the sensory data into Resource Description Framework (RDF) triples as the context information. Subsequently, the current status of the driver can be obtained through the reasoning on the context. Finally, the service composition for the current situation can be chosen and executed by querying the service configuration model. By injecting various situations repeatedly, the validity and availability of the service system can be evaluated.

This article primarily focuses on the design and implementation of a context-aware service system with the aim of detecting abnormal situations during driving and providing customized services to meet actual demands. The design of the experiment is meant to validate whether the invocation of services can meet the needs of the corresponding situations. It must be noted that in real-world scenarios, the number of vehicles can affect the traffic status (e.g. cause congestion or an accident) and may also impact the driver’s behavior (e.g. causing him to change his destination or take another route). In this article, the influence of the number of vehicles to the traffic and driver is not considered.

Experimental setup

Setting up the vehicles and drivers

From the administration interface, vehicles are added into the service system with random start points and destinations. When a vehicle is added, a driver is bound to it, and the values produced from several types of sensors are continually generated to simulate a real situation; these values include the speed, temperature, oxygen, and CO concentrations.

Configuring the sensors

To verify the “healthcare service,” we define seven types of in-vehicle sensory data as the raw context of the driver to simulate seven types of sensors deployed in the vehicle (i.e. CO, oxygen, temperature, heartbeat, BP, BS, and BP). In order to simplify the experimental scenarios, the deployment of various sensors and the specific measurement of raw sensory data are not considered in the experiment. The sensory data are generated in a reliable range based on the real data collected.

It must be noted that in real-world scenario, the raw context information is acquired from different sensors deployed in various ways. The sensors that are responsible for monitoring the driver’s health are deployed as the wearable device attached on the driver’s body (e.g. sensor-studded clothing or bracelet which can sense the health indicators). The in-car environment indicators can be collected from the CO detector, temperature transmitter, and the oxygen sensor deployed in the vehicle. Other context information such as the weather information of the given location can be acquired from web services provided by the service providers. On that occasion, the weather information service plays a role of the sensors (i.e. vital sensors).

In the vehicle, the onboard terminal (sink node) collects the sensory data periodically from the sensors through the WSN. In order to ensure the effectiveness of the measurement, the involved sensors should conform to the defined precision and unit. In this article, the precision and unit of the sensory data are defined as BP – 1 mmHg, BT – 0.1°C, HB – 1 bpm, BS – 1 mmol/L, Temperature – 1°C, Oxygen – 0.1%, and CO – 1 ppm.

Reasoning rules and service configuration models

Some of the reasoning rules are listed in Table 2. The healthcare service involves 56 rules, including CO (5 rules), oxygen (6 rules), temperature (9 rules), heartbeat (9 rules), BP (9 rules), BS (9 rules), and BT (9 rules). The configuration model is designed based on 28 hazardous situations (i.e. 4 situations for each of the 7 hazards) to provide appropriate services.

Abnormal injection

The situations of various hazards are generated in this module and injected into a given vehicle–driver combination. Each abnormal situation is designed based on common situations that affect the drivers (e.g. fever and hypertension). Some of the instances are designed based on clinical data (including treatment records and continual temperature records) from a hospital in Shijiazhuang, China. The clinical data can be used to support the simulation of normal situations and some common hazardous situations (i.e. disease-related situations, such as fever, heart disease, diabetes, and hypertension).

Experimental results and discussion

To evaluate the time consumption of the service system, we simulate the processing of the request. The client generates sensory data every 30 s and sends it to the server. Then, the time consumption of each period can be calculated. Table 4 reports the mean and standard deviation values (in ms) of each period from receiving the request to selecting the appropriate services. As shown in Table 4, for a single vehicle request with seven types of sensory data, on average, 34.2 ms are needed to transform the sensory data into context data (including loading the context model and creating the individuals of the ontology). Subsequently, the status is acquired through the reasoning on these contexts (including building the inference model and executing the SPARQL querying). The selection of services (i.e. querying the service configuration model) takes 11.2 ms on average. The total response time from receiving the sensory data to selecting the services is, on average, 81.2 ± 10.2 ms.

Table 4.

Mean and standard deviation values of each period (in ms).

Vehicles	Sensors	Pretreatment	Inference	queryConfig	Total
1	7	34.2 ± 4.9	35.7 ± 9.0	11.2 ± 2.8	81.2 ± 10.2

The impact of the number of vehicles (each of which is bound to a driver) on the response time is evaluated by increasing the number of vehicles in the simulation from 10 to 100 in increments of 10. As shown in Figure 5, as the number of injected vehicles increases, the requests must wait longer to get a response because of the constraints on the computational resources. The average response time exceeds 440 ms when the number of vehicles reaches 100. However, the efficiency of processing requests can be improved by utilizing cloud-computing technology, which offers significant processing and storage capabilities.²

Figure 5.

Average response time for each request as the number of vehicles increases from 10 to 100.

Table 5 shows the example of acquired context data and the corresponding service composition during the observation of a vehicle–driver instance from time point t₀ to t₁₃ at a 30-s interval. In the service scenario, the BT of the driver changes from 36.4°C to 39.1°C, and the status acquired from the reasoning process varies from Normal to BT-Danger. The service selection and provision are triggered at time point t₆, t₉, and t₁₂ due to the alteration of the BT status. At time t₆, the BT exceeds the threshold of Warning at the first time and the service composition (OAS→SMSD→VOAAS) is selected and executed for the driver to remind him of the abnormal BT. At time t₉, the BT reaches to 39.0°C, which starts the BT-Danger status and triggers the service selection and provision. At this stage, the onboard terminal is activated to rise the alarm and the alarm information is send to the mobile device of the driver and his family member through short message service. Meanwhile, the supervision center will receive the alarm information of the driver. The BT falls to 38.6°C at time t₁₂, and the acquired body status altered from BT-Danger to BT-Warning, which triggers the service selection and provision to handle the BT-Warning status.

Table 5.

Example of acquired context data and the corresponding service composition.

Time (Δt = 30 s)	SBP (mmHg)	BT (°C)	O₂ (%)	CO (ppm)	Status	Severity	Service composition
t ₀	135	36.4	20.9	0	Normal	0	None
t ₁	136	36.8	20.5	1	Normal	0	None
t ₂	136	36.7	20.1	0	Normal	0	None
t ₃	136	37.0	20.5	0	Normal	0	None
t ₄	134	37.4	20.7	0	Normal	0	None
t ₅	131	37.6	20.3	1	Normal	0	None
t ₆	134	38.1	20.1	0	BT-Warning	2	OAS→SMSD→VOAAS
t ₇	135	38.4	20.1	0	BT-Warning	2	None
t ₈	133	38.7	19.9	0	BT-Warning	2	None
t ₉	128	39.0	20.1	0	BT-Danger	3	OAS→(SMSD, SMSR, SCAS) →VOAAS
t ₁₀	135	39.1	20.0	0	BT-Danger	3	None
t ₁₁	133	39.1	20.4	0	BT-Danger	3	None
t ₁₂	136	38.6	20.5	0	BT-Warning	2	OAS→SMSD→VOAAS
t ₁₃	131	38.5	20.5	0	BT-Warning	2	None

The availability and validity of the service system were evaluated by injecting abnormal instances randomly. The availability of the service system was checked by determining whether it could respond to abnormal situations in an acceptable time. When the abnormal instances (or a composite sequence) are received, the service system should react to each instance and select services or service compositions to execute. A response to a request is not considered successful until the first selected service provides a response. Assume that A indicates the availability of the service system, S indicates the number of injected abnormal instances, and R indicates the total number of successful responses to the abnormal instances. The availability of the service system is calculated as

$A = \frac{R}{S}$ (7)

The validity of the service system reflects the accuracy and completeness of the execution of the selected services. Accuracy means that the service can be executed and returns a correct and acceptable result. There are many ways to provide or execute various business services for a driver. These methods can be sending an alarm message to their mobile phone (SMSD), sending signaling information to activate the onboard alarming equipment (OAS), or sending the driver the fastest route path to the appropriate hospital (RSS). The completeness involves the fact that all the services in the service composition are available and can be executed based on the execution sequence without exception. For each successful response, until all the selected services in the composition are invoked and return an acceptable result, the response to this request is considered a “validate response.” Suppose V is the validity of the service system, R indicates the total number of successful responses to abnormal instances, and C refers to the number of completely and correctly executed services or service compositions. The validity of the service system can be calculated as

$V = \frac{C}{R}$ (8)

Experiments involving a single abnormal instance injection were executed from 100 to 1300 times (at a 200-time interval) to verify the availability of the service system to react to each type of abnormal situation separately. In the experiment, we randomly injected a single abnormal situation into the request. For each of the 7 hazards, we first executed the request 100 times. Then, in the next round, we increased the number of requests by 200. This experiment was repeated until the number of requests reached 1300. The severity of every abnormal instance was chosen at random from 1 to 4. As shown in Figure 6(a), the average availability of the service system reacting to different types of abnormal situations was approximately 92% (the average availability of each type exceeded 90%). As the number of injections increases, the average availability of these situations gradually stabilizes as approximately 91%.

Figure 6.

The availability of the service system: (a) single abnormal injection and (b) multiple abnormal injection.

Multiple abnormal instances (in the form of an abnormal sequence) were injected and ranged from individual abnormal situations to all varieties of such situations. For every number of instances in the abnormal sequence (i.e. from 1 to 7), each variety of abnormal instance (in the form of sequences) was injected 500 times with random severity (i.e. from 1 to 4). The value of α in Algorithm 2 is set to 0.1, which ensures that hazards with higher severity can be responded to first. Thus, the availability of the service system for each type of abnormal instance injected accompanied by others was calculated. In Figure 6(b), because of the priority order of each abnormal situation, the availability of the service system to react to instances with lower priority (especially the temperature) declines but remains above 80%. This is because the overall impact value of each hazard is always higher than that of lower severity hazards with higher priority order based on the parameter set in Algorithm 2. Thus, the algorithm can increase the execution order of the abnormal situation when it is deteriorated (i.e. the severity is increased).

Figure 7 shows the validity of the service system for different experiments. By executing each type of abnormal situation from 100 to 1300 times (using a 200-time interval), the validity for separately reacting to each type of situation was calculated. As shown in Figure 7(a), the average validity of the service system was 94% when reacting to a single type of abnormal instance. In Figure 7(b), as the number of abnormal situations increases, the validity of the service system slowly declines (to an average of 85% for up to seven types). This is because the response to each abnormal sequence in multiple situations becomes complicated, and the selected service compositions must be executed based on the ordered situations. If the sequence is large, more time will be needed for the tail of the queue to be executed and for the services’ returns to be obtained. Further research will focus on improving delayed services in multi-hazard situations.

Figure 7.

The validity of the service system: (a) single abnormal injection and (b) multiple abnormal injection.

Conclusion

In this article, the design of a context-aware service system is proposed to address safe driving problems and make full use of business services. The main contributions of this article are as follows. (1) A systematic architecture is proposed for the design and implementation of the context-aware intelligent service system in the ITS. (2) An ontology-based context model with reasoning rules is designed that can correlate the driver, vehicle, environment, and sensors to further describe the driver status. (3) A flexible service configuration model and service invocation algorithms are proposed to provide appropriate business services based on hazardous situations. The assessment of the service system (i.e. availability and validity) was achieved through computational experiments on SCHS with various abnormal instances injected. The results indicate that the service system can manage most of the abnormal situations as expected, although some problems remain to be resolved.

Future goals include the improvement of service invocation in multi-hazard situations (e.g. the creation of a more reasonable and balanceable execution order) and in-depth research on multi-sensor data fusion to describe situations (e.g. by fusing the sensor data to diagnose some common diseases for effective rescue and combining multiple sensor data to assess the rationality of the acquired context). More hazardous situations should also be studied and implemented in the service system. In addition, more services (e.g. parking service and automatic dialing service) will also be implemented to enrich the candidate service and increase the service ability of the context-aware service system. Driver interaction will also be considered to improve the service execution mode (recommended or pushed) and increase the accuracy of the service provision.

Footnotes

Handling Editor: Kim-Kwang R Choo

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research,authorship,and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research,authorship,and/or publication of this article: This work was partly supported by the National Nature Science Foundation of China (NSFC;61370069 and 61672111),the NSFC-Guangdong Joint Found (U1501254),the Co-Construction Program with the Beijing Municipal Commission of Education and the Ministry of Science and Technology of China (2012BAH45B01),the Fundamental Research Funds for the Central Universities (BUPT2011 RCZJ16 and 2014ZD03-03),and China Information Security Special Fund (NDRC).

References

China

NBS

. Statistical communiqué of the People’s Republic of China on the 2014 national economic and social development. Beijing: National Bureau of Statistics of China, 2015.

Perera

Zaslavsky

Christen

et al . Context aware computing for the Internet of Things: a survey. IEEE Commun Surv Tut 2014; 16(1): 414–454.

Golestan

Soua

Karray

et al . Situation awareness within the context of connected cars: a comprehensive review and recent trends. Inform Fusion 2016; 29: 68–83.

Al-Sultan

Al-Bayatti

A-H

Zedan

Context-aware driver behavior detection system in intelligent transportation systems. IEEE Trans Vehic Tech 2013; 62(9): 4264–4275.

Wartzek

Eilebrecht

Lem

et al . ECG on the road: robust and unobtrusive estimation of heart rate. IEEE Trans Biomed Eng 2011; 58(11): 3112–3120.

Sun

An innovative nonintrusive driver assistance system for vital signal monitoring. IEEE J Biomed Health Informat 2014; 18(6): 1932–1939.

Sathyanarayana

Boyraz

Hansen

J-H.

Information fusion for robust “context and driver aware” active vehicle safety systems. Inform Fusion 2011; 12(4): 293–303.

Sun

Zhang

Providing context-awareness in the smart car environment. In: Proceedings of the IEEE 10th international conference on computer and information technology, Bradford, 29 June–1 July 2010, pp.13–19. New York: IEEE.

Yang

Chen

Suetal

Research and development of hybrid electric vehicles CAN-bus data monitor and diagnostic system through OBD-II and android-based smartphones. Adv Mech Eng 2013; 5(3): 741240.

10.

Ohn-Bar

Tawari

Martin

et al . On surveillance for safety critical events: in-vehicle video networks for predictive driver assistance systems. Comput Vis Image Underst 2015; 134: 130–140.

11.

Boyraz

Yang

Hansen

J-H

. Computer vision systems for “context-aware” active vehicle safety and driver assistance. In: Hansen

Boyraz

Takeda

et al . (eds) Digital signal processing for in-vehicle systems and safety. New York: Springer, 2012, pp.217–227.

12.

Sathe

Deshmukh

VD.

Advance vehicle-road interaction and vehicle monitoring system using smart phone applications. In: 2016 online international conference on green engineering and technologies, Coimbatore, India, 19 November 2016, pp.1–6. New York: IEEE.

13.

Zhang

Tan

Sha

et al . Predicting pedestrian counts in crowded scenes with rich and high-dimensional features. IEEE Trans Intell Transp Syst 2011; 12(4): 1037–1046.

14.

Sun

Pan

Context-aware smart car: from model to prototype. J Zhejiang Univ Sci A 2009; 10(7): 1049–1059.

15.

Pung

H-K

Zhang

D-Q.

A service-oriented middleware for building context-aware services. J Netw Comput Appl 2005; 28(1): 1–18.

16.

W-P

Z-H.

Framework of context-aware based service system. Chinese J Comput 2010; 33(11): 2084–2092.

17.

Wan

Zhang

Zhao

et al . Context-aware vehicular cyber-physical systems with cloud support: architecture, challenges, and solutions. IEEE Commun Mag 2014; 52(8): 106–113.

18.

Zhang

Wang

F-Y

Wang

et al . Data-driven intelligent transportation systems: a survey. IEEE Trans Intell Transp Syst 2011; 12(4): 1624–1639.

19.

Yan

Developing vehicular data cloud services in the IoT environment. IEEE Trans Ind Informat 2014; 10(2): 1587–1595.

20.

Fuchs

Rass

Lamprecht

et al . A model for ontology-based scene description for context-aware driver assistance systems. In: Proceedings of the 1st international conference on Ambient media and systems, QC, Canada, 11–14 February 2008, pp.1–8. Brussels: ICST.

21.

Madkour

Maach

Ontology-based context modeling for vehicle context-aware services. J Theor Appl Inf Technol 2011; 34(2): 158–166.

22.

OWL 2 web ontology language document overview (second edition), W3C, December 2012, https://www.w3.org/TR/owl2-overview/

23.

Protege-OWL editor, http://protege.stanford.edu/

24.

Apache Jena project, http://jena.apache.org/

25.

Raub

Environmental health criteria 213: carbon monoxide. Geneva: World Health Organization, 1999.

26.

The State Council of the People’s Republic of China. Regulation on the implementation of the road traffic safety law of the People’s Republic of China (2004), http://en.pkulaw.cn/display.aspx?cgid=52565&lib=law

27.

Q&As on hypertension, http://www.who.int/features/qa/82/en/

28.

Rodriguez

Kumar

de Caro

Hypertensive crisis. Cardiol Rev 2014; 18: 102–107.

The design of a context-aware service system in intelligent transportation system

Abstract

Keywords

Introduction

Background and related work

Context-aware service

Related work

System architecture

Context acquisition

Data transmission

Business service provision

Implementation of context-aware services

Context modeling

Context reasoning

Business service invocation

SCHS

Experiment and evaluation

Experimental setup

Setting up the vehicles and drivers

Configuring the sensors

Reasoning rules and service configuration models

Abnormal injection

Experimental results and discussion

Conclusion

Footnotes

Declaration of conflicting interests

Funding

References