- This is a draft of the report being created by the OMAuto Incubator Group at OMA. Feel free to edit this report story if you have something of value to contribute.
If you want to add or edit delete an image on this page, download the file OMAuto Incubator Report Diagrams.pptxPptx PowerPoint deck and follow the instructions. If you don't have PowerPoint, follow these instructions:
...
- Get agreement across participating parties as to what work needs to should be done and where (which SDO) it needs to be done.
- Examine landscape across mobile and automotive environment
- Identify areas of overlap across industry work groups (RVI, W3C, GSMA, 3GPP, OMA, Smart Device Link, Apple CarPlay and Android Auto, OCF, etc…)
- Produce use cases/examples including interaction between IoT and automobile
- Roadmap and proposed timeline of future work needed, for example
- Security-related issues
- Enabler creation or reuse to facilitate development of enhanced services
- Work Collaborate with additional verticals (environmental, safety, healthcare)
- Deliverables publication to be public and available online
- Reference code-based projects already underway
- Clarify what should be standardized, open source vs. proprietary to encourage interoperability
- Other TBD
...
3.1 Conventions
This paper is an informative document, which is not intended to provide testable requirements to implementations.
...
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.
...
- 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”wheel.”
- Use good proper protocols that already exist and are already deployed
- There are a number of many one-to-one company level programs underway, there . There is NOT a conversation happening at the industry-to-industry level to 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 auto industry need to be 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 with the automotive car 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
Problem statement 3 - Vehicle Security
Vehicle security Security is a very wide broad 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 to 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 introduction of the connected car puts the automotive car 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 massive 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 for an expensive recall. The connected car introduced a serious problem that OTA is solving taking advantage of the car automotive connectivity.
Figure 2- Some examples of the vulnerabilities of a modern car
...
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 securely. Adopting the OMA DM protocol to deliver provide OTA services for the automotive market is the right direction.
...
The OMA-DM protocol allows manufacturers and service providers to continuously increase the usefulness and value of connected devices throughout their entire lifecycle. They are able to can optimize device performance, deliver unique insights, facilitate the rollout of innovative services and contribute to increased ARPU.
...
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 on the Generic Open Terminal API (GotAPI) \[GotAPI\] enabler framework described in section 6.2.
5.2.2 Example Use Cases for OMA Device API
...
utilized in the Auto Environment
OMA device APIs can enable synergy between app use cases in the Auto environment (e.g. driver safety, IoT, etc) and evolve Auto technologies. For example:
...
- GotAPI-2: enables applications to obtain authorization for access to GotAPI-based APIs. This interface is fully specified by GotAPI, being a common standard (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 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 relies 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 concerning Extension Plug-Ins:
- 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.
- 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.
- 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.
- 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.
...
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.
...
- Access control on the specific contents that could be handled remotely by different entities
- Software / and firmware Management for applications inside the Client
- Lock & Wipe of the device from misuse
- Connection management for choosing various radio methods by the Client
- Device Capability Management to identify the capabilities existing in the device
- Location of the device
- Connection Statistics in terms of concerning communication characteristics over the air
...
6.6 OCF IoTivity (SANJEEV)
6.6.1 Overview and
...
purpose of project
The Open Connectivity Foundation
...
a. An Open Specification: URL
b. An Open-Source Reference Implementation of the OCF Specifications: IoTivity
c. A vendor-neutral certification program: OCF certification
...
- The Transport Abstraction layer abstracts the wired/wireless connectivity details for different hardware and software platforms and presents a unified API to enable secure Device-To-Device communications between OCF devices in a transport agnostic way.
- The core framework implements the core OCF protocol as defined in the OCF specifications and handles core essential functions like security, device discovery, data transmission and management and device provisioning.
- The data models help represent the individual devices and their capabilities as resources, as defined in the OCF specifications, that can be securely controlled other OCF devices in the network.
An elaborate description of OCF and IoTivity is outside the context of this report. Please refer to the references section for a more details.
6.6.3 The OCF Automotive Project
The automotive domain has been one of the key areas of focus for OCF since the beginning and as consumers start expecting their “connected vehicle” to be part of a seamless experience that depends on how the vehicle operates in a smart ecosystem involving a smart home, smart intelligent infrastructure and even with other vehicles.
...
“We are going to build smart cars, but we also need to build smart roads, smart parking, smart public transportation systems and more... We need an integrated system that uses real-time data to optimize personal mobility on a massive scale without hassle or compromises for travelers.”
Optimizing personal mobility, is no longer about with the connected vehicle alone. To unlock these opportunities, OCF launched the Automotive Project in August 2016. For an automotive IoT ecosystem to flourish, the deployment 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. Service providers hosting the infrastructure expect minimal changes to the existing investments and expect new revenue streams by extending their services into the IoT network. Customers expect new services and experiences with zero setup overhead. Application developers are looking to leverage their existing assets and generate more user engagement. The aim of the Project is to provide the technology, standards and collaboration needed to ensure secure interoperability between automotive and other verticals, starting with consumer electronics, smart home and healthcare. The initial use cases enabled by the project fall into the following broad categories.
...
OCF Automotive Project has been under incubation for the past six months. The incubation was carried out together with the Genivi Alliance under the Genivi Incubator projects initiative. The goals for this incubation involved realizing the aforementioned use mentioned above cases using IoTivity open source project and the RVI open source implementation provided by Genivi.
The RVI or Remote Vehicle Interaction project provides a standardized means for communications between the vehicle and its remote services over a number of many different protocols. RVI separates the vehicle data representation from the transport. The "Vehicle Signal Specification" is a simple straightforward and flexible format to represent vehicle signals using a tree-like hierarchy. RVI Core stack handles the software infrastructure needed to discover other RVI endpoints and handling 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.
...
The RVI or Remote Vehicle Interaction project provides a standardized means for communications between the vehicle and its remote services over a number of many different protocols. RVI separates the vehicle data representation from the transport. The "Vehicle Signal Specification" is a simple straightforward and flexible format to represent vehicle signals using a tree-like hierarchy. RVI Core stack handles the software infrastructure needed to discover other RVI endpoints and handling 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.
RVI project also publishes the “VEHICLE SIGNAL SPECIFICATION” via github GitHub.
This repository specifies a set of vehicle signals that can be used in automotive applications to communicate the state of various vehicle systems. A standardized vehicle signal specification allows for an industry actor to use a common naming space for communicating vehicle state and, ultimately, allows permits the decoupling of the IVI stack from the underlying vehicle electrical architecture. The collection of signal specifications, or simply signals, is vendor independent. Vendor-specific extensions can be specified in a dedicated and uncontrolled branch of the signal specification tree.
This repository specifies defines a set of vehicle signals that can be used in automotive applications to communicate the state of various vehicle systems. A standardized vehicle signal specification allows for an industry actor to use a common naming space for communicating vehicle state and, ultimately, allows permits the decoupling of the IVI stack from the underlying vehicle electrical architecture. The collection of signal specifications, or simply signals, is vendor independent. Vendor-specific extensions can be specified in a dedicated and uncontrolled branch of the signal specification tree.
...
A MEAN (Mongo-Express-Angular-Node) stack based gateway framework (WSI – Web Service Interface) for bringing multiple services and IoT devices together as part of a single programmable frameworkstructure, was already available as part in the context of the iotivity open source project. 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 depending on a desired deployment configuration. This approach provides the flexibility to choose the nexus of device-service integration at the hands of the developers.
Thinking about the connectivity to the vehicle as a service, with the help of RVI, helped us model the use cases in terms of regarding discovering and invoking services provided by an RVI instance. This made the task of realizing the use cases to be simply a matter of service invocation rather than dealing with the protocol or messaging details. This reduces the burden for app developers to a large extent.
...
The RVI service node hosted in the vehicle HMI running on GDP connects via the cloud to the home gateway. The RVI-OCF translator/gateway also runs an RVI node. RVI provides many means to access services, and we decided to use websocketsWebSockets. The RVI-OCF translator/gateway connects via websockets WebSockets to the local RVI node which then talks to the remote RVI node. Connection & remote RVI service discovery is handled purely by RVI and the RVI-OCF translator/gateway.
After connecting to the remote RVI node, the WSI Gateway simply just 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 entirely 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 information is never transmitted sent 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.
The OCF-Vehicle translator Translator is a software component that can be placed in
...
Depending on the desired end user experience and deployment configuration, the translator enables seamless service oriented access between IoT devices, web services (apps) as well as vehicle controls.
6.6.9 Next Steps
OCF has a the vision to connect the next 25 billion things
...
...
6.6.2 API's defined
Please focus on expected overall expected penetration of OSS work in IoT market
...