Patent Description:
Furthermore, the manufacturers may statically code (or, in other words, "hard code") the command sets for performing each operational state change. That is, the manufacturers may statically code the command sets to conform to particular control bus protocols (some of which may be proprietary) by which the vehicle head unit may communicate with the one or more systems. The manufacturer may hard code an operating system executed by the vehicle head unit to generate command sets conforming to the control bus protocol. Each of the command sets may vary by the control bus and/or vendor of the one or more systems, etc., resulting in time consuming static coding of command sets for particular configurations of vehicles, which may even vary between vehicle model trims.

Document <CIT> discloses that a network gateway in a vehicle connects heterogeneous networks and buses within the vehicle. The gateway implements hardware acceleration to accomplish protocol translation, e.g., between CAN, LIN, Flexray, and Ethernet buses and networks. In particular, the gateway provides hardware accelerated packet filtering, header lookup, and packet aggregation features.

In general techniques of this disclosure are directed to enabling a vehicle computing device (such as a vehicle head unit) to apply an extensible mapping for vehicle system busses. That is, vehicle system busses may conform to different proprietary and open standards by which command sets are communicated between the vehicle head unit and one or more systems of the vehicle. The vehicle head unit executes an operating system that supports a uniform command set (or, in other words, a standard command set), while the vehicle system busses communicates local control messages specified in accordance with a particular control bus protocol of a plurality of control bus protocols. Rather than hard code the operating system to support the particular local control messages, various aspects of the techniques enable the vehicle head unit to obtain an extensible mapping between the standard command set and the local command set that conforms to the particular control bus protocol supported by the control bus.

As such, various aspects of the techniques enable manufacturers to define an extensible mapping, which may be updated over time to accommodate updates to one or more of the operating system, the control bus, and/or the vehicle systems. The extensible mapping defines translations between the standard command set and the local command set, which the vehicle head unit applies to automatically translate between the standard command set and the local command set. As only the extensible mapping is defined, rather than hard coding such mappings statically within the operating system to support only the local command set, various aspects of the techniques may improve the speed with which vehicle head unit operating systems may be developed, improve interoperability with new or changing control bus protocols, and otherwise improve development of vehicle head unit operating systems while accommodating rapid deployment of such operating system that provide full featured support in terms of local command sets.

Furthermore, various aspects of the techniques may enable a vehicle head unit to adapt command sets for controlling vehicle systems. The vehicle head unit may be configured to implement a hardware abstraction layer (HAL) that determines associations between the command sets and operational state changes of the vehicle systems. Based on these associations, the HAL may adapt the command sets in an attempt to expose additional functionality (as represented by one or more operational states) of the vehicle systems. As such, the techniques may enable the HAL to automatically determine command sets specific to a particular model and manufacturer without resorting to manual configuration of the command sets.

In this respect, various aspects of the techniques may promote more efficient operation of the vehicle head units themselves. That is, the HAL may determine the associations between the command sets and the operational state changes, and adapt, based on the associations, the command sets in a manner that more efficiently causes the vehicle systems to undergo the operational state change. Rather than issue command sets that are generic to a vehicle system chosen by a large number of models and manufactures, but that may be inefficient (although functional) for some vehicle systems, the techniques may allow the HAL to adaptively generate command sets that efficiently cause the vehicle system to perform the operational state change, thereby saving processor cycles, conserving memory bandwidth and underlying memory resources consumed therewith, and promoting, as a result, more efficient power consumption.

<FIG> is a block diagram illustrating an example vehicle <NUM> configured to perform various aspects of the techniques described in this disclosure. In the example of <FIG>, vehicle <NUM> is assumed in the description below to be an automobile. However, the techniques described in this disclosure may apply to any type of vehicle capable of conveying one or more occupants between locations, such as a motorcycle, a bus, a recreational vehicle (RV), a semi-trailer truck, a tractor or other type of farm equipment, a train, a plane, a drone, a helicopter, a personal transport vehicle, and the like.

In the example of <FIG>, vehicle <NUM> includes a processor <NUM>, a graphics processing unit (GPU) <NUM>, and system memory <NUM>. In some examples, processor <NUM>, GPU <NUM>, and a transceiver module (not shown in <FIG>) may be formed as an integrated circuit (IC). For example, the IC may be considered as a processing chip within a chip package, and may be a system-on-chip (SoC).

Examples of processor <NUM>, and GPU <NUM> include, but are not limited to, one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Processor <NUM> may represent a central processing unit (CPU) of vehicle <NUM>. In some examples, GPU <NUM> may be specialized hardware that includes integrated and/or discrete logic circuitry that provides GPU <NUM> with massive parallel processing capabilities suitable for graphics processing. In some instances, GPU <NUM> may also include general purpose processing capabilities, and may be referred to as a general purpose GPU (GPGPU) when implementing general purpose processing tasks (i.e., non-graphics related tasks). Although shown as a dedicated GPU <NUM>, GPU <NUM> may represent an integrated GPU that is integrated into the underlying circuit board (such as a so-called "motherboard"), or otherwise incorporated into processor <NUM>.

Processor <NUM> may execute various types of applications. Examples of the applications include web browsers, e-mail applications, spreadsheets, video games, or other applications that generate viewable objects for display. System memory <NUM> may store instructions for execution of the one or more applications. The execution of an application by processor <NUM> causes processor <NUM> to produce graphics data for image content that is to be displayed. Processor <NUM> may transmit graphics data of the image content to GPU <NUM> for further processing based on instructions or commands that processor <NUM> transmits to GPU <NUM>.

Processor <NUM> may communicate with GPU <NUM> in accordance with an application programming interface (API). Moreover, the techniques described in this disclosure are not required to function in accordance with an API, and processor <NUM> and GPU <NUM> may utilize any technique for communicating with GPU <NUM>.

System memory <NUM> may represent a memory for vehicle <NUM>. System memory <NUM> may comprise one or more computer-readable storage media. Examples of system memory <NUM> include, but are not limited to, a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), flash memory, or other medium that can be used to carry or store desired program code in the form of instructions and/or data structures and that can be accessed by a computer or a processor.

In some aspects, system memory <NUM> may include instructions that cause processor <NUM> to perform the functions ascribed in this disclosure to processor <NUM>. Accordingly, system memory <NUM> may be a non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors (e.g., processor <NUM>) to perform various functions.

System memory <NUM> is a non-transitory storage medium. The term "non-transitory" indicates that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted to mean that system memory <NUM> is non-movable or that its contents are static. As one example, system memory <NUM> may be removed from vehicle <NUM>, and moved to another device. As another example, memory, substantially similar to system memory <NUM>, may be inserted into autonomous vehicle <NUM>. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in RAM).

As further shown in the example of <FIG>, vehicle <NUM> may include a display <NUM> and a user interface <NUM>. Display <NUM> may represent any type of passive reflective screen on which images can be projected, or an active reflective or emissive or transmissive display capable of displaying images (such as a light emitting diode (LED) display, an organic LED (OLED) display, liquid crystal display (LCD), or any other type of active display). Although shown as including a single display <NUM>, vehicle <NUM> may include a number of displays that may be positioned throughout a cabin of vehicle <NUM>. In some examples, passive versions of display <NUM> or certain types of active versions of display <NUM> (e.g., OLED displays) may be integrated into seats, tables, roof liners, flooring, windows (or in vehicles with no windows or few windows, walls) or other aspects of the cabin of vehicles. When display <NUM> represents a passive display, display <NUM> may also include a projector or other image projection device capable of projecting or otherwise recreating an image on passive display <NUM>. Furthermore, display <NUM> may include displays integrated into driver-side dashboards that virtually represent physical instrument clusters (showing speed, revolutions, engine temperature, etc.).

Display <NUM> may also represent displays in wired or wireless communication with autonomous vehicle <NUM>. Display <NUM> may, for example, represent a computing device, such as a laptop computer, a heads-up display, a head-mounted display, an augmented reality computing device or display (such as "smart glasses"), a virtual reality computing device or display, a mobile phone (including a so-called "smart phone"), a tablet computer, a gaming system, or another type of computing device capable of acting as an extension of or in place of a display integrated into vehicle <NUM>.

User interface <NUM> may represent any type of physical or virtual interface with which a user may interface to control various functionalities of vehicle <NUM>. User interface <NUM> may include physical buttons, knobs, sliders or other physical control implements. User interface <NUM> may also include a virtual interface whereby an occupant of vehicle <NUM> interacts with virtual buttons, knobs, sliders or other virtual interface elements via, as one example, a touch-sensitive screen, or via a touchless interface. The occupant may interface with user interface <NUM> to control one or more of a climate within vehicle <NUM>, audio playback by vehicle <NUM>, video playback by vehicle <NUM>, transmissions (such as cellphone calls) through vehicle <NUM>, or any other operation capable of being performed by vehicle <NUM>.

User interface <NUM> may also represent interfaces extended to display <NUM> when acting as an extension of or in place of a display integrated into vehicle <NUM>. That is, user interface <NUM> may include virtual interfaces presented via a heads-up display (HUD), augmented reality computing device, virtual reality computing device or display, tablet computer, or any other of the different types of extended displays listed above.

In the context of vehicle <NUM>, user interface <NUM> may further represent physical elements used for manually or semi-manually controlling vehicle <NUM>. For example, user interface <NUM> may include one or more steering wheels for controlling a direction of travel of vehicle <NUM>, one or more pedals for controlling a rate of travel of vehicle <NUM>, one or more hand brakes, etc..

In the example of <FIG>, processor <NUM>, GPU <NUM>, system memory <NUM>, display <NUM>, and UI <NUM> may collectively represent, at least in part, what is referred to as a head unit <NUM> (or, in other words, a "vehicle head unit <NUM>") in the automotive context. Head unit <NUM> may represent any integrated or separate computing device capable of interfacing with various aspects of vehicle <NUM> and/or providing entertainment for occupants and/or information regarding vehicle <NUM> (where such head units may be referred to as "infotainment units" or "infotainment systems").

As further shown in the example of <FIG>, vehicle <NUM> includes a number of different vehicle systems 26A-26N ("vehicle systems <NUM>"). Vehicle systems <NUM> may include a heating, ventilation, air conditioning (HVAC) system, a temperature regulation system (e.g., which may include heated and/or cooled seats in addition to the HVAC system), a lighting system (for providing interior and/or exterior lighting), a seat control system (for adjusting a position of occupant seating), a mirror control system (for controlling interior and/or exterior mirrors, including rearview mirrors, side mirrors, visor mirrors, etc.), a windshield wiper control system, an entertainment system (for controlling radio playback, video playback, image display, etc.), a safety assistant system (for controlling parking assistance, back-up assistance, etc.), a sun-/moon-roof control system (for controlling sunroofs and/or moonroofs), and any other type of vehicle system capable of control via a head unit, such as head unit <NUM>. An example of vehicle systems <NUM> may include an electronic control unit (ECU), which may control any of the foregoing examples of vehicle systems <NUM>.

Head unit <NUM> may issue one or more commands (which may be referred to as a "command set," shown in <FIG> as "CS 25A-25N," and collectively referred to as "CS <NUM>") to vehicle systems <NUM> to change an operational state of one or more of vehicle systems <NUM>. Given the wide variety of vehicle systems <NUM> (in terms of both functionality and operation) between not only different models of vehicles from the same manufacture, but also between models of vehicles from different manufacturers, head unit <NUM> may be configured to output command sets <NUM> that generally control the highest percentage of vehicle systems <NUM>, as manual configuration of command sets is time consuming, expensive, and prone to error.

Furthermore, head unit <NUM> may execute an operating system ("OS") <NUM> that is configured to output the command sets according to a control bus protocol, such as a control area network (CAN) protocol. Operating systems of head units, such as OS <NUM>, is statically configured (or, in other words, "hard coded") to communicate with vehicle systems <NUM> via the CAN protocol or other standard (e.g., an open or proprietary) control bus protocol. That is, the manufacturer may manually program the operating system to enable the operating system to interface with each of vehicle systems <NUM> via the control bus (which is not shown in the example of <FIG> for ease of illustration purposes).

Programming the operating systems to correctly interface with each of vehicle systems <NUM> may be time consuming and require significant testing to ensure correct interoperability with vehicle systems <NUM>. To illustrate, a manufacturer may source vehicle systems <NUM> from a wide variety of vendors, which may provide vehicle systems <NUM> that communicate states of vehicle properties and are controlled in accordance with a number of different control bus protocols. The manufacturer may, even within a single model, have to source vehicle systems <NUM> that communicate according to different control bus protocols (such as between different trims of the same model). The manufacturer may, as a result, create two or more different versions of the operating system, each of which are individually hard coded to communicate with vehicle systems <NUM> via the different control bus protocols. In addition, any changes to the control bus protocol may result in the manufacturer updating the operating system to hard code the operating system to support the newer versions of the control bus protocol, which may potentially reduce the ability of manufacturers to support new or changing control bus protocols, thereby potentially preventing vehicle <NUM> from receiving upgrades that improve safety, convenience and other aspects of vehicle <NUM>.

In accordance with various aspects of the techniques described in this disclosure, a vehicle computing device (such as, as one example head unit <NUM>) applies an extensible mapping for vehicle system busses (which may be referred to as a "control bus"). As noted above, vehicle system busses may conform to different proprietary and open standards by which command sets ("CS") 25A-25N ("CS <NUM>") are communicated between head unit <NUM> (which may also be referred to as a "vehicle head unit <NUM>") and one or more systems of the vehicle (e.g., vehicle systems <NUM>). Vehicle head unit <NUM> executes an operating system <NUM> that supports a uniform command set (or, in other words, a standard command set), while vehicle system busses <NUM> communicates local control messages specified in accordance with a particular local control bus protocol of a plurality of local control bus protocols. Rather than hard code operating system <NUM> to support the particular local control messages, various aspects of the techniques enable vehicle head unit <NUM> to obtain an extensible mapping <NUM> ("EM <NUM>") between the standard command set and the local command set that conforms to the particular local control bus protocol supported by the local control bus. The local control message may be formatted in accordance with one of a DBC format or a Kayak CAN definition (KCD) format.

In operation, processor <NUM> may execute OS <NUM> to control one or more of vehicle systems <NUM>, where OS <NUM> supports a standard command set. OS <NUM> outputs the standard command set as one or more messages in accordance with a common or standard control bus protocol, where these messages are referred to as "standard control messages. " Processors <NUM> may obtain EM <NUM> from system memory <NUM>, which defines a mapping between a local control message specified in accordance with a local control bus protocol and the standard control message supported by OS <NUM>.

In some examples, processor <NUM> may execute a hardware abstraction layer (HAL) <NUM>, providing what may be referred to as a software shim layer between OS <NUM> and vehicle systems <NUM> (including the control bus, which is not shown in the example of <FIG>). In other words, HAL <NUM> may represent a unit configured to extend an underlying head unit operating system <NUM> ("OS <NUM>"). Processor <NUM> may execute one or more threads representative of OS <NUM>, including one or more threads associated with HAL <NUM>. Processor <NUM> may retrieve OS <NUM> (including HAL <NUM>) from system memory <NUM> in the form of one or more commands associated with the one or more threads of OS <NUM>, loading the commands into local memory (e.g., a layer one (L1), a layer two (L2), and/or a layer three (L3) cache, which are not shown in the example of <FIG> for ease of illustration purposes) prior to execution. As such, HAL <NUM> and OS <NUM> are shown as being included within processor <NUM> using dashed lines to indicate execution by processor <NUM>, while shown as also being included in system memory <NUM> using solid lines to denote long term storage of HAL <NUM> and OS <NUM>. Although shown as being executed by processor <NUM>, HAL <NUM> may also be implemented using dedicated circuitry or hardware logic.

In any event, HAL <NUM> may obtain EM <NUM> when providing the software shim layer to enable OS <NUM> to interface with vehicle systems <NUM>. As such, OS <NUM> may generate command sets <NUM> as standard control messages that conform to a control bus protocol supported by OS <NUM>. HAL <NUM> may receive (or, in some instances, intercept) the standard control messages and translate, based on EM <NUM> and without OS <NUM> requesting such translation (and in this respect transparently form the perspective of OS <NUM>), the standard control messages to obtain the local control message that conforms to the local control bus.

EM <NUM> may define a byte-wise mapping between the standard control message and the local control message. That is, EM <NUM> may define a mapping for each byte of the standard control message, defining how each byte is to be rearranged within the message and/or the value is to be converted (e.g., for control message identifiers) to conform to the local control bus protocol. HAL <NUM> may receive the standard control message, which may include a first representation of a command set, such as one of command sets <NUM>, to initiate an operational state change of one or more of vehicle systems <NUM>.

HAL <NUM> may apply EM <NUM> to the standard control message to rearrange or otherwise convert values of bytes within the standard control message, thereby translating the standard control message to obtain the local control message the conforms with the control bus protocol. The local control message may, as such, include a second representation of the command set. HAL <NUM> may transmit, via the control bus coupled to processor <NUM> and vehicle systems <NUM>, the local control message to initiate the operational state chance of one or more of vehicle systems <NUM>.

HAL <NUM> may likewise receive (or in some instances transparently intercept from the perspective of OS <NUM> and vehicle systems <NUM>) local control messages that include operational states 27A-27N ("operational states <NUM>," which are shown in <FIG> as "ST 27A-27N") from vehicle systems <NUM>. The local control messages may conform to the local control bus protocol. HAL <NUM> may translate, based on EM <NUM>, the local control messages to obtain standard control messages, which again are supported by OS <NUM>. HAL <NUM>, as noted above, may provide this translation as part of abstracting the underlying hardware (or in other words, as part of providing the shim software layer), allowing for potentially simpler development and installation of OS <NUM> across a variety of different hardware platforms. HAL <NUM> may provide the standard control messages to OS <NUM>, which may obtain confirmation of operational state changes requested by previously sent standard control messages.

In addition, head unit <NUM> may adapt command sets <NUM> for controlling vehicle systems <NUM>. As noted above, head unit <NUM> may be configured to implement HAL <NUM> that determines associations <NUM> ("ASSOC <NUM>") between command sets <NUM> and operational states <NUM> changes of vehicle systems <NUM>. Based on these associations <NUM>, HAL <NUM> may adapt command sets <NUM> in an attempt to expose additional functionality (as represented by one or more operational states <NUM>) of vehicle systems <NUM>. As such, the techniques may allow HAL <NUM> to automatically determine command sets <NUM> specific to a particular model and manufacturer, thereby potentially avoiding manual configuration of command sets <NUM> and the accompanying time, expense, and potential for error. HAL <NUM> may use associations <NUM> as a basis for EM <NUM>, defining various mappings between the standard control message and the local control messages for achieving various operational state changes of vehicle systems <NUM>.

As noted above, HAL <NUM> may represent a unit configured to process outputs from OS <NUM> responsive, in one example, to input received via a GUI presented by display <NUM> from an occupant to change an operational state of one or more of vehicle systems <NUM>. HAL <NUM> may also process outputs from OS <NUM> that are automatically generated in response to other inputs, such as operational states <NUM>. The outputs may refer to command sets <NUM> issued by OS <NUM> to perform the operational state change. OS <NUM> may issue command sets <NUM> as a series of "SET" commands, each of which specify one of vehicle systems <NUM>, a property of the one of vehicle systems <NUM>, and a value for the specified property. The SET commands may specify the operational state to which the specified one of vehicle systems <NUM> is to maintain.

HAL <NUM> may also process inputs from vehicle systems <NUM> indicative of current operational states <NUM> of various properties of vehicle systems <NUM>. OS <NUM> may output "GET" commands that query vehicle systems <NUM> regarding the various properties to which vehicle systems <NUM> respond by providing the inputs indicative of current operational states <NUM>. Similar to the "SET" commands, the "GET" commands may each specify one of vehicle systems <NUM> and a property of the one of vehicle systems <NUM> to which the query for a value is directed. In some examples, vehicle systems <NUM> may respond with inputs after performing various operational state changes responsive to "SET" commands. Regardless, HAL <NUM> may process the outputs and the inputs to determine associations <NUM>.

To illustrate, assume that vehicle system 26A represents an HVAC system. Various HVAC systems may operate differently depending on an ignition state of the vehicle and underlying environmental control unit (ECU) of the HVAC system. Furthermore, consider that various properties of HVAC system 26A may interact with other properties of HVAC systems 26A and potentially other ones of vehicle systems 26B-26N. For example, when setting the HVAC temperature, HVAC system 26A may automatically change a speed of a fan. HAL <NUM> may determine associations <NUM> between various vehicle properties of HVAC system 26A represented by operation states 27A that result from outputting command sets 25A to vehicle systems <NUM> in order to set the HVAC temperature.

HAL <NUM> may next adapt, based on associations <NUM>, command sets <NUM>. In the above example, HAL <NUM> may adapt, based on associations <NUM> identifying the dependency between setting the HVAC temperature and automatically changing the fan speed, command set 25A to include an additional command setting the fan speed of HVAC system 26A to its previously set fan speed value (which may be configured based on occupant preference or as a result of the occupant previously setting the fan speed of HVAC system 26A). HAL <NUM> may, in this way, adapt, based on the association <NUM> (which may also be referred to as "dependencies <NUM>"), command sets <NUM> to accommodate variability between vehicle systems <NUM> of vehicle <NUM> and vehicle systems of a second vehicle.

Further examples of dependencies between parameters outside of the HVAC context may include interior lighting (dome lights, reading lights, floor lights, etc.), which may be directly controllable (via a switch or other user interface, including via the head unit) as well as associated with door or ignition states. HAL <NUM> may identify dependencies between a state of the doors and that a light turns on when the driver door is opened, which may enable HAL <NUM> to determine that the light is useful for illuminating the driver's area.

Another example may be in the context of the wipers and washers, where HAL <NUM> may determine that the wipers are set to a particular wiper rate when the washers are enabled, which may override an existing wiper rate. Yet another example may be in the context of advanced driver assistance systems (ADAS), where HAL <NUM> may identify that various states of the ADAS are only available when vehicle <NUM> is travelling at certain speeds, or when vehicle <NUM> is in certain states (e.g., when operating in reverse, the ADAS activates the rear camera and displays via the head unit the image captured by the rear camera). HAL <NUM> may determine the parameters and then identify all of the various dependencies relative to lighting, wipers and washers, ADAS, vehicle states and/or speeds.

Moreover, HAL <NUM> may determine a list of parameters that are available when vehicle <NUM> is turned on. HAL <NUM> may, as one example, determine whether vehicle <NUM> allows you to activate the headlights when the ignition is off, as some vehicles may automatically turn off the headlights when the vehicle is powered off. Hal <NUM> may determine dependencies between various parameters relative to various ignition states (e.g., off, accessories, on, etc.). Hal <NUM> may also determine dependencies between seat position relative to various states of vehicle <NUM> (such as in gear and/or moving or parked and/or not moving).

In this respect, HAL <NUM> may process changes between operational states <NUM> to generate a record of the changes, parse operational states <NUM> to find causality between properties (which may also be referred to as "parameters" - e.g., when parameter A changes, parameters B and C also change), and generate associations <NUM> that identify the causalities (or, in other words, dependencies) between changes in operational state <NUM>. In some example, HAL <NUM> may store associations <NUM> as a table, a linked list, a graph, a tree, or any other suitable data structure. In other examples, HAL <NUM> may train a model using machine learning to identify associations <NUM> and dynamically generate different versions of command sets <NUM> that address associations <NUM>. As such, HAL <NUM> may, to determine dependencies <NUM>, perform machine learning with respect to the operational state change initiated by command sets <NUM> and operational states <NUM> of the vehicle parameters.

HAL <NUM> may, upon identifying these dependencies <NUM>, define mappings <NUM> between the standard control message supported by OS <NUM> for the particular operational state changes identified by dependencies <NUM> and the local control message that conform to the local control bus protocol used to invoke the operational state changes. The mappings may enable the above noted translation, where such mappings are extensible in that EM <NUM> may change over time due to updates to one or more of OS <NUM>, the control bus, and/or vehicle systems <NUM>. In some examples, rather than HAL <NUM> defining EM <NUM>, manufacturers may manually program EM <NUM>, defining a file or script capable of being executed by HAL <NUM> to perform the translation between the standard control message and the local control message.

As such, various aspects of the techniques may enable manufacturers to define EM <NUM>, which may be updated over time to accommodate updates to one or more of OS <NUM>, the control bus, and/or vehicle systems <NUM>. EM <NUM> may define translations between the standard command set and the local command set, which the vehicle head unit may apply to automatically translate between the standard command set and the local command set. As only EM <NUM> may need to be defined, rather than hard coding such mappings statically within the operating system to support only the local command set, various aspects of the techniques may improve the speed with which vehicle head unit operating systems (e.g., OS <NUM>) may be developed, improve interoperability with new or changing control bus protocols, and otherwise improve development of vehicle head unit operating systems while accommodating rapid deployment of such operating system that provide full featured support in terms of local command sets.

Moreover, various aspects of the techniques may promote more efficient operation of head unit <NUM> itself. That is, HAL <NUM> may determine associations <NUM> between command sets <NUM> and changes of operational state <NUM>, and adapt, based on associations <NUM>, command sets <NUM>, in a manner that more efficiently causes vehicle systems <NUM> to undergo changes in operational states <NUM>. Rather than issue command sets <NUM> that are generic to vehicle systems <NUM> chosen by a large number of models and manufactures, but that may be inefficient (although functional) for some vehicle systems <NUM>, the techniques may allow HAL <NUM> to adaptively generate command sets <NUM> that more efficiently (relative to the generic command sets) cause vehicle systems <NUM> to perform the change of operational states <NUM> change, thereby saving processor cycles, conserving memory bandwidth and underlying memory resources consumed therewith, and promoting, as a result, more efficient power consumption.

Although described with respect to HVAC systems, the techniques may be applied with respect to other systems. Some possible examples include interior lighting systems (e.g., dome lights, reading lights, etc.) which head unit <NUM> may directly control as well as associated with door open or ignition states. Head unit <NUM> may determine that a light turns on when the driver door is open, and thereby determine that the light is useful for illuminating the driver's area. As another example, head unit <NUM> may identify associations between wipers and washers for the windows. Head unit <NUM> may identify associations between certain vehicle state and/or speeds and the advanced driver assistance systems (ADAS) modes (where certain ADAS modes may only be available in certain car states and/or speeds).

<FIG> and <FIG> are block diagrams illustrating examples of the head unit of <FIG> in more detail. Head unit 24A shown in the example of <FIG> is one example of head unit <NUM> shown in <FIG>. Head unit 24A may execute OS <NUM>, which provides an execution environment for a car service <NUM>.

Head unit 24A may also execute two different HALs 28A and 28B. Vehicle HAL 28A may execute a translation service <NUM>, which may perform translations, based on EM <NUM>, between the standard control message and the local control messages in accordance with various aspects of the techniques described in this disclosure. Controller area network (CAN) bus HAL 28B may represent a unit configured to convert the local control messages to universal system bus (USB) signals and USB signals to local control messages, providing yet another layer of abstraction between the hardware and OS <NUM>.

Head unit 24A may also include a USB <NUM>, which is a physical USB interface along with one or more processors, fixed-logic circuitry, dedicated signal processors, a dedicated control processor (such as a dedicated control bus processor) and/or the like that expose a USB CAN interface <NUM> and a gateway <NUM>. USB CAN interface <NUM> may represent a unit configured to provide access to CAN <NUM> via a USB port. Gateway <NUM> represents a unit configured to expose a control bus gateway by which to control access to CAN <NUM>, and may represent a firewall or other type of device capable of limiting access to CAN <NUM> when certain conditions are present (e.g., dropping a malformed CAN signal, etc.).

As noted above, translation service <NUM> may receive standard control messages from OS <NUM>, which may have originated from car service <NUM> or elsewhere (such as one or more applications executed in the execution environment provided by OS <NUM>). Translation service <NUM> may obtain EM <NUM>, which may represent a file or other data structure capable of storing mappings. An example of EM <NUM> follows below. vehicleProperty {
vhalPropertyId: WINDOW_MOVE
access: READ_WRITE
canSignal {
area: ROW_1_LEFT
messageId: 0x124
bit: <NUM>
size: <NUM>
conversionEnum { // no-op
canValue: <NUM>
}
conversionEnum {
vhalValue: <NUM> // fast open
canValue: 0xA
}
conversionEnum {
vhalValue: -<NUM> // fast close
canValue: 0xB }
}
canSignal {
area: ROW_1_RIGHT
messageId: 0x124
bit: <NUM>
size: <NUM>
conversionEnum {.

In the above example, EM <NUM> begins with a standard command "vehicleProperty," signaling that the following relates to a vehicle property (which is another way to refer to an operational state). The next line specifies a vehicle HAL (VHAL) property identifier ("vhalPropertyId") as a window move ("WINDOW_MOVE"), which defines mappings for opening and closing power windows. WINDOW_MOVE may represent one example of a standard identifier and may not be vehicle specific The third line provides what access is allowed, specifying the access as read/write ("READ_WRITE") and denoting that the window move property is capable of being red (e.g., by a GET command) and written (e.g., by a SET command). Each operational state of the vehicle may be defined in this manner with a vehicle property identifier and an access level.

After each operational state opening statements identifying the vehicle property and access, EM <NUM> may define a mapping for each applicable area in the vehicle. The mapping begins with a CAN signal ("canSignal") followed by an opening curly bracket. Each CAN signal may specify a respective area, where the first mapping identifies an area as the first row on the left ("ROW_1_LEFT"), which refers to the front driver side window (in a left side drive situated vehicle). Next, the front driver side window mapping specifies a message identifier ("messageId"), which is the message identifier used for the corresponding CAN message (i.e., 0x124 in this example). Following the message is a bit (set to zero) and size (set to four), which are CAN specific syntax that need to be set when translating the standard control message to the local control message (which may, in this example, referred to as a CAN message).

Next are three "conversionEnum" statements, each of which are defined by an opening and closing curly bracket. "conversionEnum" signals that there is a conversion between the standard control message enumeration (for specifying a no-operation window move) and the CAN message (for specifying a no-operation window move). In this example, the conversion adds a CAN value of zero to the standard control message, which does not include a VHAL value ("vhalValue") for a no-operation window move. The next conversionEnum specifies a conversion of the vhalValue for a fast open (which is two) to the can Value for performing a fast open (which is 0xA). The third conversionEnum replaces the vhalValue for a fast close (which is negative two) to the canValue for performing the fast close (which is 0xB).

Following the third conversionEnum, EM <NUM> specifies an area of the front right passenger side window ("ROW_1_RIGHT"), having the same message identifier as the first CAN signal statement, but specifying four bits and a size of four. EM <NUM> may include a number of conversionEnum statements and possibly additional CAN signal statements for different areas of the car, which are not shown for ease of explanation purposes.

Translation service <NUM> may receive a standard control message that defines a fast open of the front right driver side window as a sequence of one or more bytes, defining an operational state change as WINDOW_MOVE, ROW_1_LEFT, and a vhalValue of <NUM>. Translation service <NUM> may generate a CAN message by replacing the WINDOW_MOVE, ROW_1_LEFT with the message ID of 0x124, a bit and size as <NUM> | <NUM>, and a CAN value of 0xA. Likewise, translation service <NUM> may convert a CAN message specifying the fast open of the driver right side window, replacing the message ID of 0x124, a bit and size as <NUM> | <NUM>, and a CAN value of 0xA with WINDOW_MOVE, ROW_1_LEFT, and a vhalValue of <NUM>.

Another example of EM <NUM> is provided below, which passes a temperature in Celsius. vehicleProperty {
vhalPropertyId: HVAC_TEMPERATURE_SET // standard ID
(VHAL)
access: READ // this vehicle doesn't allow HU to set
// temperature
canSignal {
area: ROW_1_LEFT
messageId: 0x123
bit: <NUM> // value is located starting at 8th bit of
the
// payload
size: <NUM> // value takes <NUM> bytes of the payload
scale: <NUM>
offset: <NUM> // scale/offset is a common CAN technique
conversion {
method: FAHRENHEIT_TO_CELSIUS
}
}
}.

In the above example, EM <NUM> specifies a vhalPropertyId of HVAC temperature set ("HVAC_TEMPERATURE_SET"), which is a standard ID used by OS <NUM>. Access is specified in the third line, where EM <NUM> sets the access to read, as vehicle <NUM> in this instance does not allow head unit <NUM> to set the temperature (which may only be set by dedicated buttons or other controls). In the canSignal statement, EM <NUM> defines the area as front row driver side, and specifies a number of CAN specific syntax in the form of a message ID, bit, size, scale, and offset, each of which is a common CAN syntax. The "conversion" is defined whereby EM <NUM> specifies a method call to a function entitled "FAHRENHEIT_TO_CELSIUS.

Translation service <NUM> may receive a standard control message requesting the HVAC temperature and generate a CAN message that includes the message ID of 0x123, the bit and size as <NUM> | <NUM> (where the bit of eight indicates that the temperature value is located starting at the <NUM>th bit of the payload, and the size indicates that the value takes <NUM> bytes of the payload) along with the scale and offset. Translation service <NUM> may forward this message to CAN-USB HAL, which converts the CAN message to a USB signal before outputting the signal via the USB CAN interface via gateway <NUM> to CAN <NUM>. CAN <NUM> may transmit the CAN message to one or more vehicle systems <NUM>, which are represented in the example of <FIG> as electronic control units (ECU) 212A-212N ("ECUs <NUM>").

The one of ECUs <NUM> responsible for controlling the HVAC system may reply to the message with the current temperature in degrees Fahrenheit, generating a CAN message that specifies the temperature in degrees Fahrenheit starting at bit eight in the payload as a two-byte temperature having a scale of two and an offset of <NUM> (e.g., a <NUM> degree temperature may be specified as <NUM>). The HVAC ECU <NUM> may transmit the CAN message via CAN bus <NUM>, whereupon gateway <NUM>, USB CAN interface <NUM>, and CAN-USB HAL <NUM> relay the CAN message to translation service <NUM>.

Translation service <NUM> may translate the CAN message according to the foregoing mapping, replacing the message ID, bit, size, scale, and offset with HVAC_TEMPERATURE SET, READ, and ROW_1_LEFT. Translation service <NUM> may parse the temperature and invoke the FAHRENHEIT_TO_CELSIUS method, passing the temperature to the foregoing method. Prior to passing the temperature, translation service <NUM> may process the temperature according to the scale and offset (to recover the actual temperature of <NUM> degrees Fahrenheit). The FAHRENHEIT_TO_CELSIUS method may convert the temperature from degrees Fahrenheit to degrees Celsius, and specify the temperature in the standard control message. Translation service <NUM> may then transmit the standard control message to car service <NUM>.

Although described with respect to a specific conversion process, i.e., FAHRENHEIT_TO_CELSIUS in the above example, the techniques may be performed with respect to other types of conversions. For example, other example conversion processes include a RADIUS_TO_CIRCUMFERENCE that calculates wheel travel distance on each full spin, a LOG or EXPONENT to convert reading from logarithmic potentiometer to a linear scale or vise versa.

A third example of EM <NUM> is shown below, which passes a temperature to the HVAC system of vehicle systems <NUM> as +<NUM>/-<NUM> events. vehicleProperty {
vhalPropertyId: HVAC_TEMPERATURE_SET // standard ID
access: WRITE
canSignal {
area: ROW_1_LEFT
messageId: 0x123
bit: <NUM>
size: <NUM>
offset: -<NUM>
conversion {
method: DELTA UPDATE
params {
deltaUpdate {
initValue: <NUM> // <NUM> degree Celsius
maxStep: <NUM> // can't +/- more than <NUM>
// degree } }
}
}
canSignal {
area: ROW_1_RIGHT. bit: <NUM>.

In the example directly above, EM <NUM> specifies a vhalPropertyId of "HVAC_TEMPERATURE_SET" along with an access of "WRITE" and an area of the front left drivers side ("ROW_1_LEFT"), which map to syntax of the standard control message. Next, EM <NUM> specifies the messageId of 0x123, bit of <NUM>, size of <NUM>, and offset of -<NUM>, which all represent CAN protocol syntax used in place of the vhalPropertyId, access and area. EM <NUM> then specifies a conversion that calls the method "DELTA_UPDATE" and lists parameters ("params") for the "deltaUpdate. " Within the deltaUpdate of EM <NUM> is the initial value ("initValue") of <NUM> degrees Celsius, and a max step ("maxStep") size for the temperature.

Translation service <NUM> may receive or otherwise obtain a standard control message from car service <NUM> listing the HVAC_TEMPERATURE_SET, WRITE and ROW_1_LEFT, replacing these standard syntax elements with the 0x123, <NUM>, <NUM>, -<NUM>. Translation service <NUM> may insert at bit <NUM> of the payload, a two byte temperature update of -<NUM> or <NUM>, thereby translating the standard control message to a CAN message. Translation service <NUM> may output the CAN message to CAN-USB HAL <NUM>, which converts the CAN message to USB signals before sending the USB signals via the USB CAN interface <NUM> and gateway <NUM>.

CAN <NUM> may receive the CAN message and relay the CAN message to ECUs <NUM>, where the appropriate one of ECUs <NUM> (i.e., the HVAC ECU in this example) may process the CAN message and output a response CAN message. The response CAN message may traverse CAN <NUM>, gateway <NUM>, USB CAN interface <NUM>, and CAN-USB HAL <NUM> before arriving at translation service <NUM>. Translation service <NUM> may perform the inverse translation or in other words mapping, based on the above example of EM <NUM>, with respect to the response CAN message to obtain a response standard control message. Translation service <NUM> may output the response standard control message to car service <NUM>.

In the example of <FIG>, head unit 24B is another example of head unit <NUM> shown in the example of <FIG>. Head unit 24B may be similar, if not substantially similar, to head unit 24A except that in the example of <FIG> gateway <NUM> may perform the translation service previously described with respect to translation service <NUM>. Translation service <NUM> of head unit 24B is replaced with a general VHAL service <NUM> that may perform other formatting, conversion or other processes with respect to the standard control message output by gateway <NUM> according to EM <NUM>. Manufacturers may program gateway <NUM> to perform translation service <NUM> in order to provide additional security via firewalling CAN access.

<FIG> is a diagram illustrating an example of HAL <NUM> shown in <FIG> adapting command set <NUM>-1A in accordance with various aspects of the techniques described in this disclosure. HAL <NUM> may initially specify command set <NUM>-1A for an operational state change 50A that configures various parameters of HVAC system 26A to provide "MAX AC," which may refer to a maximum air condition configuration. Responsive to the occupant selecting or otherwise activating MAX AC 50A, HAL <NUM> may issue commands 52A-52F.

Command 52A specifies a SET command, which takes as variables a system identifier, a parameter, and a value. The system identifier in this example is assumed to be "HVAC_SYS," which represents an identifier associated with HVAC system 26A. All of commands 52A-52F specify the same system identifier, HVAC_SYS. The parameter of command 52A is assumed, for purposes of illustration, to be "FAN," which may refer to a fan speed of HVAC system 26A. The value of command 52A sets the fan speed to "HIGH.

Command 52B is another SET command that specifies the same system identifier and parameter as command 52A, but sets the fan speed to a value of "<NUM>. " Redundant commands (referring to commands that may attempt to initiate a similar or same configuration for the same parameter exists within command set <NUM>-1A because command set <NUM>-1A is an initial generic command set capable of initiating MAX AC 50A for a number of different models of the same manufacturer, and/or a number of different models of different manufacturers.

Command 52C is another SET command that specifies the same system identifier as command 52A, but specifies a different parameter "TEMP," which refers to the cabin temperature that HVAC system 26A is to maintain. Command 52C sets the cabin temperature to a value of "<NUM>," (which is assumed for purposes of illustration to be in degrees Fahrenheit).

Command 52D is another SET command that specifies the same system identifier as command 52A, but specifies a different parameter "VENT," which refers to a vent or set of vents in the cabin of vehicle <NUM> from which cooled air is to be vented. Command 52D sets the vent to a value of "HIGH," which may refer to the dash vents in various ECUs.

Command 52E is another SET command that specifies the same system identifier and parameter as command 52D, but sets the vent to a value of "DASH," which refers to the dash vents. Command 52F is another SET command that specifies the same system identifier and parameter as command 52E, but sets the vent to a value of "UPPER," which refers to the dash vents and any ceiling vents. Again, redundant commands (referring to commands that may attempt to initiate a similar or same configuration for the same parameter exists within command set <NUM>-1A because command set <NUM>-1A is an initial generic command set capable of initiating MAX AC 50A for a number of different models of the same manufacturer, and/or a number of different models of different manufacturers.

HAL <NUM> may issue each of commands 52A-52F (either in sequence or concurrently) to vehicle system 26A, which may respond to each of commands 52A-52F with one or more messages specifying an operational state <NUM> of the above identified parameters. HAL <NUM> may adapt command set <NUM>-1A based on operational states <NUM> to obtain adapted command set <NUM>-1A'.

As shown in the example of <FIG>, HAL <NUM> may adapt command set <NUM>-1A to include new command <NUM> and remove commands 52D and 52F. HAL <NUM> may also adapt individual command 52C to obtain command <NUM> of adapted command set <NUM>-1A'.

HAL <NUM> may obtain new command <NUM> as a result of receiving one of operational states <NUM> (e.g., in response to command 52A) indicating that HVAC system 26A is unable to complete command 52A because HVAC system 26A is not operational (referring to its active power state). HAL <NUM> may, responsive to the one of operational states <NUM>, generate command <NUM>, which sets the parameter "POWER" of HVAC system 26A to a value of "ON. " HAL <NUM> may iterate through one or more redundant commands that are similar to command <NUM>, but that specify the same parameter (but having a different identifier - such as "OPERATIONAL," or "AC"), and/or a different value (such as "YES" for "OPERATIONAL" parameter).

In this respect, command set <NUM>-1A may initially be unable to initiate operational state change 50A of HVAC system 26A because HVAC system 26A was not activated (in terms of receiving power). HAL <NUM> may, as a result, automatically adapt command set <NUM>-1A to enable command set <NUM>-1A (in the form of adapted command set <NUM>-1A') to initiate the operational state change of HVAC system 26A. In other words, HAL <NUM> may issue exploratory command sets to initiate an exploratory operational state change of the one or more systems, and responsive to issuing the command set and after the exploratory operational state change, obtain, from the one or more systems, respective indications of an actual operational state of each of one or more vehicle parameters. HAL <NUM> may next determine determine, for the exploratory command set, one or more dependencies between the actual operational states of the one or more vehicle parameters, and generate, based on the one or more dependencies, the extensible mapping to translate the command set from the local control message to the standard control message.

Continuing the example, HAL <NUM> may remove commands 52D and 52F as a result of receiving one or more of operational states <NUM> indicating that commands 52D and 52F were not recognized commands 52D and 52F (meaning, as one example, that commands 52D and 52F utilized syntax that was not supported by the ECU of HVAC system 26A). In some instances, systems <NUM> are from a first set of vendors and therefore may utilize different syntax for various parameters compared to systems from a second set of vendors (where it is assumed that the first set of vendors and the second set of vendors differ by at least one vendor). HAL <NUM> may initially issue redundant commands 52D-52F to determine which of commands 52D-52F result in a successful one of operational states <NUM>.

Although described as issuing redundant commands 52D-52F, HAL <NUM> may reduce redundant commands 52D-52F by one or more commands based on various information retrievable by HAL <NUM> from HVAC system 26A. For example, HAL <NUM> may issue a GET comment to retrieve a type, vendor, etc. of HVAC system 26A. HAL <NUM> may associate different types, vendors, etc. of HVAC system 26A with different syntax. Based on this retrieved information, HAL <NUM> may eliminate or otherwise remove one or more of redundant commands 52D-52F associated with unsupported syntax.

Returning to the example shown in <FIG>, HAL <NUM> may also adapt individual command 52C to change the value from <NUM> to <NUM>. HAL <NUM> may have previously identified a lowest temperature value of <NUM> degrees Fahrenheit for HVAC system 26A, and automatically adapt command 52C to be set to the lowest temperature.

HAL <NUM> may then automatically generate EM <NUM> based on the adapted command set <NUM>-1A'. HAL <NUM> may include general mappings for each command, which are placed into a script or other file that form EM <NUM>, where each of the commands may be translated according to EM <NUM> from standard control messages to CAN messages.

<FIG> is a diagram illustrating an example of HAL <NUM> shown in <FIG> adapting another command set <NUM>-2A in accordance with various aspects of the techniques described in this disclosure. HAL <NUM> may initially specify command set <NUM>-2A for an operational state change 50B that configures various parameters of HVAC system 26A to "SET TEMP <X>," which may refer to setting a temperature to a variable value of "X" entered by the occupant. Responsive to the occupant selecting or otherwise activating SET TEMP <X> 50B, HAL <NUM> may issue command <NUM>.

Command <NUM> specifies a SET command, which takes as variables a system identifier, a parameter, and a value. The system identifier in this example is assumed to be "HVAC_SYS," which represents an identifier associated with HVAC system 26A. The parameter of command <NUM> is assumed, for purposes of illustration, to be "TEMP," which may refer to temperature that HVAC system 26A is to maintain. The value of command <NUM> sets the temperature to a variable "X. " The occupant may specify the value for variable "X.

Responsive to issuing command <NUM> to HVAC system 26A, HAL <NUM> may receive operational states 27A and 27B. Operational state 27A indicates that a value for a fan speed parameter, "FAN," is set to a speed of "<NUM>. " Operational state 27B indicates that a vent parameter, "VENT," is set to "DASH.

After issuing command <NUM>, the occupant may indicate that the temperature is for a first HVAC zone within vehicle <NUM> and not a second HVAC zone within vehicle <NUM>. As such, HAL <NUM> may adapt command set <NUM>-2A to obtain command set <NUM>-2A' such that command set <NUM>-2A' includes commands 52N-52Q. Command 52N indicates that the temperature parameter is for the first HVAC zone within vehicle <NUM>, changing "TEMP" parameter of command <NUM> to the "ZONE1_ TEMP" parameter of command 52N. Commands 52P and 52Q also indicate that the FAN speed parameter and the VENT parameter are also for the first HVAC zone within vehicle <NUM>, becoming "ZONE1_FAN" and "ZONE1_VENT. " In this way, HAL <NUM> may adapt command sets <NUM>-2A to better accommodate the occupant and reduce the amount of time the occupant focuses on head unit <NUM>, which may improve safety during operation of vehicle <NUM>.

HAL <NUM> may then automatically generate EM <NUM> based on the adapted command set <NUM>-2A'. HAL <NUM> may include general mappings for each command, which are placed into a script or other file that form EM <NUM>, where each of the commands may be translated according to EM <NUM> from standard control messages to CAN messages.

<FIG> is a flowchart illustrating example operation of HAL <NUM> of <FIG> in performing various aspects of the extensible mapping techniques described in this disclosure. As described above, processor <NUM> may execute OS <NUM> to control one or more of vehicle systems <NUM> (<NUM>), where OS <NUM> may support a standard command set. OS <NUM> may output the standard command set as one or more standard control messages in accordance with a common or standard control bus protocol (<NUM>). Processors <NUM> may obtain EM <NUM> from system memory <NUM>, which may define a mapping between a local control message specified in accordance with a local control bus protocol and the standard control message supported by OS <NUM> (<NUM>). In some examples, processor <NUM> may execute HAL <NUM>, which may configure processor <NUM> to obtain EM <NUM> when providing the software shim layer to enable OS <NUM> to interface with vehicle systems <NUM>.

HAL <NUM> may receive the standard control message, which may include a first representation of a command set, such as one of command sets <NUM>, to initiate an operational state change of one or more of vehicle systems <NUM>. HAL <NUM> may apply EM <NUM> to the standard control message to rearrange or otherwise convert values of bytes within the standard control message, thereby translating the standard control message to obtain the local control message the conforms with the control bus protocol (<NUM>). The local control message may, as such, include a second representation of the command set. HAL <NUM> may transmit, via the control bus coupled to processor <NUM> and vehicle systems <NUM>, the local control message to initiate the operational state chance of one or more of vehicle systems <NUM>.

HAL <NUM> may likewise receive (or in some instances transparently intercept from the perspective of OS <NUM> and vehicle systems <NUM>) local control messages that include operational states 27A-27N ("operational states <NUM>," which are shown in <FIG> as "ST 27A-27N") from vehicle systems <NUM> (<NUM>). The local control messages may conform to the local control bus protocol. HAL <NUM> may translate, based on EM <NUM>, the local control messages to obtain standard control messages, which again are supported by OS <NUM> (<NUM>). HAL <NUM>, as noted above, may provide this translation as part of abstracting the underlying hardware (or in other words, as part of providing the shim software layer), allowing for potentially simpler development and installation of OS <NUM> across a variety of different hardware platforms. HAL <NUM> may provide the standard control messages to OS <NUM>, which may obtain confirmation of operational state changes requested by previously sent standard control messages (<NUM>).

<FIG> is a flowchart illustrating example operation of HAL <NUM> of <FIG> in performing various aspects of the techniques described in this disclosure. As described above, HAL <NUM> may represent a unit configured to process outputs from OS <NUM> responsive, in one example, to input received via a GUI presented by display <NUM> from an occupant to change an operational state of one or more of vehicle systems <NUM>. HAL <NUM> may also process outputs from OS <NUM> that are automatically generated in response to other inputs, such as operational states <NUM>. The outputs may refer to command sets <NUM> issued by OS <NUM> to perform the operational state change. OS <NUM> may issue command sets <NUM> as a series of "SET" commands, each of which specify one of vehicle systems <NUM>, a property of the one of vehicle systems <NUM>, and a value for the specified property. The SET commands may specify the operational state to which the specified one of vehicle systems <NUM> is to maintain. In this respect, HAL <NUM> may issue, to one or more systems 26A of a first vehicle, e.g., vehicle <NUM>, a command set 25A to initiate an operational state change of one or more of systems <NUM> (<NUM>).

In this way, HAL <NUM> may, responsive to issue command set 25A and after the operational state change, obtain from systems <NUM> respective indications of operational state of each of the vehicle parameters (<NUM>). HAL <NUM> may next determine, for command set 25A, dependencies <NUM> between operational states of vehicle parameters (<NUM>).

HAL <NUM> may next adapt, based on associations <NUM>, command set 25A to accommodate variability between systems <NUM> of the first vehicle and systems of a second vehicle (<NUM>). In the above example, HAL <NUM> may adapt, based on associations <NUM> identifying the dependency between setting the HVAC temperature and automatically changing the fan speed, command set 25A to include an additional command setting the fan speed of HVAC system 26A to its previously set fan speed value (which may be configured based on occupant preference or as a result of the occupant previously setting the fan speed of HVAC system 26A). HAL <NUM> may, in this way, adapt, based on the association <NUM> (which may also be referred to as "dependencies <NUM>"), command sets <NUM> to accommodate variability between vehicle systems <NUM> of vehicle <NUM> and vehicle systems of a second vehicle. HAL <NUM> may also generate EM <NUM> (possibly automatically) based on the adapted command set (<NUM>).

In this way, the techniques may provide a Hardware Abstraction Layer (VHAL) <NUM> to allow OS <NUM> to interact with vehicle hardware, e.g., vehicle systems <NUM>. HAL <NUM> may attempt to take different makes / models of vehicles and create an application programmer interface (API) surface that is common to all makes/models of vehicles. One problem is that there is a large variety of vehicles and vehicle behaviors may not be easily abstracted. For example, the HVAC system in cars behave differently based upon the ignition state of the vehicle and configuration of the HVAC ECU. It may not be possible to generate a common API that abstracts the behavior for each make/model of vehicle.

HAL <NUM> may currently be implemented as a list of vehicle properties that may be SET and GET. For instance, HAL <NUM> may SET the HVAC temperature and the vehicle <NUM> will respond accordingly. The complexity occurs when properties interact with each other to create side-effects. For instance, when setting the HVAC temperature, the fan speed may change automatically in response to the temperature change. This behavior may be vehicle dependent. The particular problem is that some properties may be disabled / enabled based upon the HVAC controller's settings, and OS <NUM> may need to understand these intricacies to accomplish a task.

For instance, if the AC system is disabled because the HVAC unit is off, OS <NUM> may need to turn on the HVAC unit before turning on the AC. So, when an occupant indicates to "turn on AC," OS <NUM> initiates the correct sequence of commands based on an operational state of vehicle systems <NUM>.

In some instances, it is an impedance mismatch. OS <NUM> may expose a set of APIs (i.e. "turn on the AC to max") and the vehicles have a set of functionality that they support (i.e. "set fanspeed to <NUM>" or "set temperature to <NUM>"). These two APIs don't always align perfectly, and compromises are made. One solution to this problem is to have vehicle manufacturers write more of the "middleware" code to do what OS <NUM> needs the vehicles to support. This may be labor intensive and error prone, because each vehicle manufacturer needs to be trained to write the code. Another solution is to create the abstraction at a lower level of functionality that is common across all vehicles, but isn't ideal for all of the various vehicles. As such, OS <NUM> may restrict/limit some of the behaviors and code to the lowest common denominator.

The techniques of this disclosure may provide an algorithm by which to extract dependencies <NUM> between vehicle parameters. HAL <NUM> may determine a list of properties that can be set/get. When a property generates a side effect (e.g., setting a property changes other properties in the system), HAL <NUM> may detect and record this association <NUM>, so, when the occupant initiates an operational change that is currently not allowed, HAL <NUM> may determine how to configure the properties via command sets <NUM> to initiate the operational change.

To determine the dependencies, HAL <NUM> may do the following:.

HAL <NUM> may be implemented in many ways. In some instances, HAL <NUM> may collect machine learning (ML) training set as observed data over time. In other instances, HAL <NUM> may keep track of temporal correlations of properties and determine heuristics from the correlations. In either case, the concept is to have HAL <NUM> automatically adapt command sets <NUM> to each vehicle's idiosyncrasies without having to have a human manually input this into code. In this way, HAL <NUM> may reduce the complexity to bring a new vehicle implementation to market because HAL <NUM> may automatically adapt to changes in the vehicle and does not need to be hard coded.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. It should be understood, however, that computer-readable storage mediums and media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Combinations of the above should also be included within the scope of computer-readable medium.

In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules.

Claim 1:
A method comprising:
executing, by one or more processors of a vehicle, an operating system to control a plurality of systems of the vehicle (<NUM>);
obtaining, by the one or more processors, an extensible mapping between a local control message specified in accordance with a control bus protocol and a standard control message supported by the operating system (<NUM>), wherein the extensible mapping defines how each byte of the standard control message is to be rearranged within the standard control message and/or how a value of each byte is to be converted to obtain the local control message conforming with the control bus protocol;
generating, by the operating system executed by the one or more processors, the standard control message, the standard control message including a first representation of a command set to initiate an operational state change of at least one of the systems (<NUM>);
translating, by the one or more processors and based on the extensible mapping, the standard control message to obtain the local control message, the local control message including a second representation of the command set (<NUM>, <NUM>); and
transmitting, by the one or more processors and via a control bus coupled to the one or more processors and the one or more systems, the local control message to initiate the operational state change of the one or more systems (<NUM>).