...

4.     Introduction

We live in an increasingly automated world with complex interactions between the inventions we depend on as well as those we simply enjoy using. The interactions between these devices depend largely on the standardization efforts of the internet. However, to achieve interoperability and full automotive between complex collections of machines such as cars, cities and homes deeper levels of agreed standards are needed. In the office setting, this has largely been resolved thanks to the widespread implementation of mostly the same software of all companies, such as Microsoft Windows and Microsoft Office. These products represent an implementation of a closed architectural design that works with itself smoothly. Apple has a similar approach where design, testing, and support all comes from a single source. However, even in this environment issues have appeared when one company uses one product and another company uses the other. 

An example is contact information and calendar reminders. At one time each Microsoft and Apple devised their own methods to store and share this small bit of information needed to synchronize between users in the enterprise. This allows people working in different countries and time zones to all see the dates in their own format and timezone, yet it is stored in a common format for exchange. Enterprises with mostly Microsoft Office but a few people using Apple Mac's left the minority users in the cold until a common agreed upon format was defined, developed, tested and implemented in the otherwise closed systems. The data format and API for this is now called vCard and through its implementation, the enterprise users have the choice of device, operating system, and application. Now that tablets, phones, and even Linux PCs have been added, all they need to do is implement the standard.  

Recently the open source software model (OSS) has caught momentum as a way for hundred of different companies to participate in the development of software design and code creation. This model not only includes a licensing philosophy that tries to remove costly barriers to participation but encourages the use of a common base of code with each software provider adding their unique added value and licensing only the differences. Beginning in 2006 or so, automotive software development has begun to use this method to help manage the millions of lines of code needed to create a modern vehicle. The total number of cars being developed is divided by at least 10 automakers, often with hundreds of combinations of makes, model years and trim levels resulting in relatively small numbers of validation resources for each variation. This issue is driving car development and bugs to record levels, resulting in higher prices and costly recalls after the cars are on the road. Add in the concept of self-driving cars and safety automation features and the costs can be measured in both currency and lives. The collaborative model helps with this, but still requires standards to be useful.

Interoperability standards in data formats and programming interfaces (APIs) in even more essential if non-automotive devices are attached the "connected cars". Otherwise, consumers need to buy all their home appliances and electronic devices from the car dealer. This model ended with the "car phone" but continues in some way with the limited services available in closed telematics offers by each carmaker.

4.1          Observed Problem

...

• • There are a series of initiatives in the automotive industry that will touch the mobile environment
  • There is work going on in the mobile/IoT industry that will need to interoperate with automobiles
    • It is important for all not to waste resources by “reinventing the wheel”
    • Use good protocols that already exist and are deployed
  • There are a number of one-to-one company level programs underway, there is NOT a conversation happening at the industry-to-industry level to insure ensure standards-based interoperability and reduce fragmentation of protocols across automotive interacting with IoT and mobile services
  • The overall needs of the automotive industry are not being translated into mobile/IoT industry developments – harmonization of requirements and solutions between the mobile and the automobile environments.  What are the problems the automotive industry are trying to solve?

...

• • The auto industry wants to ensure openness and mobile device interoperability in relation to the automotive telematics systems
  • Automakers run the risk of becoming a “dumb device” with no control over user data
  • Operators and automakers could be forced to the sidelines where consumer touch, data collection, and ownership are no longer future revenue sources
  • Existing automotive approach of proprietary implementations is no longer working

...

Vehicle security is a very wide subject. Over the past 10 to 20 years the number of computers (ECUs) on the car and the amount of software running on these ECUs grew exponentially. Today’s cars are equipped with tens of ECUs connected by several networks. Unfortunately, the vehicle and the network of ECUs it includes , were not designed with security in mind and were definitely not designed to be connected to the external world.

...

The huge amounts of software on the car exposes many vulnerabilities that might be exploited by hostile agents to cause harm to the driver, to steal private information or to spy on the driver whereabouts. Software update Over-the-Air (OTA) is a mandatory element enabling the OEM to fix the software vulnerabilities without the need of for an expensive recall. The connected car introduced a serious problem that OTA is solving taking advantage of the car connectivity.

...

Authentication ensures which actors are allowed to work within the OTA system. It could be an admin authenticating to the OTA server, the car authenticating itself to the OTA server, or each software package being validated right before the installation.  Authorization make The authorization makes sure that every actor works within the policies dictated by the OTA system designer. Admin have has role-based access, software for one ECU cannot be installed on a different ECU etc.

Confidentiality requires that all software artifacts are properly protected, so software and IP does not end up at in the wrong hands and potentially exploited.  Integrity verifies that every piece of software, in transit or at rest has not been maliciously or otherwise modified.

...

5.1.1 OMA DM (Yair)

The OMA-DM protocol , is used by leading Mobile Network Operators (MNOs) like AT&T, NTT DOCOMO, SoftBank, Sprint, T-Mobile US and Verizon Wireless. The MNOs use the OMA-DM protocol to manage mobile devices on their network. The following are some of the use cases MNOs have deployed:

...

-       Fault Management: Allow querying the device status and report device errors

The OMA-DM protocol is designed with interoperability and security in mind:

...

-       Security is important because devices are exposed to software attacks. The OMA DM protocol was designed with security features like device authentication and challenges.

The OMA-DM protocol allow allows manufacturers and service providers to continuously increase the usefulness and value of connected devices throughout their entire lifecycle. They are able to optimize device performance, deliver unique insights, facilitate the rollout of innovative services and contribute to increased ARPU.

...

In recent years, with the introduction of the connected car, the term “mobile device” is extended to include the “large mobile device” of the automotive industry. Many car OEMs select to use the OMA-DM protocol to manage the configuration and software of the cars they are building. This enables car manufacturers to capitalize on the full business potential of connected cars by enhancing driver experience with rapid deployment of value-added in-car services, and minimizing costs through improved efficiency and a reduction in recalls.

...

needs to be made generic - not OMA-centric Through OMA enablers focused on device APIs, we can enable automotive (Auto) systems to offer API services to apps running in app environments provided by the Auto system. Such API services can enable apps to access vehicle information/services or other connected devices. These OMA enabler APIs are based upon on the Generic Open Terminal API (GotAPI) \[GotAPI\] enabler framework described in section 6.2.

...

OMA device APIs can enable synergy between app use cases in the Auto environment (e.g. driver safety, IoT, etc) and evolving evolve Auto technologies. For example:

...

This section introduces the OMA Generic Open Terminal API Framework (GotAPI) v1.1 enabler, and the GotAPI-based Device WebAPI (DWAPIWAPI) v1.0 \[DWAPI\] enabler. At a high level, GotAPI leverages widely supported Web technologies to enable a GotAPI server host (e.g. the Auto system) to provide an easy-to-integrate framework for apps to register and authenticate, discover available API services, access those API services, and secure the data exchanged between apps and other devices/services accessed through the GotAPI server. Without GotAPI, apps typically would have to be designed to support the specific methods through which other devices/services are accessed, e.g. a variety of APIs, protocols, and connection bearers.

...

• GotAPI-1: enables applications to make API requests and receive responses. This interface is generically specified by GotAPI, as GotAPI-based API specifications will define specific request/response transactions that can be utilized in host devices based upon on the available interface technologies, payload protocols, and their applicable design patterns. These options include:
  • The interface technologies TLS 1.2, HTTP/1.1, HTTP/2, Server-Sent Events
  • The design patterns REST and JSON, such as JSON-RPC
  • A Temporary Server Feed (TSF) mechanism for binary data responses and triggering a different protocols
  • The initiation of the asynchronous messaging interface, GotAPI-5, to use WebSocket

• GotAPI-2: enables applications to obtain authorization for access to GotAPI-based APIs. This interface is fully specified by GotAPI, being a common (though optionally used) support function for all GotAPI-based APIs. GotAPI-2 supports bindings and request/response transactions that can be utilized in host devices based upon on the available interface technologies. These options include the interface technologies TLS 1.2, HTTP/1.1, HTTP/2, and URI scheme handling. The GotAPI-2 interface is based upon the concepts of OAuth, though with different semantics as necessary for adaptation to the available interface technologies.

...

• GotAPI-4: enables Extension Plug-Ins for external devices and internal enablers through which they communicate with the GotAPI Server. Note that host-device-internal enablers/applications may also be connected to GotAPI servers directly in implementation specific ways without using the GotAPI-4 interface and Extension Plug-Ins.

  The Extension Plug-Ins are independent applications. They are the mediators between the GotAPI Server, and external devices and internal enablers/applications. Typically, there are expected to be multiple Extension Plug-In applications installed on a device by the user or preinstalled on the device.

  The GotAPI-4 interface provides the following functions with respect to Extension Plug-Ins:

  1. Plug-In Discovery: GotAPI-4 Plug-In Discovery enables the GotAPI Server to discover the targeted Extension Plug-In which an application wants to access and communicate with.
  2. Service Discovery: GotAPI-4 Service Discovery enables the GotAPI Server to find all the services provided by an Extension Plug-In. In this context, the "service" means an external device or a function provided by an internal enabler through an Extension Plug-In. The Service Discovery provides not only the list of services but also the availability of each service at the time.
  3. Approval: GotAPI-4 Approval is the function to ensure security, especially to protect users’ data and privacy from unwanted exploits, so that the users can safely use the application with external devices and enablers that are connected via Extension Plug-Ins.
  4. Data Forwarding: GotAPI-4 Data Forwarding is the function that enables an application to communicate with the targeted Extension Plug-In through the GotAPI Server. Data Forwarding takes place after Plug-In Discovery (optional) and Approval processes have been successfully completed. GotAPI-4 Data Forwarding uses the “pass-through” mechanism , so that the application can access and communicate with the APIs that (i) are implemented in the Extension Plug-In and (ii) expose the features of the external devices or internal enablers.

...

• Low data byte transmission with allowance for client to sleep (i.e., non-continuous communication)
• Suitable for constrained devices (hence reduced footprint for reduced CAPEX for car manufacturers)
• Several objects can be reported in one message using simple content types like TLV, JSON and single objects with simple text content type
• Ability to support a range of solutions through pre-defined objects (connected car objects/resources)
• Client (connected car) could send notifications to server based on defined trigger events e.g. periodic reporting, reporting upon a change of value, reporting based on thresholds reached. This is key as it gets past the poll and/or notification model
• LWM2M by default works with 3GPP technologies hence easier integration with telecommunication operators

...

While most of these solutions are realized through joint collaborative efforts between industry partners, there is, in general, a lack of open source alternatives which stifles innovation. Samsung Open Source Group and Jaguar Land Rover Open Source Technology Center , followed an open collaboration model under the Genivi Alliance Incubator projects initiative. One of the key objectives of this partnership was to use completely open source software and commodity off-the-shelf hardware, to realize the use cases (in bold), with minimal resources and time.

6.6.2 Stakeholders : Roles, Responsibilities, and Expectations

We understood that, for an IoT ecosystem to flourish, the architecture should be flexible enough for the key stakeholders to bring in their value proposition and make it easy for consumption by the rest of the ecosystem. Early adopters stand to gain significantly in such an ecosystem play and this typically tends to create ecosystem mono/duo poliesduopolies. From the beginning, our goal was to identify the key stakeholders of the IoT ecosystem and provide an architecture that helps them integrate their existing solutions/software stacks, with as little friction as possible. We identified the following limited roles and expectations.

...

...

As explained in the section <<RVI Section>>, RVI seperates separates the vehicle service data representation from the transport. The "Vehicle Signal Specification" is a simple, flexible and scalable format to represent vehicle signals inside a vehicle using a simple tree-like hierarchy. RVI Core stack handles the software infrastructure needed to discover other RVI endpoints and handling of an end to end delivery of messages, i.e. the transport agnostic communications infrastructure. RVI is capable of handling message delivery over Bluetooth, WiFi, LTE and SMS.

...

 Within the IoTivity open source project, we developed a MEAN (Mongo-Express-Angular-Node) stack based framework for bringing web services and IoT devices together to realize our use cases and to understand the issues while we attempt to integrate these domains. We defined an abstract service metadata model  as a way for services to be represented within an IoT network and to move the execution of the business logic from the cloud to inside the IoT network or automobile respectively. Only the serive service inThis approach helped us to represent ANY service in a consistent manner, thereby easing the handling of protocol, ownership, privacy, security and ease of use concerns.

...

1. The RVI service node hosted in the vehicle HMI running on GDP , connects via the cloud to the home gateway.
2. The WSI gateway also runs an RVI node (this is currently an implementation limitation which can be removed once native RVI libraries are implemented)
3. RVI provides many means to access services and we decided to use websockets.
4. The WSI gateway connects via websockets to the local RVI node which then talks to the remote RVI node.
5. Connection & remote RVI service discovery is handled purely by RVI and the WSI Gateway need not worry about the internals.

...