...

• Images in source format other than Microsoft Office Graphic (Powerpoint) should be edited by other tools and uploaded to the wiki in the source formatform of origin, for future updates. Once finished editing, save the image as a PNG with filename per the caption of the image picture in the report.
• Edit the wiki page, and use the “Files” tool to upload the image. If you are updating an image with the same name, you don’t need to re-insert it, so deselect the checkbox on the image picture and select close.

...

Table of Contents

Table of Contents

...

We live in an increasingly automated world with complex interactions between the inventions we depend on, as well as those we simply merely enjoy using. The interactions (or interoperability) between these devices depend largely on standardization efforts. However, to achieve interoperability between complex collections of machines such as cars, computers, appliances or even 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 across most 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 or department uses one product and another company or department uses the other. 

One example can be seen when using contact information and calendar reminders. At one time each Microsoft and Apple devised their own methods to store and share these small bits 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 standard format for exchange. Enterprises with mostly Microsoft Office, but a few people using Apple Macs, left the minority users in the cold until a common standard 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 vCal. 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 to the enterprise, all they need to do is implement the standard.  . The result was born as BYOD or Bring Your Own Device, now an enterprise IT expectation along with the implications of incorporating personal preferences by users to maximize productivity.

Recently the open source software model (OSS) has caught momentum as a way for hundreds 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 value and licensing only these differences. Beginning in 2006 or so, automotive software development began 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 heading to production is divided by at least 10 ten 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 standardization to be useful.

...

• • 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 proper protocols that already exist and already deployed
  • There are many one-to-one company level programs underway. 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 auto industry need to be translated into merge with 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 with the car telematics systems
  • Automakers run the risk of becoming a “dumb device” with no control over user data
  • MNOs and automakers could be are 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 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 come with tens of ECUs connected 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 attached to the external world.

Figure 1- Numbers to illustrate the automotive software crisis scale

The introduction of the connected car puts the 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.

...

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.  The authorization makes sure that every actor works within the policies dictated by the OTA system designer. Admin has role-based access, software for one ECU cannot be installed install on a different ECU, etc.

Confidentiality requires that all software artifacts are properly will be protected, so software and IP does not end up 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.

OMA DM was is designed with such security design goals in mind. For the past decade, OMA DM has been successfully used on billions of mobile devices to deliver software updates over the air securely. Adopting the OMA DM protocol to provide OTA services for the automotive market is the right direction.

...

• SDL - Smart Device Link, an open source implementation of Ford’s AppLink (Ford Sync) software libraries enabling smartphone integration across all radio levels and brands of devices (Apple, Android, Windows, etc.)
• RVI - Remote Vehicle Interaction, an open source project by JLR Research Centre in Portland, OR. Enables universal connectivity to the vehicle bus transparently across LTE, Wi-Fi, Bluetooth, 3G, NFC and future networking technologies by embedding a standard software module in the vehicle car head unit.
• VSS - Vehicle Data format standard emerging from work between W3C as implemented by RVI project
• SOTA - Software Over The Air (included in RVI above) through the entire vehicle (ASIL grade Safety and Security)) through the entire vehicle (ASIL grade Safety and Security)
• IOTivity - Initially an IoT implementation of the OCF efforts, now emerging with automotive requirements influenced by RVI and VSS
  
• OMA DM, LWM2M, and GotAPI - 3 highly adopted standards for interoperability and device management developed by the wireless operators to ensure some level of compatibility and support of over 2 billion devices (phones, tablets, etc.) but not yet including cars in all cases

5.     Automotive Technology Trends

5.1          Over-the-air updates

5.1.1 OMA DM

...

The OMA-DM protocol is used deployed 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 allows manufacturers and service providers to continuously increase the usefulness and value of connected devices throughout their entire lifecycle. They can 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) Automotive 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.

...

• An Auto system app can monitor driver vital signs (heartbeat, breathing rate, temperature, blood pressure, etc)
• A user can download an RVI app providing Mobile Keyless Entry to their smartphone, and use it to unlock the vehicle
• Auto system apps can also discover other external sensors, e.g. road sensors, outside air quality sensors, etc

Through the two basic essential 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.

• the Auto system can offer vehicle information/services to apps running in an Auto Web runtime environment
• the Auto system can act as a GotAPI client in accessing information/services provided by connected devices

These use cases are illustrated shown 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:

...

GotAPI defines how apps and the GotAPI enabler components interact through the interfaces illustrated below:

• GotAPI-1 : enables 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 on the available interface technologies, payload protocols, and their applicable appropriate 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 different protocols
  • The initiation of the asynchronous messaging interface, GotAPI-5, to use WebSocket

• GotAPI-2 : enables enables applications to obtain authorization for access to GotAPI-based APIs. This interface is fully specified by GotAPI, being a 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 relies upon the concepts of OAuth, though with different semantics as necessary for adaptation to the available interface technologies.

• GotAPI-3 : enables enables the remote provisioning of API access authorizations through a policy management function, which may include one or more of:
  • OMA Device Management, using a Managed Object (MO) to be defined in a future version of the GotAPI enabler
  • An implementation-specific policy management service

• GotAPI-4 : enables 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 concerning 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 connect 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 MNOs

...

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 3^rd party management objects and application objects into the OMNA system from vendors and other standards organizations (for, e.g., IPSO Alliance and oneM2M)

...

a. An Open Specification: URL

 b. An Open-Source Reference Implementation of the OCF Specifications: IoTivity

 cc. A vendor-neutral certification program:  OCF certification

...