Patent Description:
Reliability of vehicles is increasing to the point that the average life cycle of vehicles is at or nearing ten plus years of service. As vehicles age during the years of service, computing systems, including head units, electronic control units (ECUs), and the like, may increasingly become outdated, entering end of life in terms of technical support, maintenance (and other support), and support of new features. Moreover, head units and other computing systems are increasingly being seamlessly integrated into dashboards and other components of the vehicles such that replacement of the head units is becoming difficult due to unique form factors, inclusion of large and possibly expensive displays, etc..

Although upgrade of the head unit is possible, such upgrades to replace the head unit (and other computing systems) is often expensive, as the cost of replacing an entire head unit may require replacement of the screen and other (relatively) expensive components, which, while not necessary, is required (as the head unit often integrates the display and other expensive components into a single housing or replaceable unit) and difficult (as such head units are seamlessly integrated into each vehicle and specific to each make and model of the vehicle, potentially limiting availability of replacement head units and further possibly driving up the cost). As such, operators of vehicles may purchase an entirely new vehicle in an effort to gain access to newer technology, such as computing systems, including head units and other infotainment and other components, at considerable expense.

<CIT> discloses an embedded system for operating a peripheral, wherein said peripheral may be any electronically supported device, in particular a device that is operated by firmware. The embedded system is external to the peripheral and contains an interface for connection to the peripheral. Each of said external embedded systems comprises a dedicated communication module, which allows it to build up a network with one or more other embedded systems of the same type, in as far as such other systems are in reach to build up the network. The embedded system is configured to transmit and receive mobile software entities, each containing an own operating system.

<NPL>) disclose a runtime system to allow unmodified multi-threaded applications to use multiple machines. The system allows threads to migrate freely between machines depending on the workload.

The matter for protection is defined in the appended independent claims, with optional features defined in the dependent claims appended thereto. In general, various aspects of the techniques set forth in this disclosure are directed to an extensible computing architecture for vehicles. Rather than replace the head unit or other computing systems of a vehicle, the techniques may enable a head unit or other computing system to interface with a supporting computing system that is communicatively coupled to the head unit, where the head unit or other computing device may offload or otherwise transfer execution of applications (and other runtime environment level operations, not just execution of the application space) to the supporting computing device.

The head unit or other computing device may detect communicatively coupling of the supporting device and, responsive to detecting the communicative coupling of the supporting computing device, transfer a container that includes a partition of the runtime environment to the supporting computing device. The supporting computing device may then execute the partition of the runtime environment in order to synchronize operation of the runtime environment and thereby provide a user space in which the applications may execute (while also supporting execution of the kernel space, or in other words, the runtime environment space, as a distributed runtime environment). The supporting computing device may be replaceable or otherwise upgradeable to allow extensible execution of the runtime environment by the head unit, where the supporting computing device may be upgraded to facilitate adaption of new features, support (in terms of, as an example, end of life services, such as technology support - including software patching and the like to address security and other concerns), and maintenance (in terms of, for example, hardware upgrades - such as processing capabilities, memory size, etc.).

Addition of the supporting computing device may allow for upgrades to the main computing unit (which is another way to refer to the "head unit" or other computing device) that is less expensive (as the supporting computing device is not seamlessly integrated into the vehicle, but only communicatively coupled to the head unit, thereby relieving expenses associated with the seamless integration, such as form factor, additional components - such as displays, global positioning systems (GPS), etc.). In addition, support of the addition of the supporting computing device may enable upgrades to the main computing device without having to separately replace the main computing device, thereby allowing for upgrade of the main computing device without having to replace the main computing device.

In this respect, various aspects of the techniques may provide a container software architecture (where the term contain may generally refer to a general software block or construct) to ensure synchronization between the main computing device and the supporting computing device in such a manner to potentially provide a consistent user experience even though the main computing device and the supporting computing device may execute different versions of the runtime environment. As such, the techniques may improve operation of the main computing device itself (as facilitating upgrade by way of the supporting computing device may extend the life of the head unit itself and reduce upgrade costs), while potentially maintaining a consistent user experience throughout upgrades to the supporting computing device.

In an example, aspects of the techniques are directed to a method comprising: executing, by a main computing device integrated into a vehicle, a first container that enables execution of a first instance of a runtime environment; executing, by the main computing device, a second container that enables execution of a second instance of the runtime environment, the first instance of the runtime environment and the second instance of the runtime environment configured to jointly present a user interface by which an operator of the vehicle controls functionality of the vehicle; wherein the first instance of the runtime environment is configured to: detect a supporting computing device in communication with the main computing device; transfer, responsive to detecting the supporting computing device, the second container to the supporting computing device; and interface with the second instance of the runtime environment executed by the supporting computing device to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle.

In another example, aspects of the techniques are directed to a main computing device integrated into a vehicle, the main computing device comprising: a memory configured to store a first instance of a runtime environment and a second instance of the runtime environment; one or more processors configured to: execute a first container that enables execution of a first instance of the runtime environment; execute a second container that enables execution of a second instance of the runtime environment, the first instance of the runtime environment and the second instance of the runtime environment configured to jointly present a user interface by which an operator of the vehicle controls functionality of the vehicle; wherein the first instance of the runtime environment is configured to: detect a supporting computing device in communication with the main computing device; transfer, responsive to detecting the supporting computing device, the second container to the supporting computing device; and interface with the second instance of the runtime environment executed by the supporting computing device to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle.

In another example, aspects of the techniques are directed to a non-transitory computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors of a main computing device to: execute a first container that enables execution of a first instance of a runtime environment; execute a second container that enables execution of a second instance of the runtime environment, the first instance of the runtime environment and the second instance of the runtime environment configured to jointly present a user interface by which an operator of the vehicle controls functionality of the vehicle; wherein the first instance of the runtime environment is configured to: detect a supporting computing device in communication with the main computing device; transfer, responsive to detecting the supporting computing device, the second container to the supporting computing device; and interface with the second instance of the runtime environment executed by the supporting computing device to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle.

In another example, aspects of the techniques are directed to a method comprising: receiving, from a main computing device integrated into a vehicle that supports execution of a first container in which a first instance of a runtime environment executes, and by a supporting computing device, a second container that supports execution of a second instance of the runtime environment, the first instance of the runtime environment and the second instance of the runtime environment configured to jointly present a user interface by which an operator of the vehicle controls functionality of the vehicle, and executing, by the supporting computing device, the second container to enable execution of the second instance of the runtime environment, wherein the second instance of the runtime environment is configured to interface with the first instance of the runtime environment executed by the main computing device to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle.

In another example, aspects of the techniques are directed to a supporting computing device comprising: one or more processors configured to: receive, from a main computing device integrated into a vehicle that supports execution of a first container in which a first instance of a runtime environment executes, a second container that supports execution of a second instance of the runtime environment, the first instance of the runtime environment and the second instance of the runtime environment configured to jointly present a user interface by which an operator of the vehicle controls functionality of the vehicle, and execute the second container to enable execution of the second instance of the runtime environment, wherein the second instance of the runtime environment is configured to interface with the first instance of the runtime environment executed by the main computing device to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle; and a memory configured to store the second container.

In another example, aspects of the techniques are directed to a non-transitory computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors of a supporting computing device to: receive, from a main computing device integrated into a vehicle that supports execution of a first container in which a first instance of a runtime environment executes, a second container that supports execution of a second instance of the runtime environment, the first instance of the runtime environment and the second instance of the runtime environment configured to jointly present a user interface by which an operator of the vehicle controls functionality of the vehicle, and execute the second container to enable execution of the second instance of the runtime environment, wherein the second instance of the runtime environment is configured to interface with the first instance of the runtime environment executed by the main computing device to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle; and a memory configured to store the second container.

In another example, aspects of the techniques are directed to a computing system comprising: a main computing device configured to: execute a first container that enables execution of a first instance of a runtime environment; execute a second container that enables execution of a second instance of the runtime environment, the first instance of the runtime environment and the second instance of the runtime environment configured to jointly present a user interface by which an operator of the vehicle controls functionality of the vehicle; wherein the first instance of the runtime environment is configured to: detect a supporting computing device in communication with the main computing device; and transfer, responsive to detecting the supporting computing device, the second container to the supporting computing device; and a supporting computing device configured to: receive, from the main computing device, the second container that supports execution of the second instance of the runtime environment; and execute the second container to enable execution of the second instance of the runtime environment, wherein the second instance of the runtime environment is configured to interface with the first instance of the runtime environment executed by the main computing device to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle.

<FIG> is a block diagram illustrating an example computing system that is configured to provide an extensible computing architecture for vehicles in accordance with various aspects of the techniques described in this disclosure. As shown in the example of <FIG>, a computing system <NUM> includes a main computing device <NUM> and a supporting computing device <NUM>. Although described with respect to a vehicle, the computing system <NUM> may be utilized in different contexts, including standalone computing systems (including laptop computers, desktop computers, workstations and the like), gaming systems, cellular telephones (including so-called "smartphones"), media systems (including streaming media systems), audio/visual (A/V) receivers, televisions (including so-called "smart televisions"), smart speakers, smart watches, thermostats (including so-called "smart thermostats"), smart glasses, or any other computing system.

In any event, main computing device <NUM> is an example of vehicle computing device, such as head unit or other vehicular computing system (such as an electronic control unit - ECU). <FIG> illustrates only one particular example of main computing device <NUM>, and many other examples of main computing device <NUM> may be used in other instances and may include a subset of the components included in example computing device <NUM> or may include additional components not shown in <FIG>.

As shown in the example of <FIG>, main computing device <NUM> includes presence-sensitive display <NUM>, one or more processors <NUM>, one or more communication units <NUM>, one or more input components <NUM>, one or more output components <NUM>, and one or more storage devices <NUM>. Storage devices <NUM> of main computing device <NUM> include a software hierarchy formed, in part, by a hardware abstraction layer <NUM> ("HAL <NUM>"), an runtime environment <NUM> ("RTE <NUM>"), a system and single user services (SSUS) module <NUM> ("SSUS <NUM>"), a system user interface (SUS) module <NUM> ("SUS <NUM>"), a car services (CS) module <NUM> ("CS <NUM>"), and a multi-user service space (MUSS) module <NUM> ("MUSS <NUM>").

Communication channels <NUM> may interconnect each of the components <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> for inter-component communications (physically, communicatively, and/or operatively) and thereby allow components <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> to communicate with one another. In some examples, communication channels <NUM> may include a system bus, a network connection, one or more inter-process communication data structures, or any other components for communicating data (also referred to as information). Although shown as including components <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, main computing device <NUM> may include other components or less components than those shown, where such components may be included in other control units such as a telematic control unit (TCU).

One or more communication units <NUM> of computing device <NUM> may communicate with external devices by transmitting and/or receiving data. For example, main computing device <NUM> may use one or more of communication units <NUM> to transmit and/or receive radio signals on a radio network such as a cellular radio network. In some examples, communication units <NUM> may transmit and/or receive satellite signals on a satellite network such as a Global Positioning System (GPS) network. Examples of communication units <NUM> include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and/or receive information. Other examples of communication units <NUM> may include short wave radios (e.g., NFC, BLUETOOTH (including BLE)), GPS, <NUM>, <NUM>, <NUM>, and WIFI radios found in mobile devices as well as Universal Serial Bus (USB) controllers and the like.

One or more input components <NUM> of main computing device <NUM> may receive input. Examples of input are tactile, audio, kinetic, and optical input, to name only a few examples. Input components <NUM> of main computing device <NUM> include, in one example, a mouse, keyboard, touchpad, voice responsive system, video camera, buttons, scroll wheel, dial, control pad, microphone or any other type of device for detecting input from a human or machine. Input components <NUM> may include cameras. In some examples, input component <NUM> may be a presence-sensitive input component, which may include a presence-sensitive screen, touch-sensitive screen, etc. separate from presence-sensitive display <NUM>.

One or more output components <NUM> of main computing device <NUM> may generate output. Examples of output are tactile, audio, and video output. Output components <NUM> of computing device <NUM>, in some examples, include a presence-sensitive screen (possibly separate from presence-sensitive display <NUM>), sound card, video graphics adapter card, speaker, cathode ray tube (CRT) monitor, liquid crystal display (LCD), organic light emitting diode (OLED), or any other type of device for generating tactile, audio and/or visual output to a human or machine.

In some examples, presence-sensitive display <NUM> of main computing device <NUM> may include functionality of input component <NUM> and/or output components <NUM>. In the example of <FIG>, presence-sensitive display <NUM> may include a presence-sensitive input (PSI) component <NUM> ("PSI component <NUM>"), such as a presence-sensitive screen or touch-sensitive screen. In some examples, presence-sensitive input component <NUM> may detect an object at and/or near the presence-sensitive input component. As one example range, presence-sensitive input component <NUM> may detect an object, such as a finger or stylus that is within two inches or less of presence-sensitive input component <NUM>. Presence-sensitive input component <NUM> may determine a location (e.g., an (x,y) coordinate) of the presence-sensitive input component at which the object was detected. In another example range, presence-sensitive input component <NUM> may detect an object two inches or less from presence-sensitive input component <NUM> and other ranges are also possible. Presence-sensitive input component <NUM> may determine the location of presence-sensitive input component <NUM> selected by a user's finger using capacitive, inductive, and/or optical recognition techniques.

In some examples, presence-sensitive display <NUM> may also provide output to a user using tactile, audio, or video stimuli as described with respect to output component <NUM>. For instance, presence-sensitive display <NUM> may include display component <NUM> that displays a graphical user interface. Display component <NUM> may be any type of output component that provides visual output, such as described with respect to output components <NUM>. While illustrated as an integrated component of main computing device <NUM>, presence-sensitive display <NUM> may, in some examples, be an external component that shares a data or information path with other components of main computing device <NUM> for transmitting and/or receiving input and output. For instance, presence-sensitive display <NUM> may be a built-in component of main computing device <NUM> located within and physically connected to the external packaging of main computing device <NUM> (e.g., an in-vehicle screen mounted in a dashboard of a vehicle). In another example, presence-sensitive display <NUM> may be an external component of main computing device <NUM> located outside and physically separated from the packaging of main computing device <NUM> (e.g., a monitor, a projector, etc. that shares a wired and/or wireless data path with a electronic control unit of the vehicle). In some examples, presence-sensitive display <NUM>, when located outside of and physically separated from the packaging of main computing device <NUM>, may be implemented by two separate components: a presence-sensitive input component <NUM> for receiving input and a display component <NUM> for providing output.

One or more storage components <NUM> within main computing device <NUM> may store information for processing during operation of main computing device <NUM> (e.g., computing device <NUM> may store data accessed by modules <NUM>-<NUM> during execution at main computing device <NUM>). In some examples, storage component <NUM> is a temporary memory, meaning that a primary purpose of storage component <NUM> is not long-term storage. Storage components <NUM> on main computing device <NUM> may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.

Storage components <NUM>, in some examples, also include one or more computer-readable storage media. Storage components <NUM> in some examples include one or more non-transitory computer-readable storage mediums. Storage components <NUM> may be configured to store larger amounts of information than typically stored by volatile memory. Storage components <NUM> may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage components <NUM> may store program instructions and/or information (e.g., data) associated with modules <NUM>-<NUM>. Storage components <NUM> may include a memory configured to store data or other information associated with modules <NUM>-<NUM>.

One or more processors <NUM> may implement functionality and/or execute instructions associated with main computing device <NUM>. Examples of processors <NUM> include application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configure to function as a processor, a processing unit, or a processing device. Modules <NUM>-<NUM> may be operable (or, in other words, executed) by processors <NUM> to perform various actions, operations, or functions of main computing device <NUM>. That is, modules <NUM>-<NUM> may form executable bytecode, which when executed, cause processors <NUM> to perform specific operations (and thereby causing main computing device <NUM> to become a specific-purpose computer by which to perform) in accordance with various aspects of the techniques described herein. For example, processors <NUM> of main computing device <NUM> may retrieve and execute instructions stored by storage components <NUM> that cause processors <NUM> to perform the operations described herein that are attributed to modules <NUM>-<NUM>. The instructions, when executed by processors <NUM>, may cause main computing device <NUM> to store information within storage components <NUM>.

Supporting computing device <NUM> may include components similar to main computing device <NUM>. As further shown in the example of <FIG>, supporting computing device <NUM> may include one or more processors <NUM>, one or more communication units <NUM>, one or more input components <NUM>, one or more output components <NUM>, and one or more storage devices <NUM>. Each of components <NUM>-<NUM> may be similar to, if not substantially similar to, respective components <NUM>-<NUM>, as discuss in more detail above, except that supporting computing device <NUM> may not include a presence-sensitive display similar to presence-sensitive display <NUM> or any other visual, auditory, or other output device or interface.

Supporting computing device <NUM> also includes communication bus <NUM> interconnecting modules <NUM>-<NUM>. Communication bus <NUM> may be similar to, if not substantially similar to, communication bus <NUM> discussed in more detail above.

Furthermore, storage devices <NUM> may store modules <NUM>-<NUM>, which may be similar to, if not substantially similar to, respective modules <NUM>-<NUM>. That is, storage devices <NUM> may store a HAL <NUM>, OS <NUM>, SSUS <NUM>, SUI <NUM>, CS <NUM>, and MUSS <NUM>, which each function as indicated above to offload operation of or act in coordination with respective modules <NUM>-<NUM> to execute various aspects of the techniques described in more detail below.

As described above, computing system <NUM> may be integrated or otherwise included within a vehicle. The vehicle may include one or more of a bicycle, a tricycle, a unicycle, an automobile, farm equipment (such as a tractor, combine, etc.), construction equipment (a dump truck, crane, etc.), military vehicle or equipment (a tank, armament, etc.), a truck, a semi-tractor (or, in other words, a semi-trailer), aviation equipment (such as a plane), nautical equipment (such as a boat, carrier, etc.), or any other type of vehicle.

Reliability of vehicles is increasing to the point that the average life cycle of vehicles is at or nearing ten plus years of service. As vehicles age during the years of service, computing systems, such as computing system <NUM>, including head units, electronic control units (ECUs), and the like, may increasingly become outdated, entering end of life in terms of technical support, maintenance (and other support), and support of new features. Moreover, head units and other computing systems, including main computing device <NUM>, are increasingly being seamlessly integrated into dashboards and other components of the vehicles such that replacement of the head units (where main computing device <NUM> is one example) is becoming difficult due to unique form factors, inclusion of large and possibly expensive displays, etc..

Although upgrade of the head unit is possible, such upgrades to replace the head unit (and other computing systems) is often expensive (as the cost of replacing an entire head unit may require replacement of the display and other (relatively) expensive components, which, while not necessary, is required (as the head unit often integrates the display and other expensive components into a single housing or replaceable unit) and difficult (as such head units are seamlessly integrated into each vehicle and specific to each make and model of the vehicle, potentially limiting availability of replacement head units and further possibly driving up the cost). As such, operators of vehicles may purchase an entirely new vehicle in an effort to gain access to newer technology, such as computing systems, including head units and other infotainment and other components, at considerable expense.

The migration path for acquiring updated computing systems may result in considerable expense (both in initial outlays of money to purchase a new or newer vehicle and in terms of upgrade costs for replacing head units) to operators that would like to access newer technology (e.g., a new head unit that offers extended functionality in terms of features provided by upgraded OS, applications, etc.). The expense of migration to newer technology may present a barrier to adoption of the newer technology, slowing uptake by operators of various features, that may include safety features, security features, data privacy features, and the like.

In accordance with various aspects of the techniques described in this disclosure, computing system <NUM> may implement an extensible computing architecture for vehicles. Rather than replace main computing unit <NUM> (which may represent one example of a so-called "head unit" and as such be referred to as "head unit <NUM>") or other computing systems of a vehicle, the techniques may enable head unit <NUM> or other computing system to interface with supporting computing system <NUM> that is communicatively coupled to head unit <NUM>, where head unit <NUM> or other computing device may offload or otherwise transfer execution of applications (and other runtime environment level operations, not just execution of the application space) to supporting computing device <NUM>.

Head unit <NUM> or other computing device may detect communicatively coupling of supporting device <NUM> and, responsive to detecting the communicative coupling of supporting computing device <NUM>, transfer a container <NUM> that includes a partition of runtime environment <NUM> to supporting computing device <NUM>. Although described as transferring container <NUM> to supporting computing device <NUM>, head unit <NUM> may merely transfer an indication that supporting computing device <NUM> has been detected and should begin execution of a pre-installed container (similar to container <NUM>) in order to execute a pre-installed partition of the OS, which may be similar if not substantially similar to runtime environment <NUM>. As such, transfer of the container <NUM> should be understood to refer to transfer of the actual container itself or transfer of execution of a pre-installed container from head unit <NUM> to supporting computing device <NUM>.

In any event, supporting computing device <NUM> may then execute the partition of RTE <NUM> in order to synchronize operation of RTEs <NUM> and <NUM> and thereby provide a user space in which the applications may execute (while also supporting execution of the kernel space, or in other words, the runtime environment space, as a distributed runtime environment). Supporting computing device <NUM> may be replaceable or otherwise upgradeable to allow extensible execution of RTEs <NUM> and <NUM> by head unit <NUM>, where supporting computing device <NUM> may be upgraded to facilitate adaption of new features, support (in terms of, as an example, end of life services, such as technology support - including software patching and the like to address security and other concerns), and maintenance (in terms of, for example, hardware upgrades - such as processing capabilities, memory size, etc.).

Addition of supporting computing device <NUM> may allow for upgrades to main computing unit <NUM> (which is, again, another way to refer to the "head unit" or other computing device) that is less expensive (as supporting computing device <NUM> is not seamlessly integrated into the vehicle, but only communicatively coupled to head unit <NUM>, thereby relieving expenses associated with the seamless integration, such as form factor, additional components - such as displays, global positioning systems (GPS), etc.). In addition, support of the addition of supporting computing device <NUM> may enable upgrades to main computing device <NUM> without having to separately replace main computing device <NUM>, thereby allowing for upgrade of main computing device <NUM> without having to replace main computing device <NUM>.

In this respect, various aspects of the techniques may provide a container software architecture to ensure synchronization between main computing device <NUM> and supporting computing device <NUM> in such a manner to potentially provide a consistent user experience even though main computing device <NUM> and the supporting computing device <NUM> may execute different versions of the runtime environment. As such, the techniques may improve operation of main computing device <NUM> itself (as facilitating upgrade by way of supporting computing device <NUM> may extend the life of head unit <NUM> itself, reducing upgrade costs and promoting improved functionality as offloading processing to supporting computing device <NUM> may result in improved processing, storage, and/bandwidth), while potentially maintaining a consistent user experience throughout upgrades to supporting computing device <NUM>.

In operation, main computing device <NUM> may initially execute a first container <NUM> that enables execution of a first instance of an runtime environment (e.g., RTE <NUM>). As described above, main computing device <NUM> may include the above noted software hierarchy. As such, HAL <NUM> may execute as a kernel software shim between a kernel of RTE <NUM> to provide seamless interaction between RTE <NUM> and underlying hardware of the vehicle (which is not shown for ease of illustration). Hardware components of the vehicle may include a GPS system, an automation system (such as self-driving systems and/or dynamic cruise control systems), heating, ventilation, and air condition (HVAC) systems, window systems (for controlling operation of the windows), interior lighting systems (for controlling operation of various interior lights), exterior lighting systems (for controlling operation of various exterior lights), safety systems (including, for example, automatic breaking systems - ABS, lane assist systems, attention-based safety systems, etc.), heated seating systems, cooled seating systems, or any other system present in vehicles.

As such, RTE <NUM> may execute within HAL <NUM>, where HAL <NUM> may intercept commands or other output signals issued by RTE <NUM> and translate the RTE-specific commands to vehicle-specific commands supported by the underlying vehicle hardware while also translating vehicle-specific data into RTE-specific data supported by RTE <NUM>. Translation of the OS-specific commands and the vehicle-specific data may occur transparently to RTE <NUM>, allowing separate development of HAL <NUM> from RTE <NUM> and thereby facilitate adoption of a general RTE <NUM> with a shim (e.g., HAL <NUM>) tailored for individual vehicles (which may vary across make and model in terms of original equipment manufacturer - OEM - hardware and/or components).

RTE <NUM> may execute in the above mentioned kernel space to provide an execution environment for system level applications and user applications. In the example of <FIG>, SSUS <NUM>, SUI <NUM>, and CS <NUM> may each represent system level applications that execute within the execution environment provided by RTE <NUM>. RTE <NUM> may grant each of SSUS <NUM>, SUI <NUM>, and CS <NUM> system level privileges that permit increased access to the underlying vehicle hardware, while RTE <NUM> grants user-specific privileges to applications executing within MUSS <NUM> that are more restrictive than the system level privileges granted to each of SSUS <NUM>, SUI <NUM>, and CS <NUM>. The system level privileges may allow increased access (in terms of permissions to access or priority) to the vehicle hardware components compared to the user-specific privileges. As an example, SSUS <NUM>, SUI <NUM>, and CS <NUM> may access one or more of the hardware systems or components of the vehicle to control operation of the hardware systems or components while MUSS <NUM> may only access data provided by the hardware systems or components of the vehicle (such as GPS coordinates output by the GPS system, ambient temperature output by the HVAC system, etc.).

SSUS <NUM> may represent a module configured to execute single-user services (e.g., services that are common across all users, and as such may also be referred to as "common services") and system services (e.g., first party applications that are installed across all users and present one or more system services for use by all users of main computing device <NUM>). SUI <NUM> may represent a module configured to present a system-level user interface with which the operator of the vehicle may interact to control various operations of the vehicle as well as launch or otherwise initiate execution of applications (as represented by MUSS <NUM>). CS <NUM> may represent a module configured to interface (e.g., an API) with various car services, including GPS systems, HVAC systems, seating systems, window systems, or any other the other systems listed more exhaustively elsewhere herein.

MUSS <NUM> may represent one or more modules that provide individual user profiles that include specific third party applications, user-specific automotive services (associated with an individual user), and other user-specific data or information. MUSS <NUM> may execute in the application space maintained by the underlying RTE <NUM>. MUSS <NUM> may, in this respect, represent a module executing in application space to provide extended software capabilities by way of applications that can be downloaded and/or installed to extend the capabilities of main computing device <NUM>.

Main computing device <NUM> may also initially execute (although not shown in <FIG> for ease of illustration) a second container <NUM> that enables execution of a second instance of runtime environment (e.g., RTE <NUM>), where RTE <NUM> and RTE <NUM> may be configured to jointly present a user interface (e.g., as provided by SUI <NUM> and <NUM>) by which an operator of the vehicle controls functionality of the vehicle. Main computing device <NUM> may execute container <NUM> as a primary or host container <NUM> and the container <NUM> as a secondary of client container <NUM>, where client container <NUM> operates to support execution of host container <NUM>. As such, client container <NUM> may operate on behalf of host container <NUM> and may not execute independent of host container <NUM>. Although described as operating on behalf of host container <NUM>, client container <NUM> may execute independent of host container <NUM>, where host container <NUM> may, in this example, represent a shim for passing data to client container <NUM>.

Main computing device <NUM> may execute (via, as noted above, processors <NUM>) container <NUM>, which may invoke execution of RTE <NUM> (and underlying HAL <NUM>). RTE <NUM> may, via interactions with input components <NUM> and/or communication units <NUM>, detect supporting computing device <NUM> in communication with main computing device <NUM>. That is, supporting computing device <NUM>, upon being connected to main computing device <NUM>, may power on (when powered via the communication interface) and execute a lightweight operating system or (different than RTE <NUM>) or other low-level software (such as firmware, etc.) by which to interface, via output components <NUM> and/or communication units <NUM>, with main computing device <NUM>. RTE <NUM> may then detect communicative coupling with supporting computing device <NUM>, which may involve a protocol or other application programmer interface (API) call to establish communication between main computing device <NUM> and supporting computing device <NUM>.

The connection between main computing device <NUM> and supporting computing device <NUM> is shown as connection <NUM> in the example of <FIG>. Connection <NUM> may include a wireless connection, a wired connection (where connection is established via physical wire, such as a USB connection of any version - <NUM>, <NUM>, <NUM>, etc.), or a combination of wired (e.g., for power) and wireless connection.

Responsive to detecting supporting computing device <NUM>, RTE <NUM> may transfer container <NUM> to supporting computing device <NUM>. RTE <NUM> may transfer container <NUM> via output components <NUM> and/or communication units <NUM> to supporting computing device <NUM>. Supporting computing device <NUM> may receive container <NUM>, and execute the container <NUM> to establish a software hierarchy similar to that described above with respect to main computing device <NUM>, thereby facilitating execution of HAL <NUM>, RTE <NUM>, SSUS <NUM>, SUI <NUM>, CS <NUM>, and MUSS <NUM>.

In effect, main computing device <NUM> executes an overall RTE in segments or partitions, in which a first partition of the RTE (e.g., RTE <NUM>) executes in conjunction with a second partition of the RTE (e.g., RTE <NUM>) to support the system and application space in which SSUS <NUM>, <NUM>, SUI <NUM>, <NUM>, CS <NUM>, <NUM>, and MUSS <NUM> and <NUM> execute. Main computing system <NUM> executes containers <NUM> and <NUM> until detecting that supporting computing device <NUM> is communicatively coupled to main computing device <NUM>.

Main computing device <NUM>, prior to detecting communicative coupling with supporting computing device <NUM>, executes both partitions (e.g., containers <NUM> and <NUM>) of the overall RTE in a manner similar to, if not substantially similar to, that described below with respect to execution of a single container (e.g., container <NUM>). In other words, when executing both of containers <NUM> and <NUM>, main computing device <NUM> continues to relay and synchronize data between containers <NUM> and <NUM>, executing container <NUM> to support the application space in which MUSS <NUM> and <NUM> executes.

Transferring of container <NUM> to supporting computing device <NUM>, in this way, offloads execution of the container <NUM> to supporting computing device <NUM>, which allows main computing device <NUM> to reduce processing cycle, memory, and/or bandwidth consumption. As such, RTE <NUM> operates as the host RTE relative to RTE <NUM>, which operates as a client RTE. RTE <NUM> may redirect user input and other data to RTE <NUM>, which may process the user input or other data and coordinate with RTE <NUM> to present any resulting outputs (e.g., via presence-sensitive display <NUM>).

For example, HAL <NUM> may interface with HAL <NUM> to relay commands or other data from RTE <NUM>, SSUS <NUM>, and MUSS <NUM> that may control or otherwise update various settings associated with vehicle hardware components. Likewise, HAL <NUM> may relay command or other data from the vehicle hardware components to RTE <NUM>, SSUS <NUM>, and MUSS <NUM>. In addition, RTE <NUM> and RTE <NUM> may exchange system settings, user settings, and other data or information to synchronize the various types of data in order to jointly execute a single instance of the RTE. In some examples, RTE <NUM> may have a particular version that is different than a version of the RTE <NUM>, where RTE <NUM> may present a common API with which to interface with the RTE <NUM> that is the same or backwards compatible with the API used by RTE <NUM> to interface with the RTE <NUM> (despite having different executable code that is upgraded or more processor, memory, and/or bandwidth intensive than the executable code of the RTE <NUM>). Furthermore, CS <NUM> and CS <NUM> may relay commands or other data between each other to synchronize support of car services between main computing device <NUM> and supporting computing device <NUM>.

RTE <NUM> may, in this respect, interface with RTE <NUM> executed by supporting computing device <NUM> to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle. RTE <NUM> may synchronize or otherwise maintain data structures that enable RTE <NUM> to obtain consistent state and other informational data with that maintained by RTE <NUM>, both regarding the current operator (or, in other words, user of computing system <NUM>) and the vehicle in which computing system <NUM> is integrated. As such, RTEs <NUM> and <NUM> may represent an instance of a distributed runtime environment capable of or otherwise configured to execute across one or more devices (e.g., main computing device <NUM> and/or supporting computing device <NUM>) in order to jointly present the user interface by which to interact with the operator of the vehicle and the vehicle itself.

In this way, various aspects of the techniques may provide a container software architecture to ensure synchronization between main computing device <NUM> and supporting computing device <NUM> in such a manner to potentially provide a consistent user experience even though main computing device <NUM> and the supporting computing device <NUM> may execute different versions of the runtime environment (as described in more detail below). As such, the techniques may improve operation of main computing device <NUM> itself (as facilitating upgrade by way of supporting computing device <NUM> may extend the life of head unit <NUM> itself, reducing upgrade costs and promoting improved functionality as offloading processing to supporting computing device <NUM> may result in improved processing, storage, and/bandwidth), while potentially maintaining a consistent user experience throughout upgrades to supporting computing device <NUM>.

<FIG> is a block diagram illustrating example operation of a head unit in performing various aspects of the extensible hardware architecture techniques described in this disclosure. As shown in the example of <FIG>, a head unit <NUM> is configured to execute an OEM container <NUM> and a cartridge container <NUM>. Head unit <NUM> may represent one example of main computing device <NUM> shown in the example of <FIG>, while OEM container <NUM> may represent one example of container <NUM> shown in the example of <FIG> and cartridge container may represent one example of container <NUM> shown in the example of <FIG>.

As such, OEM container <NUM> may include RTE <NUM>, SSUS <NUM>, SUI <NUM>, CS <NUM>, and MUSS <NUM>, which may execute to provide the functionality described above. In addition, cartridge container <NUM> may include RTE <NUM>, SSUS <NUM>, SUI <NUM>, CS <NUM>, and MUSS <NUM>, which may execute to provide the functionality described above. Head unit <NUM> may execute a single instance of HAL <NUM>, which is similar to HAL <NUM> and HAL <NUM>, except configured to support both of OEM container <NUM> and cartridge container <NUM>.

Head unit <NUM> may execute both containers <NUM> and <NUM> as independent containers in which different partitions of the runtime environment (e.g., RTE <NUM> and RTE <NUM>) execute to jointly present the user interface with which the operator interacts to control hardware components of the vehicle. Although HAL <NUM> may not synchronize data or other information (given that there is a single instance of HAL <NUM>), RTE <NUM> and RTE <NUM> along with CS <NUM> and CS <NUM> may synchronize data (including state data, such as system settings and user settings) between one another. That is, RTE <NUM> may synchronize a user setting, a system setting, or some other setting between RTE <NUM> and RTE <NUM> to maintain a consistent user experience whether executing RTE <NUM> or RTE <NUM> alone (e.g., without executing the other RTE).

In addition, RTE <NUM> may redirect execution of an application to cartridge container <NUM>, issuing a redirect command to the RTE <NUM>. Responsive to the redirect command, RTE <NUM> may invoke the application, maintaining the application space in which the application executes, and execute the application.

As described above, RTE <NUM> may detect communicative coupling with cartridge <NUM>, an example implementation of supporting computing device <NUM>. That is, RTE <NUM> may detect formation of communication channel <NUM> (which is another way to refer to "connection <NUM>") between head unit <NUM> and cartridge <NUM>, which previously was a virtual connection <NUM> internal to head unit <NUM>. In other words, when synchronizing internally within head unit <NUM>, RTE <NUM> may establish virtual connection <NUM> between OEM container <NUM> and cartridge container <NUM>, where virtual connection <NUM> may appear to each of RTE <NUM> and RTE <NUM> as an external connection similar to connection <NUM>.

Responsive to detecting the formation of connection <NUM>, RTE <NUM> may initiate a number of different operations to transfer cartridge container <NUM> to cartridge <NUM>. First, RTE <NUM> may replicate HAL <NUM> to obtain HAL <NUM>, which RTE <NUM> may provide to cartridge <NUM>. HAL <NUM> may then, after replication, reinitialize as HAL <NUM>, which forms a first partition of a distributed HAL. RTE <NUM> may transfer HAL <NUM> to cartridge <NUM>, where HAL <NUM> forms a second partition of the distributed HAL. Cartridge <NUM> may execute HAL <NUM> to communicate with HAL <NUM> and enable cartridge <NUM> to interface with the hardware components of the vehicle (e.g., possibly by transferring commands and other data to HAL <NUM>, which relays the commands and other data to the hardware components of the vehicle).

RTE <NUM> may next initiate transfer of cartridge container <NUM> to cartridge <NUM>, thereby enabling execution of the software hierarchy by the cartridge <NUM>. Cartridge <NUM> may execute RTE <NUM> followed by execution of SSUS <NUM>, SUI <NUM>, CS <NUM>, and MUSS <NUM>. Execution of RTE <NUM>, SSUS <NUM>, SUI <NUM>, CS <NUM>, and MUSS <NUM> may result in the exchange of commands and other data that synchronizes operation of each of RTE <NUM>, <NUM>, SSUS <NUM>, <NUM>, SUI <NUM>, <NUM>, CS <NUM>, <NUM>, and MUSS <NUM>, <NUM>. As such, one or more of RTE <NUM>, SSUS <NUM>, SUI <NUM>, CS <NUM>, and MUSS <NUM> may receive a user setting, a system setting, or other data by which to synchronize operation of the distributed execution environment across head unit <NUM> and cartridge <NUM>.

As head unit <NUM> may include an integrated display (e.g., presence sensitive display <NUM>), while cartridge <NUM> may not include any form of integrated display (e.g., to reduce costs associated with cartridge <NUM>), RTE <NUM> may interface with RTE <NUM> to present the user interface via the integrated display of the head unit <NUM>. Applications executed by MUSS <NUM> may pass function calls and kernel level function calls related to graphical user interfaces or other types of interfaces to RTE <NUM>, which may interface with RTE <NUM> to jointly process the commands.

RTE <NUM> may translate or otherwise process the function calls to conform to the API for communicating with RTE <NUM>. That is, RTE <NUM> may conform to a different version of the RTE than RTE <NUM>, and the function calls may conform to the version of the RTE to which RTE <NUM> conforms. As such, RTE <NUM> may translate the function calls to conform to the version of the RTE to which RTE <NUM> conforms to maintain backward compatibility with the version of the RTE to which RTE <NUM> conforms. In this respect, RTE <NUM> may represent a shim or other software construct by which to provide backward compatibility between different versions of software (such as runtime environments).

<FIG> is a diagram illustrating an example of a vehicle that includes a computing system configured to operate in accordance with various aspects of the extensible computing architecture techniques described in this disclosure. As shown in the example of <FIG>, an interior of vehicle <NUM> may include a computing system in which head unit <NUM> is communicatively coupled (e.g., via a USB connection <NUM>) to cartridge <NUM>, which may reside in a glovebox <NUM> of vehicle <NUM>. Cartridge <NUM> and USB connection <NUM> is shown in dashed lines to indicate that cartridge <NUM> and USB connection <NUM> are installed behind the dashboard (for USB connection <NUM>) and glovebox cover (for cartridge <NUM>) and therefore not visible when viewed by an operator of vehicle <NUM>. Although not shown, cartridge <NUM> may include another USB port (or other interface port) by which to interface with yet another computing device, such as a smartphone, laptop computer, desktop computer, workstation, gaming system, etc..

Although shown as being installed in glovebox <NUM>, cartridge <NUM> may be installed anywhere in vehicle <NUM> where power is available to be provided to cartridge <NUM>. As such, cartridge <NUM> may be installed in a center dash console location 504A, mounted below driver dash location 504B, a driver door location 504C, an under driver seat location 504D, a center arm rest console location 504E, an under passenger seat location 504F, and/or a passenger door location <NUM>, as well as any other location at which power is available (but not shown in the example of <FIG>) such as a rear trunk, a forward trunk, under a rear passenger seat, a rear passenger door, etc..

<FIG> is a flowchart illustrating example operation of a computing system in performing various aspects of the extensible computing architecture techniques described in this disclosure. As described in more detail above, main computing device <NUM> may initially execute both first container <NUM> and second container <NUM> in order to execute the first instance of RTE <NUM> and the second instance of RTE <NUM> (<NUM>, <NUM>). In order to execute RTEs <NUM> and <NUM>, main computing device <NUM> may execute a distributed HAL, such as HAL <NUM> (as shown in the example of <FIG>). The distributed HAL may enable RTEs <NUM>, <NUM> to interface with underlying vehicle hardware components, providing an interface, such as an API, with which RTEs <NUM> and <NUM> may interface to provide commands and receive data from the underlying vehicle hardware components (e.g., any of the systems described above in more detail).

RTE <NUM> and/or <NUM> may detect communicative coupling of supporting computing device <NUM> (<NUM>). RTE <NUM> may transfer, responsive to detecting the communicative coupling of supporting computing device <NUM> (or, in other words, responsive to detecting supporting computing device <NUM>), second container <NUM> to supporting computing device <NUM> (<NUM>). Supporting computing device <NUM> may receive second container <NUM> (<NUM>), and execute second container <NUM>. That is, supporting computing device <NUM> may execute a lightweight or minimal operating system by which to initially connect to main computing device <NUM> (such as a boot loader or other low-level operating system that may provide minimal functionality in order to interface with main computing device <NUM> but that does not facilitate user or operator interaction or otherwise present a user interface - except potentially a low level user interface, such as a command line interface for purposes of debugging, data gathering, troubleshooting, etc.).

In any event, supporting computing device <NUM> may receive second container <NUM>, whereupon the low-level operating system may mount second container <NUM> and execute second container <NUM> to thereby execute RTE <NUM> (<NUM>). In executing RTE <NUM>, RTE <NUM> and RTE <NUM> may synchronize user settings, system settings, and other data or information to thereby jointly present a user interface with which the operator of the vehicle may interact (<NUM>, <NUM>). RTE <NUM> may receive an indication to initiate execution of an application (e.g., via presence-sensitive display <NUM>) and transfer the indication to supporting computing device <NUM> (<NUM>, <NUM>). Supporting computing device <NUM> may receive the indication <NUM> (<NUM>), where RTE <NUM> may initiate execution, responsive to receiving the indication, the indicated application (<NUM>). RTE <NUM> and RTE <NUM> may continue in this manner to present the user interface, synchronize user settings, system settings, or other state data between RTEs <NUM> and <NUM>, and execute application responsive to indications (<NUM>-<NUM>).

If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. In this manner, computer-readable media generally may correspond to (<NUM>) tangible computer-readable storage media, which is non-transitory or (<NUM>) a communication medium such as a signal or carrier wave.

Disk and disc, as used, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, ultra Blu-ray, etc. where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Accordingly, the term "processor," as used may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described. In addition, in some aspects, the functionality described may be provided within dedicated hardware and/or software modules.

Claim 1:
A method comprising:
receiving, from a main computing device integrated into a vehicle that supports execution of a first container in which a first instance of a runtime environment executes, and by a supporting computing device, a second container that supports execution of a second instance of the runtime environment, the first instance of the runtime environment and the second instance of the runtime environment configured to jointly present a user interface by which an operator of the vehicle controls functionality of the vehicle; and
executing, by the supporting computing device, the second container to enable execution of the second instance of the runtime environment, wherein the second instance of the runtime environment is configured to interface with the first instance of the runtime environment executed by the main computing device to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle.