Network Management for Vehicle Operating Systems

Abstract

A vehicle head unit including a memory configured to store an operating system and one or more processors may be configured to perform various aspects of the present technology. The one or more processors may execute the operating system that presents a single application programming interface that obtains instructions for one or more vehicle networks and provides function calls for configuring the one or more vehicle networks within the operating system. The one or more processors may also configure, via the single application programming interface, one or more network interfaces for the one or more vehicle networks within the operating system such that one or more applications executing within the application space presented by the operating system interface with the one or more vehicle networks.

Description

[Background technology]

[0001] A vehicle may include a so-called "head unit" or other integrated computing device that presents an interface (e.g., a graphical user interface (GUI)) that controls vehicle systems such as a heating, ventilation, and air conditioning (HVAC) system, a lighting system (for controlling interior and / or exterior lighting), an infotainment system (including standard amplitude modulation (AM) radio, frequency modulation (FM) radio, streaming radio, video playback, audio playback, etc.), a seating system (for controlling driver and / or passenger seat position), a mirror system (for controlling exterior and / or interior mirrors), a telematics system (for capturing data related to vehicle use and / or operation), and an over-the-air update system (for updating firmware and / or other software executed by the vehicle). The head unit may issue one or more commands (also referred to in this disclosure as a "command set") to vehicle systems to change the operational state of one or more of the vehicle systems.

[0002] As vehicles such as automobiles, motorcycles, buses, recreational vehicles (RVs), semi-trailer trucks, tractors or other types of agricultural equipment, trains, airplanes, drones, helicopters, and personal transportation vehicles continue to evolve, such vehicles may begin to implement various networks to interconnect vehicle systems to a head unit. Recently, standard Layer 2 networks (such as Ethernet networks) have been introduced into vehicles to facilitate communication between various vehicle systems. While Ethernet networks (or other Layer 2 networks) may provide uniform network access among vehicle systems, the operating system executed by the head unit (sometimes referred to as the vehicle operating system) may have difficulty configuring such networks in terms of presenting them for use by applications running within the execution environment provided by the operating system. Summary of the Invention

[0003] In general, the technology of the present disclosure is directed to efficiently configuring network management for applications executed by a vehicle head unit. Rather than relying on so-called “low-level” management of the network, various aspects of the technology enable a vehicle operating system executed by the vehicle head unit to present a single application programming interface (API) for configuring network access and control for applications executing within the vehicle operating system's application space (as opposed to a secure kernel space). Through this single API, applications may register network access calls with the vehicle operating system for a particular vehicle network that interconnects the vehicle head unit running the vehicle operating system to various vehicle systems. The vehicle operating system may be configured to implement an access control list (ACL) and use this ACL to determine whether a particular application attempting to register a vehicle network access call is allowed to access the underlying vehicle network. If authorized via the ACL, the vehicle operating system may configure an interface (which may be a virtual interface) through which the particular application may access the underlying vehicle network; such configuration may include assigning a network address (e.g., an Internet Protocol (IP) address).

[0004] In this way, rather than relying on complex, so-called "low-level" configurations where vehicle manufacturers statically configure (or, in other words, "hard-code") vehicle network configurations for each application on their own, such vehicle manufacturers may program applications or have third-party application developers develop applications that interface with a single API exposed natively by the vehicle operating system to perform network management. Vehicle manufacturers may deploy ACLs that restrict or allow access to the underlying vehicle network based on an application certification process that complies with the laws of the various jurisdictions in which the vehicle is sold.

[0005] Additionally, vehicle operating systems may be developed that accommodate various jurisdictional laws while also enabling vehicle network access for applications executed by the vehicle operating system. Given that vehicle network access may be managed through a single API, vehicle manufacturers may not require dedicated computer programmers to "hard-code" network access, but may facilitate independent network management by application developers (including first-party and third-party application developers). Because this single API is managed by the vehicle operating system developer, such vehicle network management may be natively supported as the vehicle operating system undergoes additional development and modifications.

[0006] Thus, a single network management API may facilitate more efficient operation of the vehicle operating system, as well as improve access to the vehicle network by applications executed by the vehicle operating system. Because a single API may reduce errors caused by such "hard-coded" network management, which may result in errors (security or otherwise) that could create safety or vehicle network misuse issues, the vehicle operating system may operate more efficiently, resulting in efficient utilization of the vehicle head unit's computing resources (e.g., in terms of processor cycles, memory, memory bandwidth, and associated power). Furthermore, given the centralization of a single API for network management, application developers may secure access to specific vehicle networks through manufacturing validation, while manufacturers may also disable vehicle network access to vehicle systems that may pose security and / or safety risks, thereby improving the safety and / or security of the vehicle itself.

[0007] In one example, various aspects of the present technology are directed to a method that includes obtaining, by one or more processors of a vehicle head unit, instructions for one or more vehicle networks; executing, by the one or more processors, an operating system that presents a single application programming interface that provides function calls for configuring the one or more vehicle networks within the operating system; and configuring, via the single application programming interface, one or more network interfaces for the one or more vehicle networks within the operating system such that one or more applications executing within the application space presented by the operating system interface with the one or more vehicle networks.

[0008] In another example, various aspects of the present technology are directed to a vehicle head unit comprising: a memory configured to store an operating system; and one or more processors, the one or more processors configured to execute the operating system that presents a single application programming interface that obtains instructions for one or more vehicle networks and provides function calls for configuring the one or more vehicle networks within the operating system; and configure, via the single application programming interface, one or more network interfaces for the one or more vehicle networks within the operating system such that one or more applications executing within the application space presented by the operating system interface with the one or more vehicle networks.

[0009] In another example, various aspects of the present technology are directed to a non-transitory computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors of a vehicle head unit to obtain instructions for one or more vehicle networks, execute an operating system that presents a single application programming interface that provides function calls for configuring the one or more vehicle networks within the operating system, and configure, via the single application programming interface, one or more network interfaces for the one or more vehicle networks within the operating system such that one or more applications executing within the application space presented by the operating system interface with the one or more vehicle networks.

[0010] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram illustrating an exemplary vehicle configured to perform various aspects of the techniques described in this disclosure. [Figure 2] FIG. 2 is a block diagram illustrating a conceptual configuration of network management via a single application programming interface for the vehicle shown in the example of FIG. 1 in accordance with various aspects of the techniques described in this disclosure. [Figure 3] FIG. 3 is a block diagram illustrating in greater detail the vehicle operating system shown in the example of FIGS. 1 and 2 that supports efficient network management in accordance with various aspects of the techniques described in this disclosure. [Figure 4] FIG. 4 is a block diagram illustrating how the vehicle operating system shown in the example of FIGS. 1-3 may implement access control lists while performing network management in accordance with various aspects of the techniques described in this disclosure. [Figure 5] FIG. 3 illustrates a state diagram depicting exemplary operation of the vehicle operating system shown in the example of FIGS. 1 and 2 when performing network management in accordance with various aspects of the techniques described in this disclosure. [Figure 6] 2 is a flowchart illustrating exemplary operations by the vehicle operating system shown in the example of FIG. 1 in performing various aspects of network management techniques. DETAILED DESCRIPTION OF THE INVENTION

[0012] 1 is a block diagram illustrating an example vehicle 100 configured to perform various aspects of the techniques described in this disclosure. In the example of FIG. 1, vehicle 100 is assumed to be an automobile for the purposes of the following discussion. However, the techniques described in this disclosure may be applied to any type of vehicle that utilizes a network for communication between vehicle systems, and such vehicles may include motorcycles, buses, recreational vehicles (RVs), semi-trailer trucks, tractors or other types of agricultural equipment, trains, airplanes, drones, helicopters, personal transportation vehicles, etc. In some examples, vehicle 100 may be an autonomous vehicle.

[0013] 1, vehicle 100 includes a processor 102, a graphics processing unit (GPU) 104, and a system memory 106. In some examples, processor 102, GPU 104, and a transceiver module (not shown in FIG. 1) may be formed as an integrated circuit (IC). For example, the IC may be considered a processing chip within a chip package or may be a system-on-chip (SoC).

[0014] Examples of processor 102 and GPU 104 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 circuits. Processor 102 may represent the central processing unit (CPU) of vehicle 100. In some examples, GPU 104 may be dedicated hardware including integrated and / or discrete logic circuits that provide GPU 104 with massively parallel processing capabilities suitable for graphics processing. In some examples, GPU 104 may also include general-purpose processing capabilities and may be referred to as a general-purpose GPU (GPGPU) when implementing general-purpose processing tasks (e.g., non-graphics-related tasks). Although shown as a dedicated GPU 104, GPU 104 may represent an integrated GPU that is integrated into an underlying circuit board (such as a so-called "motherboard") or otherwise incorporated into processor 102.

[0015] The processor 102 may execute various types of applications 118. Example applications include a web browser, a navigation application, a radio application (including a streaming music application), a text application, a vehicle management application, a system configuration application, a vehicle system control application (for the heating, ventilation, and air conditioning (HVAC) system, the mirror system, the seating system, the lighting system, and / or any other system represented by vehicle systems 114A-114N, as some examples), an email application, a spreadsheet application, a video game, or any other application that may generate a visible object for display or otherwise interface with the vehicle 100. The system memory 106 may store instructions for executing one or more applications 118. Execution of the applications 118 by the processor 102 causes the processor 102 to generate graphics data for image content displayed via the display 108, as one example. The processor 102 may send the graphics data of the image content to the GPU 104 for further processing based on instructions or commands that the processor 102 sends to the GPU 104.

[0016] The processor 102 may communicate with the GPU 104 according to an application programming interface (API). Furthermore, the techniques described in this disclosure are not required to function according to an API, and the processor 102 and the GPU 104 may utilize any technique for communicating with the GPU 104.

[0017] System memory 106 may represent memory for vehicle 8. System memory 106 may include one or more computer-readable storage media. Examples of system memory 106 include, but are not limited to, random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other media that can be used to carry or store desired program code in the form of instructions and / or data structures and that are accessible by a computer or processor. In some aspects, system memory 106 may include instructions that cause processor 102 to perform functions attributed to processor 102 in this disclosure. Thus, system memory 106 may represent a non-transitory computer-readable storage medium on which are stored instructions that, when executed, cause one or more processors (e.g., processor 102) to perform various functions.

[0018] As such, system memory 106 may, in other words, represent a non-transitory storage medium. The term "non-transitory" indicates that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be interpreted to mean that system memory 106 is non-removable or that its contents are static. As one example, system memory 106 may be removed from vehicle 100 and moved to another device. As another example, memory substantially similar to system memory 106 may be inserted into vehicle 100. In certain examples, non-transitory storage media may store data that is changeable over time (e.g., in RAM).

[0019] As further shown in the example of FIG. 1 , vehicle 100 may include a display 108 and a user interface 110. Display 108 may represent any type of passive reflective screen capable of projecting an image, or an active reflective, emissive, or transmissive display capable of displaying an image (such as a light-emitting diode (LED) display, an organic LED (OLED) display, a liquid crystal display (LCD), or any other type of active display). Although shown as including a single display 108, vehicle 100 may include multiple displays that may be disposed throughout the cabin of vehicle 100. In some examples, a passive version of display 108 or a specific type of active version of display 108 (e.g., an OLED display) may be integrated into a seat, a table, a roof liner, flooring, a window (or, in a windowless or windowless vehicle, into a wall), or other aspect of the vehicle's cabin. When display 108 represents a passive display, display 108 may also include a projector or other image projection device capable of projecting or otherwise reproducing an image onto passive display 108. Additionally, the display 108 may include a display integrated into the driver's side dashboard that provides a virtual representation of the physical instrument cluster (showing speed, revolutions per minute, engine temperature, etc.).

[0020] Display 108 may also represent a display in wired or wireless communication with vehicle 100 if vehicle 100 is autonomous. Display 108 may represent, for example, a computing device such as a laptop computer, a head-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 so-called "smartphones"), a tablet computer, a gaming system, or any other type of computing device that can function as an augmentation or replacement for a display integrated into vehicle 100.

[0021] User interface 110 may represent any type of physical or virtual interface with which a user may interface to control various functions of vehicle 100. User interface 110 may include physical buttons, knobs, sliders, and / or other physical controls. User interface 110 may also include a virtual interface whereby an occupant of vehicle 100 interacts with virtual buttons, knobs, sliders, or other virtual interface elements, by way of example, via a touch-sensitive screen or via a touchless interface. An occupant may interface with user interface 110 to control one or more of the environment within vehicle 100, audio playback by vehicle 100, video playback by vehicle 100, transmissions through vehicle 100 (such as cell phone calls), or any other operation capable of being performed by vehicle 100.

[0022] User interface 110 may also represent an interface augmented to display 108 when functioning as an augmentation or replacement for a display integrated into vehicle 100. That is, user interface 110 may include a virtual interface presented via a heads-up display (HUD), an augmented reality computing device, a virtual reality computing device or display, a tablet computer, or any other different type of augmented display listed above.

[0023] In the context of vehicle 100, user interface 110 may also represent physical elements used to manually or semi-manually control vehicle 100. For example, user interface 110 may include one or more steering wheels for controlling the direction of movement of vehicle 100, one or more pedals for controlling the speed of movement of vehicle 100, one or more handbrakes, etc.

[0024] 1, the processor 102, GPU 104, system memory 106, display 108, and UI 110 may collectively represent, at least in part, what is referred to in the context of an automobile as a head unit 112 (or, in other words, a "vehicle head unit 112"). The head unit 112 may represent any integrated or separate computing device capable of interfacing with various aspects of the vehicle 100 and / or providing entertainment and / or information about the vehicle 100 to passengers (such a head unit may be referred to as an "infotainment unit" or "infotainment system").

[0025] 1, vehicle 100 may include a number of different vehicle systems 114A-114N (“vehicle systems 114”). Vehicle systems 114 may include a heating, ventilation, and air conditioning (HVAC) system or climate control system (e.g., which may include heated and / or cooled seats in addition to an HVAC system) (either or both of which may be referred to herein as environmental systems), a lighting system (for providing interior and / or exterior lighting), a seat control system (for adjusting the position of a passenger seat), 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 displays, etc.), a safety assistance system (for controlling parking assist, reverse assist), a driving mode system (for controlling the suspension, transmission, etc.), a sunroof / moonroof control system (for controlling the sunroof and / or moonroof), and any other type of vehicle system controllable via a head unit, such as head unit 112. An example of a vehicle system 114 may include an electronic control unit (ECU), which may control any of the aforementioned examples of a vehicle system 114.

[0026] The head unit 112 may issue one or more messages as commands to the vehicle systems 114 to change the operational state of one or more of the vehicle systems 114. The head unit 112 may execute an operating system (“OS”) 116 configured to provide interaction with the vehicle systems 114. The OS 116 may represent a proprietary operating system programmed and internally developed by the manufacturer of the vehicle 100, or a different third-party operating system developed outside the manufacture of the vehicle 100.

[0027] Although described with respect to a third-party application independently developed by a third party, various aspects of the present technology may be applied to a proprietary OS developed by the manufacturer (i.e., first party) or a hybrid in which OSes run side by side to support both a first-party OS and a third-party OS. Additionally, although described with respect to a natively running OS (meaning the head unit 112 runs the OS 116), in some examples, a separate computing device may run the OS 116, in which case the OS 116 represents a projected instance of the OS 116. The projected instance of the OS 116 may refer to a graphical user interface (GUI) transmitted by the separate computing device (such as a mobile phone (including a so-called "smartphone"), laptop computer, portable gaming device, or any other mobile computing device).

[0028] In any event, the OS 116 may include a kernel that executes within a so-called kernel space, which provides a secure operating environment in which the OS 116 can interact with underlying hardware, such as the processor 102, the GPU 104, the system memory 106, and the display 108. The kernel of the OS 116 may expose an interface, such as an application programming interface (API) 119, through which applications executing within a higher-level application space (AS) 120 (relative to the kernel space) may interface with the underlying hardware. This OS-level API (the API exposed by the kernel) 119 may provide certain functionality, such as interrupts, to identify changes in the state of the underlying hardware, such as communications received via interface 111 (“INT 111”) over a network established via the vehicle system 114.

[0029] Interface 111 may represent any type of interface through which head unit 112 communicates with vehicle systems 114. Interface 111 may correspond to a Controller Area Network (CAN) interface, a Layer 2 interface (such as an Ethernet interface), a Layer 3 interface (such as an Internet Protocol (IP) interface), or any other type of interface implemented in a vehicle, such as vehicle 100. Interface 111 may include a physical port that interconnects with dedicated network hardware in the form of a wire (e.g., an Ethernet cable) or other physical connection, or a virtual interface (represented by interface 111) executed by an underlying processor that manages the interconnection between head unit 112 and vehicle systems 114 over a wireless Ethernet network.

[0030] 1, interface 111 is assumed to be a hardware (or, in other words, physical) Layer 2 interface coupled to a physical cable to each of vehicle systems 114. Within this assumption, the Layer 2 interface is also assumed to be a hardware Ethernet interface physically coupled (in hardware, or, in other words, via a physical Ethernet port) to each of vehicle systems 114 via an Ethernet cable via physical and / or virtual hubs and / or switches (such hubs / switches are not shown for ease of illustration) operating according to a Layer 2 protocol (e.g., Ethernet) to switch (or, in some cases, route, when the Layer 2 switch / hub is assumed to be a Layer 2.5 hub / switch) frames (or some other data unit, such as a packet, in the case of a Layer 3 network) between vehicle head unit 112 and vehicle systems 114.

[0031] The manufacturer of vehicle 100 may configure various virtual local area networks (VLANs) that create virtual networks between one or more of vehicle systems 114 and vehicle head unit 112. In this case, the VLANs may provide independent networks (e.g., logically separate virtual networks) that establish connections between various vehicle systems 114 and head unit 112 (e.g., vehicle system 114A may establish communication with vehicle head unit 112 via an Ethernet network and VLAN A, vehicle system 114B may establish communication with vehicle head unit 112 via an Ethernet network and VLAN B, etc.).

[0032] Although described as separate VLANs (e.g., VLAN A, B, etc.) for each individual vehicle system 114, two or more vehicle systems 114 may communicate with the vehicle head unit 112 through a single VLAN established on an underlying Ethernet network. Additionally, although described herein with respect to VLANs, various aspects of the present technology may be performed with respect to any vehicle network, including an Ethernet network (e.g., directly configuring physical interfaces), a virtual network (e.g., a VLAN), or any other type of vehicle network capable of supporting intercommunication.

[0033] In any event, manufacturers of vehicles such as vehicle 100 are beginning to introduce more advanced networks to facilitate communication between vehicle head units 112 and vehicle systems 114. These advancements in network communications may provide many advantages in terms of being secure and less susceptible to exploitation, as well as high-bandwidth communications that facilitate the rapid transmission of data (e.g., gigabytes (GB) of data) that may enable next-generation features (e.g., in-depth telematics, autonomous driving, over-the-air updates, etc.).

[0034] However, the introduction of advanced network processing may require detailed hard-coding of virtual interfaces to couple the OS 116 configured to run by the head unit 112 to such networks (such as the VLANs described above). That is, the OS 116 may not natively expose the VLANs, requiring manufacturers to custom-program (or, in other words, “hard-code”) the connections between the OS 116 and the vehicle systems 114. These manufacturers may rely on custom programming (e.g., in C or C++ programming languages) to expose the underlying VLANs running on the hardware Ethernet network that couples the vehicle head unit 112 and vehicle systems 114 to the applications 118.

[0035] Additionally, vehicle manufacturers may implement access control lists (ACLs) to grant or deny access to VLANs from specific applications 118 executed by the OS 116 within the application space 120. The manufacturer may vet each of the applications 118 to grant access to such VLANs in a manner that protects safety and / or security. The manufacturer may code such ACLs independently (meaning separately from the developers of the OS 116) to provide such functionality, including modifying the OS 116. Given that the OS 116 may be updated over time, requiring security redevelopment of the OS 116 (in terms of implementing ACLs for the apps 118) to facilitate OS 116 updates, this development disconnect may make ACLs difficult to maintain. The lack of native support for such ACLs in the context of the vehicle 100 may not only reduce adoption of the OS 116 but also expose security and / or safety concerns.

[0036] According to various aspects of the technology described in this disclosure, OS 116 can be configured to perform efficient network management for applications 118 executed by vehicle head unit 112. Rather than relying on so-called “low-level” management of the network, various aspects of the technology enable OS 116 executed by vehicle head unit 112 to present a single application programming interface (API) 119 for configuring network access and control for applications 118 executing within the application space (as opposed to a secure kernel space) of the vehicle operating system represented by OS 116 (which itself may be referred to as “vehicle OS 116”). Through the single API 119, applications 118 can register network access calls with vehicle OS 116 for particular vehicle networks that interconnect vehicle head unit 112 running vehicle OS 116 to various vehicle systems 114. Vehicle OS 116 can implement access control lists (ACLs) 121 that can be configured to determine whether a particular application attempting to register a vehicle network access call is allowed to access the underlying vehicle network. If authorized via ACL 121, vehicle OS 116 may configure an interface (which may be a virtual interface) through which a particular application may access the underlying vehicle network, including the assignment of a network address (e.g., an Internet Protocol (IP) address).

[0037] During operation, OS 116 may obtain an indication of one or more vehicle networks, i.e., the manufacturer may configure each of the above-mentioned VLANs in vehicle 100 to interconnect vehicle head unit 112 to one or more vehicle systems 114. Once configured, the manufacturer may register each of the VLANs with OS 116 via API 119, as well as further interface with API 119 to configure ACL 121.

[0038] The vehicle head unit 112, and more specifically, the processor 102 of the vehicle head unit 112, may execute an OS 116 that exposes an API 119 that provides function calls for configuring one or more vehicle networks within the OS 116. A manufacturer may then configure a vehicle network and ACL 121 within the OS 116 simply by interfacing with the API 119. Because the OS 116 actively exposes the API 119, any development of the OS 116 may result in active maintenance of the API 119, thereby maintaining a standard approach for configuring vehicle networks within the OS 116 (e.g., via function calls).

[0039] The OS 116 may be initialized (during boot-up and after bringing up the vehicle network), which may result in one or more network interfaces being configured within the OS 116 via a single API 119 for one or more vehicle networks through which one or more applications 118 executing within an application space 120 presented by the OS 116 may interface with the one or more vehicle networks. The OS 116 may configure these interfaces at least in part by assigning an address for each of the one or more network interfaces, which is used to distinguish each interface (which may also refer to a virtual interface defined within the OS 116). The OS 116 may statically assign such addresses or may rely on dynamic assignment of these addresses, in which case the address may include a network address (or, in other words, a Layer 3 network address such as an Internet Protocol (IP) address). The OS 116 may perform such dynamic assignment of addresses in accordance with the Dynamic Host Configuration Protocol.

[0040] OS 116 may also configure ACLs 121 for one or more of these interfaces within OS 116 that grant or deny access by applications 118 to various interfaces through which OS 116 communicates with the vehicle network. ACLs 121 may represent a form of application access rules for network interfaces that control access by applications 118 to one or more network interfaces.

[0041] In this way, rather than relying on complex so-called "low-level" configuration where a manufacturer of a vehicle, such as vehicle 100, statically configures (or, in other words, "hard-codes") the vehicle network configuration for each application 118 on its own, such a vehicle manufacturer may program applications 118 or have third-party application developers develop applications 118 that interface with a single API exposed natively by vehicle OS 116 to perform network management. Vehicle manufacturers may deploy ACLs 121 that restrict or allow access to the underlying vehicle network based on an application certification process that complies with the laws of the various jurisdictions in which the vehicle is sold.

[0042] Additionally, a vehicle OS 116 may be developed that accommodates various jurisdictional laws while also enabling vehicle network access for applications 118 executed by the vehicle OS 116. Given that vehicle network access may be managed through a single API 119, vehicle manufacturers may not require dedicated computer programmers to "hard-code" network access, but may facilitate independent network management by application developers (including first-party and third-party application developers). Because the single API 119 is managed by the developer of the vehicle OS 116, such vehicle network management may be natively supported as the vehicle OS 116 undergoes additional development and modifications.

[0043] Thus, the single network management API 119 may facilitate more efficient operation of the vehicle OS 116, as well as improve access to the vehicle network by the applications 118 executed by the vehicle OS 116. The single API 119 may reduce errors caused by such “hard-coded” network management, which may result in errors (security or otherwise) that could create safety or vehicle network misuse issues, thereby allowing the vehicle OS 116 to operate more efficiently, resulting in efficient utilization of the computing resources (e.g., in terms of processor cycles, memory, memory bandwidth, and associated power) of the vehicle head unit 112. Furthermore, given the centralization of a single API 119 for network management, application developers may secure access to specific vehicle networks through manufacturing validation, while manufacturers may also disable vehicle network access to vehicle systems 114 that may pose security and / or safety risks, thereby improving the safety and / or security of the vehicle 100 itself.

[0044] Figure 2 is a block diagram illustrating a conceptual configuration of network management via a single application programming interface for the vehicle shown in the example of Figure 1, in accordance with various aspects of the techniques described in this disclosure. In the example of Figure 2, vehicle 200 may represent an example of vehicle 100 shown in the previous example of Figure 1.

[0045] Vehicle 200 may include a vehicle head unit 212 and a vehicle system 214 separated by a bridge and / or switch 202 (which may represent a physical bridge and / or switch, or a logical bridge and / or switch, or in other words, a virtual bridge and / or switch). Bridge and / or switch ("bridge / switch") 202 may represent a Layer 2 network device or a Layer 2.5 network device (which is not a Layer 2 network device that broadcasts frames / packets from each port, but includes some ability to learn destinations and route frames / packets to those destinations).

[0046] The vehicle head unit 212 may execute an OS 216 along with applications (“apps”) 218, as described above with respect to the vehicle head unit 112. The vehicle head unit 212 may also include an Ethernet interface 204 for establishing Ethernet communications with the bridge / switch 202. Ethernet refers to a set of networking standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE) as IEEE 802.3, which defines how wired and wireless Layer 2 network communications are established and maintained to support network communications. The Ethernet interface 204 may conform to any Layer 2 communications standard, but for purposes of explanation, it will be assumed to operate in accordance with IEEE 802.3. Ethernet interface 204

[0047] The Ethernet interface 204 includes a physical Ethernet port, labeled Eth0 206, which is coupled to the bridge switch 206 wirelessly or via a physical wire (often referred to as an Ethernet cable). The Ethernet interface 204 also supports multiple virtual Ethernet ports, labeled Eth0.1 208A, Eth0.2 208B, ..., Eth0.N 208N (sometimes referred to as "virtual Ethernet ports 208"). The OS 116 may manage and maintain the virtual Ethernet ports 208 and define such virtual Ethernet ports 208 for use by one or more of the apps 218. While the example of FIG. 1 shows each one of the apps 118 interfacing with a single (and dedicated) virtual Ethernet port, the apps 118 may request one or more virtual Ethernet ports 208 for a variety of different reasons.

[0048] To support virtual Ethernet ports 208, OS 116 may include an Ethernet manager 210 that runs in kernel space (as opposed to the more restrictive and less privileged application space). Applications 218 may issue function calls associated with network APIs that request virtual Ethernet ports 208, where Ethernet manager 210 may not only represent these network APIs but also provide additional network management functionality for maintaining an Ethernet network that includes virtual Ethernet ports 208 (sometimes referred to as virtual Ethernet interfaces 208). Although a single app, e.g., app 218A, is shown connecting to a single Ethernet port, e.g., Ethernet port 208A, multiple apps 218 may connect to the same single Ethernet port.

[0049] OS 216 may also execute network apps 228 that support configuration of networks, such as VLANs 230 within the overall Ethernet network shown in the example of Figure 2. Network apps 228 may call a single API 219 to interface with Ethernet manager 210 to configure the network shown in the example of Figure 2.

[0050] As further shown in the example of FIG. 2, the manufacturer of vehicle 200 may configure VLANs 230A-230N (“VLANs 230”). VLANs 230, as briefly described above, represent separate, partitioned and isolated virtual networks, which are partitioned and isolated at Layer 2. Each of VLANs 230 is assigned a unique VLAN tag (meaning unique within vehicle 200 and, potentially, within external networks, depending on whether the network extends outside vehicle 200). VLANs 230 may allow a single physical network to be partitioned into separate, logically isolated networks.

[0051] The API 219 may enable the network application 228 to configure the virtual Ethernet interface 208 that allows the applications 218 running within the OS 216 to access the VLANs 230, and such configuration may include IP configuration, network feature settings (which reside within the OS 216 and are used to define various capabilities associated with the underlying network, such as the presence or absence of a captive portal, bandwidth priority, latency priority, transport (Universal System Bus, Personal Area Network, Ethernet, cellular, wireless, etc.)), etc. Additionally, the network app 228 may interface with the Ethernet manager 210 via the API 219 to configure the ACL 221 that controls access by the apps 218 to the virtual Ethernet interface 208, which may be associated with one or more VLANs 230.

[0052] Figure 3 is a block diagram illustrating in more detail the vehicle operating system shown in the examples of Figures 1 and 2 that supports efficient network management in accordance with various aspects of the techniques described in this disclosure. In the example of Figure 3, the vehicle OS 316 includes the Ethernet manager 310 described above, which manages the network configuration for the virtual Ethernet interface 208 via API 319. However, the OS 316 includes two different portions of the API 119: API 319A, which provides an interface for configuring the interconnections between the virtual Ethernet interface 208 and the VLANs 230, and API 319B, which manages ACLs 321.

[0053] Vehicle OS 316 includes Ethernet services 311, network agent 312, network services daemon 314, and OS kernel 316 (each of which may be similar to similarly named components of Unix- and / or Linux-based operating systems). Ethernet services 311 may represent OS-level services (running in kernel space) that implement functionality associated with Ethernet in terms of managing the underlying hardware (e.g., physical Ethernet interfaces), while also implementing various APIs, such as backend API 319A for managing ACLs 321 against rules for user identifiers ("uids") for access to the vehicle network.

[0054] The Ethernet manager 310 may be invoked by apps such as the network app 228 to establish the virtual Ethernet interface 208. The Ethernet manager 310 may also be invoked (via function calls) to configure the VLANs 230 within the OS 116 and define the network addresses, network capabilities, and ACLs 121. The Ethernet manager 310 is instantiated via function calls to system services (e.g., Ethernet services 311) that are responsible for managing Ethernet communications.

[0055] Once instantiated, network app 228 may call functions associated with API 319A supported by Ethernet manager 310 to configure network access to vehicle system 114 over VLAN 230. Network app 228 may also call functions associated with API 319A to define (or edit, delete, or otherwise manage) ACL 321. Ethernet manager 310 may subsequently call Ethernet services 311 via API 319A to configure network access between one or more apps 118 / 218 and vehicle system 114 over VLAN 230, including implementing ACL 321. Ethernet services 311 may interface with network services daemon 314 via backend API 319B to configure ACL 321 at the network services layer, which may effectively prevent access to VLAN 230 from unauthorized applications using privileges assigned by OS kernel 316 (associated with a given user as identified by uid).

[0056] The network agent 312 may help configure the network connection to the vehicle systems 114 over the VLAN 230. The network agent 312 may configure IP addresses and network capabilities in response to the Ethernet manager 310 invoking functions in the API 319A, where the Ethernet services 310 may interface with the network agent 312 to secure an IP address to be assigned to the virtual Ethernet interface 208. Each of these updates to the provided API 119 may affect the underlying system code of the OS 316 to provision the network connection and associated ACL 321 between the apps 118 / 218 and the vehicle systems 114 / 214 over the VLAN 230.

[0057] 4 is a block diagram illustrating how the vehicle operating system shown in the example of FIGS. 1-3 may implement access control lists while performing network management in accordance with various aspects of the techniques described in this disclosure. In the example of FIG. 4, OS 416 may represent an example of OS 116 in which original equipment manufacturer (OEM) telematics app 418A and OEM camera app 418B (e.g., for viewing the vehicle's backup camera or other camera system) run within the application space along with so-called third-party apps 438.

[0058] 1 and 2, although in some examples, only OEM apps, such as OEM telematics app 418A and OEM camera app 418B, may represent examples of applications 118. That is, for security and safety purposes, access to particular vehicle systems 114 / 214 may be restricted to signed OEM applications, such as OEM telematics app 418A and OEM camera app 418B.

[0059] Considering the security and safety concerns discussed above, a manufacturer may define ACL 121 to prohibit any applications other than specifically authorized applications, such as OEM telematics app 418A and OEM camera app 418B, from accessing VLAN 230 for accessing vehicle systems 114. In the example of FIG. 4 , any attempt by third-party app 438 to access VLAN 230B associated with Eth0.2 408B may be denied at the operating system level via OS 416. More specifically, network services daemon 314 may interface with OS kernel 316 to reference uid-based ACL 121 that specifically denies third-party app 438 access to VLAN 230B and / or the underlying Eth0.2 408B. In this manner, safety and security may be preserved using a single API 119 / 219 / 319A / 319B for managing network access.

[0060] 5 is a state diagram illustrating an example operation of the vehicle operating system shown in the examples of FIGS. 1 and 2 when performing network management in accordance with various aspects of the techniques described in this disclosure. In the example of FIG. 5, one or more of the apps 118 may interface with a single API 119 to register network callbacks (500). By registering with a connection manager responsible for managing the Ethernet manager 210, the apps 118 may receive callbacks that notify the apps 118 when a particular network is available, when it is lost, and whether a registering one of the apps 118 has access to a particular network. This network access includes the Ethernet network described above.

[0061] The app 118 may register a callback specifying a particular network in various ways. In some examples, the registered callback may define the network in terms of network characteristics such as bandwidth, latency, signal-to-noise ratio, etc. The registered callback may also request a callback only from networks that offer a particular quality of service (QoS), which is similar to network characteristics but is often defined in a hierarchy of network characteristics, typically with fallback QoS requirements. The registered callback may also define the network in terms of network type, such as wired versus wireless, transport protocol, etc., and / or by specifying which particular network is requested, such as a Bluetooth connection, an Ethernet connection, etc.

[0062] When a network is unavailable (“NO” 502) (in that the callback specification for the registered network is not satisfied by an existing network registered with the OS 216), the OS 216 does not send any callbacks back to the apps 118 (504), but app network access can be modified (506) by the single API 119. That is, the single API 119 can configure additional networks (e.g., VLANs) after OS 116 execution occurs due to the detection of a new system 114, the addition of a new system 114 (e.g., via USB or other wired or wireless connection, etc.). In this way, an Ethernet network can become available (“YES” 502), in which case the OS 216 sends a callback to the registered apps 118 to notify them that an Ethernet network (and / or an associated one of the VLANs 230) is available (508).

[0063] 6 is a flowchart illustrating exemplary operations by the vehicle operating system shown in the example of FIG. 1 in performing various aspects of network management techniques. Initially, OS 116 may obtain (600) an indication of one or more vehicle networks. That is, the manufacturer may configure each of the above-mentioned VLANs in vehicle 100 to interconnect vehicle head unit 112 to one or more vehicle systems 114. Once configured, the manufacturer may register each of the VLANs with OS 116 via API 119, as well as interface with API 119 to configure ACLs 121.

[0064] The vehicle head unit 112, and more specifically, the processor 102 of the vehicle head unit 112, may execute (602) an OS 116 that exposes an API 119 that provides function calls for configuring one or more vehicle networks within the OS 116. A manufacturer may then configure vehicle networks and ACLs 121 within the OS 116 simply by interfacing with the API 119. Because the OS 116 actively exposes the API 119, any development of the OS 116 may result in active maintenance of the API 119, thereby maintaining a standard approach for configuring vehicle networks within the OS 116 (e.g., via function calls).

[0065] The OS 116 may be initialized (during boot-up and after bringing up the vehicle network). As a result of this initialization, one or more network interfaces for one or more vehicle networks may be configured within the OS 116 via a single API 119 (604) through which one or more applications 118 executing within an application space (AS) 120 presented by the OS 116 may interface with the one or more vehicle networks. The OS 116 may configure these interfaces at least in part by assigning an address for each of the one or more network interfaces, which is used to distinguish each interface (which may also refer to a virtual interface defined within the OS 116). The OS 116 may statically assign such addresses or may rely on dynamic assignment of these addresses, in which case the address may include a network address (or, in other words, a Layer 3 network address such as an Internet Protocol (IP) address). The OS 116 may perform such dynamic assignment of addresses in accordance with the Dynamic Host Configuration Protocol.

[0066] OS 116 may also configure ACLs 121 for one or more of these interfaces within OS 116 that grant or deny access by applications 118 to various interfaces through which OS 116 communicates with the vehicle network. ACLs 121 may represent a form of application access rules for network interfaces that control access by applications 118 to one or more network interfaces.

[0067] By way of example, and not limitation, such computer-readable storage media may include 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. Also, any connection is properly referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio waves, and microwaves, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio waves, and microwaves are included within the definition of medium. However, it should be understood that computer-readable storage medium(s) and data storage media do not include connections, carrier waves, signals, or other transitory media, but instead cover non-transitory tangible storage media. As used herein, disk and disc include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable storage media.

[0068] The instructions may be executed by one or more processors, such as 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. Accordingly, the term "processor," as used herein, may refer to any of the foregoing structures, or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein may be provided in dedicated hardware and / or software modules. The techniques may also be implemented entirely in one or more circuits or logic elements.

[0069] The techniques of this disclosure may be implemented in a wide range of devices or apparatuses, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chipsets). While various components, modules, or units are described in this disclosure to highlight functional aspects of devices configured to implement the disclosed techniques, they do not necessarily require realization by different hardware units. Rather, as described above, the various units may be combined into a hardware unit or may be provided by a collection of interoperable hardware units, including one or more processors as described above, in combination with appropriate software and / or firmware.

[0070] This disclosure includes many examples, including the following: Example 1 1. A method comprising: obtaining, by one or more processors of a vehicle head unit, instructions for one or more vehicle networks; executing, by the one or more processors, an operating system presenting a single application programming interface that provides function calls for configuring the one or more vehicle networks within the operating system; and configuring, via the single application programming interface, one or more network interfaces for the one or more vehicle networks within the operating system such that one or more applications executing within an application space presented by the operating system interface with the one or more vehicle networks.

[0071] Example 2 2. The method of embodiment 1, wherein configuring the one or more network interfaces includes configuring at least one network address for each of the one or more network interfaces.

[0072] Example 3 3. The method of example 2, wherein configuring the one or more network interfaces includes assigning the at least one network address for each of the one or more network interfaces according to a Dynamic Host Configuration Protocol.

[0073] Example 4 4. The method of any combination of examples 1 to 3, wherein configuring the one or more network interfaces includes configuring application access rules for the network interfaces that control access by the one or more applications to the one or more network interfaces.

[0074] Example 5 5. The method of example 4, further comprising denying application access to the network interface based on the application access rules.

[0075] Example 6 6. The method according to any combination of examples 1 to 5, wherein the one or more vehicular networks include one or more Layer 2 networks.

[0076] Example 7 7. The method of embodiment 6, wherein the one or more vehicular networks include one or more virtual local area networks running on the one or more Layer 2 networks.

[0077] Example 8 8. The method of example 7, wherein the one or more Layer 2 networks include one or more Ethernet networks.

[0078] Example 9 The method of any combination of examples 1 to 8, wherein the operating system also includes a kernel space reserved for running a privileged operating system kernel, and the application space provides an interface for the one or more applications to interact with the privileged operating system kernel.

[0079] Example 10 10. The method of any combination of Examples 1 to 9, wherein the one or more vehicle networks are configured to interconnect the vehicle head unit to one or more vehicle systems of a vehicle.

[0080] Example 11 10. The method of claim 9, wherein the one or more vehicle systems include a heating, ventilation and air conditioning system, a seat control system, an interior lighting system, an exterior lighting system, a communication system, a mirror control system, and a video system.

[0081] 12 1. A vehicle head unit comprising: a memory configured to store an operating system; and one or more processors, the one or more processors configured to execute the operating system, the operating system presenting a single application programming interface that obtains instructions for one or more vehicle networks and provides function calls for configuring the one or more vehicle networks within the operating system, and to configure, via the single application programming interface, one or more network interfaces for the one or more vehicle networks within the operating system such that one or more applications executing within an application space presented by the operating system interface with the one or more vehicle networks.

[0082] Example 13 13. A vehicle head unit as described in Example 12, wherein the one or more processors are configured to configure at least one network address for each of the one or more network interfaces when configuring the one or more network interfaces.

[0083] Example 14 A vehicle head unit as described in Example 13, wherein the one or more processors are configured, when configuring the one or more network interfaces, to assign the at least one network address for each of the one or more interfaces in accordance with a Dynamic Host Configuration Protocol.

[0084] Example 15 A vehicle head unit described in any combination of Examples 12 to 14, wherein the one or more processors, when configuring the one or more network interfaces, are configured to configure application access rules for the network interfaces that control access by the one or more applications to the one or more network interfaces.

[0085] Example 16 16. The vehicle head unit of Example 15, wherein the one or more processors are further configured to deny application access to the network interface based on the application access rules.

[0086] Example 17 A vehicle head unit described in any combination of examples 12 to 16, wherein the one or more vehicle networks include one or more Layer 2 networks.

[0087] Example 18 18. A vehicle head unit as described in Example 17, wherein the one or more vehicle networks include one or more virtual local area networks running on the one or more Layer 2 networks.

[0088] Example 19 19. The vehicle head unit of embodiment 18, wherein the one or more Layer 2 networks include one or more Ethernet networks.

[0089] Example 20 1. A non-transitory computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors of a vehicle head unit to obtain instructions for one or more vehicle networks, execute an operating system that presents a single application programming interface that provides function calls for configuring the one or more vehicle networks within the operating system, and configure one or more network interfaces for the one or more vehicle networks within the operating system via the single application programming interface so that one or more applications executing within an application space presented by the operating system interface with the one or more vehicle networks.

[0090] Various embodiments have been described. These and other embodiments are within the scope of the following claims.

Claims

1. obtaining, by one or more processors of a vehicle head unit, indications of one or more vehicle networks; executing, by the one or more processors, an operating system that presents a single application programming interface that provides function calls within the operating system for configuring the one or more vehicle networks; and configuring one or more network interfaces for the one or more vehicle networks such that one or more applications executing within the operating system and within an application space presented by the operating system interface with the one or more vehicle networks via the single application programming interface.

2. The method of claim 1 , wherein configuring the one or more network interfaces comprises configuring at least one network address for each of the one or more network interfaces.

3. 3. The method of claim 2, wherein configuring the one or more network interfaces comprises assigning the at least one network address for each of the one or more network interfaces according to a Dynamic Host Configuration Protocol.

4. 4. The method of any combination of claim 1, wherein configuring the one or more network interfaces includes configuring application access rules for the network interfaces that control access by the one or more applications to the one or more network interfaces.

5. The method of claim 4 , further comprising denying application access to the network interface based on the application access rules.

6. The method of any combination of claims 1 to 5, wherein the one or more vehicular networks include one or more Layer 2 networks.

7. The method of claim 6 , wherein the one or more vehicular networks include one or more virtual local area networks running on the one or more Layer 2 networks.

8. The method of claim 7 , wherein the one or more Layer 2 networks include one or more Ethernet networks.

9. the operating system also includes a kernel space reserved for executing a privileged operating system kernel; 9. The method of any combination of claims 1 to 8, wherein the application space provides an interface for the one or more applications to interact with the privileged operating system kernel.

10. 10. The method of any combination of claims 1 to 9, wherein the one or more vehicle networks are configured to interconnect the vehicle head unit to one or more vehicle systems of a vehicle.

11. 10. The method of claim 9, wherein the one or more vehicle systems include a heating, ventilation and air conditioning system, a seat control system, an interior lighting system, an exterior lighting system, a communication system, a mirror control system, and a video system.

12. 1. A vehicle head unit, comprising: a memory configured to store an operating system; one or more processors, wherein the one or more processors: Obtaining an indication of one or more vehicular networks; executing an operating system that exposes a single application programming interface that provides function calls for configuring the one or more vehicle networks within the operating system; and configuring one or more network interfaces for the one or more vehicle networks such that one or more applications executing within the operating system and within an application space presented by the operating system interface with the one or more vehicle networks via the single application programming interface.

13. 13. The vehicle head unit of claim 12, wherein the one or more processors are configured to configure at least one network address for each of the one or more network interfaces when configuring the one or more network interfaces.

14. 14. The vehicle head unit of claim 13, wherein the one or more processors, when configuring the one or more network interfaces, are configured to assign the at least one network address for each of the one or more network interfaces in accordance with a Dynamic Host Configuration Protocol.

15. 15. The vehicle head unit of any combination of claims 12 to 14, wherein the one or more processors, when configuring the one or more network interfaces, are configured to configure application access rules for the network interfaces that control access by the one or more applications to the one or more network interfaces.

16. The vehicle head unit of claim 15 , wherein the one or more processors are further configured to deny application access to the network interface based on the application access rules.

17. 17. The vehicle head unit of any combination of claims 12 to 16, wherein the one or more vehicle networks include one or more Layer 2 networks.

18. 20. The vehicle head unit of claim 17, wherein the one or more vehicle networks include one or more virtual local area networks running on the one or more Layer 2 networks.

19. 20. The vehicle head unit of claim 18, wherein the one or more Layer 2 networks include one or more Ethernet networks.

20. A non-transitory computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors of a vehicle head unit to: obtaining an indication of one or more vehicular networks; executing an operating system that presents a single application programming interface that provides function calls for configuring the one or more vehicle networks within the operating system; A non-transitory computer-readable storage medium that configures one or more network interfaces for the one or more vehicle networks such that one or more applications executing within the operating system and within an application space presented by the operating system interface with the one or more vehicle networks via the single application programming interface.

Images