A framework to stimulate innovation based on automotive data
collection
Citation for published version (APA):
Redegeld, J. (2017). A framework to stimulate innovation based on automotive data collection. Technische Universiteit Eindhoven.
Document status and date: Published: 28/09/2017 Document Version:
Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication:
• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.
• The final author version and the galley proof are versions of the publication after peer review.
• The final published version features the final layout of the paper including the volume, issue and page numbers.
Link to publication
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying the publication in the public portal.
If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:
www.tue.nl/taverne
Take down policy
If you believe that this document breaches copyright please contact us at:
openaccess@tue.nl
providing details and we will investigate your claim.
A Framework to Stimulate
Innovation Based on
Automotive Data Collection
Jeroen Redegeld November 2016
A Framework to Stimulate
Innovation Based on
Automotive Data Collection
Jeroen Redegeld November 2016
Collection
J. Redegeld
Eindhoven University of Technology Stan Ackermans Institute / Software Technology
Partners
Ministry of Infrastructure and the
Environment Eindhoven University of Technology
Steering Group Prof.dr. J.J. Lukkien Dr.ir. P.J.L. Cuijpers
Date September 2016
Document status Public
Contact Address
Eindhoven University of Technology
Department of Mathematics and Computer Science
MF 7.090, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands +31402474334
Published by Eindhoven University of Technology Stan Ackermans Institute
Printed by Eindhoven University of Technology UniversiteitsDrukkerij
SAI report no. 2016/054 Abstract
Keywords Smart mobility, ITS, IOT, ICT, Pipe and Filter Architecture, Framework, Automotive Data, Data Collection, RWS, IenM, TU/e, SAI, Software Technology, PDEng Preferred
reference A Framework to Stimulate Innovation Based on Automotive Data Collection. Eindhoven University of Technology, SAI Technical Report, November 2016. (2016/054) Partnership This project was supported by Eindhoven University of Technology and Ministry of
Infrastructure and the Environment. Disclaimer
Endorsement Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the Eindhoven University of Technology or Ministry of Infrastructure and the Environment. The views and opinions of authors expressed herein do not necessarily state or reflect those of the Eindhoven University of Technology or Ministry of Infrastructure and the Environment, and shall not be used for advertising or product endorsement purposes.
Disclaimer
Liability While every effort will be made to ensure that the information contained within this report is accurate and up to date, Eindhoven University of Technology makes no warranty, representation or undertaking whether expressed or implied, nor does it assume any legal liability, whether direct or indirect, or responsibility for the accuracy, completeness, or usefulness of any information.
Trademarks Product and company names mentioned herein may be trademarks and/or service marks of their respective owners. We use these names without any particular endorsement or with the intent to infringe the copyright of the respective owners.
Copyright Copyright © 2015. Eindhoven University of Technology. All rights reserved.
No part of the material protected by this copyright notice may be reproduced, modified, or redistributed in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the Eindhoven University of Technology and Ministry of Infrastructure and the Environment.
Foreword
Vehicles join the rapidly growing group of connected systems. Connectivity in automotive plays at three levels: networked components within a single vehicle, communication with vehicles within the immediate vicinity for safety related applications, and data collection at regional and country level, using the car as a sensor. Automotive is also a domain with a complex interplay of stakeholders. The system and software architecture of the respective systems reflects this complexity.
TU/e is executing a joint project with Rijkswaterstaat to study this development, and to propose an open architecture that admits third parties to propose new applications. The work of Jeroen fits in this project where he outlines the general architecture and subsequently zooms in on the design of the data collection framework inside the vehicle. This represents a piece of the puzzle, that involves bringing together the ongoing standardization by IEEE and ETSI and the world of smartphone applications and quick innovations.
ii
Preface
This report summarizes the results of the “A Framework to Stimulate Innovation Based on Automotive Data Collection” project, which is carried out by Jeroen Redegeld as his graduation project for the Professional Doctorate in Engineering (PDEng) degree program in Software Technology (ST). The PDEng degree program in ST is offered by Eindhoven University of Technology, Eindhoven, the Netherlands, in the context of the 4TU.School for Technological Design, Stan Ackermans institute. The project that is described in this report is part of a larger, multidisciplinary, smart mobility project that originated from a collaboration between Waterways and Public Works Agency (Rijkswaterstaat in Dutch), and Eindhoven University of Technology. A more elaborate description about the project context can be found in Chapter 1.
The goal of the project that is described in this report is to design a framework that enables collection, pre-processing, storing, and using in-vehicle generated automotive data by third party applications. Data collection and usage should be generic, transparent, and independent. The idea is that third party developers can use the framework to develop applications that require access to in-vehicle data without implementing the required low-level mechanisms that are required to gain access to this in-vehicle data. The framework does not offer functionality to end users, but is an enabling technology that simplifies development of applications that require access to in-vehicle data.
Content in this report is mostly intended for readers with a technical background. Chapter 1 contains information about the project setting and some related work. Stakeholders that are directly involved within the project are addressed in chapter 2. Chapter 3 describes the problem that needs to be solved, introduces the product stakeholders, and addresses design opportunities. Necessary domain knowledge is introduced in chapter 4. Different project variations and feasibility of the current project are addressed in chapter 5. Next, chapter 6 addresses the project requirements. Chapter 7 describes the system architecture and design, and chapter 8 addresses the implementation. Chapter 9 concerns the verification and validation of the solution, and chapter 10 describes the deployment of the current solution and the envisioned deployment. The conclusions are captured in chapter 11. Project management and retrospective are addressed in chapters 12 and 13 respectively.
It is a pleasure to work with state of the art technology in a new domain. Learning new things is an essential activity in order to keep up and contribute to the latest developments in the automotive domain. I hope that reading this report gives a clear idea about one of the many problems and opportunities that exist within the automotive domain. I certainly learned a lot during this project.
Jeroen Redegeld September 2016
iv
Acknowledgements
A project of this magnitude cannot be completed by a single person. I owe many people my gratitude for their contribution to this project. Without them I would not be able to work on this interesting project, now and in the future.
First of all, I would like to thank dr. Ad Aerts, the program director of the PDEng program in Software Technology, for accepting me for the PDEng program, and for his support and nice conversations we had during the program. Ad, thanks for everything. I would like to thank Maggy de Wert, the management assistance of the PDEng program in Software Technology, and here successor Désirée van Oorschot for all their assistance, nice conversations, and patience.
This final project did not exist without the help of prof.dr. Johan Lukkien, chair of the System Architecture and Networking group of the Department of Mathematics and Computer Science, dr.ir. Pieter Cuijpers, Assistant Professor of the System Architecture and Networking group. I would like to thank Johan for the realization of this project in combination with the possibility to continue working on this project as a PhD candidate. I also appreciate all the critical feedback and nice discussions, both on a technical and non-technical level, with both Pieter and Johan. I also want to thank Anjolein Gouma, secretary of the System Architecture and Networking group, for all here assistance.
I also want to thank everyone from the department of Industrial Engineering and Innovation Sciences for their support. prof.dr.ir. Geert Verbong and prof.dr. Hans Jeekel thank you so much for your input. I also want to thank Tanja, Darja, and Edgar, the PhD researchers that are working on the same project, for their cooperation. I also want to thank all experts, both from the university and from external parties, that helped me out during my project.
I would like to thank all my PDEng colleagues for the intensive time both in and outside office hours. Nate, thanks for helping me out with setting up and explaining Android Studio. Sarwan, thanks for the nice discussions during the many lunchbreaks we spent together during our final projects. I also want to thank Dima and Spiros my colleagues and housemates during the final project, for all the discussions we had at home.
Of course, I also want to thank all instructors that were involved in the PDEng program. Cynthia, Marloes, and Sandra, thanks for all the assistance and training in the field of professional development. Judy, thank you so much for all the assistance in the field of technical writing. Onno, thanks for your training and feedback in the field of modeling and UML. Egbert, thank you so much for your enthusiastic talks and conversations about agile design.
Last, but not least, I would like to thank my parents, Jannie and Tonnie, and brother, Dennis, for their support during my, mostly educational, career. Thank you so much for believing in me. I really appreciate it that I am able to plan my own career. Once more, thank you all for your help, patience, and assistance during this project. Jeroen Redegeld
vi
Executive Summary
A trend in the automotive industry is that more hard- and software is added to vehicles. This means that the number of sensors increased over time; hence more in-vehicle data becomes available. The increase of in-vehicle data, improvements in mobile computation power, and the availability of mobile wireless internet connections are enablers for new applications that require access to in-vehicle data.
The first step in the development of an application that requires access to in-vehicle data is accessing the required in-vehicle data. The second step that is required for most applications is to preprocess acquired data before using or storing it. Existing applications that use in-vehicle data all solve this problem in their own way.
This report describes the design and development of a framework that allow developers to share solutions to data access and preprocessing problems. By sharing solutions to the data access and preprocessing problems, development can be simplified. This potentially boosts development of applications that require access to in-vehicle data. Functionality that is useful for people that install the framework is offered in the form of plugins. A plugin is developed by a third party and contains concrete implementations that enable data access and preprocessing of data.
Data owners will install the framework and plugins of their preference. The intention is that data owners can inspect what data is used by what plugin, change data access settings, and extend functionality by installing plugins.
The framework is based on a pipe and filter architecture. Sensor data and filtered data is exchanged in the form of observable objects. An observable object uses an event based mechanism to notify registered parties about an update. The usage of plugins suggests that the framework should be third party extendable, upgradable, and flexible. The notion of data owner sharing settings suggests that the framework should be configurable, transparent, and integer. Data owner settings have to be enforced. The ability to install multiple plugins requires a robust and reliable framework that can cope with multiple plugins from different developers.
The project contains a prototype implementation of the framework. This prototype is implemented on an Android smartphone. This prototype supports the implementation of drivers to obtain access to sensor data, and the implementation of filter groups to preprocess data.
The prototype implementation should be used in the research phase that continues after this project. It is recommended to improve the implementation using the future work points listed in the conclusion chapter, chapter 11. The intention is to make the framework public, but that is not enough to convince the industry in using the framework. It is recommended to implement a use-case to demonstrate the added value of the framework. This use-case should also be used to obtain insides that are relevant for the research project.
viii
Table of Contents
Foreword ... i
Preface ... iii
Acknowledgements ... v
Executive Summary ... vii
Table of Contents ... ix
List of Figures ... xiii
List of Tables ... xv
1 Introduction ... 1
1.1 Project Context ... 1
1.2 Waterways and Public Works Agency ... 2
1.3 Eindhoven University of Technology ... 2
1.4 Related Work ... 3
1.4.1. OEM Integrated Systems ... 3
1.4.2. Aftermarket Systems ... 4
1.4.3. Observations and Framework Placement ... 7
1.5 Outline ... 8
2 Stakeholder Analysis ... 9
2.1 Waterways and Public Works Agency ... 9
2.2 Eindhoven University of Technology ... 9
2.2.1. System Architecture and Networking Group ... 9
2.2.2. Technology, Innovation and Society Group ... 10
2.2.3. Professional Doctorate in Engineering in Software Technology .. 10
3 Problem Analysis ... 11 3.1 Context ... 11 3.2 Product Stakeholders ... 11 3.3 Design Opportunities ... 17 4 Domain Analysis ... 19 4.1 Introduction ... 19
4.2 Composition of In-Vehicle Hard- and Software ... 19
4.3 Applications that Require Access to Automotive Data ... 21
x
5 Feasibility Analysis ... 23
5.1 Project Alternatives ... 23
5.1.1. Generic Data Warehouse Access Layer... 23
5.1.2. In-Vehicle Applications ... 25
5.1.3. Automotive Data Collection Framework ... 25
5.2 Issues ... 26 5.3 Risks ... 26 6 System Requirements ... 27 6.1 Definition of a Framework ... 27 6.2 Framework Functionality ... 27 6.3 Functional Requirements ... 28
6.3.1. Third Party Extendibility, Upgradability, and Flexibility ... 29
6.3.2. Configurability, Transparency, and Traceability ... 29
6.3.3. Installability and Portability ... 29
6.4 Non-Functional Requirements ... 29
6.4.1. Security, Safety, and Integrity ... 29
6.4.2. Robustness and Reliability ... 29
7 System Architecture and Design ... 31
7.1 Used Development Methods and Tools ... 31
7.2 Logical View ... 31 7.2.1. Domain Analysis ... 31 7.2.2. Software Design ... 32 7.3 Process View ... 36 7.3.1. Sensor Behavior ... 36 7.3.2. Filter Behavior ... 37 7.3.3. Namespace Behavior ... 42 7.3.4. Storage Behavior ... 42 7.4 Development View ... 47 7.5 Physical View ... 47 8 Implementation ... 49 8.1 Introduction ... 49
8.2 Motivation for Using the Android Platform ... 49
8.3 Data Collection and Storage ... 51
9 Verification and Validation ... 55
9.1 Validation ... 55
9.1.2. Data User ... 55 9.2 Verification ... 56 10 Deployment ... 59 10.1 Current Deployment ... 59 10.2 Envisioned Deployment ... 60 11 Conclusions ... 63 11.1 Results ... 63 11.2 Future Work ... 63 12 Project Management ... 67 12.1 Introduction ... 67 12.2 Work-Breakdown Structure (WBS) ... 67 12.3 Project Planning ... 68 12.4 Project Executing ... 68 13 Project Retrospective ... 71 13.1 Project Reflection ... 71 13.1.1. Required Knowledge ... 71 13.1.2. Project Management ... 71
13.2 Design Opportunities Revisited ... 72
Bibliography ... 73
Appendix A. Software Design ... 75
Appendix B. Accessibility ... 79
xii
List of Figures
Figure 1 – Placement Overview of Educational Programs [1] ... 1
Figure 2 – Frontview of the Female A-Type and B-Type J1962 DLCs ... 5
Figure 3 – Picture of an A-Type J1962 DLC ... 5
Figure 4 – Wireless OBD2 Modules ... 6
Figure 5 – Stakeholders Withing the Data Domain ... 12
Figure 6 – Stakeholders Withing the Framework Design ... 13
Figure 7 - Conceptual View of In-Vehicle Systems ... 20
Figure 8 - Suitable Communication Options per Application Category ... 22
Figure 9 – Deployment of Applications in the Automotive Context ... 23
Figure 10 – Generic Database Access Layer ... 24
Figure 11 – High Level Use-Cases Diagram ... 28
Figure 12 – Domain Analysis Diagram ... 32
Figure 13 – Pipe and Filiter Framework Concept ... 33
Figure 14 – Pipe and Filters Concept with Security Layers ... 33
Figure 15 – Abstract Class Diagram of the Framework ... 35
Figure 16 – Sequence Diagram of a Sensor that is Polled ... 38
Figure 17 – Sequence Diagram of a Sensor that Periodically Pushes Data ... 39
Figure 18 – Sequence Diagram of a Sensor that Pushes Data After an Event ... 40
Figure 19 – Sequence Diagram of a Filter ... 41
Figure 20 – Sequence Diagram of the Initialization of the SensorCollection where the SensorCollection Creates Sensor Objects ... 43
Figure 21 –Sequence Diagram of the Initialization of the SensorCollection where the Driver Creates Sensor Objects ... 44
Figure 22 – Sequence Diagram of a Filter that Invokes a StorageInterface ... 45
Figure 23 – Sequence Diagram of a StorageInterface that Moves Data to LocalStorage ... 45
Figure 24 – State Machine of the Upload Strategy of the StorageInterface ... 46
Figure 25 – State Machine of the Database Cleaning Strategy ... 47
Figure 26 – Class Diagram of the StorageAdapter ... 48
Figure 27 – Global Usages of Smartphone Operating Systems ... 50
Figure 28 –Usages of Smartphone Operating Systems within Europe ... 50
Figure 29 – Usages of Smartphone Operating Systems within the Netherlands ... 51
Figure 30 –ThinkSpeak Server Page Showing Received Data Over Time... 52
Figure 31 – ThinkSpeak Server Page Showing the Last Received Value ... 52
Figure 32 – First Sensor and Filter Implementation of the Andrion App ... 53
Figure 33 – Data Sharing Settings and Service Test of the Android App ... 53
Figure 34 – Android Coordinate System Relative to the Phone ... 53
xiv
Figure 36 – Liniar Accelerometer Sensor and Absolute Force Filter that are
Implemented in the Android App ... 54
Figure 37 – Deployment Diagram of the Current Prototype Implementation ... 59
Figure 38 – Deployment Diagram of the Envisioned Improvements ... 61
Figure 39 – Work-Breakdown Structure of the Automotiva Data Collection Project 67 Figure 40 – List of Important Data ... 69
Figure 41 – Initial Project Grantt Chart ... 70
Figure 42 – Class Diagram Implemented Framework ... 75
List of Tables
Table 1 – System Architecture and Networking Group Stakeholders ... 9 Table 2 – Technology, Innovation and Society Group Stakeholders ... 10 Table 3 – Professional Doctorate in Engineering in Software Technology Stakeholder
... 10 Table 4 – Stakeholder Analysis of the Data Owner ... 14 Table 5 – Stakeholder Analysis of the OEM Supported Data Interface ... 14 Table 6 – Stakeholder Analysis of the Aftermarket Data Interface ... 15 Table 7 – Stakeholder Analysis of the Preprocessing Filter ... 15 Table 8 – Stakeholder Analysis of the Storage Interface ... 16 Table 9 – Stakeholder Analysis of the Framework Designer (TU/e) ... 16 Table 10 – Data Access Methods Comparison ... 22 Table 11 – Accessibility Modifiers ... 79
xvi
1 Introduction
In this very first chapter, the project, its context, and the project environment are described. The two parties that are involved in this project are introduced in more detail. A short overview of related work is given, and the final section described the remainder of the report.
1.1
Project Context
In the final nine months of his Professional Doctorate in Engineering (PDEng) degree program in Software Technology, Jeroen Redegeld worked on the “A Framework to Stimulate Innovation Based on Automotive Data Collection” project.
The PDEng degree program in Software Technology is offered by the department of Mathematics and Computer Science of Eindhoven University of Technology (TU/e). This program is provided in the context of the 4TU.School for Technological Design, Stan Ackermans institute, which is a joint initiative of the four universities of technology in the Netherlands (TU Delft, Eindhoven University of Technology, University of Twente, and University of Wageningen).
The PDEng program is an accredited two-year, third-cycle (doctorate-level) engineering degree program. The program focusses on the development of both technical and non-technical competences required to develop software intensive systems in an industrial setting. A project based design and development approach is chosen to simulate an industrial setting. PDEng trainees are encouraged to use latest research results in an enterprise setting. The placement of the PDEng degree among other degrees is graphically shown in Figure 1 [1]. More information about the different PDEng degrees can be found in [2] and [3]. Information about the 4TU.School for Technological Design and the Stan Ackermans institute can be found in [3]. sci en ce (f u n d amen tal) / res earch
engineering (applied) / design
comp reh e n si ve u n ive rsiti e s BSc MSc PhD PhD MSc BSc Professional Bachelor
HBO; Fachhochschule; Polytechnics
4yr 3yr 0,5 – 1 yr 2yr 2yr 4yr PDEng Professional Doctorate in Engineering design oriented Academic Engineer 4yr 2yr 3yr 2,5 - 3yr PhD
Figure 1 – Placement Overview of Educational Programs [1]
The PDEng project that is described in this report is part of a larger project in the area of Smart Mobility that holds four PhD positions. Smart mobility covers development of mobility solutions in the areas of vehicle technologies, Intelligent Transport Systems (ITS), data handling strategies, and mobility services [4]. The realization of the four PhD positions is the result of a cooperation between Waterways and Public Works Agency, or in Dutch Rijkswaterstaat (RWS), and Eindhoven University of Technology.
2
The first PhD project focuses on different users of Smart Mobility and their wishes and needs. This also includes identification of undesirable aspects. The second PhD position focuses on the governance of Smart Mobility. Governance includes access and usage of data, and legislation and liability in the Smart Mobility context. The analysis of historical experiments is the topic of the third PhD position. Insight in tools and techniques should boost the development of Smart Mobility. Collection, processing, storing, and securing data in a Smart mobility setting is the topic of the last PhD position.
One of the goals of this research project is the development of a revolutionary design and supporting architecture that can cope with large amounts of data in a real-time and flexible setting. The PDEng project is part of this last PhD position, and the intention is that Jeroen Redegeld continues as a PhD researcher where he uses the obtained results from this PDEng project.
1.2
Waterways and Public Works Agency
Waterways and Public Works Agency (RWS) is a governmental agency within the Netherlands. RWS is responsible for the design, construction, management, and maintenance of the main infrastructure facilities in the Netherlands. The main infrastructure facilities consist of the main road system, the main waterway network and the main water systems. RWS is part of the Dutch Ministry of Infrastructure and the Environment, or in Dutch het Ministerie van Infrastructuur en Milieu (IenM). The Smart Mobility program is related to the main road system, so focus is placed on describing the activities of RWS that are part of the activities that are connected to the main road system.
As part of the government, RWS is responsible to maintain public order and safety on the main infrastructure facilities in the Netherlands. RWS aims to guide and inform traffic in an optimal way to improve traffic flow, lower traffic jams, reduce the emission of hazardous substances, and improve safety. Real- time traffic management and maintenance are important aspects to achieve those goals.
Traffic managers use real-time feeds from various systems that are installed along the road site such as measurement loops and cameras. Additional information such as road constructions, planned events, traffic jams, incident reports, and status of bridges are also used in this process. Road users are informed by means of different systems such as radio broadcasts, digital broadcasts such as Traffic Message Channel (TMC), internet pages and online route planners, mobile applications, and matrix signs along the road. When needed, RWS has the ability to impose restrictions such as a limited speed, closing a traffic lane, and limit the number of vehicles that enter a highway section by using a slip road filtering system (toerit doseer installatie in Dutch). RWS is interested in the developments made in the area of Intelligent Transport Systems (ITS) – the use of Information and Communication Technologies (ICT) in the field of mobility – to improve mobility in the Netherlands. Newly developed ITS can improve the utilization of the current road network, improve safety of road users, reduce emissions of hazardous substances, and reduce energy consumption such as fuel and electricity consumption. RWS can use information collected by ITS for real-time traffic management and planning road maintenance. Development of new ITS could lead to the introduction of new roadside systems making existing expensive systems used to gather data obsolete. This information is vital for RWS since construction, installation, management, and maintenance of those roadside systems is one of the many tasks of RWS.
1.3
Eindhoven University of Technology
The PDEng program in Software Technology, the System Architecture and Networking (SAN) group, and the Technology, Innovation and Society (TIS) group, all part of Eindhoven University of Technology, are involved in this project.
The PDEng program in Software Technology is introduced in the previous section. For the PDEng program, this project is used to confirm that the trainee has the necessary skills to obtain the PDEng degree in Software Technology. This means that the trainee has to show both technical and non-technical competences that are required to complete the project within the available time.
The PhD position that focusses on the data aspects in a Smart Mobility context is a project within the System Architecture and Networking (SAN) group. The SAN group focusses on studding parallel and distributed systems with resource restrictions such as embedded systems. The SAN group is one of the two groups within the section Security and Embedded Network Systems (SENS), a research program. The SENS research program is part of the department of Mathematics and Computer Science of Eindhoven University of Technology. Knowledge and insights gained from the PDEng and PhD projects are important for the SAN group and should lead to publications. The other three PhD projects that were described in the first section are part of the Technology, Innovation and Society (TIS) group. The TIS group is part of the faculty of Industrial Engineering and Innovation Science of the TU/e
1.4
Related Work
In most systems, data access is an integrated part of a solution or product that is sold. Hard- and software that is required to access in-vehicle data is either installed during manufacturing of the vehicle, or in an aftermarket setting. The next two subsections give an overview of existing systems, and in the third subsection summarizes observations and tries to place the current project with respect of related work.
1.4.1. OEM Integrated Systems
In modern, mostly high-end cars, it is a trend to include a data collection and sharing module. OEMs (Original Equipment Manufacturer) use this technique to access data that allows them to analyze the usage of vehicles developed by them, and to offer extra services to their customers. The OEM is responsible for the integration of the required hard- and software.
Ownership of data in this context is a hot topic. Various parties such as the OEM, the vehicle owner, and the vehicle driver claim that they are the owner of the generated data. In this model, the OEM determines what data is collected, how this data is stored and processed, and whom can access this data. In most cases, this means that data is not accessible by others since the OEM claims ownership of the collected data. An example of a company that mainly focuses on solutions for automotive manufacturers is CloudMade. CloudMade offers various products and services related to artificial intelligence and contextual awareness such as predictive learning of driver preferences, integration with ADAS, and personalized search results.
Predictive learning requires the installation of dedicated hardware components within a vehicle. Those components are used to make decisions and recommendations, and to collect the required in-vehicle data. A bidirectional secure connection between the car and a cloud is used to make in-vehicle data available to the cloud, and to upload results to the vehicle. The cloud solution uses data analytics to analysis data gathered from multiple vehicles. Settings allow users to configure the behavior of the system in order to meet different privacy requirements. An example application is to plot vehicle specific data on a geographical map in order to provide Customer Relationship Management (CRM) related features such as roadside assistance.
Another service that is offered by Cloudmade, is combining data from different decentralized content providers. Required data to answer a single query is obtained from different sources. For example, the location of the most suitable restaurant in the area is based on a database with restaurants in the neighborhood, restaurant reviews from the general audience, restaurant reviews from friends that are shared via social media, and on the personal preference.
4
Vehicle manufacturers can integrate the various services offered by Cloudmade in a Human Machine Interface (HMI). Support and SDKs exist for the following platforms: Linux, Android, QNX, WinCE, Windows Phone, iOS, and Mac OSX.
The offered solutions minimize data and maintenance costs related to transferring, storing, and processing data. The claim of CloudMade is that customer data is treated in a secure way. Some systems can be deployed on a private cloud.
It is not clear what information is used and stored in the cloud by Cloudmade, and whom is the owner of the stored data. There is no notion of third party plugins that can access collected data. Privacy settings are available, but I have the impression that those settings are only available to the automotive manufacturers. This means that automotive manufacturers determine if end users can influence privacy settings. Information related to CloudMade is based on [5].
1.4.2. Aftermarket Systems
In an aftermarket setting, the installation of required data collection hard- and software takes place after manufacturing of the target vehicle. Vehicle manufacturers are typically not involved in the development process of aftermarket systems.
There are two strategies to obtain required in-vehicle data. The first method, the integrated aftermarket system, uses data that is generated by the vehicle itself. The second method, the standalone aftermarket system, uses own sensors to measure required parameters. Both versions are addressed below.
Integrated Aftermarket Systems
An integrated aftermarket system requires data exchange between the host vehicle and the aftermarket system. Most aftermarket solutions use a generic, standardized interface to obtain in-vehicle information. In that way, the developed hardware is not specifically design for a single vehicle type or brand.
All cars sold in the United States have to adhere to the On-Board Diagnostics version two (OBD2) specification starting from 1996. The OBD2 specification is mandatory within the European Union for all gasoline cars from 2001 and for all diesel cars from 2003. The OBD2 specification is explained below.
Using the OBD2 port and its protocols is the most promising way for an aftermarket system since all modern cars are equipped with the OBD2 standards. There are still a lot of differences in exchanged messages between vehicle make, model and even year. The reason is that the OBD2 standards introduced by the Society of Automotive Engineers (SAE) and International Organization for Standardization (ISO) were developed to reduce emissions. The initial intention of the OBD2 standards is to monitor emissions and provide a way to diagnose engine problems. Employed protocols are not designed to monitor various sensors. Most, if not all, OEMs extended existing standards with their own set of messages for advanced diagnoses. A consequence is that those extensions are not standardized.
The OBD2 standard specifies two female Diagnostic Link Connectors (DLC) – a physical interface used to interact with in-vehicle systems – and its pinout. The SAE J1962 standard specifies both DLCs. Both DLCs contain 16 pins, seven pins have a standardized function and two pins are used to power connected devices. The remaining seven pins are not used in the OBD2 standards, and manufacturers are free to use them. The difference in the two specified connectors is that the A-type connector is used in vehicles with a 12 volts system voltage, and the B-type connector is used in vehicles with a 24 volts system voltage. Figure 2 shows drawings of the female A-type and B-type J1962 DLC, and Figure 3 shows a picture of an A-type J1962 DLC. Both pictures show the DLC that is installed in the vehicle. The DLC is located on the inside of the vehicle within 0.61 meter (2 feet) of the steering wheel.
Figure 2 – Frontview of the Female A-Type and B-Type J1962 DLCs
Figure 3 – Picture of an A-Type J1962 DLC
The OBD2 standard specifies the following five signaling protocols that all use the DLC:
SAE J1850 PWM
Uses a Pulse Width Modulation (PWM) signal, which runs at 41.6 kbps. SAE J1850 VPW
Uses a Variable Pulse Width signal, which runs at 10.4 kbps. ISO 9141-2
Uses asynchronous serial communication, which runs at 10.4 kbps. ISO 14230-4
The Keyword Protocol 2000 (KWP2000) is an asynchronous serial communication protocol, which runs at10.4 kbps.
ISO 15765-4/SAE J2480
A CAN (Controller Area Network) communication protocol that has four variants:
o 11 bit identifier, 500 kbps o 29 bit identifier, 500 kbps o 11 bit identifier, 250 kbps o 29 bit identifier, 250 kbps
The OBD2 standard specifies Diagnostic Trouble Codes (DTC) used to monitor functions in the powertrain, chassis, body, and other codes that do not fall in the mentioned categories. The intended use of DTC is that technicians use the provided information to diagnose vehicle subsystems. Most specified DTCs are related to the powertrain. Powertrain systems are responsible for the propulsion of the vehicle, such as the engine and transmission. Chassis systems are related to active safety, driving dynamics, and assistance, such as ABS (Antilock Braking System) and ESP (Electronic Stability Program) [6]. Body systems implement functionality that offers body and comfort functions to the users of the vehicle, such as climate control, window wipers, lights, mirrors, locks, and Cruise Control (CC) [6].
The OBD2 specification only specifies a limited set of standards that can be used to obtain in-vehicle information. In most vehicles more information can be obtained, but the protocols used to obtain that information are OEM specific.
Various OBD2 interface cables and modules exist. A module that transmits and receives data via a wireless link, such as Bluetooth or Wi-Fi, is mostly used to capture data during driving. A dedicated application is installed on a smartphone or tablet. The app uses the data from the OBD2 module to display vehicle information. Some applications implement data logging functionality in order to generate graphs of logged
6
data. Examples of those kind of applications are Torque Light1, Torque Pro2,
DashCommand3, and Engine Link4. The applications do not offer a way to preprocess
and share gathered data.
Wireless OBD2 dongles mostly contain a multiprotocol OBD interpreter IC (Integrated Circuit) that implement the five OBD2 data protocols. Popular multiprotocol OBD interpreter ICs are the ELM327 and the STN11x0 series. Most interpreter ICs have UART (Universal Asynchronous Receiver/Transmitter) port that is used to set parameters and receive decoded OBD2 data. A UART port is an asynchronous serial communication port that can be connected to a microcontroller or, with some minimal hardware, to a computer. Figure 4 shows an example of an OBD2 to Wi-Fi adapter (left) and an OBD2 to Bluetooth adapter (right).
Figure 4 – Wireless OBD2 Modules
Standalone Aftermarket Systems
A standalone solution does not use data that is generated by the host vehicle. Dedicated sensors provide required data. The host vehicle is optionally used to power required hardware.
A good example of a standalone aftermarket system is a navigation systems running on a dedicated navigation device or on a smartphone. A navigation system contains a GPS receiver that provides location information. This GPS information is translated to a location, heading, and speed. Map data and additional Points of Interest (POI) are offline available, or downloaded on demand by using a mobile internet connection. Some navigation solution also collect statistics from users to improve their services for other users. For example, average speed information might be collected to improve predicted travel time for other users.
Another example application that uses a standalone aftermarket module is the car insurance offered by the ANWB (Algemene Nederlandse Wielrijdersbond, the Royal Dutch Touring Club). In-vehicle data is used to analyze the driving style of a driver.
1 See https://play.google.com/store/apps/details?id=org.prowl.torquefree 2 See https://play.google.com/store/apps/details?id=org.prowl.torque 3 See http://www.palmerperformance.com/products/dashcommand/ 4 See http://www.outdoor-apps.com/
Drivers receive feedback on their driving style in order to adopt a safer driving style. Safe drivers are rewarded with a discount on the car insurance. Collected data is also used for other purposes. The mentioned example is the detection of dangerous traffic situations.
Insured cars are equipped with an OBD2 module with integrated sensors and SIM module. The OBD2 connection is only used to power the module, so no data is obtained via the OBD2 connection. The integrated sensors measure GPS location, G-force, and timestamp information that is preprocessed by the module. The SIM module is used to establish a wireless data connection to upload the preprocessed data to a server that is maintained by the insurance company.
Drivers receive personal feedback every 10 days. Personal feedback is accessible by an online profile and app (Android and iOS). The insurance company analyses the collected data to generate feedback and to calculate insurance discount. The insurance company checks if you are not exceeding the maximum allowed speed, if you brake and accelerate in a fluent way, and if you take corners in a controlled way.
Drivers remain owner of the collected data, and can submit a request to get access to their data. Anonymized data – data that cannot be traced back to a person - is also used for statistical analysis. After canceling the insurance contract, a driver can submit a request to delete their data. Information about this insurance is based on [7].
Similar insurance constructions also exits outside the Netherlands. For instance, the Snapshot insurance policy that is offered by the insurance company progressive5 offers
a similar insurance policy.
1.4.3. Observations and Framework Placement
The first subsection lists the observations that are based on the discussion of existing systems. The second subsection reflects upon those observations and places the framework design in context with existing systems.
Observations in Existing Systems
For most applications, accessing in-vehicle data is just a sub problem that is part of the total application. This holds for both OEM integrated systems and aftermarket systems. The implemented solution is optimized for the specific application that requires access to in-vehicle data. Different sensors with dedicated drivers are used. The driver converts the sensor specific information to an information stream that is compatible with the application. This approach leads to different sensor types, different driver implementations, and different data types.
The next step, after accessing in-vehicle data, is to preprocess this data before it can be used, e.g., uploading or visualizing this processed data. It is common to preprocess data directly after collecting it. One of the reasons is bandwidth and storage limitations.
Placement of the Framework
The framework is an abstraction layer between sensor hardware and applications that require access to in-vehicle data. This means that the framework is middleware that does not offer end user functionality out of the box. The aim of the framework is to provide easy access to in-vehicle data and offer a convenient data preprocess flow while maintaining a transparent view on data sharing settings. The power of the framework is to share and reuse partial solutions in the data accessing and processing problem.
8
End user functionality is obtained by installing plugins that contain drivers, preprocessing algorithms, upload drivers for storage facilities, and links to other applications. No single driver or algorithm solution exists, so developers need to provide an implementation. The intention of the framework is to enable sharing of those components between different parties. This also enables adding data from future sensors without redesigning the framework. Sharing data also means the option of configuring and enforcing sharing settings of the various data elements.
Developers use the framework to simplify the processes required to obtain access to in-vehicle data. Partial solutions that exist can be reused. For instance, access to sensor data can be shard. This requires only one dedicated driver that converts the sensor data into a generic data format that can be used by multiple developers. Preprocessed data is than stored in an external data storage solution and/or used in other applications. The idea is that the framework simplifies development of innovative applications that require access to in-vehicle data. The long-term goal is to boost development of applications that require access to in-vehicle data by simplifying the data access and preprocess steps that are required.
Users that install the framework application do so because it offers a clear view on their privacy and sharing settings. Furthermore, functionality can be easily installed, updated, and removed by means of the framework.
1.5
Outline
Chapter two addresses the stakeholders that are directly involved in the project. In the next chapter, the problem is introduced and the stakeholders of the framework, the product stakeholders, are addressed. Note that the product stakeholders of this project are not the same as the project stakeholders. The last section of chapter three gives an overview of the design opportunities within this project. Chapter four provides relevant domain knowledge that is used during the realization of the framework design. The next chapter contains an overview of project alternatives and a feasibility analysis of the various project forms. Chapter five concludes with an analysis of the possible issues and risks of the selected project. Both functional and non-functional system requirements are addressed in chapter six. The system architecture and design is addressed in chapter seven. This chapter contains the logical view, the process view, development view, and the physical view of the framework. Chapter eight is devoted to the implementation. Next, chapter nine discusses the verification and validation of the implemented framework by using the requirements of chapter six. Information about the current deployment diagram and the future envisioned deployment diagram are addressed in chapter ten. Project conclusions are listed in chapter eleven including a list of future work. The final chapters, chapter twelve and thirteen, are devoted to project management and project retrospective respectively.
2 Stakeholder Analysis
The previous chapter introduced Rijkswaterstaat and Eindhoven University of Technology as project partners. In this chapter the goals, intentions, and interests of both the institutes and specific project stakeholders is described. The generic nature of the developed product does not limit the usage to the project partners only, so product stakeholders are separately addressed in 3.2.
2.1
Waterways and Public Works Agency
The motivation for RWS to invest in the development of ITS, as explained in the previous chapter, is that new systems can help to improve mobility in the Netherlands. The framework that is developed as part of the PDEng project is an enabler for applications that improve mobility and will be used during the PhD research. Hence, this framework does not implement any functionality. RWS is informed about the development of the framework. Involvement of RWS is desirable on a use-case level that provides a proof of concept of the framework.
RWS is involved in a higher level management that involves all four PhD positions. Supervision is arranged at two levels by a steering group and a core group. Steering group meetings are planned one or two times a year whereas core group meetings are scheduled three to four times a year. The steering group guards the overall progress, quality and usability of the delivered work. Focus of the core group is more on the contents level where inspiration and deepening of the projects contents is addressed. Both groups also focuses on establishing contacts with relevant persons or parties such as domain experts. Members of the TU/e are present in both groups including the PDEng project owner and project supervisor.
2.2
Eindhoven University of Technology
The PDEng project is owned and supervised by the SAN group and involves stakeholders from the TIS group and from the PDEng in Software Technology program.
2.2.1. System Architecture and Networking Group
The SAN group represents the project owner in this PDEng project since the PhD project is part of the SAN group. Table 1 shows an overview of the stakeholders within the SAN group. Both the project owner and supervisor assist on a content level. The main concern of the project owner is that obtained results are usable. The project supervisor is more concerned about the process.
Table 1 – System Architecture and Networking Group Stakeholders
Stakeholder Role
Prof.dr. J.J. Lukkien Project owner
Dr.ir. P.J.L. Cuijpers Project supervisor
The university is not interested in solving a single problem. A single problem is used to get an understanding of the problem domain and to test a proposed solution. The proposed solution should be applicable for a collection of similar problems. The aim is to develop a method, a data collection framework that stimulates development of applications that require access to in-vehicle data. The proposed framework is considered to be an enabling technology that opens access to in-vehicle data in a transparent and flexible way.
10
2.2.2. Technology, Innovation and Society Group
The people from the TIS group that are involved in the research question, how to collect and store data, consists of the three cooperating PhD positions, and two professors. Table 2 shows an overview of the persons that are involved.
Table 2 – Technology, Innovation and Society Group Stakeholders
Stakeholder Role
Prof.dr.ir. G.P.J. Verbong TU/e professor
Prof.dr. J.F. Jeekel TU/e professor and RWS contact T.N. Manders MSc PhD, Smart Mobility experiments
D. Vrscaj MSc PhD, users of Smart Mobility
E. Salas Girones PhD, governance of Smart Mobility
2.2.3. Professional Doctorate in Engineering in Software
Technology
The goal of the PDEng program in Software Technology is to deliver well-trained and skilled software engineers that can operate in an industrial setting. To do so, the program director (Table 3) monitors progress of the trainees during their final project.
Table 3 – Professional Doctorate in Engineering in Software Technology Stakeholder
Stakeholder Role
Dr. A.T.M. Aerts Program director
3 Problem Analysis
Now the project environment and project stakeholders are known, it is time to focus on the actual problem. The first section of this chapter introduces the problem that needs to be solved. This is done by looking at some parties that are involved in Dutch mobility. Next an overview of different product stakeholders is given. The final section of this chapter addresses the identified design opportunities related to the framework.
3.1
Context
Mobility has a prominent place within the Dutch society. At the beginning of 2015, the total population in the Netherlands just exceeded 16.9 million [8]. At that same time the number of registered passenger cars in the Netherlands was close to 8.0 million [9]. Historical data shows that passenger cars are responsible for the largest fraction of the total distance traveled in the Netherlands. An estimated 104.2 billion kilometers was traveled by car in 2015 within the Netherlands. That is 78.4 percent of the total estimated 132.9 billion kilometers traveled within the Netherlands in 2015. Figures presented in this paragraph are based on [10].
Another important group of road users are freight carriers. This is one of the largest sectors in the Netherlands, providing 750 thousand jobs and 8.5% of the Gross Domestic Product (GDP) in the Netherlands [11].
Road maintenance and real-time traffic management are important tasks of RWS to keep the traffic flowing. This involves acquiring information about the current road condition and inform road users about changes. Currently information is acquired by means of various roadside units such as cameras and induction detection loops in the road. Traffic participants are informed about road conditions by means of various dynamic signs such as variable speed signs and matrix signs.
Different road users and road owners have different interests that might overlap when it comes to development of new technologies. Road owners such as RWS are interested in the condition of the road. For example rutting figures when planning road maintenance and traction figures when temperatures reach freezing point to support winter services. Road users can also benefit from traction information in the form of a warning. Heavily loaded trucks consume more fuel when frequently decelerating and accelerating, so the freight industry might benefit from an application that minimizes speed fluctuations.
The trend in the automotive world is to introduce more hard- and software systems that digitalize information related to the vehicle. One of the first steps in the development of application that require access to this data is accessing this data. A framework that offers connectivity to in-vehicle data could open up development of in-vehicle applications. A framework could support multiple in-vehicle applications in order to share the common infrastructure that is required to obtain access to in-vehicle data. Transparency towards end users that install applications that require access to in-vehicle data is crucial in the acceptance phase.
A framework allows development of application for different vehicle users and for road owners. Furthermore, vehicle specific issues can be converted to a standard representation in order to integrate the framework, required hardware, and applications that use the framework in a vehicle. Within the TU/e the framework is used during research of various data related aspects within the automotive context.
3.2
Product Stakeholders
The stakeholder analysis in this section focuses on the stakeholders of the framework. Since a framework targets more than only the directly involved stakeholders, the term product stakeholders is used to indicate the larger, and more abstract group of involved stakeholders.
12
Listing the stakeholders of the framework turned out to be challenging because of the abstract nature of the different stakeholders. In more concrete projects it is possible to interact with stakeholders or a representative selection of stakeholders. A stakeholder analysis on an abstract group of stakeholders makes this process more complicated or even impossible. A more thorough stakeholder analysis will be part of a book chapter contribution that will appear after finalizing this PDEng project.
A strategy is to interview concrete stakeholders. The main risk is that the set of derived requirements is biased because concrete stakeholders relate the framework to their concrete use-cases. Interviewing more stakeholders is a way to lower this risk. A challenge is to find enough stakeholders that want to participate and to determine when the sample set is representative. Another challenge is the time that is required to interview stakeholders, analyses wishes and concerns, and compile a balanced set of requirements.
Figure 5 – Stakeholders Withing the Data Domain
The stakeholder analysis strategy used is to identify various abstract stakeholders that form groups to avoid replication. Figure 5 shows identified stakeholders and their relation to the vehicle and vehicle data. Note that this diagram is not UML compliant. The upper part of Figure 5 shows actors that are in the data production chain. They are responsible for the data generation process by direct interaction with the vehicle. The lower part of Figure 5 shows actors that want to access this data. Note that there is a subtle difference between the data producers and data users. The data producers interact with the complete vehicle whereas data users are only interested in the data
class Data Stakeholders Data Producers Vehicle Data Data Users Driver OEM Passenger
Vehicle Owner Vehicle User
Local Application Remote Application Data Owner * 1 * * 1 * permission * * * * * 1 * *
that is part of the vehicle. A concrete stakeholder could be related to multiple actor roles.
The tricky part is the ownership of the data. Different stakeholders have conflicting views on ownership. Generalization of data ownership is used to avoid specifying requirements and concerns for every possible concrete data owner. The non-normative usage of the specialization relation between the data producer’s package and the data owner actor captures this strategy.
During the development of the framework, an iterative approach is used for the stakeholder analysis of the abstract groups. This means that the chosen architecture is also used in the stakeholder analysis process. Figure 6 shows a high level stakeholder overview that maps various actors to the pipes and filtered design that will be presented in chapters seven and eight. This diagram is used to identify relevant stakeholders within the data harvesting process.
Figure 6 – Stakeholders Withing the Framework Design
Figure 6 shows that both locally and remotely deployed applications require access to data and filters that implement preprocessing algorithms. In case of a remote application, information is stored in a storage solution. When an application that is deployed in the vehicle that is subject to data collection, an API is used to access this data. Note that an application might implement both a local and remote subsystems. On the next pages, contain tables with goals and related requirements and concerns and related threads of the following stakeholders:
Data owner (Table 4)
Driver that interacts with the data producing component, e.g., a sensor o OEM driver developer (Table 5)
o Aftermarket driver developer (Table 6)
Filter that implements a preprocessing algorithm (Table 7) Storage Interface that enables external connectivity (Table 8) Framework designer (TU/e) (Table 9)
class Framework Stakeholders
Data Users Developers Framework Filter Storage Driver API Sensor Driver Data Data Owner Local Application Remote Application Privacy Settings Filter Developer Driver Developer Storage Developer Framework Legend Framework Developer * 1 * * 1 * permission * * * 1 * * * 1 * 1 * 1 * * * * * * * 1
14
Table 4 – Stakeholder Analysis of the Data Owner
Goal Requirements
Transparency/ Configurability
Understand what sharing settings mean Inspect data sharing settings at all time Update data sharing settings at all time Traceability Inspect which data is accessed by whom Inspect when data is accessed Flexibility
Install/add new functionality at any given time Remove unused functionality at any given time
Update existing functionality at any given time (given that an update is available)
Usability Get something in return for sharing data, e.g., alternative route suggestions, traffic status information or discount
Concern Threats
Liability Sharing specific data is mandatory by law
Security Sharing settings are violated Privacy is violated, e.g., due to hacking or eavesdropping Robustness External parties that do not respect the interfaces introduce unforeseen conditions that influence other systems
Table 5 – Stakeholder Analysis of the OEM Supported Data Interface
Goal Requirements
Reliability/ Robustness
Data interface is stable (specification does not change) Data interface is foolproof (cannot be used for unintended purposes)
Extendibility/
Upgradability Being able to respond to fast market changes Offer new functionality and security updates
Usability Data interface is considered to be added value, e.g., including the data interface is mentioned in the brochure
Concern Threats
Safety Unauthorized access to non-shared vehicle data Unauthorized access to vehicle functionality Standard Compliant
Interface is not used because interfacing is cumbersome Interface is not used because it does not work with standard solutions (interface does not comply to data sharing standard)
Liability Sharing data is mandatory by law
Table 6 – Stakeholder Analysis of the Aftermarket Data Interface
Goal Requirements
Usability/
Attractiveness Can be used in most/all vehicles, e.g., use an existing interface to acquire data such as the OBD port Installability Easy to install in an aftermarket setting, preferably without professional help Flexibility/
Upgradability/ Extendibility
Update software to add new functionality Update software to support new vehicles
Update software to solve compatibility issues, e.g., after an OEM updates their software
Update software to fix bugs or issues Configurability Change vehicle specific settings
Concern Threats
Liability OEM claim after an accident or malfunction Usability Changes after installing an OEM issued update Security Unauthorized data access such as eavesdropping Standard Compliant
Interface is not used because interfacing is cumbersome Interface is not used because it does not work with standard solutions (interface does not comply to data sharing standard)
Table 7 – Stakeholder Analysis of the Preprocessing Filter
Goal Requirements
Throughput/
Responsiveness Required resources and response time requirements are realistic Reliability/Integrity Produced result is correct, i.e., implementation matches the algorithm specification Tractability Possibility to store input data metrics Inspect whom access output data
Inspect when output data is accessed
Configurability Use algorithm parameters that can be changed by users Upgradability/
Maintainability Update algorithm implementations
Concern Threats
Security Reverse engineering of algorithms by competitors
Usability Required input data is not available Insufficient resources available, e.g., memory or CPU time Liability Claim after malfunctioning algorithm
16
Table 8 – Stakeholder Analysis of the Storage Interface
Goal Requirements
Usability
Storage interface is compatible with the targeted storage solution, e.g., uses a data sharing standard
Sharing status is visible to users, e.g., the use is informed when data cannot be shared with a server
Configurability Users can restrict network access, e.g., data limit
Concern Threats
Security Unauthorized data access such as eavesdropping Security leaks in used security solutions such as encryption
Reliability/ Robustness
Loss of data, e.g., due to a network failure, server failure, or equipment reboot
Table 9 – Stakeholder Analysis of the Framework Designer (TU/e)
Goal Requirements
Usability Offer a general solution that can be used of (almost) all use-cases that require access to in-vehicle data
Third party extendable
Offer a structured way to enable the following: Make sensor data available
Preprocess data Store data
Use data in other locally deployed applications Attractiveness /
Installability
Installing new functionality should be easily possible Updating new functionality should be easily possible Removing installed functionality should be easily possible Transparency Users have to be able to view sharing settings Users have to be able to change sharing settings
Reliability/
Robustness Support of concurrent plugins without influencing each other Integrity Privacy settings are enforced upon third party plugins
Connectivity
Different data sources can be connected
Other applications can get access to data (when this is allowed by the user)
Storing data is possible (when this is allowed by the user), e.g., via a mobile internet connection or Wi-Fi
Installability
End users have to be able to easily install the framework End users have to be able to easily install plugins End users have to be able to easily update plugins End users have to be able to easily remove plugins Configurability Third party plugins can define settings that users can change after installation Extendibility/
Table 9 – Stakeholder Analysis of the Framework Designer (TU/e) (Continued)
Concern Threats
Security/
Integrity Violation of sharing settings Unauthorized data access Reliability/
Robustness Independent plugins influence each other
Standards compliant The framework cannot be used for a certain standard Liability Claim after unauthorized data access Claim after unauthorized shared data within the framework For all modules that are added to the framework it holds that they have to be compatible with the framework. This is a requirements that falls under the usability goal.
The main focus is on the requirement of the framework during the design and development process.
3.3
Design Opportunities
The framework acts as a middleware layer that does not offer direct functionality to end users. Developers use the framework to simplify application development. This means that design opportunities are related to non-functional properties of the framework. The framework is developed from scratch, so quite some design opportunities exist.
The framework should be extendable. Users have to be able to add new functionality by installing multiple plugins. Plugins implement details required to obtain access to data and to preprocess data.
The framework should support reusability. The construction of the framework needs to support reuse of existing subcomponents such as sensor data and preprocessed data. The framework should be transparent. Users have to understand what data is shared with whom. Furthermore, integrity is required when it comes to enforcing sharing settings.
Integrity is also required for plugins that are considered to be Intellectual Property (IP). Developers have to be able to block access to IP related data of plugins.
