If you want to add or edit an image on this page, download the file OMAuto Incubator Report Diagrams.pptx PowerPoint deck and follow the instructions. If you don't have PowerPoint, follow these instructions:
Enable a path for automakers and operators to encourage communications interoperability across automotive and wireless industries.
Reference | Details |
---|---|
\[GotAPI\] | Generic Open Terminal API Framework (GotAPI), Candidate Version 1.1 – 15 Dec 2015, Open Mobile Alliance, http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/generic-open-terminal-api-framework-1-1 |
\[DWAPI\] | Device WebAPI-PCH, Candidate Version 1.0 – 19 Apr 2016, Open Mobile Alliance, http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-device-webapi-v1-0 |
This is an informative document, which is not intended to provide testable requirements to implementations.
Term | Meaning |
---|---|
| |
Abbreviation | Meaning |
---|---|
DWAPI | Device WebAPI |
GotAPI | Generic Open Terminal API |
OMA | Open Mobile Alliance |
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.
Figure 1- Numbers to illustrate the automotive software crisis scale
The introduction of the connected car puts the automotive industry in a situation that is very similar to the introduction of the connected computer back in the late 90s. Connecting computers to the internet back then required IT to build the infrastructure to protect the computers on the internal networks. Fortunately, most of this IT software could be leveraged to protect the communication of the car to the external world. However, protecting the communication between the car computers and between the hostile environment and the car computers is still a challenge.
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 an expensive recall. The connected car introduced a serious problem that OTA is solving taking advantage of the car connectivity.
Figure 2- Some examples of the vulnerabilities of a modern car
OTA Software Update Security
When it comes to OTA software update the security goals of the end-to-end OTA system include the following aspects:
- Authentication
- Authorization
- Confidentiality
- Integrity
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 sure that every actor works within the policies dictated by the OTA system designer. Admin have 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 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.
OMA DM was designed with such security design goals in mind. For the past decade, OMA DM has been successfully used on billions of mobile devices to securely deliver software updates over the air. Adopting the OMA DM protocol to deliver OTA services for the automotive market is the right direction.
Figure 3- End to end OTA Software Update
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:
- Provisioning: Initial device configuration (aka Bootstrap) and enabling and disabling device features
- Device Configuration: Modifications of various settings and parameters of the device
- Software Upgrades: Enable Over-the-air (OTA) software update including Firmware Update (FUMO) and system and applications components (SCOMO)
- Fault Management: Allow querying the device status and report device errors
The OMA DM protocol is designed with interoperability and security in mind:
- Interoperability is achieved by the work of the OMA Interoperability (IOP) work group. The IOP work group specify and maintain the required processes, policies and test programs in addition to running regular test-fests where different vendors can attend and test their client and server software.
- 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 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 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 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 Auto technologies. For example:
Through the two basic roles below, Auto systems (e.g. an RVI) that host a GotAPI-based API server can support a wide variety of use cases for apps running in the Auto system, e.g.
These use cases are illustrated below.
Use Case A: Web apps (e.g. an Auto Driving Lessons Coach) can access the RVI data and external device data through GotAPI/Device API. GotAPI enables the Web app to access RVI information/services without needing to implement the RVI-specific interfaces:
Use Case A
Use Case B: An RVI can access external device information/services, e.g. exposing access to a home lighting system.
Use Case B
This section introduces the OMA Generic Open Terminal API Framework (GotAPI) v1.1 enabler, and the GotAPI-based Device WebAPI (DWAPI) 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 be designed to support the specific methods through which other devices/services are accessed, e.g. a variety of APIs, protocols, and connection bearers.
DWAPI builds upon GotAPI in defining Web-based APIs used to access healthcare devices through IEEE-specified interfaces. Additional APIs such as for 3D printer access are in development at OMA.
Overview: Various External Devices Working with Apps Through GotAPI
GotAPI Architecture
GotAPI defines how apps and the GotAPI enabler components interact through the interfaces illustrated below:
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:
GotAPI Interfaces
The OMA LWM2M (Light Weight Machine To Machine) protocol provides the capability for applications to communicate and manage IoT devices. LWM2M is based on the IETF Constrained Application Protocol (CoAP) providing communication between a LWM2M Server and a LWM2M Client (where Client is located in a constrained IoT device).
Some of the abilities which are helpful from connected car perspective from LWM2M are the following:
The core interfaces between the server and the client are categorized into:
OMA LWM2M is unique in the aspect, that it converges both management and application control functionality within one communication session allowing for efficient handling of IoT devices. Since OMA LWM2M protocol is based on IETF CoAP, the OMA LWM2M protocol allows different transport bindings (e.g., UDP, SMS) and is secured using IETF DTLS protocol.
The device management features defined by OMA for release 1.0 of LWM2M are:
The object registry provides a unique way of identifying the necessary and relevant objects. The object registry is maintained by OMNA (Open Mobile Naming Authority). It includes categories for interleaving 3rd party management objects and application objects into the OMNA system from vendors and other standards organizations (for e.g., IPSO Alliance and oneM2M)
The Open Connectivity Foundation (OCF), a global consortium of leading companies focused on creating a standard for interoperable devices and services was founded in 2014. The OCF approach has three key deliverables:
OCF's initial efforts to venture into the Connected Vehicle space involved analysis of the Connected Vehicle – Smart Home crossover use cases based on consumer interests and strategy reports. We also took a look at the contemporary demonstrations shown in trade shows. Based on the above, we consolidated the list of use cases, under the following broad categories.
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.
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 polies. 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.
Role | Responsibilities | Expectations |
---|---|---|
Service Provider (Cloud, Web, Network) | Hosts the service infrastructure backbone Enable authenticated access to the infra. | Minimal/No changes in existing business models (non disruptive). Support exisiting legacy services.
Extending service into the IoT network.
More user engagement from multiple sources. |
Customers | Consume Services & IoT Devices Provide credentials for privacy and security | Zero/Minimal Setup overhead Ease of Use of Products & Services Cost and Time savings with more personalization. New experiences in doing day to day activities. |
Application Developers | Innovate and delight customers with New {Web services & IoT devices} Apps | Maximize Asset Reuse Simpler development New revenue streams |
Auto makers & Tier 1 | Manufacture at Scale Compliance to standards (where applicable) | Increased user adoption Feature Differentiation |
As explained in the section <<RVI Section>>, RVI seperates 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 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 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.
Thinking about the connectivity to the vehicle as a service helped us to model the use case in terms of discovering and invoking services provided by the vehicle. This made the task of realizing the use cases to be simply a matter of service invocation rather than dealing with protocol details and intricacies. These details are best handled by the software stack dictated by the automaker or Tier-1 service provider. It addresses the key issue of who owns this part of the stack, which is always a point of concern in commercial deployments.
In this context, the RVI Expert Group within Genivi had an open source software in place for many important vehicle connectivity use cases which we could readily use for representing vehicle connectivity as a service within the WSI architecture. This extends the connectivity services hosted by the vehicle to be accessed by IoT devices inside the smart home.
The RVI-OCF Gateway basically handled all the service specific details.
After connecting to the remote RVI node, the WSI Gateway simply translates between the service definitions provided by Remote RVI Service Node into corresponding OCF device control commands based on application developer logic. This mapping is totally independent of how the gateway functions and thus provides maximum flexibility to implement any rules or service logic you can come up with, depending on the scenario. In this case, the service was controlling the HVAC parameters of a vehicle. In future, we could extend the service to be whatever the situation demands. Another major benefit of this approach is that the IoT device data is never transmitted out of the home. Similarly, the vehicular data is never transmitted over the cloud. This provides a clear separation of the data across the domains, namely smart home and vehicle with a reduced security and privacy risk – while giving total control over the customer data to the existing services. In addition to the above demos and use cases, we also have made OCF stack called as IoTivity, as part of the GDP and AGL (Automotive Grade Linux), so that interested developers will now be able to implement use cases.
All of our source code is published under
https://github.com/GENIVI/meta-genivi-ocf-demo/tree/master
http://git.s-osg.org/ocf-automotive-sampleapps/
A complete video demonstration of WSI at work is presented here.
https://www.youtube.com/watch?v=351m-GrRSNE
The complete blog is presented here.
https://blogs.s-osg.org/osg-ocf-automotive-fortnight/
6.6.2 API's defined
Please focus on overall expected penetration of OSS work in IoT market
6.7 OMA-DM and vehicle security (YAIR N)
6.7.1 Overview and objective of project...
6.7.2 API's defined
7. Analysis and recommendations to achieve interoperability (JOEL H)
8. References (Temporary)