Printer Friendly

SmartDeviceLink as an Open Innovation Platform for Connected Car Features and Mobility Applications.

INTRODUCTION

The automotive industry is experiencing an era of expanded technology opportunity, particularly in the areas of vehicle electronics and connectivity. The industry has developed methods of innovation and product development suited to the production of very robust commodity products in a highly optimized, global manufacturing system. In recent years, vehicle infotainment systems have been combined with internet services via the wireless cellular data network to create new opportunities. This combination disrupts the traditional development process significantly. New methods of innovation and development are needed for this era of rapid development.

Open innovation is a topic within the field of innovation management. The term has been promoted by Henry Chesbrough from the Center for Open Innovation at the University of California. He has written books and papers on the subject [1, 2], although the idea has been discussed as far back as 1960s [3]. The fundamental premise is that properly managed inflows and outflows of knowledge can improve innovation within a firm while creating new markets of the technology outside the firm.

In a new business model, a good understanding of the value proposition, target market, value chain, revenue mechanism(s), value network, and competitive strategy is needed to extract value from the technology. Developing this understanding often involves a process of trial and error and can take considerable time. A firm with a new technology needs to develop the business model very quickly. Most of the time, firms and industries operate with a closed innovation strategy where incremental technological improvements drive product differentiation, meet new government regulations, market changes, etc. These firms frequently compete by being lean and robust, but lack the resources to consistently create value from rapidly changing technology.

The value network, or ecosystem, is developed through an evolutionary process that begins pretty chaotically but ends in business model(s) that add value. Early in the process, members of the ecosystem have varied characteristics, motivations, and contributions to make. As the ecosystem matures through trial and error, the necessary operational components become clearer, and some members may drop out while others may commit more resources. There can be mergers, spinoffs and selloffs until a stable business is established, commoditization sets in and a closed innovation model is once again preferred.

In software development, open source is a key enabler for an open innovation platform. The ecosystem consists of member firms working together on a common software platform that allows innovators to develop technology and business models utilizing road vehicle entertainment systems for live testing for their concepts. In the following sections, the authors introduce their open innovation platform and several use cases, hoping to encourage technology entrepreneurs to join their ecosystem.

Open Innovation Platform

SDL is the focus of an open innovation ecosystem intended to discover new businesses arising from recent technology advancements. These new businesses may be based on unexpected combinations of hardware, software, and ecosystem members that are admittedly difficult to predict at this point. Therefore, the adaptive nature of open innovation approach is necessary.

The SDL Open Innovation ecosystem is intended to involve members from large and small firms that may develop software, hardware or both. Currently the SDK is targeted to mobile devices that support iOS and Android operating systems but is open to new hardware devices if they support Bluetooth, WiFi and/or USB.

The ecosystem also accommodates members from other automotive OEMs, suppliers and after-market companies that wish to implement the core application (Figure 1) on their infotainment platforms. The openness of the platform makes possible many different alliances of development partners, OEMs, suppliers and aftermarket companies. The nature of the software interfaces is such that members can have very different business priorities, development cycles, revenue models and technologies.

SDL allows mobile apps to read vehicle data and control vehicle sub-systems such as the audio and climate systems. It is extensible, other convenience sub-systems or even brought-in aftermarket modules can be added. Figure 2 shows how SDL Core interfaces with the rest of the vehicular sub-systems and features. These features include navigation systems, climate control, GPS, geo-fencing, speech recognition, radio, audio equalizer, etc.

SDL facilitates a channel for rapid prototyping and innovation that is not constrained by the traditional process of automobile parts development but is rather on the timeline of software development. This allows parties other than the OEM, including third party developers, universities, and startups, to quickly integrate their applications into the car using mobile device apps. By digitizing the controls into an open source programmable application program interface (API), it is possible to incorporate machine learning and ambient intelligence to learn user preferences over time and intelligently pre-set them automatically. This can disrupt the traditional model of the human machine interaction.

This paper describes a system to connect the rider to the vehicle. It first begins with an introduction into SmartDeviceLink and its capabilities to show how it can be used as an Open Innovation Platform for the vehicle. This is followed by examples of innovative features for the Connected Car using SDL.

The first use case is an intelligent climate control system, integrating brought-in sensors and wearable devices for automated climate and air quality control. This utilizes air-quality sensors to detect both the interior and exterior air quality and adjust the fan speed and recirculation vent appropriately to maintain clean air within the vehicle cabin. This has particular use in high-density cities high air pollution. Furthermore, we discuss the usage of wearable devices with cloud data to create an intelligent climate control system based on real-time feedback from the vehicle occupants to improve the user experience.

The second example is for a hybrid radio system, which combines internet content providers with broadcast radio services. We will demonstrate an example of hybrid radio implementation with a mobile app called NextRadio. NextRadio receives the FM radio in the car and combines it with metadata received on the smartphone to enhance the radio experience in the vehicle. Album art, song information, and music genre are added to the display. Additionally, it enables selection of radio stations within range of the vehicle by genre or current song, none of which is possible with just FM radio.

The third example is a mobility application, specifically ride-sharing. In this case, SDL acts as the medium to enable not the driver but the passenger to control the vehicle sub-systems from their phone, either in a taxi or ride-share or in a large passenger vehicle. This allows for dynamic control of their preferences from their phone based on various meta-data, which we can learn about them over time. This also has great implications for autonomous vehicles, which may lack a familiar console interface to control these options.

We discuss the implications of this system as a whole and how it fits into the current trends in Mobility. Finally, we also touch on some other examples including audio equalizer and auto-high beam.

SMARTDEVICELINK OVERVIEW

SmartDeviceLink (SDL) is an open source project pioneered by Ford Motor Company that connects in-vehicle infotainment systems to smartphone applications allowing automakers the opportunity to provide customers with highly integrated connected experiences, and app developers with new and exciting ways of connecting with their customers. It is managed by the open source community, SmartDeviceLink Consortium Inc. (SDLC), which includes companies such as Ford Motor Company and Toyota Motor Company. It is open to OEMs, suppliers and app developers who are integrating with SDL or have plans to integrate with SDL in the future [4].

SDL comprises of head unit software, known as SDL core, and mobile SDKs for Android, iOS, and cloud configuration. SmartDeviceLink can be treated as a specification which can be implemented by arbitrary developers. Nevertheless, open source implementation is provided. SDL core's implementation is provided in C++. It supports several transport protocols: Bluetooth, WiFi and USB. SmartDeviceLink supports both media and non-media apps. Media apps are dedicated to audio streaming and provide an alternative user interface (UI) to the native media UI, which usually include FM/AM/XM, and CD. Non-media apps extend the built-in applications, and normally read vehicle data and provide added functionality to the driver. The head unit defines four states called HMI_LEVEL for each connected mobile app: FOREGROUND, LIMITED, BACKGROUND, and NONE.

When the app is selected from the head unit, it opens a predefined UI templates and is put in FOREGROUND state, which gives the app all of its allowed permissions. Once opened, the driver may switch to a different screen on the head unit, such as the navigation screen. If the driver navigates to a different screen on the head unit, the app enters BACKGROUND state where most of its permissions are lost. A LIMITED mode is defined for media apps. This mode is entered if the HMI is displaying the predefined UI template, but does not have propriety. This can happen if an app is streaming music and the driver receives a phone call for example.

Mobile applications can communicate with SDL through the SDL software development kit (SDK), which is available for Android and iOS platforms [5]. The SDK makes the app discoverable by the vehicle's head unit. It exposes a set of remote procedure calls (RPCs) through a defined set of application programming interface (API). In brief, the app instantiates an instance of the SDL proxy class, provided by the SDK, which handles the communication between the app and the vehicle. The RPCs are methods of the proxy class. Moreover, the proxy class receives the vehicle's notifications and makes them available for the mobile app.

Different OEM's can implement SDL and provide different capabilities. Once the proxy starts within the app and connects with the vehicle, basic information about vehicle capabilities such as vehicle's language, audio capabilities, etc. are immediately made available to the app. The app can further query for specific capabilities through the proxy APIs. Although the RPC implementation is not directly exposed to the app developer, it is worth noting that the RPC protocols are implemented as JSON strings.

A remote control extension for SDL is created and is available in the public repository. The extension consists of additions to SDL core inside the vehicle and to the mobile SDK for Android and iOS. Three major RPC's responsible for remote control, and their corresponding APIs are shown in Table 1. These APIs provide enough abstraction for mobile apps to control vehicle modules with different capabilities inside vehicles by different OEMs.

Security Considerations

As with any open source platform and wireless applications, a major consideration for any system is security. In the case of SmartDeviceLink, the base security mechanism is pre-defined, but the OEM can extend it to add additional layers of security. Apps during testing phases can also have more privileges than during release.

The core of SmartDeviceLink security is the policy table, which is hosted in the cloud by the OEM. Each SmartDeviceLink App requires an App ID to be generated by the OEM, which identifies the app in the policy table. Each App ID is associated with an explicit set of RPCs which the app can execute in each of the four HMI_LEVEL states of the app. If the App ID is not present in the table or if the app attempts to execute an RPC not listed in its HMI state, it will be denied. In this way, the OEM has central control over all app permissions and modes. Usage of a new app prompts an update of the policy table from the cloud. Updates can also be set to be done periodically. Vehicles are shipped with a default policy table at the outset.

Security starts by requiring the application developers to request an App ID from the OEM and specifying what APIs are required. The OEM can choose to group the APIs into logical groups which are referred to as functional groups. Each OEM can group the APIs differently, or not group them at all for more control.

Once App ID is approved, the OEM registers that App ID on a server and specifies which function groups can be used, and in what HMI state (FOREGROUND, LIMITED, BACKGROUND, NONE). Whenever the mobile application establishes connection, it tries to download a policy table automatically from the Cloud which contains the app's privileges. The policy table implementation and security is left to the OEM, and it is highly recommended that this policy table be encrypted. The mobile application will then be able to call APIs as dictated in the policy table.

If the OEM wants to revoke App ID permissions, the OEM has to modify the entries for the App ID in the cloud. As soon as any arbitrary mobile application downloads a new policy table to the vehicle, the specified App ID gets revoked.

Without any enhancements, the default security model for SmartDeviceLink protects against average user misuse only. The App ID can be reverse engineered in the current model, and updates to the policy table do not occur if there is no internet connection. This can be enhanced by the OEM in several ways. For example, it would be possible for the OEM to not keep any persistent policy table inside the vehicle, and hence severely limit the app's capability if there is no internet connection available. It is also possible to force the permissions for a given App ID to expire after a given time as long as the vehicle has a tamper-proof clock available.

To protect the App ID from reverse engineering, the mobile application could obtain an encrypted App ID from the third-party server and decrypt it in the head unit. This would make it possible to use asymmetric encryption, similar to how the HTTPS protocol works. An API can be added to SmartDeviceLink and be configured such that all mobile apps have access to it at any time. Each mobile application would act as a relay between the head unit and the third party server, and then the third party server sends the App ID for the mobile application securely to the vehicle. For this to work, the customer would have to provide credentials to login to the server in order for the server to respond back to the head unit. The login mechanism in this case would most likely be the weakest link since a human is involved. If an attacker stole a username and password, the attacker could then use the third-party server to personalize an App.

Regardless of the security model used, it is highly recommended that the OEM give the ultimate control to the vehicle owner. Whenever a mobile application attempts to call a remote control API for the first time in an ignition cycle, a pop-up screen with timeout timer can be displayed to the driver to grant remote control permission to the mobile application. Moreover, at all times there must be a notification on the head unit display that there is a mobile application running capable of remotely controlling the vehicle. At any time, the driver can navigate to the proper menus to disable remote control ability for a specific application or for all applications simultaneously.

Other security considerations arise depending on the implementation specifications. For example, Denial of Service attacks can be possible if the mobile application keeps causing remote control permission pop-up to appear. A mobile application may increase the load of the CAN bus if it can keep requesting parameters to change at a fast rate. If the mobile application can cause a menu on the head unit to change, another form of Denial of Service is possible. Solving these challenges is left to the OEM because they depend on the OEM's architecture and specification. Finally, the OEM is strongly advised against adding API's which affect the vehicle's torque.

CLIMATE CONTROL AND AIR QUALITY

In this section, we discuss how SDL-RC can be used to create innovative models for enhanced climate control that allows integration of brought-in sensors and cloud information.

Climate comfort in the vehicle involves a system of integrated heating, ventilation and air conditioning (HVAC), either controlled manually or automatically [6]. Automotive HVAC systems vary in capabilities, from a basic system that just maintains the set temperature to one that adjusts based on temperature, humidity and sun-load sensors. High-end vehicles feature multi-zone automatic climate control that differentiates driver, front passenger and rear passenger zones. Some even have infrared sensors that monitor the occupants' surface temperature.

Further advancement includes the addition of air quality management. This is an increasing concern as urban areas continue to grow. It is characterized by an Air Quality Index (AQI), which is an indicator of the health impact of the air as measured by the concentration of harmful gases and particulates in the air. Cabin air quality can be improved through proper management of the climate control system [7].

As shown in Figure 5, a sensor installed in the vehicle measure different pollutants in the cabin air, such as [PM.sub.2.5] (particulate matter less than 2.5 micron in diameter), carbon monoxide (CO), and hydrocarbons (HC). The sensor communicates with the mobile app and sends the measurements of the different pollutants periodically. The app communicates with the climate control system through SDL, modifying the parameters shown in Table 2. A threshold is defined in the mobile app, such that when [PM.sub.2.5] or other important chemical measurements exceed that threshold, a clean cycle is initiated. The recirculation door is closed if it is not already closed, and the blower speed is increased, causing the cabin air to flow through the air filter continuously. This filters the cabin air.

Also, the system in Figure 5 leverages cloud information about air quality. If there is a spike of pollution in the external air, the system can switch to recirculation while the vehicle is passing through the polluted area. This architecture has been piloted in China and demonstrated effectiveness of the proposed solution [8].

As seen in the example, using SDL, the intelligence in the system is implemented on the smartphone. The smartphone can connect to brought-in air-quality sensors of the customer's choice. This circumvents the need for automotive-grade sensors to be developed and greatly expedites the process of getting this feature into the vehicle, given that automotive-grade air quality sensors in the market are limited.

Furthermore, this adds the ability to incorporate intelligence into the algorithm to automatically make the necessary adjustments to maintain both cabin comfort and air quality [9]. For example, if the system learns that a particular rider consistently adjusts the temperature higher than average, then it can remember this and apply it to future rides, even in climates distinct from where it observed this preference. With this information, the vehicle can even pre-condition the cabin to its best guess at climate preferences prior to picking up the rider. If he or she adjusts the settings, it can record this and further improve its understanding of the rider's preferences.

Wearables and Automated Climate Control

To further the ambient intelligence system, we have incorporated wearable devices that measure the wearer's skin temperature via a wrist-worn skin contact sensor. If the wearer is cold, the system can automatically increase the cabin temperature, and vice versa. This can be facilitated by a learning system that tracks trends and potential causes of the wearer's discomfort. The architecture of such a system is shown in Figure 6.

HYBRID RADIO

Recent years have seen rapid growth of novel vehicle infotainment options that leverage connectivity platforms between phone apps and the vehicle HMI through, for example, Pandora, Spotify, and TuneIn radio. Although the popularity of these services challenges the radio industry, traditional AM/FM radio is still the most prevalent in-car infotainment option. AM/FM radio has a number of advantages, especially as an in-vehicle entertainment option. It delivers local and national content that is free, convenient, and is generally available in places where data coverage is fragmented. It is governed by well-established government authorities with regulations and international treaties that provide defined standards across political boundaries. AM/FM Radio can also take advantage of vehicle connectivity platforms to introduce innovative ways of enhancing the experience of traditional broadcast.

Hybrid radio is an emerging concept that enhances traditional broadcast radio with internet connectivity to provide a richer user experience and potential enterprise value. An example of a hybrid radio application that can be demonstrated today is NextRadio. The NextRadio mobile application is currently available on many popular cellphones sold in the United States. It takes advantage of the FM radio built into the cellphone to receive audio content. It also uses a cloud based platform, called TagStation (Figure 7), to create an interactive real-time experience. TagStation enables the radio industry to manage metadata associated with the broadcasted content. TagStation is unique in that the cloud-service interfaces directly with the radio station's live on-air system, which allows for event by event metadata management. NextRadio synchronizes the broadcast signal with the backend meta-data provided by a TagStation server to supplement the audio content with additional information such album art, listener feedback, song tagging, and social integration.

NextRadio can be naturally extended to the in-vehicle environment leveraging SDL, while taking advantage of existing car radio equipment. The vehicle has more electrical energy capacity than the cellphone. Consequently, the location system in the vehicle is more robust than in most cellphones and using the vehicle's GPS instead of the mobile phone's saves power on the cellphone battery. Similarly, the audio system in the car is better powered, larger and is tuned for the vehicle cabin compared to the mobile device. In integrating SDL with NextRadio we can leverage the radio parameters available for radio control presented in Table 3.

In order to obtain the meta-data for the station, the current station needs to be identified. To do this, the radio band (AM/FM) and currently tuned frequency from the vehicle are sent to TagStation from the NextRadio app. For vehicles with HD Radio, additional data includes HD Radio status, and the currently tuned HD Radio subchannel. Global Positioning System (GPS) location data supplied by either the vehicle or the cellphone are also used to confirm the identity of the currently tuned radio station.

After the station is identified, TagStation sends back the meta-data for the specified station. Then, using SDL functions, the NextRadio App provides supplemental content and soft buttons and meta-data with associated voice commands for the possible actions related with the given broadcast. The sequence diagram is presented in Figure 8.

NextRadio facilitates customer engagement with the content through enhanced user interactions, such as bookmarking a song (Figure 9a), calling a phone number for a radio station (Figure 9b), saving a coupon from an advertisement (Figure 9c), finding advertised POI in the embedded navigation (Figure 9d), or requesting more information with an e-mail or SMS message. All actions work with a single button press or a voice trigger.

NextRadio also provides enhanced station discovery compare to the standard car radio HMI shown in Figure 10a. Figure 10b show the car interface that lists genres of the stations available at given GPS location. Selecting a given genre as shown in Figure 10c will open the list of the stations with currently played content shown in Figure 10d. Selecting a station will switch the radio tuner to this station.

This use case demonstrates the possibility and benefits of integrating the NextRadio app over SDL with the vehicle AM/FM RDS radio with its large antenna, powerful receiver and integration into the vehicle sound system. SmartDeviceLink also supports integration with the vehicle HMI that provides conceptual integrity between the vehicle and NextRadio. Through this integration it is possible to provide NextRadio features in a robust, high-quality vehicle environment.

This capability enables intelligent searching for broadcast content to find stations with specific content, for example: a regional hockey game; a list of stations within a particular genre or format such as local news; stations that play jazz, classical music, etc. The system can be further extended to include autonomous recommendations for station selection based on the current broadcast options, historical listening habits, and connection to the social networks. Additional advantages of using the hybrid system include using broadcast radio when streaming audio is not available and vice-versa, and using broadcast radio instead of streaming to reduce data usage.

The integration of hybrid radio can also provide significant enterprise value. The ability to capture and analyze customer listening patterns can provide substantially more detailed analytics for the station programming and advertisement positioning.

MOBILITY

As transportation moves away from personal car ownership and towards ride-sharing, vehicle and subsystems design will likely need to change. The user experience will be different, and user interaction models will also shift given that riders will no longer be in their own personal vehicles with their preferences already set and their personal belongings in place. The vehicles driven in may be unfamiliar to the rider as well, and travelers will be seated in the rear or the passenger seat. If traveling, they may not speak the local language, either to communicate with the driver to change settings or to read the lettering on the vehicle controls. In any event, setting personal preferences becomes a frequent, sometimes cumbersome, task on almost every trip.

In the mobility space, SDL enables these vehicle sub-system controls to be extended to other passengers in the vehicle who may either be seated in the rear of the vehicle or otherwise unable to configure the climate in their zones. For vehicles with multiple zones, such as a larger family van or a shuttle bus, this can extend control of the individual zone climate to the passengers themselves.

Additionally, since SDL allows digital control of analog features, these controls can be initiated dynamically with a computer algorithm that remembers the rider's preferences. For example, upon booking a ride, the vehicle can be pre-conditioned to the rider's preferences (set on a previous ride) given the current weather conditions and location as parameters. When the vehicle arrives, it will already be set to the rider's preferences, inclusive of seat positioning, climate, and audio entertainment.

In theory, with SDL, even a remote coordinator could now adjust the vehicle settings. For example, in the case of a ride-sharing fleet, a traffic controller could remotely send pickup and destination routing instructions to the fleet directly to their navigation units. Vehicle data can also be remotely read and tracked in real-time in the same fashion.

Ride-Sharing

Using SDL, we prototyped a ride-sharing application to demonstrate this use case. Specifically, we created a pair of rider and driver mobile apps to simulate the typical user experience in booking a ride-share with any of the major ride-sharing providers in the market.

The layout and flow of these interactions is shown in the Figure 11 below:

Essentially this exposes the vehicle sub-systems as APIs to the cloud to be controlled as a secure service. The driver app acts as a relay station between the vehicle and the rider app, which will control the vehicle's subsystems.

The driver app is paired to the vehicle through Bluetooth to the head unit, as it typically is. The professional driver uses this to facilitate Bluetooth phone calls, music, and running their ride-sharing application to receive rides, run the map, and receive payments. When a driver is ready to embark and receive passengers, he/she marks as such in the app and then can receive requests for rides.

The rider app can be run on any phone with no prior connections to the vehicle. Through a cloud connection, the rider requests a ride and is specifically paired to a vehicle and a driver app. Once the rider is in the vehicle, the driver can start the ride and so lock out other riders from taking the vehicle. By doing so, this creates a secure connection between the two phones to coordinate the ride.

In a similar fashion, our driver app also listens for requests for rides from the rider app. However, in this case, our app also adds a layer to facilitate commands to SDL to programmatically control radio and climate control settings. These commands can be triggered from the rider app, which are then passed to the cloud. The driver app is listening for these commands from the cloud and relays them to SDL to control the vehicle. This is all done through the same secure pairing of the driver and rider apps already done with ride-sharing applications today.

For our prototype, we used an Android driver application, both an iOS and a web-based rider app, and Google Firebase as the cloud service intermediary. While we only implemented climate and radio control, this is extensible to any other functions in the vehicle, both for monitoring data as well as controlling the sub-systems.

Automatic Audio Equalizer

Beyond this, we can also add a feature for ride-sharing to adjust the audio equalizer depending on the occupancy of the vehicle. To optimize the audio, most vehicles have the capability to adjust where the audio system focuses the sound. That is, like a home audio system, audio can be focused in the front, middle, or rear seats.

However, most car owners do not even know this feature exists, let alone take the time to adjust it. While it may seem a trivial setting, in the case of ride-sharing, it can be useful to focus the music towards either the driver or the passengers, particularly with our capability to let the passengers choose their own music. When using the translation app, of course, the sound system should focus toward the driver so they can hear.

Given these examples, there is a use case for setting focus in the audio system in ride-sharing. Using SDL, we can intelligently set this through the app itself whenever it is necessary. For example, when using the translation application, the audio can be focused in the front on the driver. If the passenger requests control of the music, then the audio focus will target the rear where the passenger is seated. In all other cases, we will leave it at the discretion of the driver with the original settings on the vehicle.

Taking this a step further now, with SDL, we also can control the sound equalizer. This is also a setting that few know about or set themselves. With SDL, we can set this programmatically through our mobile app. With metadata about the song being played, whether through NextRadio, streaming radio service providers, or metadata on the local file itself, we can know the genre of the song currently being played. Together with genre-specific presets, the equalizer can dynamically be set from song to song. For example, if listening to music from a local library of favorite songs, the equalizer will set itself automatically to match the current song. This enhances the experience and is a seamless process that can actually be done invisibly to the user.

Auto High Beam

In luxury vehicles, there is a feature called auto high beam, which automatically toggles the high beam at night. Typically, the driver is supposed to turn off the high beam at night when there is oncoming traffic or vehicles nearby in front to avoid blinding the other drivers. However, when there are no vehicles in front, one can re-engage the high-beam. Sometimes this interaction may take place many times on a given stretch of road.

Auto high beam controls this toggling at speeds of over 25 mph at night using a front-facing camera that detects lights from other vehicles or street lighting. When other vehicles are detected or speeds reduce below a threshold, it turns off the high beam. After a short while, it will re-engage the high beam.

On certain roads with short range line of sight due to curvature or changes in altitude, the brief delay before re-engaging the high beam may be long enough to encounter another oncoming vehicle and thus irritate the other driver. Also in subdivisions, the feature may engage the high beam even when typically, drivers would switch it off. In these instances, drivers will have to manually disengage auto high beam to disable it.

With SDL, the GPS location of these areas where drivers are disabling this feature can be recorded and intelligently managed. With this crowdsourced information, the feature can be automatically disabled in those areas while enabled in other areas.

SUMMARY

This paper summarizes the SmartDeviceLink platform and its capabilities as an Open Innovation Platform to bring novel Connected Car features and services. It is open source, so any automaker who wishes to adopt it as their system will be able to benefit from the work done by other contributors. For developers, features developed for SDL become portable across different vehicles which implement SDL.

We have presented several use cases for this technology, including intelligent climate control, enhanced hybrid radio, and mobility solutions. This is only intended to exhibit some possibilities. There are many other use cases, from dynamically controlling the audio equalizer to the seats positions, heating or cooling, and even massage seats.

The addition of more connected sensors like the air quality sensors will enable the vehicle to gain more data and insight. With the popularity of wearable devices like the Apple Watch, data like the user's real-time skin-temperature can be used to personalize climate settings using cloud services and machine learning algorithms. Besides learning from sensors, the user can also set preferences to guide the system. These can be implemented through neural networks. Neural networks have been shown to be an efficient and effective approach to implement non-linear models for personalized ambient experience such as climate control [10-11].

Finally, as vehicles move towards autonomous driving, this type of system becomes a necessity to improve the daily user experience. The main differentiator in a rideshare will be the personalization of the trip, given that there will be no car ownership in the process. This provides an extensible open innovation platform to facilitate implementation of novel features in the areas of infotainment and passenger comfort systems in the vehicle.

REFERENCES

(1.) Chesbrough, H. W. (2003). Open Innovation: The new imperative for creating and profiting from technology. Boston: Harvard Business School Press.

(2.) Chesbrough, H. W. (2005). Open Innovation: The New Imperative for Creating and Profiting from Technology. Boston, Massachusetts: Harvard Business School Publishing Corporation.

(3.) Hartmann, P., Trott, P. (2009). Why Open Innovation is Old Wine in New Bottles. International Journal of Innovation Management, 715-736. Retrieved October 13, 2016, from http://www.hamafarini.com/images/EditorUpload/1.pdf

(4.) SmartDeviceLink Consortium. 2017. SmartDeviceLink. [ONLINE] Available at: https://smartdevicelink.com/consortium/. [Accessed 20 Jan 2017].

(5.) Ford. 2016. Developer Documentation [ONLINE] Available at: https://developer.ford.com [Accessed 12 October 2016].

(6.) Daly, S., 2011. "Automotive Air Conditioning and Climate Control Systems". Butterworth-Heinemann,p 432.

(7.) Muller, D., Klingelhofer, D., Uibel, S., Groneberg, D.A., 2011. "Car indoor air pollution - analysis of potential sources". Journal of Occupational Medicine and Toxicology, 6:33.

(8.) Yang, J., Chen Y., Liu Y., Makke O., Yeung J., Gusikhin O., MacNeille, P., "The Effectiveness of Cloud-based Smart In-vehicle Air Quality Management". In proceedings of 2016 IEEE Advanced Information Management, Communicates, Electronic and Automation Control Conference, October 3-5, Xi'an, China, pp. 325-329.

(9.) Gusikhin, O., Makke, O., Yeung, J. and MacNeille, P. "SmartDeviceLink Application to Intelligent Climate Control". In Proceedings of the 13th International Conference on Informatics in Control, Automation and Robotics (ICINCO 2016) - Volume 1, pages 234-240 ISBN: 978-989-758-198-4.

(10.) Thomas, B., Soleimani-Mohseni, M., Jan 2007. Artificial neural network models for indoor temperature prediction: investigations in two buildings. Neural Computing and Applications, Volume 16, Issue 1, pp 81-89.

(11.) Kajino, Y., Sugi, H., Kawai, T., Ito, Y., Tateishi, M., Samukawa, K., 2000. Development of Automatic Climate Control with Neural Control. SAE Technical Paper 2000-01-0978, pp. 1-6.

CONTACT INFORMATION

Jeffrey Yeung, M.S.

Ford Motor Company

Dearborn, MI

jyeung5@ford.com

ACKNOWLEDGMENTS

The authors wish to thank Ben Hussmann from NextRadio for kindly reviewing this paper.

DEFINITIONS/ABBREVIATIONS

SDL - SmartDeviceLink

HMI - human machine interface

API - application program interface

CAN - controller area network

Jeffrey Yeung, Omar Makke, Perry MacNeille, and Oleg Gusikhin

Ford Motor Company

doi:10.4271/2017-01-1649
Table 1. SDL Remote Control APIs

API                    Parameters  Description

get inter for Vehicle  Zone        Returns supported modules the
Capabilities()                     vehicle is equipped with (Radio,
                                   Climate Unite...).
get inter for Vehicle  Zone        Reads module data, Modules are
Data()                 Module      obtained from get inter for vehicle
                                   Capabilities.
get inter for Vehicle  Zone        Control API. Sets the data of the
Data()                 Module,     Module for the specified zone
                       Data

Table 2. SDL Parameters for Climate Control

Parameter           Description

acEnable            Taggles AC ON/OFF
desiredTemp         User input (the set temperature in the head unit).
fanSpeed            Blower speed in %
currentTemp         Outside Ambient Temperature
temperatureUnite    Unit of the temperatures
circulateAirEnable  Air recirculation ON/OFF
autoModeEnable      Auto mode value ON/OFF
DefrostZone         Front, Rear defrost ON/OFF
DualModeEnable      Dual mode is ON/OFF for units supporting zone
                    control

Table 3. SDL Parameters for Radio Control

Parameters             Description

frequency Integer      The Integral part of the frequency
Frequency Fraction     The decimal part of the frequency
bond                   AM/FM/XM
rdsData                RDS Data received for the station (read only)
availableHDs           Number of available HD channels (read only)
signalStrength         Signal strength in percentage
signalChangeThreshold  Threshold for "available" in percentage
radioEnable            Radio is ON or OFF
COPYRIGHT 2017 SAE International
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2017 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Yeung, Jeffrey; Makke, Omar; MacNeille, Perry; Gusikhin, Oleg
Publication:SAE International Journal of Passenger Cars - Electronic and Electrical Systems
Article Type:Report
Geographic Code:1USA
Date:May 1, 2017
Words:6217
Previous Article:Real-time Sensing of Particulate Matter in a Vehicle Exhaust System.
Next Article:Using Bluetooth Low Energy for Dynamic Information-Sharing in Vehicle-to-Vehicle Communication.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters