Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Rapidly growing technical development becomes evident through the usage of the comprehensive interconnection between electronic systems in nearly all areas of our everyday life. Modern automobiles are no longer complex mechanical, but increasingly complex electronic systems. They contain a large number of sensor devices essential for smooth technical operation (e.g. parameters like engine revolutions and vehicle speed) and environment perception (e.g. barometric air pressure and ambient air temperature). This data is a prerequisite for the growing number of “advanced driver assistance systems” (ADAS). Data from these sensors also built the base of semi-autonomous and autonomous driving systems. The Canadian Author Cory Doctorow remarked in a lecture about the consequences of electronic interconnections during the “28. Chaos Communication Congress 2011” (28C3) in Berlin: “We don’t have cars anymore; we have computers we ride in” (Doctorow 2011).

According to the availability of existing techniques of communication, increasing data-bandwidth as well as decreasing cost of transmission, the collected data from automobiles for various purposes should be utilized. This includes communication models such as vehicle-to-vehicle (v2v), vehicle-to-infrastructure (v2i), or vehicle-to-x (v2x). Reacting to this situation, “Extended Floating Car Data” (XFCD) expand on the concept of “Floating Car Data” (FCD) and take on a central role in future developments. Automobiles would become interconnected and retrievable mobile sensors themselves and are high-profile within research and economy. This new massive amount of data that is valuable to many key industry players, and thus the emergence of many new applications, right up to autonomous cars, will influence our everyday life heavily.

The incentive of this research work needs the utilization of the accumulated data from the computer system automobiles for analysis. As this data from sensor-information is being generated in the light of the dimensional time and space, it can be seen as potential spatio-temporal information and consequently as geo-information or geodata. This enables a space applied process as well as a visualization and so demonstrates a fascinating field, especially from the point of view of geo-information science and cartography. Within the scope of the research work, it appears that spatio-temporal consideration, especially with the usage of cartographic visualization in combination with additional methods of visualization, provides an adequate opportunity for analysis. Consequently, this represents a basis to make the information overload manageable and evaluable for the human being. In this regard, it was possible to carry out a prototypical implementation of the data entry. The automobile had applied the application of the required by law “On Board Diagnostics” (OBD) interface, a smartphone supported procedure, as well as a web-based visualization for a usage scenario. The at hand research work is supposed to contribute to this new kind of mass information and make it available as geo-information in accordance with the concept of “Extended Floating Car Data” (XFCD) and to utilize those for spatio-temporal visualizations (visual analysis).

Therefore, the question of whether a technical implementation, through the application of open source software is solely possible, was considered. With the idea in mind, that a human is part of the automobile system (and thus creator of his own spatial mobility), the question arising is how data and its visualization can be supported, for e.g. the human as a driver or planner. Implementing methods from the field of (geo-)visual analytics, recording, processing, and visualizing data of one or more vehicles can be used to analyse driving styles and environmental behaviour. A spatio-temporal point of view – especially regarding web-based applications of cartographic visualizations in combination with other methods of representation – enables users to interpret the vehicle’s data. The different applications, however, will have to take into account each specific context.

But there are still a lot of unsolved problems, which require more in-depth research. How can the data be recorded, processed, visualized, and displayed in an automated fashion? What are the most interesting facts? What data can be used in this way and how can it be combined, processed, visualized, analysed, and interpreted in a logical and productive way? Which components and strategies of visualization are most effective and how can they be defined, combined, and eventually applied? Against the backdrop of the well-known visualization pipeline, it is necessary to identify and develop suitable components and strategies for each stage of filtering, mapping, and rendering. The intention is to combine and utilize them in a pattern and rule based approach.

2 Data, Content and Application Potential

The surveillance and geolocation of the recording of traffic (specifically of automobiles) can be divided into the general recording of traffic (e.g. through induction loops, photoelectric barriers as well as camera surveillance systems), and into the individual recording of traffic or geolocation (e.g. through GPS Global Positioning System). However, general recording of traffic requires costly and local or stationary measuring sensors. The question arises, which information and potential added values during mobile measuring can be provided in terms of the individual vehicle compared to the overall traffic system and beyond.

“Floating Car Data” (FCD) and “Extended Floating Car Data” (XFCD) are suitable for the explanation of time and space applied data from automobiles and will be elaborated hereinafter (Fig. 1). In relation to a technical point of view, those specific connections between telecommunication and information are necessary and can be classified as “traffic telematics”.

Fig. 1.
figure 1

Schematic representation of the composition of a FCD and XFCD information.

Full size image

Floating Car Data (FCD).

FCD enables the acquisition of individual geolocations, e.g. the individual data collection and transmission in regards to single vehicle with this traffic system. The more vehicles are generating information within the overall system, the more extensive the overall data system becomes and ultimately those findings and information become more reliable. The single vehicle that generates FCD for the overall data system can be recognized as samples to access and evaluate the whole traffic situation. The analogy of “corks swimming in the river” seems to be most adequate to describe this principle (Pfoser 2008a, 321).

Main components of the FCD system are called “On Board Units” (OBU), which are located (often stationary) in the vehicle and have data binding (e.g. via the mobile phone network GSM Global System for Mobile Communication) as well as a central system or server to which the information is sent through programmed algorithms, including time and space intervals or occurrence triggering. This data transfer from an automobile to a central station is usually referred as “vehicle-to-infrastructure communication” (v2i). It should be noted, that FCD is heavily related with the concept of “Floating Cellular Data” or “Floating Phone Data” (FPD) that is being used to collect and transfer data. The advantage is that there is no need for special equipment or hardware. Any mobile phone with GPS or mobile phone tracking and data connection is needed for the acquisition and transmission of data.

To summarize, FCD or FPD data sets are point data and is determined by the acquisition at the position also known as coordinates of the vehicle (spatial reference) and the timestamp (time reference). The data have spatial and temporal components that can be used for further proceedings. This way, travel time and driving progress can be reconstructed as well as information can be calculated out of this data to be used for e.g. the individual velocity of a vehicle or the behaviour of the processes of acceleration and slowing-down. The collected information out of these individual automobiles can predict situations about the overall traffic system through statistical methods. The bandwidth of potential (traffic) services on the FCD basis can therefore be versatile (according to Lorkowski 2003, 7–12):

  • deflection of the average velocity,

  • displaying the situation of the roads,

  • automated reports for traffic jams and current status,

  • dynamic route planning, on and off board navigation systems,

  • generation of digital road networks.

This implies the necessity to equip a preferable large amount of automobiles with the technique to generate a reliable base of data. Automobile fleets such as cabs and public transportation are often being used for traffic recordings.

Extended Floating Car Data (XFCD).

FCD already provides several possibilities to track movements of individual vehicles and to derive traffic information. Those possibilities should be extended through additional data, specifically from automotive electronic and sensor technology.

BMW investigated “Extended Floating Car Data” in 1999. Next to other automotive manufactures, this company offers automobiles with respective OBU and merges the data based on the XFCD concept through telematics services (under the brand name “BMW Connected Drive”). Without agreeing on the specifics provided by BMW, the term XFCD illustrates a fitting description for the extension of the FCD concept (as a usual geometric point object) specifically with the addition of data of the automotive electronic or sensor technology: “The location and timestamp information are enriched with vehicle status information derived from the in-vehicle bus system or additionally attached sensors” (Barceló and Kuwahara 2010, 164). XFCD so extends the range and quality of recorded (and transmitted) data, “[…] while here all information of the automotive electronics (such as ABS, ESP, rain sensors, etc.) are being used and analysed for different situations (condition of traffic, weather, condition of roads, etc.)” (Halbritter et al. 2008, 147).

According to the information and parameters that are completed through this, comprehensive and heterogeneous datasets are created as well as many potential possibilities to derive calculated new information out of this. As modern automobiles include several different sensors today, the collected data from automobiles can not only be utilized for traffic relevant considerations (e.g. Monitoring of traffic) but also for environment relevant considerations (e.g. Monitoring of the environment). This way automobiles become mobile sensors. XFCD delivers event and state data and so generates potential (traffic) service which can be characterised in general as the following (Breitenberger et al. 2004, modified):

The variety of possible applications can be clarified as follows: The emergence of real-time location data has created an entirely new set of location-based services from navigation to pricing property and casualty insurance based on where, and how, people drive their cars” (McKinsey 2011, 6). Fundamentally, a great number of applications for different areas are possible through XFCD. As an example (Table 1):

Table 1. Content and services based on XFCD (selection).
Full size table

  • traffic monitoring (e.g. traffic intensity and quality),

  • environmental monitoring (e.g. weather events),

  • emissions (e.g. ecological footprint and air quality),

  • driving behaviour (e.g. routes, driving speeds and brake activation),

  • navigation (e.g. depending on traffic or environmental situation),

  • electro-mobility (e.g. route planning and range estimate).

It already becomes apparent how convincing the information of the collected data can become and how heavily privacy can be interfered through the usage of this data. Potential users or user groups can be identified, which can be considered heterogeneous:

  • private user or end-user,

  • planner (e.g. traffic and environment planning),

  • manager (e.g. automobile fleet management),

  • decision maker (e.g. politics and administration),

  • economical actors (e.g. automaker, insurer).

The question is how this information, even after comprehensive (computer-aided) processing and filtering, are made analysable and controllable for the user, meaning the usage for the individual area of application. As human beings have the possibility and ability to be the generator and end user of that information and are used to read and process the information quickly, the visualization can be a suitable instrument. It needs to be emphasized that XFCD as well as FCD are spatial data. This way it is comprehensible that spatial data processing and map based or cartographic visualization is acting as a major part of the analysis and evaluation of this information. Next to the spatial component, the temporal component represents the second important condition and requires additional methods. The visualization of spatio-temporal information or spatio-temporal data can be seen as superordinate term.

This new way of data serves as a basis for technologies such as semi-autonomous and autonomous driving (however, a transmission of data from the system of the vehicle is not mandatory in this case). The possible uses of XFCD are going even further. Through technologies such as “vehicle-to-vehicle communication” automobiles have the possibility to give warnings between themselves on the basis of data of potential danger (e.g. Accidents or icy roads) by exchanging data collected from individual vehicles among themselves: “The Key aspect of XFCD is that they have the potential to indicate hazardous conditions before they turn into real incidents” (Schneider et al. 2010, 164). To enable this, general and main requirements can be formulated to the XFCD-Systems (by Stottan 2013, 52):

  • low ongoing operating costs (specifically communication costs),

  • scalable and usable anonymization,

  • reliable and suitable OBU,

  • easy and usable standardisation for provision for charitable.

Next to the transparency and data protection (specifically in terms of the effective anonymization), the standardisation of uniform and general data models turns out to be very problematic. Without those, the exchange as well as the usage of that data in scientific as well as commercial context is difficult to apply.

3 Data Logging, Filtering and Visualization

The increase of electronic components in an automobile is accompanied by a growing number of electronic control units (ECU). Taking the automobile series of model Mercedes Benz E-Class (Daimler AG) as an example, there is an increase in numbers from 17 in 1995 (Model: W210) to 67 in 2011 (Model: BR212) (cf. Schäffer 2012, 19–22). Every ECU is equipped with an intelligent mechanism in the form of a micro-controller, controlled by a software and designed for a specific task or a specific area of activity. It picks up and processes the signals of the connected sensors and generates the signals for the connected output device. The electronic interconnection within the automobile is realised through an on-board power supply. It can be thought of as a connected or allocated system of a specialised control device, whereby the single control devices can exchange data with each other through a common data bus. Therefore, data bus systems can be considered as networks for data exchange and ECUs can be considered as network nodes. The CAN-Bus (Controller Area Network) can be cited as an example of an often found bus system. It has become the common standard for automobile since its development in 1983–1987 mainly by Bosch and Intel and its introduction in 1991 and is often used in the automation engineering (cf. CiA 2016).

It arises the issue how sensor data from the automotive’s electronics in terms of XFCD (and therefore as geodata) can be utilized technically. This research paper investigates the complete procedure of data acquisition, from the vehicle to the extern visualization and processing. It also develops and applies a qualified process as a technical cycle to equip the data in the vehicle’s generated data with a spatial and time reference. It was specifically motivating to use a technical approach which is not exclusively covering automobiles of the new generation but also older models. No proprietary or commercial system was used to show a potential and practical approach to enable the usage of data from automobiles for every person. Also, no hardware was used that needs to be installed in the automobile. It was aimed to exclusively use complimentary and open source software as well as reasonably priced hardware.

Automakers developed a wide range of implementations such as communication protocols, diagnosis codes or connectors to diagnose the vehicle systems and its single components, specifically for fault diagnostics in repairs shops. This range is caused by the specifics of the different automakers, their technical transcription, as well as missing standards and norms. As malfunctions in the combustion system or in the exhaust gas function can be a potential danger for the driver and the environment, the compliance of statutory emission limit value for this issue needs to be defined by the legislature. In the USA, the California Air Resource Board (CARB) established measurement criteria and technical specification named “On Board Diagnostics” (OBD or OBD II). The technical details (such as form and layout of the diagnostic connector as well as defined diagnosis routines and “Diagnostic Trouble Codes” (DTC) were taken on internationally and were determined in the ISO-Norm 15031 “road vehicles – communication between vehicle and external equipment for emission-related diagnostics”. Those provide the technical basis for an establishment in the regional mandatory legislation, such as Japan, USA, Europe. As far as it concerns the statuary mandatory functions, pin configurations are always determined. However, automobile manufacturers are eligible to use the not assigned pins of the diagnostic connector for own proprietary applications. It is even possible to resort to the existing OBD protocol for communication, but only with a not standardized proprietary command.

Through OBD-diagnose-hardware or with the connection to a computer and a specific software, the predefined diagnostic routine and respective diagnostic data can be obtained. The list of the OBD (II) potential possible parameters (as long as automobile specific available) is long (cf. Schäffer 2012, 205–224).

By over 80 defined parameters, less than 32 parameters are regulated through the legislature for supervision of exhaust relevant components and systems. Provided that the respective automobile supports OBD, it can be used for further consumption (e.g. fuel) and supervisory sensors (e.g. fine particles or NOx). During communication, the OBD supported information or parameters are called OBD PID (Parameter Identifier). The conclusive identification with PID enables the specific access to sensors or measured data and routines. The query of the respective supported parameter is possible (in blocks) here. Inquiries (always binary) and responses are expressed through the hexadecimal system and need to be converted for further use (cf. ib., 96f) The following table specifies the PID for further investigations as an example (Table 2).

Table 2. Selected OBD PID (incl. range and und measuring units).
Full size table

The by law required OBD interface is therefore the physical technical interface for automotive electronics. Because of the availability of relatively reasonable hardware for diagnosis, it makes sense to gather (computer supported) (sensory) data this way. Modern smartphones (as mobile computers) provide the required technical features and are very suitable (alternative to build-in OBU) for communication with the OBD hardware (wireless or tethered), for processing and storage of the data, and for the data transfer through the combination with a web based or server-sided provided system. During the acquisition of data, the connection of space and time can be added through a GPS supported smart phone and so enables the generation of XFCD.

These discoveries made a technical process and its development and implementation possible (Fig. 2). Based on this process, three main central tasks can be identified: (1) data acquisition and transmission, (2) server-side data processing, as well as (3) the visualisation and application with the help of web browsers through the end-user (cf. Voland 2014).

Fig. 2.
figure 2

Smartphone supported process for generating of XFCD from OBD data with subsequent web based process and visualisation (schematic illustration of the setup).

Full size image

Data Logging.

In the first step of the process, the OBD interface of the used automobile is equipped with an OBD hardware and a connected smart phone. Different OBD adapters with wireless Bluetooth connection are applied. A mobile application on the smartphone is being used for communication from the OBD hardware or interface to recall data (e.g. in a time interval). In this context, several software solutions are already existing, but the selection is very limited for open source software for active and advanced projects. For the open source system Android, the application, android-OBD-reader (under apache license 2.0, cf. AOBDR 2016) is an example. For the research work a constructive collaboration with the contribution of this open source project has been developed, to make the collected OBD data (XFCD) through the mobile application available. The mobile application on smart phones expands the acquisition of OBD data with the real time coordinates delivered through GPS and a time stamp. The generated XFCD are being cached or sent from the automobile (identifiable by its vehicle identification number, VIN) to a server with an existing internet connection. The tasks of the mobile applications can be summarized as:

  • selection of OBD PID and configuration of the interval of inquiries,

  • communication with the OBD via (ELM327-based) OBD Bluetooth hardware (sending requests and processing those responses),

  • generating data sets: analysing values and adding spatio-temporal references (coordinates and time stamps, spec. through GPS)

  • instant sending of data set to the server with an existing internet connection or caching data set for subsequent sending (with a non-existing internet connection).

Data Processing.

Within the open source project, the development of a server-side software component “OBD-server” (under apache license 2.0, cf. AOBDR 2016) as a service was conducted. The possibility was created to upload data from the mobile application to the server (or the server-side software component). To proceed further, CartoDB was chosen to connect the following open source software: PostgreSQL/PostGIS as spatial database system, GEOS (libgeos) and GDAL (libgdal) to process vector and raster data, and Mapnik to generate map tiles, also raster and vector data and leaflet as a viewer to see the map. CartoCSS is being used for the generation of graphical submittals, which is based on the web development tool CSS (Cascadian Style Sheets). CartoDB encompasses an API (Application Programming Interface) for the implementation in its own applications as an interface to CartoDB specific functions, which includes a specific SQL API that enables a read and write permission to the PostgreSQL/PostGIS-database (cf. CartoDB 2016).

The server component “OBD-server” is constantly receiving data from the mobile application “android-OBD-reader”. The collected data can be perceived through a soft copy on the server. Afterwards, on the server-side the readout of the “OBD-server” existing data sets occurs (of all available vehicles or VIN) and as a second step, database tables are created, as well as a quick clearing of data or databank. The interchange format is JSON, meaning the format of data sent from the mobile application, received from the server component, and then made available. This format is supported by PostgreSQL/PostGIS as well as CartoDB. Following this, further processing of data, the reprocessing of visualization (e.g. transfer of existing vector data into image and raster data), as well as the deployment of a web based application is taking place (Fig. 3).

Visualization.

In the last step, the user is able to use the server provided application through a web browser (cross-platform). The ‚torque’ library, provided form CartoDB, enables the use of a map-based dynamic display for movement through JavaScript, CartoCSS and HTML5 (spec. HTML5 Canvas). To allow the efficient transfer of the massive amount of data from the server to the client, a compressed ‚data cube’- format is being used in the sense of a multidimensional OLAP cube (online analytical processing) or data set. The edge of the cube is equivalent to the dimension (cf. Han 2008).

Fig. 3.
figure 3

Output from the server (top), CartoDB User Interface: database table/“Table View” (middle), CartoDB User Interface: Visualisation/“Map View” (bottom).

Full size image

4 Additional Data Processing

The processing (specifically server-side) is an important component to increase the quality and information content of the collected data. Complex procedures are partially necessary, to evaluate realized implementation that have not taken into consideration. The following principle measures are being investigated for implementation depending on the application correlation.

Map Matching.

As the determination of the location (e.g. via GPS) can result in an imprecise or insufficient outcome for several reasons, there is the need of techniques that acquire the exact location of a vehicle (or the potential location at a specific time) (cf. Pfoser 2008b). This can be done with the help of Map-Matching algorithms (specifically through Kalman filtering) that can already be applied during data acquisition as well as during later analysis data import or a subsequently processing step. It seems logical that the traffic coverage (for traffic lane analysis) requires a high accuracy for location determination. A respective method can help potentially through an open source software such as pgRouting as PostgreSQL/PostGIS, expansion of road networks (with or without the ability for routing) though OpenStreetMap-Data (OSM), as well as the implementation of a Map-Matching algorithm.

Generation of Trajectories.

Since XFCD are generally geometrical and to the point data, a technique that can match the gathered points to the respective trajectories needs to be applied. This step can be implicated during the Map Matching process. Only then, a reasonable evaluation for a number of issues and use cases can be made. Processing is done through special algorithms, e.g. as the semantic method, depending on the issue or the aimed processing stage. When looking at a simple processing or derivation of trajectories, such as single tracks of the specific vehicle, data storage becomes an issue. Since a differentiation between several geometry types is done in spatial DBS (such as in PostgreSQL/PostGIS), a data base table can only contain data of determined types (e.g. point, line, polygon). As data converts from point geometry into line geometry when deriving from trajectories, the database table requires different types of geometry and therefore a modified setup of the database or the whole data base scheme.

Anonymization.

Data anonymization, to protect privacy of the user, is an important requirement encompassing the data protection law. Thus, the execution should be involved in the process chain as early as possible. Depending on the technical execution, this can already be done before transmission within the vehicle or directly after transmission to the server, whereas the data anonymization for vehicle and driver should be applied before transmission already. As it is possible to derive trajectories of the single vehicle from the available data (in terms of evaluating movement profiles and to draw conclusions about the departure and final destination), the anonymization of trajectories through the alteration of individual start and target coordinates or points can form a spatial approach. In this regard, three strategies can be identified (Fig 4):

Fig. 4.
figure 4

Anonymization strategies (modification of the start and end points of a trajectory).

Full size image

A potential approach for the anonymization of trajectories can be the application of a buffer function, i.e. a removal of a trajectory’s segment, which resides within a circular buffer area in the starting point or destination. Another approach can be the removal of trajectory’s segments of a defined distance between starting point and destination. Since the movement and distance is looked at in the road network, it can be referred as ‘network distance’. A potential third approach is the removal of trajectory’s segments to the defined number of passed network nods from start point to destination. To increase security, all three named cases should preferably use random values in a defined range for the defined variables. It needs to be emphasized that the named approaches are a proposing suggestions and is likely to be inadequate for every potential use case.

Generation of Additional Data.

Acquisition of data from a database is possible by several ways. One method is ‚data mining’ as a “summary of different statistical procedures with the goal to filter relevant information from a massive amount of data, e.g. through intelligent identifying of relationship and distribution patterns” (Bollmann and Koch 2005). Another possibility is to calculate data from the existing one. The following shows an example of a specific calculation which elaborates the correlation between fuel consumption and CO2 emission and to point out a potential calculation (with the use of the automotive electronics’ data). Depending on available data (vehicle or fuel specific), the calculation is possible through several different formulas with different accuracy. The calculation conducted is based on the value of the air-mass sensor (MAF), the vehicles’s speed (VSS) as well as the information of the kind of used fuel which also needs to be available (or can be determined by OBD PID 51 FUEL_TYPE). According to the kind of fuel (for further investigation it is petrol), specific constants need to be involved in the calculations: the needed air volume to combust one litre of fuel (14,7 kg) and the average density of petrol (740 kg/m3). Through this information, every single and point based data sets for the fuel consumption at a specific point in time can be calculated (so-called current fuel consumption). The described procedure shows that further statistical calculations can be made, e.g. average consumption value (based on the number of kilometres, a trajectory or route, a time frame, or aggregated sections of roads). Based on the information about the current fuel consumption, a calculation of the caused CO2 emission can be made. It is necessary to know the specific emission factor, the relation between used amount of fuel and the amount of the consequent emission (CO2 and equivalents). The adjusted emission factor (CO2 equivalents included) is indicated as 2,874 kg/l for petrol, i.e. the consumption of one litre of petrol produces about 2,87 kg of CO2 emission (BLfU 2016). Those single calculated values, considered throughout the process, can be used for statistical analysis as well.

5 Need for Holistic and Integrated Approaches

The approach presented can be successful when tested with different automobiles, smartphones, and OBD Bluetooth hardware (quoted data editing and processing excluded). It results in the conduction of the complete technical procedure, from the smart phone supported data (on board) to the transfer in a spatial database and visualization in CartoDB. A suggestion for visualizing a usage scenarios was developed, based on a conducted interview with experts. It entails the setup of a cartographical visualization as well as the setup of user interface and interaction and was implemented in form of wireframes and mock-ups. It shows to expand the addressed approaches to solve the issue of automated generation and deployment of interactive and contextual (geo-)visualization (also for XFCD). The starting point needs to be the general influencing factors and requirements for cartographic visualization.

To demonstrate the transfer of geodata as raw data to an analogue or digital graphic of a map, this pipeline shows the sequence of the process (filtering, mapping, rendering). It becomes clear that the demonstration of data is determined by the step of filtering (included in the XFCD). For mapping and rendering, there are principles and regulations for graphical processing of data, cartography, and the configuration of user interface and interaction available. A strategic approach can exist in definition and application of design patterns for approved solutions for recurring general and organizational tasks. The single design patterns (such as elements from the user interface and interaction) can be consolidated into complete libraries. Regarding cartographic media, the concept of GeoViz patterns is interesting (cf. Heidmann 2013). This shows the definition and application of policies as a guidance for a potential approach (cf. Asche and Engemaier 2012). One potential approach could be to formulate a rule-based graphical user face and interaction. It can be established on fundamental principles and requirements of graphical layouts (especially in cartography, geo-visualization, e.g. graphic variables and cartographical presentation methods, etc.) to solve the respective questions through the help of design patterns. It is to aim for merging of and applying methods and strategies of an appropriate representation for spatio-temporal visualization. A broad formalization can be achieved and consequently the automation of the process of generating (Fig. 5).

Fig. 5.
figure 5

Potential approach for formalization of manufacturing process (scheme).

Full size image

Process modelling of knowledge-based systems, specifically rules based systems, indicate a suitable approach for automatic generation of this type of visualization. Decision diagrams (as well as the connection and combination of them) can serve to formulate and display decision rules, which are needed for the generation process. The combination of several methods of software engineering such as design patterns or libraries, service oriented architecture, and model view controller (MVC) with a rule based approach, can be a potential contribution to solve the issue. This approach would be more complex and extensive and would require an additional research work.

6 Conclusion and Outlook

The research work presented in this paper was able to demonstrate an insight and an overview of the utilization of spatio-temporal data within the automotive electronics based on the XFCD concept as well as its technical generation of data. The OBD diagnose interface enables an access to the data bus system of the automobile. This opens the possibility to have a wide but limited (by regular usage) access to specific by law required parameters. XFCD enables a variety of applications (on- and off-board), whereas the data of diverse sensor technology can be emphasized, especially for the detection of the surroundings and environment of a vehicle. As extension of the FCD concept, which is already used for traffic monitoring, XFCD or automobiles are providing an added value as mobile sensors, specifically in the field of environmental monitoring. Interesting application can be the estimation of emission values and the gathering of the concentration of surrounding air (as long as an access for respective sensors is available).

In addition, it needs to be tested whether the combination of XFCD (which show a high spatio-temporal dynamic) and data from stationary measuring sites can support the consolidation of data basis and enable a precise prediction. The field of application through visualization offers many potential areas of operation. Visualization provides the basis for decision and practices. Its elaboration is an important and comprehensive task, which needs to be referred to the specific context (application context, user context, medium for illustration) and to process carefully. A decidedly examination with the visualization of XFCD has not been conducted sufficiently so far.

Fitting and contextual solutions need to be found for this new kind of massive and spatio-temporal data to make effective visualization available. A structured approach could lie in the application of design patterns based on a cartographic rule-based approach with a visualization pipeline. The competencies of the several disciplines such as informatics, cartography, interface and interaction design is needed. Currently, there is the problem of a not existing standardized data model for XFCD. However, this is the basis for an extensive utilization of this data. Without a common model, it becomes difficult to establish an open communication of data and marketplace as platform.

Therefore, it is important to consider the security of the accruing masses of data (big data), which are generated in the vehicle and are potentially transmitted to the outside. As a minimum, the vehicle or driver specific identifying features should be removed to protect privacy. Further approaches need to be evaluated in this context. It is crucial that data is not privileged to interested industry players, e.g. automobile manufacturer or insurance companies. Instead it is necessary that the driver, as the generator of the data, is not only able to determine the utilization of data through external interested parties but also is able to gain insights in its own generated data. Here, geo-visualization is also suitable for making the information of the data legible.