Network management for vehicle operating system

Abstract

A vehicle host unit includes a memory configured to store an operating system, and one or more processors may be configured to perform various aspects of the techniques. One or more processors may obtain an indication of one or more vehicle networks and execute an operating system that presents a single application programming interface that provides function calls through which the one or more vehicle networks are configured within the operating system. The one or more processors may also configure, via a single application programming interface, one or more network interfaces in the operating system for the one or more vehicle networks through which one or more applications executing in an application space presented by the operating system interface with the one or more vehicle networks.

Description

Background Art

[0001] The vehicle may include a so-called "head unit" or other integrated computing device that presents an interface (such as a graphical user interface - GUI) through which vehicle systems are controlled, such as a heating, ventilation and air conditioning (HVAC) system, a lighting system (for controlling interior and / or exterior lights), an infotainment system (including standard amplitude modulation - AM - radio, frequency modulation - FM - radio, streaming radio, video playback, audio playback, etc.), a ride system (for controlling the position of the driver and / or passenger seats), a mirror system (for controlling exterior and / or interior mirrors), a telematics system (for capturing data related to vehicle usage and / or activity), a wireless update system (for updating firmware and / or other software executed by the vehicle), etc. The head unit may issue one or more commands (also referred to herein as a "command set") to the vehicle systems to change the operating 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 farm equipment, trains, airplanes, drones, helicopters, personal transportation vehicles, and the like continue to evolve, these vehicles may begin to implement various networks for interconnecting vehicle systems to a host unit. Recently, vehicles have turned to standard layer 2 networks (such as Ethernet networks) to facilitate communications between various vehicle systems. Although Ethernet networks (or other layer 2 networks) can provide unified network access between vehicle systems, operating systems executed by host units (which operating systems may be referred to as vehicle operating systems) may be difficult to configure in terms of presenting such networks for use by applications executing within the execution environment provided by the operating system. Summary of the invention

[0003] In general, the technology of the present disclosure relates to enabling efficient configuration of network management for applications executed by a carrier host unit. Rather than resorting to so-called "low-level" network management, various aspects of these technologies enable a carrier operating system executed by a carrier host unit to present a single application programming interface (API) to configure network access and control for applications executed in the application space (rather than the secure kernel space) of the carrier operating system through the single application programming interface. Via the single API, applications can register calls with the carrier operating system for network access to specific carrier networks that interconnect the carrier host unit executing the carrier operating system to various carrier systems. The carrier operating system can be configured to implement an access control list (ACL) and use the ACL to determine whether a specific application attempting to register a call for carrier network access is able to access the underlying carrier network. If authorized via the ACL, the carrier operating system can configure an interface (which can be a virtual interface) through which a specific application can access the underlying carrier network, including assigning a network address (e.g., an Internet Protocol-IP-address).

[0004] In this manner, vehicle manufacturers can program applications or allow third-party application developers to develop applications that interface with a single API natively presented by the vehicle operating system to perform network management, rather than resorting to complex so-called "low-level" configurations in which these vehicle manufacturers statically configure (or in other words, "hard code") the vehicle network configuration independently for each application. Vehicle manufacturers can deploy ACLs that restrict or allow access to the underlying vehicle network based on an application approval process that complies with the laws of the various jurisdictions where the cars are sold.

[0005] Furthermore, a vehicle operating system may be developed that accommodates the various laws of a jurisdiction while also enabling vehicle network access for applications executed by the vehicle operating system. Given that vehicle network access may be managed via a single API, a vehicle manufacturer may not require a specialized computer programmer 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 is managed by the developer of the vehicle operating system, such vehicle network management may be natively supported as the vehicle operating system undergoes additional development and revisions.

[0006] Thus, a single network management API can facilitate more efficient operation of the vehicle operating system while also improving access to the vehicle network by applications executed by the vehicle operating system. The vehicle operating system can operate more efficiently because the single API can reduce errors introduced by such "hard-coded" network management that may lead to errors (security or otherwise) that may introduce issues with the security or utilization of the vehicle network, which results in efficient use of the computing resources of the vehicle host unit (e.g., in terms of processor cycles, memory, memory bandwidth, and associated power). Further, in view of the unified single API for network management, application developers can ensure access to certain vehicle networks via manufacturing verification, while also allowing manufacturers to disable vehicle network access to vehicle systems that may pose a security and / or safety risk, thereby improving the security and / or safety of the vehicle itself.

[0007] In one example, various aspects of these technologies relate to a method comprising: obtaining, by one or more processors of a carrier host unit, an indication of one or more carrier networks; executing, by the one or more processors, an operating system, the operating system presenting a single application programming interface that provides function calls, through which the one or more carrier networks are configured within the operating system; and configuring one or more network interfaces for the one or more carrier networks in the operating system via the single application programming interface, through which one or more applications executing in an application space presented by the operating system interface interface with the one or more carrier networks.

[0008] In another example, various aspects of these technologies relate to a carrier host unit, which includes: a memory configured to store an operating system; and one or more processors, the one or more processors configured to: obtain an indication of one or more carrier networks; execute the operating system, the operating system presenting a single application programming interface that provides function calls, and one or more carrier networks are configured within the operating system through these function calls; and configure one or more network interfaces for the one or more carrier networks in the operating system via the single application programming interface, and one or more applications executed in the application space presented by the operating system interface with the one or more carrier networks through the one or more network interfaces.

[0009] In another example, various aspects of these technologies relate to a non-transitory computer-readable storage medium having instructions stored thereon, which when executed cause one or more processors of a carrier host unit to: obtain an indication of one or more carrier networks; execute an operating system that presents a single application programming interface that provides function calls through which one or more carrier networks are configured within the operating system; and configure one or more network interfaces for the one or more carrier networks in the operating system via the single application programming interface, and one or more applications executing in an application space presented by the operating system interface to interface with the one or more carrier networks through the one or more network interfaces.

[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 DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a block diagram illustrating an example vehicle configured to perform various aspects of the techniques described in this disclosure.

[0012] Figure 2 is a diagram illustrating various aspects of the technology described in the present disclosure. Figure 1 A block diagram of a conceptual configuration of a single application programming interface for network management of a carrier is shown in an example.

[0013] Figure 3 is a more detailed illustration of various aspects of the technology described in the present disclosure, supporting efficient network management, Figure 1 and Figure 2 Block diagram of the vehicle operating system shown in the example.

[0014] Figure 4 is a diagram showing various aspects of the technology described in the present disclosure Figures 1 to 3 A block diagram of how a carrier operating system implements access control lists while performing network management is shown in an example of FIG.

[0015] Figure 5 is a representation showing various aspects of the technology described in the present disclosure Figure 1 and Figure 2 An illustration of a state diagram of example operations of a carrier operating system when performing network management is shown in the example of FIG.

[0016] Figure 6 It is shown by Figure 1 A flowchart of example operations of a carrier operating system in performing various aspects of network management techniques is shown in the example of FIG. DETAILED DESCRIPTION

[0017] Figure 1 is a block diagram illustrating an example vehicle 100 configured to perform various aspects of the techniques described in this disclosure. Figure 1 In the example of FIG. 1 , the following description assumes that the vehicle 100 is a car. However, the techniques described in the present disclosure can be applied to any type of vehicle that utilizes a network to communicate between vehicle systems, where 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, the vehicle 100 may be an autonomous vehicle.

[0018] exist Figure 1 In some examples, 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 transceiver module ( Figure 1 (not shown) may be formed as an integrated circuit (IC). For example, the IC may be considered a processing chip within a chip package and may be a system on chip (SoC).

[0019] 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 circuit systems. Processor 102 may represent a central processing unit (CPU) of vehicle 100. In some examples, GPU 104 may be dedicated hardware including integrated and / or discrete logic circuit systems that provide GPU 104 with massively parallel processing capabilities suitable for graphics processing. In some cases, 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 integrated into an underlying circuit board (such as a so-called "motherboard") or otherwise incorporated into processing 102.

[0020] The processor 102 may execute various types of applications 118. Examples of applications include a web browser, a navigation application, a radio application (including a streaming music application), a texting application, a car management application, a system settings application, a vehicle system control application (e.g., a heating, ventilation and air conditioning (HVAC) system, a mirror system, a ride system, a lighting system, and / or any other system represented by vehicle systems 114A to 114N), an email application, a spreadsheet application, a video game, or other application that may generate visual objects 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 application 118 by the processor 102 causes the processor 102 to generate graphical data of image content to be displayed, for example, via the display 108. The processor 102 may transmit the graphical data of the image content to the GPU 104 for further processing based on instructions or commands transmitted by the processor 102 to the GPU 104.

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

[0022] The system memory 106 may represent a memory for the vehicle 8. The system memory 106 may include one or more computer-readable storage media. Examples of the 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 may be used to carry or store desired program code in the form of instructions and / or data structures and may be accessed by a computer or processor. In some aspects, the system memory 106 may include instructions that cause the processor 102 to perform the functions attributed to the processor 102 in the present disclosure. Thus, the system memory 106 may represent a non-transitory computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors (e.g., the processor 102) to perform various functions.

[0023] Thus, in other words, system memory 106 may 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 an example, system memory 106 may be removed from vehicle 100 and moved to another device. As another example, a memory substantially similar to system memory 106 may be inserted into vehicle 100. In some examples, a non-transitory storage medium may store data that may change over time (e.g., in RAM).

[0024] like Figure 1 As further shown in the example of , the vehicle 100 may include a display 108 and a user interface 110. The display 108 may represent any type of passive reflective screen onto which an image may be projected, or an active reflective or 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, the vehicle 100 may include multiple displays that may be positioned throughout the cabin of the vehicle 100. In some examples, a passive version of the display 108 or an active version of some type of display 108 (e.g., an OLED display) may be integrated into a seat, table, headliner, floor, window (or in a vehicle without windows or with fewer windows, walls), or other aspects of the cabin of the vehicle. When the display 108 represents a passive display, the display 108 may also include a projector or other image projection device capable of projecting or otherwise recreating an image on the passive display 108. Additionally, the display 108 may include a display integrated into the driver's side instrument panel that virtually represents a physical instrument cluster (showing display speed, rpm, engine temperature, etc.).

[0025] When the vehicle 100 is autonomous, the display 108 may also represent a display in wired or wireless communication with the vehicle 100. The display 108 may, for example, represent a computing device such as a laptop computer, a heads-up display, a head-mounted display, an augmented reality computing device or display (such as "smart glasses"), a virtual reality computing device or display, a mobile phone (including so-called "smartphones"), a tablet computer, a gaming system, or other types of computing devices that can act as an extension of a display integrated into the vehicle 100 or in place of the display.

[0026] The user interface 110 may represent any type of physical or virtual interface with which a user may interface to control various functionalities of the vehicle 100. The user interface 110 may include physical buttons, knobs, sliders, and / or other physical control implementations. The user interface 110 may also include a virtual interface through which an occupant of the vehicle 100 may interact with a virtual button, knob, slider, or other virtual interface element, for example, via a touch screen or via a non-touch interface. A passenger may interface with the user interface 110 to control one or more of the climate within the vehicle 100, audio playback by the vehicle 100, video playback by the vehicle 100, transmissions (such as cell phone calls) by the vehicle 100, or any other operation that can be performed by the vehicle 100.

[0027] The user interface 110 may also represent an interface extended to the display 108 when acting as an extension of or replacing a display integrated into the vehicle 100. That is, the 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 types of extended displays listed above.

[0028] In the context of the vehicle 100, the user interface 110 may further represent physical elements for manually or semi-manually controlling the vehicle 100. For example, the user interface 110 may include one or more steering wheels for controlling the direction of travel of the vehicle 100, one or more pedals for controlling the travel speed of the vehicle 100, one or more handbrakes, and the like.

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

[0030] like Figure 1 As further shown in the example of FIG. 1 , the vehicle 100 may include a plurality of different vehicle systems 114A through 114N (“vehicle systems 114 ”). The vehicle systems 114 may include a heating, ventilation and air conditioning (HVAC) system or a temperature control system (e.g., the temperature control system may include heated and / or cooled seats in addition to the HVAC system) (either or both of which may also be referred to herein as a climate system), a lighting system (for providing interior and / or exterior lighting), a seat control system (for adjusting the seating position of an occupant), a mirror control system (for controlling interior and / or exterior mirrors, including rearview mirrors, sideview mirrors, visor mirrors, etc.), a windshield wiper control system, an entertainment system (for controlling radio playback, video playback, image display, etc.), a safety assistance system (for controlling parking assistance, reverse assistance, etc.), a driving mode system (for controlling the suspension, transmission, etc.), a sun-roof / moon-roof control system (for controlling a sun-roof and / or a glass sunroof), and any other type of vehicle system that can be controlled via a head unit (such as the head unit 112). Examples of the vehicle systems 114 may include an electronic control unit (ECU), which may control any of the foregoing examples of the vehicle systems 114.

[0031] 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 dedicated, internally developed operating system programmed by the manufacturer of the vehicle 100 or a different third-party operating system developed outside of the manufacturer of the vehicle 100.

[0032] Although described with respect to third-party applications independently developed by a third party, various aspects of these techniques may be applied to a dedicated OS developed by a manufacturer (in other words, meaning a first party) or a hybrid OS in which the OS is executed concurrently to support both a first-party OS and a third-party OS. In addition, although described with respect to a natively executed OS (meaning that the host unit 112 executes the operating system 116), in some examples, a separate computing device may execute the OS 116, in which case the OS 116 represents an intended instance of the OS 116. The intended instance of the OS 116 may refer to a graphical user interface (GUI) that is transmitted (via a separate computing device, such as a mobile phone - including a so-called "smartphone", a laptop computer, a portable gaming device, or any other mobile computing device).

[0033] In any case, OS 116 may include a kernel executing in a so-called kernel space that provides a secure operating environment in which OS 116 can interact with underlying hardware, such as processor 102, GPU 104, system memory 106, and display 108. The kernel of OS 116 may present interfaces, such as application programming interfaces (APIs) 119, through which applications executing in a higher (compared to kernel space) application space (AS) 120 may interact with the underlying hardware via the kernel. The OS-level API (which is an API presented by the kernel) 119 may provide certain features, such as interrupts, by which changes in the state of the underlying hardware may be identified, such as communications received via carrier system 114 over an established network via interface 111 ("INT 111").

[0034] The interface 111 may represent any type of interface through which the host unit 112 may communicate with the vehicle system 114. The 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 the vehicle 100). The interface 111 may include a physical port interconnected with dedicated network hardware in the form of a wired connection (e.g., an Ethernet cable) or other physical connection, or a virtual interface implemented by an underlying processor (represented by the interface 111) that manages the interconnectivity between the host unit 112 and the vehicle system 114 via a wireless Ethernet network.

[0035] exist Figure 1 In the example of , the interface 111 is assumed to be a hardware (or in other words physical) layer 2 interface coupled to a physical cable to each of the carrier systems 114. Within this assumption, the layer 2 interface is also assumed to be a hardware Ethernet interface, which is physically coupled to each of the carrier systems 114 via an Ethernet cable (via a hardware Ethernet port, or in other words a physical Ethernet port) via a physical and / or virtual hub and / or switch, which operates according to a layer 2 protocol (e.g., Ethernet) to switch (or route in some cases - when the layer 2 switch / hub is considered to be a layer 2.5 hub / switch) frames (or some other data units, such as packets in the case of a layer 3 network) between the carrier host unit 112 and the carrier system 114 (wherein such a hub / switch is not shown for ease of illustration purposes).

[0036] The manufacturer of the vehicle 100 may configure various virtual local area networks (VLANs) that create a virtual network between one or more of the vehicle systems 114 and the vehicle host unit 112. In this case, the VLANs may provide independent networks (e.g., virtual networks that are logically separated from one another) that establish connectivity between different vehicle systems 114 and the host unit 112 (e.g., vehicle system 114A may establish communication with the vehicle host unit 112 via an Ethernet network and VLAN A, vehicle system 114B may establish communication with the vehicle host unit 112 via an Ethernet network and VLAN B, etc.).

[0037] 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 host unit 112 via a single VLAN established over an underlying Ethernet network. Additionally, although described herein with respect to VLANs, various aspects of these techniques may be performed with respect to any vehicle network, including an Ethernet network (e.g., directly configuring a physical interface), a virtual network (such as a VLAN), or any other type of vehicle network capable of supporting intercommunication.

[0038] In any case, manufacturers of vehicles, such as vehicle 100, are beginning to introduce more sophisticated networks to facilitate communications between vehicle head units 112 and vehicle systems 114. Such advances in network communications can provide numerous benefits in terms of security and ease of exploitation, while also providing high bandwidth communications that facilitate rapid data transfer (e.g., on the order of gigabytes-GB) that can enable next generation features such as deep telematics, autonomous operation, over-the-air updates, etc.

[0039] However, the introduction of complex networks may require detailed hard coding of virtual interfaces through which the OS 116 configured to be executed by the host unit 112 is coupled to such networks (such as the VLANs set forth above). That is, the OS 116 may not natively expose the VLANs, and require manufacturers to independently program (or, in other words, "hard code") the connectivity between the OS 116 and the vehicle system 114. These manufacturers may resort to specialized programming (e.g., in accordance with the C or C++ programming languages) in order to expose the underlying VLANs implemented through the hardware Ethernet network coupling the vehicle host unit 112 and the vehicle system 114 to the application 118.

[0040] Further, the vehicle manufacturer may implement access control lists (ACLs) to grant or disallow access to VLANs from certain applications 118 executed by OS 116 within application space 120. The manufacturer may review each of the applications 118 to grant access to such VLANs in order to maintain security and / or safety. The manufacturer may independently (meaning, separate from the developer of OS 116) code such ACLs, including modifying OS 116, to provide such functionality. Given that OS 116 may be updated over time, such divergence in development may result in difficulties maintaining ACLs, which may require redevelopment of the security of OS 116 (in terms of implementing ACLs for app 118) to facilitate updates to OS 116. The lack of native support for such ACLs in OS 116 in the context of vehicle 100 may reduce adoption of OS 116 while also exposing security and / or safety issues.

[0041] According to various aspects of the techniques described in the present disclosure, an OS 116 may be configured to perform efficient network management for applications 118 executed by a carrier host unit 112. Rather than resorting to so-called "low-level" network management, various aspects of the techniques enable an OS 116 executed by a carrier host unit 112 to present a single application programming interface (API) 119 through which network access and control may be configured for applications 118 executing in an application space (rather than a secure kernel space) of a carrier operating system represented by the OS 116 (and thus may be referred to as "carrier OS 116"). Via the single API 119, applications 118 may register calls with the OS 116 for network access to specific carrier networks that interconnect the carrier host unit 112 executing the carrier OS 116 to various carrier systems 114. The carrier OS 116 may be configured to implement access control lists (ACLs) 121 to determine whether a particular application attempting to register a call for carrier network access is able to access the underlying carrier network via these access control lists. If authorized via the ACLs 121, the carrier OS 116 may configure an interface (which may be a virtual interface) through which the particular application may access the underlying carrier network, including assigning a network address (e.g., an Internet Protocol—IP—address).

[0042] In operation, the OS 116 may obtain an indication of one or more vehicle networks. That is, the manufacturer may configure each of the above-mentioned VLANs within the vehicle 100 to interconnect the vehicle head unit 112 to one or more vehicle systems 114. Once configured, the manufacturer may register each of the VLANs with the OS 116 via the API 119, while also interfacing with the API 119 to configure the ACL 121.

[0043] The vehicle head unit 112, and more specifically the processor 102 of the vehicle head unit 112, may execute an OS 116 that presents an API 119 that provides function calls through which one or more vehicle networks may be configured within the OS 116. Manufacturers may then simply interface with the API 119 to configure vehicle networks and the ACL 121 within the OS 116. Because the OS 116 actively presents the API 119, any development of the OS 116 may result in active maintenance of the API 119 that maintains a standard way (e.g., via function calls) for configuring vehicle networks within the OS 116.

[0044] The OS 116 may be initialized (during boot and after starting the carrier network), which may result in one or more network interfaces for one or more carrier networks being configured in the OS 116 via a single API 119, through which one or more applications 118 executing in an application space 120 presented by the OS 116 interface with the one or more carrier networks. The OS 116 may configure the one or more network interfaces by at least partially assigning an address for each of the one or more network interfaces, the address being used to distinguish between each interface (which again may refer to a virtual interface defined within the OS 116). The OS 116 may statically assign such addresses or resort to dynamic assignment of such addresses, where the addresses may include network addresses (or in other words, layer 3 network addresses, such as Internet Protocol (IP) addresses). The OS 116 may dynamically assign such addresses in accordance with a dynamic host configuration protocol.

[0045] 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 the various interfaces through which OS 116 communicates with the carrier network. ACL 121 may represent a form of application access rules for network interfaces that control access by applications 118 to one or more network interfaces.

[0046] In this manner, manufacturers of vehicles such as vehicle 100 may program applications 118 or allow third-party application developers to develop applications 118 that interface with a single API 119 natively presented by the vehicle OS 116 to perform network management, rather than resorting to complex so-called "low-level" configurations in which such vehicle manufacturers statically configure (or, in other words, "hard code") vehicle network configurations independently for each of the applications 118. Vehicle manufacturers may deploy ACLs 121 that restrict or allow access to the underlying vehicle network based on an application approval process that complies with the laws of the various jurisdictions in which the automobiles are sold.

[0047] In addition, the vehicle operating system 116 is developed to accommodate laws of different jurisdictions while also enabling vehicle network access for applications 118 executed by the vehicle OS 116. Given that vehicle network access can be managed via a single API 119, the manufacturer of the vehicle may not require a dedicated computer programmer to "hard code" network access, but can 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 operating system 116, such vehicle network management can be natively supported as the vehicle OS 116 undergoes additional development and revisions.

[0048] Thus, a single network management API 119 can facilitate more efficient operation of the vehicle OS 116 while also improving access to vehicle networks by applications 118 executed by the vehicle OS 116. The vehicle OS 116 can operate more efficiently because the single API 119 can reduce errors introduced by such "hard-coded" network management that may lead to errors (security or otherwise) that may introduce issues with the security or utilization of the vehicle network, which results in efficient use of the computing resources of the vehicle host unit 112 (e.g., in terms of processor cycles, memory, memory bandwidth, and associated power). Further, in view of the unified single API 119 for network management, application developers can ensure access to certain vehicle networks via manufacturing validation, while also allowing manufacturers to disable vehicle network access to vehicle systems 114 that may pose a security and / or safety risk, thereby improving the security and / or safety of the vehicle 100 itself.

[0049] Figure 2 is a diagram illustrating various aspects of the technology described in the present disclosure. Figure 1 A block diagram of the conceptual configuration of a single application programming interface for network management of a carrier is shown in the example of FIG. Figure 2 In the example of Figure 1 An example of the vehicle 100 shown in the previous example.

[0050] The carrier 200 may include a carrier host unit 212 and a carrier system 214 separated by a bridge and / or switch 202 (which may represent a physical bridge and / or switch or a logical - or in other words - a virtual bridge and / or switch). The bridge and / or switch ("bridge / switch") 202 may represent a layer 2 network device or a layer 2.5 network device (which includes some ability to understand destinations and route frames / packets to those destinations, rather than a layer 2 network device that broadcasts frames / packets out every port).

[0051] The carrier host unit 212 may execute an OS 216 and applications ("apps") 218 ​​in the manner described above with respect to the carrier host unit 112. The carrier host unit 212 may also include an Ethernet interface 204 to establish Ethernet communications with the bridge / switch 202 through the Ethernet interface. Ethernet refers to a set of networking standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE) as IEEE802.3 that define how to establish and maintain wired and wireless layer 2 network communications in support of network communications. The Ethernet interface 204 may conform to any layer 2 communication standard, but for purposes of illustration, it is assumed to operate in accordance with IEEE 802.3. Ethernet interface 204.

[0052] The Ethernet interface 204 includes a physical Ethernet port (denoted as Eth0 206) coupled to the bridge switch 206 wirelessly or via a physical line (commonly referred to as an Ethernet cable). The Ethernet interface 204 also supports multiple virtual Ethernet ports, which are denoted as Eth0.1 208A, Eth0.2 208B, ..., Eth0.N 208N (these virtual Ethernet ports may also be referred to as "virtual Ethernet ports 208"). The OS 116 can manage and maintain the virtual Ethernet ports 208, thereby defining these virtual Ethernet ports 208 for use by one or more of the apps 218. Although in Figure 1 1. The example of 200 is shown as each of the apps 118 being interfaced with a single (and dedicated) virtual Ethernet port, but an app 118 may request one or more virtual Ethernet ports 208 for a variety of different reasons.

[0053] To support virtual Ethernet ports 208, OS 116 may include an Ethernet manager 210 that executes in kernel space (rather than the more restrictive and less privileged application space). Apps 218 may issue function calls associated with networking APIs that request virtual Ethernet ports 208, where Ethernet manager 210 may represent these networking APIs while also providing additional network management functionality to maintain an Ethernet network, including virtual Ethernet ports 208 (which may also be referred to as virtual Ethernet interfaces 208). Although shown as a single app (e.g., app 218A) connected to a single Ethernet port (e.g., Ethernet port 208A), multiple apps 218 may be connected to the same single Ethernet port.

[0054] OS 216 may also execute network app 228, which supports Figure 2 The network app 228 can call a single API 219 to interface with the Ethernet manager 210 to configure the network (such as VLAN 230) within the entire Ethernet network shown in the example of FIG. Figure 2 The network shown in the example.

[0055] like Figure 2As further shown in the example of FIG. 2 , the manufacturer of vehicle 200 can configure VLANs 230A to 230N ("VLANs 230"). As briefly stated above, VLANs 230 represent separate partitioned and isolated virtual networks that are partitioned and isolated at layer 2. Each VLAN in VLANs 230 is assigned a unique VLAN tag (meaning unique within vehicle 200 and possibly external networks depending on whether the network extends outside of vehicle 200). VLANs 230 can enable a single physical network to be partitioned into separate logically isolated networks.

[0056] The API 219 may enable the network app 228 to configure the virtual Ethernet interface 208 that enables the app 218 executing within the OS 216 to access the VLAN 230, which may include IP configuration, setting network capabilities (these capabilities exist in the OS 216 and are used to define various functions associated with the underlying network, such as the presence of a captive portal, bandwidth priority, latency priority, transport - such as universal system bus, personal area network, Ethernet, cellular, wireless, etc.), etc. In addition, the network app 228 may interface with the Ethernet manager 210 via the API 219 to configure the ACLs 221 that control access by the app 218 to the virtual Ethernet interfaces 208, which may be associated with one or more VLANs 230.

[0057] Figure 3 is a more detailed illustration of various aspects of the technology described in the present disclosure, supporting efficient network management, Figure 1 and Figure 2 A block diagram of the vehicle operating system shown in the example. Figure 3 In the example of , the carrier OS 316 includes the Ethernet manager 310 stated above that manages the network configuration for the virtual Ethernet interface 208 through the API 319. However, the OS 316 includes two different parts of the API 119, an API 319A that provides an interface through which the interconnectivity between the virtual Ethernet interface 208 and the VLAN 230 is configured, and an API 319B for managing the ACL 321.

[0058] The vehicle OS 316 includes an Ethernet service 311, a network agent 312, a network service daemon 314, and an OS kernel 316 (each of which may be similar to similarly named components of Unix-based and / or Linux-based operating systems). The Ethernet service 311 may represent an OS-level (which executes in kernel space) service that implements functionality associated with Ethernet in terms of managing underlying hardware (such as a physical Ethernet interface), and that also implements various APIs, such as a backend API 319A for managing ACLs 321 associated with user identifier ("uid") rules for accessing the vehicle network.

[0059] The Ethernet manager 310 may be called by an app, such as the network app 228, to establish a virtual Ethernet interface 208. The Ethernet manager 310 may also be called (via a function call) to configure a VLAN 230 within the OS 116, defining network addresses, network capabilities, and ACLs 121. The Ethernet manager 310 is instantiated via a function call to a system service (e.g., Ethernet service 311) responsible for managing Ethernet communications.

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

[0061] The network agent 312 can assist in configuring network connectivity with the vehicle system 114 via the VLAN 230. The network agent 312 can configure IP addresses and network capabilities in response to the Ethernet manager 310 invoking the API 319A function, wherein the Ethernet service 310 can interface with the network agent 312 to protect the IP address assigned to the virtual Ethernet interface 208. Each of these updates for providing the API 119 can affect the underlying system code of the OS 316 to provide network connectivity and associated ACLs 321 between the apps 118 / 218 and the vehicle system 114 / 214 via the VLAN 230.

[0062] Figure 4 is a diagram showing various aspects of the technology described in the present disclosure Figures 1 to 3 A block diagram of how a carrier operating system implements access control lists while performing network management is shown in the example of FIG. Figure 4 In the example of , OS 416 may represent an example of OS 116 in which an original equipment manufacturer (OEM) telematics app 418A and an OEM camera app 418B (e.g., for viewing a vehicle's backup camera or other camera system) execute in the application space along with so-called third-party apps 438.

[0063] Although each of the OEM telematics app 418A, the OEM camera app 418B, and the third-party application 438 may represent the above Figure 1 and Figure 2 , but in some cases, only OEM applications (such as OEM telematics app 418A and OEM camera app 418B) may represent examples of applications 118. That is, for safety and security purposes, access to certain vehicle systems 114 / 214 may be limited to signed OEM applications, such as OEM telematics app 418A and OEM camera 418B.

[0064] In view of the safety and security issues stated above, the manufacturer may define ACL 121 to prohibit any application other than specially certified applications (such as OEM telematics app 418A and OEM camera app 418B) from accessing VLAN 230 to access vehicle systems 114 through these VLANs. Figure 4In the example of , any attempt by a third-party app 438 to access the VLAN 230B associated with Eth0.2 408B may be denied at the operating system level via the OS 416. More specifically, the network service daemon 314 may interface with the OS kernel 316 to retrieve a uid-based ACL 121 that explicitly denies the third-party app 438 access to the VLAN 230B and / or the underlying Eth0.2 408B. In this manner, security and safety may be ensured using a single API 119 / 219 / 319A / 319B through which network access is managed.

[0065] Figure 5 is a representation showing various aspects of the technology described in the present disclosure Figure 1 and Figure 2 FIG. 1 is a diagram of a state diagram of an example operation of a carrier operating system when performing network management. Figure 5 In the example of , one or more of the apps 118 can interface with a single API 119 to register for network callbacks (500). By registering with the connectivity manager responsible for managing the Ethernet manager 210, the apps 118 can receive callbacks that alert the apps 118 when a particular network is available, when it is lost, and whether one of the registered apps 118 has access to the particular network. The network access includes the Ethernet network stated above.

[0066] App 118 can register callbacks that specify specific networks in different ways. In some examples, the registered callbacks can define the network based on network characteristics (such as bandwidth, latency, signal-to-noise ratio, etc.). The registered callbacks can also request callbacks only for networks that provide a specific quality of service (QoS), which is similar to network characteristics, but is generally defined in a network characteristic hierarchy that generally has a fallback QoS requirement. The registered callbacks can also define the network based on the type of network (such as wired vs. wireless), the transport protocol, and / or by specifying which specific network is requested (such as a Bluetooth connection, an Ethernet connection, etc.).

[0067] When the network is not available (“No” 502) (where an existing network registered with the OS 216 does not satisfy the registered callback specification for the network), the OS 216 does not send any callbacks back to the app 118 (504), but the app network access may be changed (506) through the single API 119. That is, the single API 119 may configure additional networks (e.g., VLANs) after execution of the OS 116 by discovering new systems 114, adding new systems 114 (e.g., through USB or other wired or wireless connectivity, etc.). As a result, the Ethernet network may become available (“Yes” 502), in which case the OS 216 may send a callback to the registered apps 118 alerting them that the Ethernet network (and / or associated VLANs in VLAN 230) is available (508).

[0068] Figure 6 It is shown by Figure 1 100. A flowchart of an example operation of a vehicle operating system in performing various aspects of a network management technique is shown in the example of FIG. 100. Initially, the OS 116 can obtain an indication of one or more vehicle networks (600). That is, the manufacturer can configure each of the above-mentioned VLANs within the vehicle 100 to interconnect the vehicle host unit 112 to one or more vehicle systems 114. Once configured, the manufacturer can register each of the VLANs with the OS 116 via the API 119, while also interfacing with the API 119 to configure the ACL 121.

[0069] The vehicle host unit 112, and more specifically the processor 102 of the vehicle host unit 112, may execute an OS 116 that presents an API 119 that provides function calls through which one or more vehicle networks are configured within the OS 116 (602). Manufacturers may then simply interface with the API 119 to configure vehicle networks and ACLs 121 within the OS 116. Because the OS 116 actively presents the API 119, any development of the OS 116 may result in active maintenance of the API 119 that maintains a standard way (e.g., via function calls) for configuring vehicle networks within the OS 116.

[0070] The OS 116 may be initialized (during boot and after the carrier networks are started), which may result in one or more network interfaces for one or more carrier networks being configured in the OS 116 via a single API 119, through which one or more applications 118 executing in an application space (AS) 120 presented by the OS 116 interface with the one or more carrier networks (604). The OS 116 may configure the one or more network interfaces by at least partially assigning an address for each of the one or more network interfaces, the address being used to distinguish between each interface (which again may refer to a virtual interface defined within the OS 116). The OS 116 may statically assign such addresses or resort to dynamic assignment of such addresses, where the addresses may include network addresses (or in other words, layer 3 network addresses, such as Internet Protocol (IP) addresses). The OS 116 may dynamically assign such addresses in accordance with a dynamic host configuration protocol.

[0071] 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 the various interfaces through which OS 116 communicates with the carrier network. ACL 121 may represent a form of application access rules for network interfaces that control access by applications 118 to one or more network interfaces.

[0072] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory or any other storage medium that can be used to store the desired program code in the form of an instruction or data structure and can be accessed by a computer. In addition, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, optical fiber cable, twisted pair, digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwaves are used to send instructions from a website, server or other remote source, then coaxial cable, optical fiber cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwaves are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals or other temporary media, but are directed to non-temporary tangible storage media. Disks and optical disks as used herein include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks and blue-ray disks, wherein disks generally reproduce data magnetically, and optical disks reproduce data optically with lasers. The combination of the above items should also be included in the scope of computer-readable media.

[0073] 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 circuit systems. Thus, 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. Furthermore, the techniques may be fully implemented in one or more circuits or logic elements.

[0074] The techniques of the present disclosure may be implemented in a variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs), or a set of ICs (e.g., a chipset). Various components, modules, or units are described in the present disclosure to emphasize the functional aspects of a device configured to perform the disclosed techniques, but the components, modules, or units do not necessarily need to be implemented by different hardware units. Rather, as described above, the various units may be combined in a hardware unit, or provided by a collection of interoperable hardware units including one or more processors as described above in combination with appropriate software and / or firmware.

[0075] This disclosure includes many examples. These examples include the following.

[0076] Example 1. 1. A method, comprising: obtaining, by one or more processors of a carrier host unit, an indication of one or more carrier networks; executing, by the one or more processors, an operating system, the operating system presenting a single application programming interface that provides function calls, through which one or more carrier networks are configured within the operating system; and configuring one or more network interfaces for the one or more carrier networks in the operating system via the single application programming interface, through which one or more applications executed in an application space presented by the operating system interface with the one or more carrier networks.

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

[0078] Example 3. The method of Example 2, wherein configuring the one or more network interfaces comprises assigning at least one network address to each of the one or more network interfaces according to a dynamic host configuration protocol.

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

[0080] Example 5. The method of Example 4 further comprises denying application access to the network interface based on the application access rule.

[0081] Example 6. A method as described in any combination of Examples 1 to 5, wherein the one or more carrier networks include one or more layer 2 networks.

[0082] Example 7. The method of Example 6, wherein the one or more carrier networks include one or more virtual local area networks executed on one or more layer 2 networks.

[0083] Example 8. The method of Example 7, wherein the one or more layer 2 networks include one or more Ethernet networks.

[0084] Example 9. The method of any combination of Examples 1 to 8, wherein the operating system further comprises a kernel space reserved for executing a privileged operating system kernel, and wherein the application space provides an interface by which one or more applications interact with the privileged operating system kernel.

[0085] Example 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 the vehicle.

[0086] Example 11. The method of Example 9, wherein the one or more vehicle systems include a HVAC system, a seat control system, an interior lighting system, an exterior lighting system, a communication system, a mirror control system, and a video system.

[0087] 12. A carrier host unit, comprising: a memory configured to store an operating system; and one or more processors configured to: obtain an indication of one or more carrier networks; execute the operating system, the operating system presenting a single application programming interface that provides function calls, through which one or more carrier networks are configured within the operating system; and configure one or more network interfaces for the one or more carrier networks in the operating system via the single application programming interface, and one or more applications executed in an application space presented by the operating system interface with the one or more carrier networks through the one or more network interfaces.

[0088] Example 13. The carrier host unit of Example 12, wherein when configuring the one or more network interfaces, the one or more processors are configured to configure at least one network address for each of the one or more network interfaces.

[0089] Example 14. The carrier host unit of Example 13, wherein when configuring the one or more network interfaces, the one or more processors are configured to assign at least one network address to each of the one or more network interfaces according to a dynamic host configuration protocol.

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

[0091] Example 16. The carrier host 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 rule.

[0092] Example 17. The vehicle host unit of any combination of Examples 12 to 16, wherein the one or more vehicle networks include one or more layer 2 networks.

[0093] Example 18. The carrier host unit of Example 17, wherein the one or more carrier networks include one or more virtual local area networks executed on one or more layer 2 networks.

[0094] Example 19. The vehicle host unit of Example 18, wherein the one or more layer 2 networks include one or more Ethernet networks.

[0095] Example 20. A non-temporary computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors of a carrier host unit to: obtain an indication of one or more carrier networks; execute an operating system that presents a single application programming interface that provides function calls through which one or more carrier networks are configured within the operating system; and configure one or more network interfaces for the one or more carrier networks in the operating system via the single application programming interface, through which one or more applications executing in an application space presented by the operating system interface interface with the one or more carrier networks.

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

Claims

1. A method comprising: obtaining, by one or more processors of a vehicle head unit, an indication of one or more vehicle networks; executing, by the one or more processors, an operating system, the operating system presenting a single application programming interface providing function calls by which the one or more carrier networks are configured within the operating system; as well as One or more network interfaces for the one or more carrier networks are configured in the operating system via the single application programming interface, and one or more applications executed in the application space presented by the operating system are connected to the one or more carrier networks through the one or more network interfaces. 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. The method of claim 2, wherein configuring the one or more network interfaces comprises assigning the at least one network address to each of the one or more network interfaces according to a dynamic host configuration protocol.

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

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

6. The method of any combination of claims 1 to 5, wherein the one or more carrier networks comprise one or more layer 2 networks.

7. The method of claim 6, wherein the one or more carrier networks include one or more virtual local area networks executed 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 method according to any combination of claims 1 to 8, wherein the operating system further comprises a kernel space reserved for executing a privileged operating system kernel, and The application space provides an interface through which the one or more applications interact with the privileged operating system kernel.

10. A method as claimed in any combination of claims 1 to 9, wherein the one or more vehicle networks are configured to interconnect the vehicle host unit to one or more vehicle systems of a vehicle.

11. The method of claim 9, wherein the one or more vehicle systems include a HVAC 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. A vehicle host unit, comprising: a memory configured to store an operating system; as well as One or more processors configured to: obtaining an indication of one or more carrier networks; executing the operating system, the operating system presenting a single application programming interface providing function calls by which the one or more carrier networks are configured within the operating system; as well as One or more network interfaces for the one or more carrier networks are configured in the operating system via the single application programming interface, and one or more applications executed in the application space presented by the operating system are connected to the one or more carrier networks through the one or more network interfaces.

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

14. The carrier host unit of claim 13, wherein when configuring the one or more network interfaces, the one or more processors are configured to assign the at least one network address to each of the one or more network interfaces according to a dynamic host configuration protocol.

15. A carrier host unit as described in any combination of claims 12 to 14, wherein when configuring the one or more network interfaces, the one or more processors are configured to configure application access rules for controlling access to the one or more network interfaces by the one or more applications.

16. The carrier host 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. A carrier host unit as described in any combination of claims 12 to 16, wherein the one or more carrier networks include one or more layer 2 networks.

18. A carrier host unit as described in claim 17, wherein the one or more carrier networks include one or more virtual local area networks executed on the one or more layer 2 networks.

19. The vehicle host 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 carrier host unit to: obtaining an indication of one or more carrier networks; executing an operating system that presents a single application programming interface that provides function calls by which the one or more carrier networks are configured within the operating system; and One or more network interfaces for the one or more carrier networks are configured in the operating system via the single application programming interface, and one or more applications executed in the application space presented by the operating system are connected to the one or more carrier networks through the one or more network interfaces.

Images