Cloud-based vehicle information and control system

Systems and methods for providing a cloud-based vehicle information and control ecosystem are disclosed. A particular embodiment includes: providing a first layer of a cloud-based vehicle information and control ecosystem, the first layer being in data communication with at least one network resource via a network cloud; providing a second layer of the cloud-based vehicle information and control ecosystem in data communication with the first layer, the second layer being in data communication with at least one mobile device; providing a third layer of the cloud-based vehicle information and control ecosystem in data communication with the second layer, the third layer including a subsystem for linking the third layer to at least one electronic control unit (ECU) of a vehicle; and causing, by use of a data processor, data indicative of a state change occurring in the at least one ECU to be communicated to a component in the first layer.

TECHNICAL FIELD

This patent document pertains generally to tools (systems, apparatuses, methodologies, computer program products, etc.) for allowing electronic devices to share information with each other, and more particularly, but not by way of limitation, to a cloud-based vehicle information and control system.

BACKGROUND

An increasing number of vehicles are being equipped with one or more independent computer and electronic processing systems. Certain of the processing systems are provided for vehicle operation or efficiency. For example, many vehicles are now equipped with computer systems for controlling engine parameters, brake systems, tire pressure and other vehicle operating characteristics. A diagnostic system may also be provided that collects and stores information regarding the performance of the vehicle's engine, transmission, fuel system and other components. The diagnostic system can typically be connected to an external computer to download or monitor the diagnostic information to aid a mechanic during servicing of the vehicle.

Additionally, other processing systems may be provided for vehicle driver or passenger comfort and/or convenience. For example, vehicles commonly include navigation and global positioning systems and services, which provide travel directions and emergency roadside assistance. Vehicles are also provided with multimedia entertainment systems that include sound systems, e.g., satellite radio, broadcast radio, compact disk and MP3 players and video players. Still further, vehicles may include cabin climate control, electronic seat and mirror repositioning and other operator comfort features.

However, each of the above processing systems is independent, non-integrated and incompatible. That is, such processing systems provide their own sensors, input and output devices, power supply connections and processing logic. Moreover, such processing systems may include sophisticated and expensive processing components, such as application specific integrated circuit (ASIC) chips or other proprietary hardware and/or software logic that is incompatible with other processing systems in the vehicle.

Moreover, these processing systems in vehicles have failed to exploit the advantages of wide-area data networking. Although some vehicles support the use and integration of mobile phones in some vehicle subsystems for voice communications, conventional vehicle systems do not support the integration of wide-area data networking or the use of information obtained from or sent to network resources.

DETAILED DESCRIPTION

As described in various example embodiments, systems and methods for providing a cloud-based vehicle information and control ecosystem are described herein. In one particular embodiment, the cloud-based vehicle information and control ecosystem can be configured like the ecosystem illustrated inFIG. 2. However, it will be apparent to those of ordinary skill in the art that the cloud-based vehicle information and control ecosystem described and claimed herein can be implemented, configured, and used in a variety of other applications and systems.

Particular example embodiments relate to the communication of signals and information and the activation of procedures and/or services between network resources, mobile devices, and Controller Area Network (CAN) buses in a vehicle. Embodiments disclosed herein generally enable the communication of signals between electronic control units (ECUs) of a vehicle, a controller platform, network-based mobile devices, such as mobile phones or mobile computing platforms, and network resources, such as server computers. Data signals communicated from the ECUs to the mobile devices or network resources may include information about the state of one or more of the components of the vehicle. In particular, in some embodiments the data signals, which are communicated from the ECUs to the CAN bus, are abstracted by an automotive data abstraction and communication device (abstraction device). The abstraction device connects directly to an On Board Diagnostics (OBD) connector that enables access to the CAN bus. The abstraction device converts the data signals from a vehicle-specific format to a mobile device format defined by an Application Programming Interface (API). The abstraction device then wirelessly and securely transmits the data signals to the mobile device and/or a network resource. By converting the data signals to the mobile device format, the mobile device may use the data signals without knowing the vehicle-specific format. Additionally, the mobile device format defined by the API exposes the data signals, ECUs and other vehicle hardware and software in a standardized way, thereby enabling multiple vendors or software developers to create mobile device applications that process the data signals. In the same way, the API can expose the data signals. ECUs and other vehicle hardware and software in a standardized way for the network resources.

Additionally, a user of the mobile device and/or a network resource can send a write or control signal from the mobile device and/or network resource through the abstraction device to the CAN bus. The write/control signal enables the user of the mobile device and/or network resource to alter the state of one or more components included in the vehicle. The write signal is formatted in the mobile device format defined by the API and wirelessly transmitted to the abstraction device. The abstraction device converts the write/control signal to the vehicle-specific format and communicates the write signal to the vehicle. By converting the write signal from the mobile device format defined by the API to the vehicle-specific format, the abstraction device may interface with multiple vehicles. Additionally, the mobile device format defined by the API acts as a common programming language enabling multiple vendors to write mobile device and/or network resource applications that may communicate read and write signals to multiple types of vehicles independent of the model or manufacturer.

Additionally, the abstraction device can include a certification module, which controls access to some data signals and limits access to one or more components of the vehicle through verification of a user, a mobile device application, a mobile device, a network resource, a network resource application, software on the head unit or other device, or some combination thereof. By including the certification module, the system controls access to sensitive portions of the CAN bus, such as airbags, brakes, or Global Positioning System (GPS) location. This assures that a virus, a rogue application, or misuse by a user cannot damage the vehicle or injure the occupants, while allowing an approved application access to any required data or device. Additionally, the certification module allows the manufacturer to control dissemination of proprietary signals. Additional embodiments are described with reference to the appended drawings.

The certification module can be configured to grant various levels of access to the CAN bus and associated CAN messages based on a level of authorization associated with the application or device that requests such access. For example, a fully certified mobile device or a mobile device having a fully certified app (referred to herein as “OEM certified”) can be assigned a full authentication level and granted access to native, raw data signals on the CAN bus. In this way, equipment used by manufacturers, authorized service technicians, etc., can be given direct access to raw CAN messages, without abstraction by an API. In this way, only OEM certified devices can obtain access to the raw CAN messages, thereby giving vehicle manufacturers the ability to restrict access to raw CAN messages by devices that are not granted full certification. In contrast, in the absence of the embodiments described herein, there has been no certification in many vehicles regarding the devices that can be given direct access to raw CAN messages, which has presented significant security and safety issues.

Moreover, the certification module can be configured to grant more restrictive access to the CAN bus to mobile devices that do not qualify for OEM certification. For example, a mobile device and/or a network resource that is authenticated by the certification module at a more restrictive authentication level, can be given access to higher-level events mapped from the CAN messages, as opposed to being given direct access to raw CAN messages. The authentication level might give only read access, or read access combined with write access for only certain events (i.e., those that do not pose a safety hazard).

As used herein, the term “CAN bus,” refers to any bus used in a vehicle for communicating signals between ECUs or components. The CAN bus may be a bus that operates according to versions of the CAN specification, but is not limited thereto. The term “CAN bus” can therefore refer to buses that operate according to other specifications, including those that might be developed in the future.

As used herein and unless specified otherwise, the term “mobile device” extends to any device that can communicate with the abstraction devices described herein to obtain read or write access to messages or data signals communicated on a CAN bus or via any other mode of inter-process data communications. In many cases, the mobile device is a handheld, portable device, such as a smart phone, mobile phone, cellular telephone, tablet computer, laptop computer, display pager, radio frequency (RF) device, infrared (IR) device, global positioning device (GPS). Personal Digital Assistants (PDA), handheld computers, wearable computer, portable game console, other mobile communication and/or computing device, or an integrated device combining one or more of the preceding devices, and the like. Additionally, the mobile device can be a computing device, personal computer (PC), multiprocessor system, microprocessor-based or programmable consumer electronic device, network PC, diagnostics equipment, a system operated by a vehicle manufacturer or service technician, and the like, and is not limited to portable devices. The mobile device can receive and process data in any of a variety of data formats. The data format may include or be configured to operate with any programming format, protocol, or language including, but not limited to, JavaScript, C++, iOS, Android, etc.

As used herein and unless specified otherwise, the term “network resource” extends to any device, system, or service that can communicate with the abstraction devices described herein to obtain read or write access to messages or data signals communicated on a CAN bus or via any other mode of inter-process or networked data communications. In many cases, the network resource is a data network accessible computing platform, including client or server computers, websites, mobile devices, peer-to-peer (P2P) network nodes, and the like. Additionally, the network resource can be a web appliance, a network router, switch, bridge, gateway, diagnostics equipment, a system operated by a vehicle manufacturer or service technician, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” can also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. The network resource may include any of a variety of providers or processors of network transportable digital content. Typically, the file format that is employed is Extensible Markup Language (XML), however, the various embodiments are not so limited, and other file formats may be used. For example, data formats other than Hypertext Markup Language (HTML)/XML or formats other than open/standard data formats can be supported by various embodiments. Any electronic file format, such as Portable Document Format (PDF), audio (e.g., Motion Picture Experts Group Audio Layer 3-MP3, and the like), video (e.g., MP4, and the like), and any proprietary interchange format defined by specific content sites can be supported by the various embodiments described herein.

The data network (also denoted the network cloud) used with the network resources can be configured to couple one computing or communication device with another computing or communication device. The network may be enabled to employ any form of computer readable data or media for communicating information from one electronic device to another. The network can include the Internet in addition to other wide area networks (WANs), metro-area networks, local area networks (LANs), other packet-switched networks, circuit-switched networks, direct data connections, such as through a universal serial bus (USB) or Ethernet port, other forms of computer-readable media, or any combination thereof. On an interconnected set of networks, including those based on differing architectures and protocols, a router or gateway can act as a link between networks, enabling messages to be sent between computing devices on different networks. Also, communication links within networks can typically include twisted wire pair cabling, USB, Firewire, Ethernet, or coaxial cable, while communication links between networks may utilize analog or digital telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Networks (ISDNs). Digital User Lines (DSLs), wireless links including satellite links, cellular telephone links, or other communication links known to those of ordinary skill in the art. Furthermore, remote computers and other related electronic devices can be remotely connected to the network via a modem and temporary telephone link.

The network may further include any of a variety of wireless sub-networks that may further overlay stand-alone ad-hoc networks, and the like, to provide an infrastructure-oriented connection. Such sub-networks may include mesh networks, Wireless LAN (WLAN) networks, cellular networks, and the like. The network may also include an autonomous system of terminals, gateways, routers, and the like connected by wireless radio links or wireless transceivers. These connectors may be configured to move freely and randomly and organize themselves arbitrarily, such that the topology of the network may change rapidly.

The network may further employ a plurality of access technologies including 2nd (2G), 2.5, 3rd (3G), 4th (4G) generation radio access for cellular systems, WLAN, Wireless Router (WR) mesh, and the like. Access technologies such as 2G, 3G, 4G, and future access networks may enable wide area coverage for mobile devices, such as one or more of client devices, with various degrees of mobility. For example, the network may enable a radio connection through a radio network access, such as Global System for Mobile communication (GSM), General Packet Radio Services (GPRS), Enhanced Data GSM Environment (EDGXE), Wideband Code Division Multiple Access (WCDMA), CDMA2000, and the like. The network may also be constructed for use with various other wired and wireless communication protocols, including TCP/IP, UDP, SIP, SMS, RTP. WAP, CDMA, TDMA, EDGE, UMTS. GPRS, GSM, UWB, WiMax, IEEE 802.11x, and the like. In essence, the network may include virtually any wired and/or wireless communication mechanisms by which information may travel between one computing device and another computing device, network, and the like.

In a particular embodiment, a platform system and/or a mobile device with may act as a client device enabling a user to access and use the cloud-based vehicle information and control system via the network. These client devices may include virtually any computing device that is configured to send and receive information over a network, such as network ecosystem as described herein. Such client devices may include mobile devices, such as cellular telephones, smart phones, tablet computers, display pagers, radio frequency (RF) devices, infrared (IR) devices, global positioning devices (GPS), Personal Digital Assistants (PDAs), handheld computers, wearable computers, game consoles, integrated devices combining one or more of the preceding devices, and the like. The client devices may also include other computing devices, such as personal computers (PCs), multiprocessor systems, microprocessor-based or programmable consumer electronics, network PC's, and the like. As such, client devices may range widely in terms of capabilities and features. For example, a client device configured as a cell phone may have a numeric keypad and a few lines of monochrome LCD display on which only text may be displayed. In another example, a web-enabled client device may have a touch sensitive screen, a stylus, and a color LCD display screen in which both text and graphics may be displayed. Moreover, the web-enabled client device may include a browser application enabled to receive and to send wireless application protocol messages (WAP), and/or wired application messages, and the like. In one embodiment, the browser application is enabled to employ HyperText Markup Language (HTML), Dynamic HTML, Handheld Device Markup Language (HDML), Wireless Markup Language (WML), WMLScript, JavaScript, EXtensible HTML (xHTML), Compact HTML (CHTML), and the like, to display and send a message with relevant information.

The client devices may also include at least one client application that is configured to receive content or messages from another computing device via a network transmission. The client application may include a capability to provide and receive textual content, graphical content, video content, audio content, alerts, messages, notifications, and the like. Moreover, the client devices may be further configured to communicate and/or receive a message, such as through a Short Message Service (SMS), direct messaging (e.g., Twitter), email, Multimedia Message Service (MMS), instant messaging (IM), internet relay chat (IRC), mlRC, Jabber, Enhanced Messaging Service (EMS), text messaging. Smart Messaging, Over the Air (OTA) messaging, or the like, between another computing device, and the like. The client devices may also include a wireless application device on which a client application is configured to enable a user of the device to send and receive information to/from network resources wirelessly via the network.

FIG. 1illustrates a block diagram of an example vehicle data abstraction and communication system100in which components of the embodiments described herein may be implemented.FIG. 1depicts an example of an operating environment for the vehicle data abstraction and communication systems described herein.FIG. 1also illustrates an example embodiment in which a mobile device102is identified as having an authentication level that permits the mobile device102to have access to higher-level events mapped from CAN messages, as opposed to being given direct access to raw CAN messages.

InFIG. 1, the system100includes a vehicle104, an abstraction device122, and a mobile device102. Generally,FIG. 1depicts the communication of data signals from the vehicle104to the abstraction device122and to the mobile device102. Some of the data signals can be produced at the vehicle104, the format of the data signals are converted at the abstraction device122, and the data signals are processed at the mobile device102.

FIG. 1depicts a system100that includes the vehicle104. The systems and methods described herein can be used with substantially any mechanized system that uses a CAN bus as defined herein, including, but not limited to, industrial equipment, boats, trucks, or automobiles; thus, the term “vehicle” extends to any such mechanized systems. The systems and methods described herein can also be adapted for use with other devices that have accessible data, such as medical equipment. The systems and methods described herein can also be used with any systems employing some form of network data communications.

In a particular embodiment related to a cloud-based vehicle information and control ecosystem, vehicle104may include multiple automotive components118A-118N (generally, a component118or components118). The components118include the individual apparatuses, systems, subsystems, mechanisms, etc. that are included in the vehicle104. The components118may include, but are not limited to, windows, door locks, oxygen sensors, an ignition system, windshield wipers, brakes, engines. GPS and navigation systems, a tachometer, etc.

The vehicle104may additionally include one or more electronic control units120A-120N (an ECU120or ECUs120). The ECUs120are associated with the components118. As used with respect to the relationship between the ECUs120and the components118, the term “associated with” may refer to the component118including an ECU120, the component118being coupled to and ECU120for monitoring a state of the component118, the ECU120controlling the component118, or some combination thereof. As illustrated inFIG. 1, one ECU120is associated with one component118. However, this depiction is not meant to be limiting. In some embodiments, one ECU120may be associated with multiple components118. Additionally or alternatively, multiple ECUs120may be associated with a single component118. Additionally or alternatively, some embodiments include ECUs120associated with some subset of ECUs120, etc.

InFIG. 1, a first component118A is associated with a first ECU120A, a second component1I188B is associated with a second ECLU1208, and an Nth component118N is associated with an Nth ECU120N. The inclusion of the Nth component118N, the Nth ECU120N, and the ellipses is meant to indicate that the number of components118and/or ECUs120are not limited. That is, the vehicle104may include hundreds or thousands of components118and/or ECUs120, for instance.

In the particular embodiment shown inFIG. 1, the first ECU120A associated with the first component118may monitor the first component118. The ECU120A may communicate a state or a condition of the first component as a data signal to the CAN bus116. For example, if the first component118A was the steering wheel, the first ECU120A may communicate the radial position of the steering wheel in real time to the CAN bus116. Similarly, the second ECU120B and the Nth ECU120N may communicate the data signals to the CAN bus116regarding the state or the condition of the second component118B and the Nth component120N, respectively. Accordingly, the data signals may include, but are not limited to, positions of the windows, positions of the door locks, oxygen levels measured in the oxygen sensors, ignition timing, state of the windshield wipers, a position of the steering wheel, RPM of the engine, and the like.

The data signals may be formatted in a vehicle-specific format—i.e., specific to a vehicle make and model. The vehicle-specific format generally refers to the format of the data signals for the vehicle104. That is, the vehicle104may be manufactured by a first manufacturer that may have a vehicle-specific format for all its vehicles. Alternatively, the first manufacturer may have a vehicle-specific format for different models, years, option packages, etc. Generally, the vehicle-specific formats of different vehicles104are not the same. Thus, a vehicle manufactured by the first manufacturer typically has a different vehicle-specific format that a second vehicle manufactured by a second manufacture. Additionally or alternatively, in some embodiments, the data signals may be differential signals.

The CAN bus116receives the data signals from the ECUs120. Additionally, the CAN bus116may enable the components118or some subset thereof to internally communicate without an additional computer system. Thus, data signals received at the CAN bus116may be available for download, may be internally communicated within the vehicle104, or may be dropped.

In some embodiments, the CAN bus116may be coupled to a bus connector126that enables access to the CAN bus116. For example, in this and other embodiments, the vehicle104may include an On Board Diagnostics (OBD) connector. The bus connector may be configured according to an OBD II specification, for instance. In embodiments with multiple CAN buses116, the vehicle104may include multiple bus connectors126and/or alternative bus connectors that enable access to one or more CAN buses116. In most modern vehicles, the CAN bus116includes the bus connector126located under the hood or accessible through the removal of a panel in the cabin of the vehicle104. However, embodiments described herein can be implemented by using connector124that connects with CAN bus116in any available way.

The data signals or some subset thereof may be communicated to the abstraction device122. In some embodiments, the abstraction device122is a discrete unit that can be adapted for use with one or more existing or new vehicles104. For example, as explained herein, the abstraction device122can be embodied in a discrete unit that can be installed in an existing or new vehicle104by connecting it to the bus connector126(e.g., an OBD II connector) associated with CAN bus116. In this way, the methods and systems described herein can be easily used with substantially any new or existing vehicle104that includes a CAN bus116.

In other embodiments, the abstraction device122or elements thereof may be integrated into new vehicles or retrofitted into an existing vehicle. Under this approach, the elements of the abstraction device122are a substantially permanent system of vehicle104. In this case, abstraction device122can replace or supplement the bus connector126that may otherwise be present in the vehicle104. In these embodiments, the abstraction device122may be a platform within a larger apparatus or system or may be an integrated circuit with controllers and/or microcontrollers that manage or dictate the function of the abstraction device122.

The abstraction device122couples with the bus connector126associated with the CAN bus116via a connector124. For example, the CAN bus116may have a bus connector126(e.g., an OBD II connector) that is adapted to connect with the connector124or the abstraction device122may include the connector adapted to interface with the bus connector126. Generally, the interface between the connector124and the bus connector126includes a physical connection as well as an electrical interface such that the data signals communicated to the CAN bus116may be further communicated to the abstraction device122.

When connected to the CAN bus116, the connector124may communicate the data signals to mapping platform112. Generally, the mapping platform112may be configured to convert a data signal from the vehicle-specific format into a mobile device format and/or a network resource format defined by an Application Programming Interface (API). Additionally, in some embodiments, the API included in the mapping platform112may enable the conversion of data signals from multiple vehicle-specific formats to the mobile device format and/or a network resource format. Thus, the mapping platform112may not be specific to the vehicle104. Some additional details of the mapping platform112and the API are discussed with reference toFIG. 3.

Alternatively, in some embodiments, the abstraction device122may include one or more controllers114that may be configured to receive one or more data signals from the CAN bus116. The controller114may then communicate the data signals to the mapping platform112.

In the example embodiment ofFIG. 1, the abstraction device122includes a certification module108configured to limit access to the data signal converted to the mobile device format by the mapping platform112. In the example ofFIG. 1, the certification module108determines that mobile device102is authenticated at a level that permits the mobile device102to access events mapped from the CAN messages by the mapping platform112rather than accessing the native, raw CAN messages. For instance, mobile device102can be a device operated by a driver or passenger of the vehicle, with a mobile device application106that is configured to detect, respond to, or initiate events mapped from the CAN messages by the mapping platform112. The events can be limited to those that have been determined to be appropriate for the authentication level of the mobile device102. In this way, mobile device102, in this example, is prevented from having full access to the raw CAN messages, thereby substantially limiting the ability of mobile device102to perform action that might damage the vehicle104or put the passengers in danger.

In this and other embodiments, the certification module108may function through communication with a transceiver110and a controller114. The transceiver110(“Tx/Rx” inFIG. 1) may receive an identification signal from the mobile device102and/or a mobile device application106on the mobile device102. The communication of the identification signal is indicated by the arrow128inFIG. 1. The identification signal128may include one or more privileges possessed by the mobile device102and/or the mobile device application106. For example, the mobile device102may be owned or operated by a mechanic who may have a specific privilege without authentication of the specific mobile device application106or the specific mobile device application106may include a privilege. Some examples of privileges may include one or more read privileges and/or one or more write privileges. The identification signal128may be communicated from the transceiver110to the certification module108. The certification module108may verify or authenticate whether the mobile device102and/or the mobile device application106includes a specific privilege.

The certification module108may communicate whether the mobile device102and/or the mobile device application106has an authentication level that permits access to events mapped by mapping module112or direct access to raw CAN messages. In this example, in which mobile device102has an authentication level that permits access to events, the certification module communicates whether the authentication level grants the mobile device102specific privilege to the controller114. If the mobile device102and/or the mobile device application106do not include the specific privilege, then the controller114may prohibit conversion of data signals and/or transmission of the data signals from the transceiver110to the mobile device102. If however, the mobile device102and/or the mobile device application106do include the specific privilege, the controller114may allow the mapping platform112to perform a conversion and/or the transmission of the data signals to the mobile device102by the transceiver110. The certification module108may therefore restrict the transmission of the data signal through authentication of privileges assigned to the mobile device102or the mobile device application106.

In some embodiments, the certification module108may be able to authenticate or verify multiple read privileges. Different read privileges may correspond to different subsets of the data signals that may be converted by the mapping platform112and/or transmitted to the mobile device102. For example, the read privileges may include a first read privilege that prevents the transmission of a first subset of data signals and a second read privilege that may allow the transmission of the first subset of data signals.

Abstraction device122can be implemented using systems that enhance the security of the execution environment, thereby improving security and reducing the possibility that the abstraction device122and the related services could be compromised by viruses or malware. For example, abstraction device122can be implemented using a Trusted Execution Environment, which can ensure that sensitive data is stored, processed, and communicated in a secure way.

As stated above, the transceiver110may receive data signals that have been converted to the mobile device format and/or a network resource format defined by the API. The transceiver110may then communicate the data signals formatted in the mobile device format to the mobile device102. InFIG. 1, the communication of the data signal to the mobile device102is represented by arrow130A. More specifically, in this and other embodiments, the transceiver110may be configured to wirelessly communicate the data signal in the mobile device format to the mobile device102. The transceiver110may include several configurations. In this and other embodiments, the transceiver110may include: a wireless receiver to receive identification signals and/or write signals from the mobile device102; another receiver to receive the data signals from the mapping platform112; a wireless transmitter to communicate the data signals in the API to the mobile device102; and another transmitter that communicates identification signals to the communication module108and/or write signals to the mapping platform112. In some embodiments, the transceiver110includes a Bluetooth transceiver.

Additionally in some embodiments, the transceiver110may establish a secure channel between the abstraction device122and the mobile device102. In addition to or alternative to the secure channel, the abstraction device122may encrypt the data signals formatted in the mobile device format. The mobile device102may decrypt the data signals. The inclusion of the secure channel and/or encryption may enhance security of the data signals communicated to the mobile device102.

The mobile device102receives the data signals communicated from the abstraction device122. In embodiments in which the transceiver110wirelessly communicates the data signals to the mobile device102, the mobile device102can include wireless capabilities such as Bluetooth. Wi-Fi, 3G, 4G, LTE, etc. For example, if the transceiver110includes a Bluetooth transceiver, the mobile device102includes Bluetooth capabilities. Generally, the mobile device102includes one or more mobile device applications106that process the data signals. The mobile device application106may be loaded, downloaded, or installed on the mobile device102. Alternatively, the mobile device102may access the mobile device application106via a network cloud or internet browser, for example. The mobile device application106may also be accessed and used as a Software as a Service (SaaS) application. The mobile device application106may be written or created to process data signals in the mobile device format rather than the vehicle-specific format. Accordingly, the mobile device application106may be vehicle-agnostic. That is, the mobile device application106may process data signals from any vehicle104once the data signals formatted in the vehicle-specific format are converted by the mapping platform112.

In some embodiments, the mobile device application106includes an ability to perform an API call. The API call is represented inFIG. 1by arrow132A. The API call132A may be an integrated portion of the mobile device application106and may allow a user of the mobile device102to request data signals from the vehicle104. The API call132A may be communicated to the transceiver110, which then relays the content of the API call132A through the mapping platform112, which converts the requested data signals to the mobile device format. The requested data signals are transmitted to the mobile device102. In other embodiments, a remote procedure call (RPC) can be used to request data or invoke a function using an inter-process communication that allows a mobile device application106, for example, to cause a sub-process or procedure to execute in a vehicle component118or the abstraction device122.

By processing the data signals, the mobile device application106may function better than a mobile device application without the data signals or may be able to provide functionality not possible without the data signals. For example, the mobile device applications106may include a navigation application. The navigation application may receive GPS signals as well as data signals related to a radial position of the steering wheel, an angle of the tires, a speed, etc. of the vehicle104. The navigation application may process the GPS signals as well as the data signals from the vehicle104. Thus, the navigation application may output more accurate navigation data than another navigation application that only processes GPS signals.

Additionally or alternatively, the mobile device application106may enable abstraction of data signals for aggregate uses. For some aggregate uses, the mobile device application106may sync with one or more secondary systems (not shown). For example, the mobile device102may abstract data signals related to states of the windshield wipers. The mobile device102may communicate with a secondary system that determines weather patterns based on the state of windshield wipers in multiple vehicles in a given location at a given time.

Examples of the mobile device applications106are not limited to the above examples. The mobile device application106may include any application that processes, abstracts, or evaluates data signals from the vehicle104or transmits write/control signals to the vehicle104.

Referring now toFIG. 2, a cloud-based vehicle information and control ecosystem201is illustrated. In an example embodiment, the communication path between a mobile device and the subsystems of a vehicle as described above can be expanded into a cloud-based vehicle information and control ecosystem that brings the full power of the Web to bear on enhancing the driving experience. In the particular example embodiment shown inFIG. 2, the ecosystem201can be partitioned into three layers: an application layer (first layer), a framework layer (second layer), and a platform layer (third layer). The application layer represents the most abstract and broad level of the vehicle information and control system. The application layer can include a vehicle information and control system210, which can provide several subsystems including a map or geo-location-based support subsystem212, a user or people/communication-based support subsystem214, a media (e.g., audio or video) support subsystem216, and a vehicle subsystem218. These subsystems provide support for a variety of vehicle, driver, passenger, and 3rdparty applications, such as geo-navigation, in-vehicle control of media, hands-free communication, monitoring and control of various vehicle systems and components, convergence of social communities with vehicle operation, mining of vehicle and/or driving related data from a single vehicle or thousands of vehicles. The application layer can be in data communication with content sources240via the network cloud205directly or via one or more apps (software application modules)242configured to process and serve data and services from a particular content source240. The network cloud205represents one or more of the various types of data networks described above, such as the Internet, cellular telephone networks, or other conventional data networks and related network protocols. The content sources240represent a type of the network resources (e.g., server computers, websites, etc.) described above. In an example embodiment, the application layer is configured to provide information access and control to users from a variety of user devices via local or remote data communications.

Additionally, the application layer can provide a user interface server220to support human interaction with the various applications of the application layer. In a particular embodiment, the user interface server220can include: a map or geo-location-based support subsystem interface222, a user or people/communication-based support subsystem interface224, a media (e.g., audio or video) support subsystem interface226, and a vehicle subsystem interface228. The user interface server220can be in data communication with the vehicle information and control system210via the network cloud205. The user interface server220can also be in data communication with content sources240via the network cloud205.

In an example embodiment, the map or geo-location-based support subsystem212and its related interface222provides information and services to support in-vehicle navigation, mapping, routing, location searching, proximity alerting, and a variety of functions related to geo-location. One of the components118of the vehicle104can include a global positioning system (GPS) device that can produce a geo-coordinate position of the vehicle104at any point in time. Alternatively or in addition, a GPS device can be available in a mobile device that is accessible to one of the components118of the vehicle104. The data from these one or more GPS devices is accessible to the geo-location-based support subsystem212using the data transfer mechanisms described above. The geo-location-based support subsystem212can use this geo-coordinate position of the vehicle104to correlate the locations of points of interest in proximity to the location of the vehicle. The locations of these points of interest can be obtained from a locally maintained database or from any of the network resources accessible via the network cloud205. The geo-location-based support subsystem interface222can present these points of interest to an occupant of the vehicle104using the data transfer mechanisms described above. The occupant of the vehicle can select one or more points of interest and the geo-location-based support subsystem212can generate mapping, navigation, and routing information related to the selected points of interest. The geo-location-based support subsystem interface222can also generate alerts to notify the vehicle occupant of the proximity of a point of interest.

In an example embodiment, the user or people/communication-based support subsystem214and its related interface224provides information and services to support interactions and communications between people. These interactions and communications can include in-vehicle wireless telephone communications, messaging, texting, social network updates (e.g., Facebook, Twitter, etc.), contact list management, conferencing, and the like. The user or people/communication-based support subsystem214can also coordinate with the geo-location-based support subsystem212to correlate the geo-locations of people of interest and generate corresponding alerts. The people of interest can be determined or user-specified based on contact lists, social network profiles, network resource searches, and the like.

In an example embodiment, the media (e.g., audio or video) support subsystem216and its related interface226provides information and services to support the search, selection, purchase, and playing of audio, video, or other media selections in the vehicle. One of the components118of the vehicle104can include a media player, which can receive content for playback from a traditional antennae source, an optical disc source (e.g., compact disc—CD), magnetic tape, or the like. Additionally, the media player can include a dock or physical interface for receiving a portable MP3 player, cellular telephone, or other mobile device. The media player can be configured to play or record media content from these mobile devices. Moreover, the media player can include an interface for search, selection, purchase, and playing of audio, video, or other media selections from a network resource. In this manner, any media content available in the network cloud205can be streamed or downloaded to a media player and played or recorded in the vehicle.

In an example embodiment, the vehicle subsystem218and its related interface228provides information and services to support the monitoring, configuration, and control of vehicle subsystems. As described above, the components118of the vehicle104can include a variety of vehicle subsystems and related ECUs. The status of these vehicle subsystems can be communicated through the abstraction layers shown inFIG. 2as described above. The vehicle subsystem218can receive these vehicle subsystem status signals and process these signals in a variety of ways. Similarly, vehicle control signals generated by the vehicle subsystem218and its related interface228can be communicated through the abstraction layers shown inFIG. 2as described above. These control signals can be used by one or more components118of the vehicle104to configure and control the operation of the one or more components118.

Referring still toFIG. 2, the framework layer represents a set of interfaces and control subsystems supporting the application layer and platform layer to which the framework layer is connected. The framework layer provides a lower level of abstraction for servicing a particular type of device, such as a mobile device102and the mobile apps160therein. The framework layer can provide a user interface server250to support human interaction with the various applications of the application layer via a map or location-based support subsystem interface252, a user or people/communication-based support subsystem interface254, a media support subsystem interface256, and a vehicle subsystem interface258. In one embodiment, the user interface server250at the framework layer can substantially mirror the functionality provided by the user interface server220at the application layer, except the user interface server250can be implemented in a smaller footprint (e.g., requires less memory and less processing power). As a result, the user interface server250may have less robust functionality or a reduced level of functionality with respect to subsystems of the user interface server250and corresponding subsystems of user interface server220. However, the user interface server250can still provide support (albeit a reduced level of functionality) for vehicle and/or driver applications even when connection with the network cloud205is interrupted, intermittent, or temporarily lost. Thus, the framework layer is well-suited, though not exclusively suited, to a mobile environment where uninterrupted access to the network cloud205cannot always be assured. When access to the network cloud205is available, the full support of the vehicle and/or driver applications can be provided by the components of the application layer. When access to the network cloud205is not available or not reliable, a somewhat reduced level of support of the vehicle and/or driver applications can still be provided by the components of the framework layer without network cloud205connectivity. As shown inFIG. 2, the user interface server250can provide a user interface for the mobile apps executing on a mobile device102. Because the user interface server250is in data communications with the components118of the vehicle104via the platform system270(described below), the user interface server250can provide any data or vehicle status signals needed by a mobile device app106. Similarly, the user interface server250can communicate any control signals or configuration parameters from the mobile device app106to a corresponding component118via the platform system270.

The platform layer represents a variety of components designed to reside on or with a platform system270, which is typically installed on or in a vehicle, such as the vehicle104described above. As shown inFIG. 2, the platform system270, of an example embodiment, can include a cloudcast subsystem272, a carlink subsystem274, a platform operating system276, and a virtualization module278. The platform operating system276can provide an execution environment for the platform system270components and interfaces to low-level hardware. The platform operating system276can execute platform apps105to process platform system270data and/or data captured from the ECUs of the vehicle. The virtualization module278can provide a logical abstraction or virtualization of the resources (hardware or software functional components) installed with or accessible to the platform system270. The cloudcast subsystem272provides a variety of technologies and/or interfaces with which the platform system270can, for example, decode data and/or a media stream for presentation to vehicle occupants. A detail of cloudcast subsystem272in a particular embodiment is shown inFIG. 3.

As shown inFIG. 3, the cloudcast subsystem272of the platform system270can include an HDMI (High-Definition Multimedia Interface) module including a compact HDMI audio/video interface for transferring uncompressed digital audio/video data from an HDMI-compliant device (“the source”) to a compatible digital audio and/or display device in the vehicle. The HDMI module can operate in concert with the media (e.g., audio or video) support subsystem216and related interfaces226and256to present high quality media to vehicle occupants. Similarly, the cloudcast subsystem272can include a Mobile High-definition Link (MHL) for connecting portable electronic devices (e.g., mobile devices) to the platform system270. A variety of other modules or components provided in the cloudcast subsystem272can enable the transfer of data and media content to/from the platform system270in a variety of modes, protocols, and formats. In an example embodiment, these other modules provided in the cloudcast subsystem272can include a Bluetooth (a wireless technology standard for exchanging data over short distances) module, a USB (Universal Serial Bus) module, a WiFi (a popular technology allowing an electronic device to exchange data wirelessly over a computer network) module, a SPTS (Single Program Transport Stream) processing module, and a Droidlink module for communication with a particular type of mobile phone. It will be apparent to those of ordinary skill in the art that other modules or other groupings of modules can be provided in the cloudcast subsystem272to support particular types of mobile devices.

) As also shown inFIG. 3, the platform system270can include a headunit subsystem271, which includes a headunit native human machine interface (HMI) used to convey information and media content to an occupant of a vehicle. For example, the headunit native HMI can include devices or interfaces to devices, such as conventional plasma or liquid crystal display (LCD) monitors, heads-up display devices, projection devices, audio sound systems, and the like. Additionally, the headunit native HMI can include devices or interfaces to devices for receiving input from a user. For example, touch screens, buttons, softkeys, keyboards or key panels, voice command input systems and the like can be coupled with the headunit native HMI of the platform system270. The map or geo-location-based support subsystem212, user or people/communication-based support subsystem214, media (e.g., audio or video) support subsystem216, vehicle subsystem218and related interfaces222-258can receive input from occupants and render output for occupants using the various components of the headunit subsystem271. It will be apparent to those of ordinary skill in the art that various HMI devices can be provided in the platform system270of a particular vehicle. As shown inFIG. 3, the headunit native HMI of headunit subsystem271can also receive data and media streams from a variety of devices or sources, including audio sources, FM radio sources, Radio Data System (RDS), Digital Audio Broadcasting (DAB), touch panel sources, Hands-Free Profile (HFP), A2DP, and video sources, such as a backup camera in a vehicle. RDS is a communications protocol standard for embedding small amounts of digital information in conventional FM radio broadcasts. Digital Audio Broadcasting, (DAB or DAB+) is a digital radio transmission standard. Hands-Free Profile (HFP) is a Bluetooth profile allowing hands-free kits to communicate with mobile phones in a car. The profile defines how high quality audio (stereo or mono) can be streamed from one device to another over a Bluetooth connection. For example, music can be streamed from a mobile phone to a wireless headset, hearing aid & cochlear implant streamer, car audio, or from a laptop/desktop to a wireless headset. A2DP can be used in conjunction with an intermediate Bluetooth transceiver that connects to a standard audio output jack, encodes the incoming audio to a Bluetooth-friendly format and sends the signal wirelessly to Bluetooth headphones that decode and play the audio. Bluetooth headphones, especially the more advanced models, often come with a microphone and support for the Headset (HSP). Hands-Free (HFP) and Audio/Video Remote Control (AVRCP) profiles. Conventional A2DP is designed to transfer a uni-directional 2-channel stereo audio stream, like music from an MP3 player, to a headset or car radio. Thus, in a variety of ways, the headunit native HMI of the headunit subsystem271can receive and render information and media content for an occupant of a vehicle. Similarly, in a variety of ways, the headunit native HMI of the headunit subsystem271can receive input and command selections from an occupant of a vehicle. As described above in connection with mapping platform112, the platform system270can also include an event Human Interface Device (HID) mapper. The event HID mapper can map CAN messages to corresponding higher-level events. The higher-level events can trigger communications to other parts and other layers of the system, such as via a Bluetooth interface.

Referring still toFIG. 3, the platform system270can also include the carlink module274. The carlink module274, of an example embodiment, performs a function similar to the abstraction device122described above. In particular, the carlink module274may include one or more controllers that may be configured to receive one or more data signals from the CAN bus116. In this manner, the carlink module274provides a link between the platform system270and the vehicle ECUs coupled to the CAN bus116. The controller(s) in the carlink module274may then communicate the data signals to the cloudcast subsystem272and/or other subsystems of the platform system270. In particular, low-level state changes occurring in vehicle components118can be mapped to corresponding higher-level events using the event HID mapper of the headunit subsystem271as described above.

As shown inFIG. 3, the data and service requests exchanged between the carlink module274, the cloudcast subsystem272, the headunit subsystem271, and the mobile device106can be transferred using a Remote Procedure Call (RPC) framework277. Similarly, as shown inFIG. 2, the data and service requests exchanged between the platform layer, the framework layer, and the application layer of the cloud-based vehicle information and control ecosystem201can be transferred using a low overhead RPC mechanism280. The low overhead RPC mechanism280can also be used for transferring data and activating procedures between subsystems within each layer. The RPC framework277and the low overhead RPC mechanism280of an example embodiment provides a low overhead RPC mechanism configured to transfer data and service remote procedure requests in a more efficient manner than conventional RPC systems. Many of the state changes occurring in the vehicle components118can be represented in one or more data bits. The embodiments described herein provide a lower overhead RPC mechanism well-suited, though not exclusively suited, for applications, such as capturing data from and controlling actions of components118of a vehicle104. The embodiments described herein provide a lower overhead RPC mechanism for performing remote procedure calls between subsystems using a reduced amount of data, thereby allowing secure and efficient RPC using minimal communications bandwidth. The details of the lower overhead RPC mechanism of an example embodiment are described in a related patent application titled, “Systems and Methods for Low Overhead Remote Procedure Calls” and filed by the same applicant as the present patent application.

Referring now toFIG. 4, a diagram presents an example of a set of events300that can be exposed within the cloud-based vehicle information and control ecosystem201, wherein the events are determined to have an authentication level that grants access to higher-level events converted by the platform system270, as opposed to having direct access to raw CAN messages. The set of events300depicted inFIG. 4is just one example of the events that can be exposed within the cloud-based vehicle information and control ecosystem201. In this example, the set of events300are read-only or are selected to have little or no risk of potential damage to the automobile or danger to occupants if the events300happen to be accessed by viruses or malware or are initiated by user error. The set of events300can be mapped from corresponding vehicle state change information as described above.

In some embodiments, only a subset of events300are exposed within the cloud-based vehicle information and control ecosystem201if, for example, certain subsystems or devices are determined to have a more restricted authentication level. In general, the set of events300are selected based on the authentication level of the subsystem or device, the ECUs present in a particular vehicle make and model, and the intended purpose and functionality of the subsystems or devices that are to be used within the cloud-based vehicle information and control ecosystem201as described herein.

Referring now toFIG. 5, an example illustrates a mechanism for communicating a translation of raw CAN data to corresponding events that can be passed up and processed by higher abstraction layers of the cloud-based vehicle information and control ecosystem201. As described above, the platform system270of an example embodiment provides a mechanism configured to transfer data and service remote method or procedure requests at higher abstraction layers of the cloud-based vehicle information and control ecosystem201. State changes occurring in the vehicle components118(shown inFIG. 1) can be transferred to a corresponding signal transceiver of CAN transceiver unit501shown inFIG. 5. These vehicle state changes can be represented in one or more data bits. In the example embodiment shown inFIG. 5, the vehicle state changes can be transferred from the CAN transceiver unit501to event translator503via an internal bus. The event translator503can be configured to pack the vehicle state change information into the smallest unit of data needed to preserve the vehicle state change information. The event translator503can be configured to select the best of several available modes for communicating the vehicle state change information to higher-level processes of the cloud-based vehicle information and control ecosystem201.

FIG. 6illustrates an example of the data structures and methods or procedures used to service various events mapped from vehicle state change information passed to the subsystems of the cloud-based vehicle information and control ecosystem201as described above. As shown in the example ofFIG. 6, a radio in a vehicle can have a variety of events and actions associated therewith. Using the mechanisms described herein, these events and actions can be conveyed to and serviced by the various layers and subsystems of the cloud-based vehicle information and control ecosystem201as described herein. As a result, an efficient, scalable, modular, and layered cloud-based system can be implemented.

FIG. 7is a processing flow diagram illustrating an example embodiment of systems and methods for providing a cloud-based vehicle information and control ecosystem as described herein. The method of an example embodiment includes: providing a first layer of a cloud-based vehicle information and control ecosystem, the first layer being in data communication with at least one network resource via a network cloud (processing block810); providing a second layer of the cloud-based vehicle information and control ecosystem in data communication with the first layer, the second layer being in data communication with at least one mobile device (processing block820); providing a third layer of the cloud-based vehicle information and control ecosystem in data communication with the second layer, the third layer including a subsystem for linking the third layer to at least one electronic control unit (ECU) of a vehicle (processing block830); and causing, by use of a data processor, data indicative of a state change occurring in the at least one ECU to be communicated to a component in the first layer (processing block840).

The example computer system700includes a data processor702(e.g., a central processing unit (CPU), a graphics processing unit (CPU), or both), a main memory704and a static memory706, which communicate with each other via a bus708. The computer system700may further include a video display unit710(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system700also includes an input device712(e.g., a keyboard), a cursor control device714(e.g., a mouse), a disk drive unit716, a signal generation device718(e.g., a speaker) and a network interface device720.