Control of vehicle signal authorization

Abstract

To provide systems, methods and software for achieving control of permissions of vehicle signals.SOLUTION: A method used to control permissions of vehicle signals includes: receiving a permission map, where the permission map comprises a configured permission value of a permission element of a node in a vehicle signal catalog; and setting a permission value of the permission element of the node in the vehicle signal catalog according to the configured permission value in the permission map.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention relates to controlling the permission of vehicle signals.

Background Art

[0002] A vehicle may include a number of sensors, and these sensors emit or generate signals that constantly report state changes in what they are monitoring. These signals can be used to determine the states of different aspects of the vehicle. A vehicle or an entity within the vehicle may further set different values for these signals to control the operation of the vehicle.

Summary of the Invention

Means for Solving the Problems

[0003] In some cases, vehicle signals may define a signal catalog using the Vehicle Signal Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA). Such a signal catalog provides a normative definition of a set of signals that can be emitted or generated by sensors within the vehicle.

[0004] In some operations, non-native applications (e.g., applications running on an external device or third-party applications installed on the vehicle, etc.) need access to some of the signals. The access can be read access, write access, or both. The vehicle needs to determine whether the non-native application has the appropriate permission to access these signals.

[0005] In some implementations, reading and writing vehicle signals may be configured by using different permission values. In some cases, the permission values ​​for vehicle signals may be configured based on a node in a tree structure of a signal catalog defined using VSS. Software or hardware within the vehicle may compare the permission value of a vehicle signal or node in the signal catalog with the permission value of an entity requesting access (e.g., a non-native application, as discussed earlier) to determine whether to grant access. The approaches described in this disclosure provide efficient methods for controlling access to vehicle signals, preventing security breaches, and protecting the safety of vehicle operation. Figures 1–6 and their associated descriptions provide additional details of these implementations. The present invention provides, for example, the following items: (Item 1) The above method is Receiving an authorization map, wherein the authorization map includes configured authorization values ​​for the authorization elements of nodes in the vehicle signal catalog. Set the permission value of the permission element of the node in the vehicle signal catalog in accordance with the permission value configured in the permission map above. Methods that include... (Item 2) The above vehicle signal catalog is based on the Vehicle Signaling Specifications (VSS) of the Connected Vehicle Systems Alliance (COVESA), and the methods described in the above items apply. (Item 3) The method described in any one of the above items, wherein the permission element is either a read permission element or a write permission element. (Item 4) The above permitted values ​​are from a predefined set of permitted values, as described in any one of the above items. (Item 5) The permission values ​​described above are those used in any one of the above items, indicating that read access to the signal values ​​of the node is limited to a selected group of applications that have the same permission values. (Item 6) The method of any one of the above items, wherein the above node is a branch node, and the method further comprises setting the permission value of the above permission element of the above node in the above vehicle signal catalog in accordance with the above configured permission value in the above permission map. (Item 7) Setting the permission value of the permission element of the subnode of the above node in the above vehicle signal catalog is, The above permission map determines whether it contains the permission values ​​of the above permission elements of the above subnodes, In response to the determination that the above permission map does not include the permission value of the above permission element of the above subnode, the above permission value of the above permission element of the above subnode is set to be the same as the above configured permission value. The method described in any one of the above items, including: (Item 8) A computing device, wherein the computing device is At least one hardware processor, One or more computer-readable storage media coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein, when the programming instructions are executed, the computing device, Receiving an authorization map, wherein the authorization map includes configured authorization values ​​for the authorization elements of nodes in the vehicle signal catalog. Set the permission value of the permission element of the node in the vehicle signal catalog in accordance with the permission value configured in the permission map above. One or more computer-readable storage media that perform operations including A computing device equipped with [a certain feature]. (Item 9) The above vehicle signal catalog refers to computing devices listed in any one of the above items, based on the Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA). (Item 10) The above permission element is either a read permission element or a write permission element, as described in either of the above items for the computing device. (Item 11) The above permitted values ​​are from a predefined set of permitted values, and the computing device is one of the items listed above. (Item 12) The above permission values ​​indicate that read access to the signal values ​​of the above node is limited to a selected group of applications having the same permission values, as described in any one of the above items for the computing device. (Item 13) The computing device described in any one of the above items, wherein the above node is a branch node, and the above operation further comprises setting the permission value of the above permission element of the above node in the above vehicle signal catalog in accordance with the above configured permission value in the above permission map. (Item 14) Setting the permission value of the permission element of the subnode of the above node in the above vehicle signal catalog is, The above permission map determines whether it contains the permission values ​​of the above permission elements of the above subnodes, In response to the determination that the above permission map does not include the permission value of the above permission element of the above subnode, the above permission value of the above permission element of the above subnode is set to be the same as the above configured permission value. A computing device, including any one of the items listed above. (Item 15) A computer-readable medium, the computer-readable medium storing instructions, and when the instructions are executed, the computing device, Receiving an authorization map, wherein the authorization map includes configured authorization values ​​for the authorization elements of nodes in the vehicle signal catalog. Set the permission value of the permission element of the node in the vehicle signal catalog in accordance with the permission value configured in the permission map above. A computer-readable medium that causes an operation including (Item 16) The vehicle signal catalog is the computer-readable medium according to any one of the above items, based on the Vehicle Signal Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA). (Item 17) The permission element is the computer-readable medium according to any one of the above items, which is a read permission element or a write permission element. (Item 18) The permission value is from a set of predefined permission values, and is the computer-readable medium according to any one of the above items. (Item 19) The permission value indicates that read access to the signal value of the node is limited to a selected group of applications having the same permission value, and is the computer-readable medium according to any one of the above items. (Item 20) The node is a branch node, and the operation further includes setting the permission value of the permission element of the sub-node of the node in the vehicle signal catalog according to the configured permission value in the permission map, and is the computer-readable medium according to any one of the above items. (Abstract) Systems, methods, and software are used to control the permission of vehicle signals. In some aspects, one exemplary method includes receiving a permission map, where the permission map includes configured permission values of permission elements of nodes in a vehicle signal catalog, and setting the permission values of the permission elements of the nodes in the vehicle signal catalog according to the configured permission values in the permission map.

Brief Description of the Drawings

[0006] ​​​​​

[0007] [Figure 2] Figure 2 is a flowchart showing an exemplary method of controlling the permission of vehicle signals according to an implementation.

[0008] [Figure 3] Figure 3 is a high-level architecture block diagram of a computing system according to an implementation.

[0009] [Figure 4] Figure 4 is a diagram illustrating an exemplary structure of vehicle signals according to an implementation.

[0010] [Figure 5] Figure 5 is a flowchart showing an exemplary method of configuring the permission of vehicle signals according to an implementation.

[0011] [Figure 6] Figure 6 is a block diagram illustrating a permission configuration for vehicle signals according to an implementation.

[0012] Like reference numbers and designations in the various drawings refer to like elements.

Best Mode for Carrying Out the Invention

[0013] Figure 1 is a schematic diagram showing an exemplary communication system 100 for controlling the permission of vehicle signals according to an implementation. At a high level, the exemplary communication system 100 includes a vehicle 120 communicatively coupled to an application 122. The vehicle 120 is also communicatively coupled to a server 130 via a network 140.

[0014] Vehicle 120 may include automated vehicles (e.g., automobiles, passenger cars, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aircraft systems, drones, helicopters, etc.), spacecraft (e.g., spaceplanes, space shuttles, space capsules, space stations, satellites, etc.), watercraft (e.g., ships, boats, hovercraft, submarines, etc.), railway vehicles (e.g., trains, trams, etc.), and other types of vehicles, whether existing or future, including any combination of any of the above. In the illustrated example, vehicle 120 includes one or more sensors 102 connected to bus 110, a vehicle component controller 104, a vehicle system processor 106, a communication sub-system 116, a user interface 118, a memory 114, and an authorization control module 112.

[0015] In some examples, a vehicle may include one or more sensors. One or more sensors may generate inputs (e.g., video input or audio input) that reflect the environment around or inside the vehicle. Examples of sensors may include cameras, microphones, lasers, radar, ultrasonic sensors, light detection and ranging (LIDAR), or any other sensors.

[0016] Vehicle 120 includes one or more sensors 102 that detect or measure information about vehicle 120. Examples of sensors 102 may include sensors that capture external environmental information about vehicle 120 (e.g., cameras, microphones, lasers, radar, ultrasound, light detection and ranging (LIDAR), etc.). These sensors may provide environmental inputs to an automated processing platform operating on vehicle 120 for making automated decisions. Examples of sensors 102 may also include devices that capture internal information about vehicle 120 (e.g., monitors for components such as the engine, battery, fuel, electronic systems, and cooling systems). These sensors may provide operating status and warnings to an automated processing platform operating on vehicle 120. Examples of sensors 102 may also include acoustic sensors that can detect sound levels inside vehicle 120. Acoustic sensors may determine noise levels inside vehicle 120 or provide inputs to other signal processors that determine noise levels.

[0017] Vehicle 120 includes a vehicle component controller 104. Although shown as a single vehicle component controller 104 in Figure 1, vehicle 120 may include two or more vehicle component controllers 104. A vehicle component controller 104 represents a controller that controls the operation of components on vehicle 120. Examples of components may include the engine, accelerator, brakes, radiator, battery, steering wheel, transmission system, cooling system, electrical system, entertainment system, and any other components of vehicle 120. For example, a vehicle component controller 104 may control the speaker system of vehicle 120 (including controlling volume, balance, fade, and any other settings for the audio output inside vehicle 120). A vehicle component controller 104 may automatically operate each component according to inputs from the vehicle system processor 106 or a combination thereof. In some implementations, a vehicle component controller 104 may include a data processing unit.

[0018] The vehicle system processor 106 may include one or more processing components (alternatively referred to as “processors” or “central processing units (CPUs)”) configured to execute instructions related to one or more processes, steps, or actions for an automated processing platform operating on the vehicle 120. Generally, the vehicle system processor 106 executes instructions and manipulates data to perform the operation of the automated processing platform. The vehicle system processor 106 may receive input from the sensor 102 and generate commands for the vehicle component controller 104. In some cases, the vehicle system processor 106 may perform automated operations. In some cases, the vehicle system processor 106 may include data processing devices.

[0019] The communication subsystem 116 may be configured to provide wireless or wireline communication to data or control information of the vehicle 120. For example, the communication subsystem 116 may support transmission via wireless local area network (WLAN or WiFi), near-field communication (NFC), infrared (IR), radio frequency identification (RFID), Bluetooth® (BT), Universal Serial Bus (USB), or any other short-range communication protocol. The communication subsystem 116 may also support Global System for Mobile Communications (GSM®), Interim Standard 95 (IS-95), Universal Mobile Telecommunications System (UMTS), CDMA2000 (Code Division Multiple Access), Advanced Universal Mobile Telecommunications System (E-UMTS), Long-Term Evolution (LTE), LTE-Advanced, 5G, or any other radio access technology. The communication subsystem 116 may include, for example, one or more antennas, receivers, transmitters, local oscillators, mixers, and digital signal processing (DSP) units. In some implementations, the communication subsystem 116 may support multiple-input multiple-output (MIMO) transmission. In some implementations, the receivers within the communication subsystem 116 may be advanced receivers or baseline receivers.

[0020] The user interface 118 may include, for example, one or more displays or touchscreen displays (e.g., liquid crystal displays (LCDs), light-emitting diodes (LEDs), organic light-emitting diodes (OLEDs), or micro-electromechanical systems (MEMS) displays), a keyboard or keypad, a trackball, a speaker, or a microphone. The user interface 118 may also include an I / O interface, such as a Universal Serial Bus (USB) interface.

[0021] Memory 114 may be a computer-readable storage medium. Examples of memory 114 include volatile and non-volatile memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, and others. Memory 114 may store the operating system (OS) of the vehicle 120 and various other computer executable software for performing one or more of the processes, steps, or operations described above.

[0022] The authorization control module 112 represents an application, a set of applications, software, a software module, hardware, or any combination thereof that can be configured to control the access permissions for vehicle signals of vehicle 120. In some implementations, the authorization control module 112 may receive requests for vehicle signals from, for example, application 122. The requests may be for read, write, or both. The authorization control module 112 decides whether to accept the request based on the authorization elements of the requested vehicle signal. In some cases, the authorization control module 112 decides whether to accept the request based further on the authorization elements of the entity requesting the vehicle signal. Figure 2 and its associated description provide additional details of these implementations. In some implementations, the authorization control module 112 may be stored in memory 114 and implemented as a separate software program or as part of a software program executed by the vehicle system processor 106.

[0023] As illustrated, bus 110 provides a communication interface to components of an automated processing platform operating on vehicle 120. In some cases, bus 110 may be implemented using a Controller Area Network (CAN) bus.

[0024] Application 122 represents an application, a set of applications, software, a software module, hardware, or any combination thereof that requests vehicle signals. In some cases, the application may run on an electronic device that connects to the vehicle 120. Such electronic devices may include, but are not limited to, endpoints, computing devices, mobile devices, mobile electronic devices, user devices, mobile stations, subscriber stations, portable electronic devices, mobile communication devices, wireless modems, wireless terminals, or other electronic devices. Examples of endpoints may include mobile devices, IoT (Internet of Things) devices, EoT (Enterprise of Things) devices, cellular phones, personal data assistants (PDAs), smartphones, laptops, tablets, personal computers (PCs), pagers, portable computers, portable gaming devices, wearable electronic devices, health / medical / fitness devices, cameras, or other mobile communication devices having components for communicating voice or data over a wireless or wired communication network. Electronic devices may also include peripheral devices (e.g., headsets, remote controllers, or displays). Electronic devices may connect to the vehicle 120 using short-range communication technology. Short-range communication technologies can be wireless (e.g., BT, NFC, WLAN, etc.). Short-range communication technologies can also be wired (e.g., USB, etc.).

[0025] In some cases, application 122 may also be installed on vehicle 120. For example, application 122 may be a third-party application that controls some of the operations of vehicle 120.

[0026] Server 130 represents an application, a set of applications, software, a software module, hardware, or any combination thereof that can be configured to manage authorization control of vehicle 120. In some implementations, server 130 may receive, store, transmit, and adjust the values ​​of authorization elements within vehicle 120, the authorization values ​​of applications, or both.

[0027] The exemplary communication system 100 includes a network 140. Network 140 represents an application, a set of applications, software, software modules, hardware, or a combination thereof that can be configured to transmit data between a server 130 and a vehicle 120 within the communication system 100. Network 140 includes a wireless network, a wireline network, or a combination thereof. For example, network 140 may include one or more radio access networks (RANs), core networks (CNs), and external networks. A RAN may include one or more radio access technologies. In some implementations, the radio access technology may be Global Systems for Mobile Communications (GSM®), Interim Standard 95 (IS-95), Universal Mobile Telecommunications System (UMTS), CDMA2000 (Code Division Multiple Access), Evolved Universal Mobile Telecommunications System (E-UMTS), Long-Term Evolution (LTE), LTE-Advanced, 5G, or any other radio access technology. In some cases, the core network may be an evolved packet core (EPC).

[0028] A RAN (Radio Area Network) is part of a wireless telecommunications system that implements radio access technologies (e.g., UMTS, CDMA2000, 3GPP LTE, 3GPP LTE-A, and 5G). In many applications, a RAN includes at least one base station. A base station can be a radio base station that can control all or at least some of the radio-related functions within the fixed part of the system. A base station can provide a radio interface within its coverage area or cell to mobile devices for communication. Base stations can be distributed across the entire cellular network to provide wide-area coverage. A base station communicates directly with one or more mobile devices, other base stations, and one or more core network nodes.

[0029] The elements in Figure 1 are shown as including various component parts, sections, or modules that implement various features and functionalities, but these elements may instead include numerous submodules, third-party services, components, libraries, etc., as needed. Furthermore, the features and functionalities of various components may be combined into fewer components as needed.

[0030] Figure 2 is a flowchart illustrating an exemplary method 200 for controlling the authorization of a vehicle signal or a node in a signal catalog, as implemented. Method 200 may be carried out by entities shown in Figure 1, including, for example, a vehicle 120. Method 200 shown in Figure 2 may also be carried out using additional entities, fewer entities, or different entities. Furthermore, Method 200 shown in Figure 2 may be implemented using additional actions, fewer actions, or different actions, which may be performed in the order shown or in a different order. In some cases, an action or group of actions may be repeated or iterated, for example, for a specified number of iterations, or until a termination condition is reached.

[0031] In 202, the vehicle receives access requests to vehicle signals or nodes in a signal catalog. As discussed below, nodes in a signal catalog may be data entry nodes or branch nodes. In some cases, requests may be received from applications (e.g., application 122 in Figure 1). Applications may run on electronic devices outside the vehicle, and requests may be transmitted using wireless or wireline connections (e.g., Bluetooth®, NFC, WiFi, LTE, 5G, USB, or any other local area network or wide area network communication technology). Applications may also run on the vehicle (e.g., third-party applications that may be installed on the vehicle's operating system).

[0032] Vehicle signals represent signals that carry information about vehicle operation. Examples of information carried by vehicle signals include information related to driving operations (e.g., speed, acceleration, position, etc.), information related to entertainment operations (e.g., speaker volume, cabin operation information (e.g., air conditioning (AC) settings, seat position, etc.)), and any other information related to vehicle operation.

[0033] In some cases, the Vehicle Signaling Specification (VSS), developed by the Connected Vehicle Systems Alliance (COVESA), can be used to provide a common format / structure for vehicle signals. VSS introduces a domain classification for vehicle signals that can be used as a standard in automotive applications for communicating information about a vehicle. VSS defines vehicle signals in a tree-like structure, in the classical sense of attributes, sensors, and actuators, along with raw data communicated via the vehicle bus and data more commonly associated with infotainment systems. COVESA defines a catalog of signals; more generally, a catalog of signals may be referred to as a "signal catalog." The signal catalog is organized into a tree structure where data entry nodes are leaf nodes, and branch nodes regroup sets and sub-branches of data entry nodes. Each data entry node defines a specific vehicle signal using, for example, type (e.g., sensor, actuator, attribute, etc.), data type (e.g., integer, floating-point, string, etc.), units (e.g., km / h, Celsius, etc.), etc.

[0034] Table 1 shows examples of signal structures / formats defined for vehicle signals according to COVESA VSS. [Table 1]

[0035] Figure 4 is diagram 400 illustrating the structure of a vehicle signal according to the implementation. Each node in diagram 400 represents a vehicle signal. Node 410 is the root node for the vehicle. Node 410 has subnodes Vehicle.Cabin 420 and Vehicle.Speed ​​422. The node Vehicle.Speed ​​422 is a leaf node and does not have subnodes. The node Vehicle.Speed ​​422 is of floating-point data type, indicating that a floating-point number is used to represent the value of the node Vehicle.Speed. Vehicle.Cabin 420 is a branch node and has a subnode Vehicle.Cabin.Seat 430. Vehicle.Cabin.Seat 430 is also a branch node, which has subnodes Vehicle.Cabin.Seat.Row1 440 and Vehicle.Cabin.Seat.Row2 442. Vehicle.Cabin.Seat.Row1 440 is also a branch node, which has subnodes Vehicle.Cabin.Seat.Row1.Pos1 450 and Vehicle.Cabin.Seat.Row1.Pos3 452. Vehicle.Cabin.Seat.Row1.Pos1 450 is a branch node, which has a subnode Vehicle.Cabin.Seat.Row1.Pos1.Tilt 460. Vehicle.Cabin.Seat.Row1.Pos1.Tilt 460 is a leaf node, which has a floating-point data type. Vehicle.Cabin.Seat.Row1.Pos3 452 is a branch node, which has a subnode, Vehicle.Cabin.Seat.Row1.Pos3.Tilt 462. Vehicle.Cabin.Seat.Row1.Pos3.Tilt 462 is a leaf node, which has a floating-point data type. Although not illustrated, each branch node may have additional subnodes.

[0036] In addition to signal type and data type, data entry nodes representing vehicle signals may include other elements (e.g., min (representing the minimum signal value), max (representing the maximum signal value), etc.).

[0037] As seen in Table 1 above, the dots indicate name paths for identifying components as branches (sets of data entries) or data entries (sensors, actuators, or attributes). Sensors represent one-way signals emanating from a vehicle (e.g., generated according to measurements from one or more sensors within the vehicle). Actuators represent two-way signals that can be either “set” or “gain” values ​​(i.e., the signal can indicate a current state or be used to set a state). Branches are nodes in a tree structure. Attributes are typically fixed values. Sensors / actuators may typically have a publisher (or producer) that continuously updates the signal value when a change occurs within the sensor, while attributes typically have set values ​​that should not change more than once per ignition cycle. In some cases, the signals in Table 1 may be implemented using Extensible Markup Language (XML), JavaScript Object Notation (JSON) scripts, or other encoding formats.

[0038] A request in 202 can be a read request, a write request, or a combination of both. A read request indicates that the application is requesting to retrieve information represented by a vehicle signal or node (e.g., vehicle speed). A write request indicates that the application is requesting to set information represented by a vehicle signal or node (e.g., writing the volume of a speaker on the vehicle).

[0039] In some cases, a request may include the signal / node's pathname or identifier (e.g., the signal / node's Vehicle.VehicleIdentification or UUID (Universally Unique Identifier) ​​as defined in the VSS), and the requested permission (e.g., read, write, or both). In some cases, the request may also include information about the requested application (e.g., the application's identifier). The request may also include permissions assigned to the application.

[0040] In 204, the software or hardware on the vehicle determines whether to accept a request to access a node in the vehicle signal or signal catalog. In some implementations, the decision is made, at least in part, based on the authorization elements of the node in the vehicle signal or signal catalog deployed within the vehicle. If the access request is accepted for a branch node in the signal catalog, access to all nodes below that branch node is also accepted.

[0041] In some cases, in addition to elements (e.g., data types, min, max, etc., as discussed earlier), one or more permission elements may be defined for each node in a vehicle signal or signal catalog. For example, an permission element may be either a read permission element (e.g., “x-read-permission” as described below) or a write permission element (e.g., “x-write-permission” as described below). Alternatively, a single permission element may be defined for both read and write permissions, and different values ​​within the permission element may be used to define different read and write permissions (e.g., one or more bits in the first permission element represent read permission, and one or more bits in the second permission element represent write permission).

[0042] In some cases, the authorization elements for each vehicle signal / node may be set by the vehicle manufacturer, the vehicle's operational administrator, the vehicle owner, the vehicle driver, or any combination thereof. The authorization elements may be set directly in the vehicle's user interface or through a server (e.g., server 130 in Figure 1).

[0043] In some cases, permission elements can be defined as part of the VSS. Alternatively, or in combination, permission elements can be defined as their own elements (for example, as x-read-permission or x-write-permission, where "x" indicates a proprietary, private, extended, or special element). This approach can avoid future definition conflicts of permission-related elements by the VSS.

[0044] In some cases, different permission values ​​may be defined for all nodes in the signal catalog tree. In this case, each node may have different permission values. Alternatively, or in combination, sets of permission values ​​may be used to control access to different sets of nodes in the signal catalog tree. For example, the following permission values ​​may be predefined and used:

[0045] “READ_ACCESS”: This can be assigned to read-permitted elements of a node where access to retrieve information is not restricted (e.g., vehicle speed).

[0046] “PERSONAL_INFO”: This can be assigned to a read permission element of a node where access to retrieve information is restricted to a selected group of applications (e.g., a signal representing personal information such as driver identification, owner name, vehicle identification number (VIN), insurance information, etc.). “READ_ACCESS” and “PERSONAL_INFO” are two permission values ​​with different restriction / security levels that can be assigned to a read permission element.

[0047] “WRITE_ACCESS”: This is assigned to the write permission element of a node where write access is restricted (e.g., signals related to vehicle operation such as acceleration, braking, steering, and cruise control). “WRITE_ACCESS” is the permission value that can be assigned to the write permission element.

[0048] When there are numerous vehicle signals or nodes defined within a catalog, and each signal / node requires a permission element to be defined, this can be time-consuming and prone to errors. In some cases, inheritance can be used to leverage the tree structure of the VSS. This approach simplifies the assignment of permissions to numerous nodes. In this approach, permission values ​​defined for a branch node also apply to all of the branch node's subnodes unless different permission values ​​are defined for some of the subnodes. In this embodiment, it is not necessary to specify permission values ​​for each node in the signal catalog; instead, permission values ​​can be automatically assigned to nodes via inheritance. This provides a efficient mechanism for vehicle manufacturers to define who can obtain access to vehicle signals represented as nodes in the signal catalog.

[0049] In one implementation of the inheritance approach, write permission is propagated only to subnodes that are data entry nodes with actuator signal types, and to subnodes that are branch nodes themselves.

[0050] In some cases, a permission map, as described below, can be used to define permission for vehicle signals. The permission map may contain permission values ​​for one or more nodes in the signal catalog, and the permission elements for the remaining nodes may be set based on the inheritance approach already discussed. Software tools may be implemented to walk through the signal catalog tree, add permission elements to each node, and set their values ​​according to the permission map.

[0051] Alternatively or additionally, the signal catalog may include default permission values ​​for each node. Defaults may be overridden by the vehicle manufacturer, the vehicle's operational administrator, the vehicle owner, the vehicle driver, or any combination thereof.

[0052] Signal catalogs can be implemented using YAML (yet another markup language), JSON (JavaScript Object Notation), or any other format.

[0053] The following are some examples of setting vehicle signal permissions using permission maps by using JSON. In one example, the “READ_ACCESS” permission value is assigned to the “Vehicle.Speed” data entry node in the signal catalog. [ka]

[0054] The “x-read-permission” entry specifies that its subentries are applicable to read permission elements (matching “x-read-permission”) for each node in the signal catalog specified under the “nodes” subentry.

[0055] The “permission” entry defines the permission value that should be assigned. The “nodes” entry in the permission map defines the nodes to which the permission value will be assigned. The “nodes” entry can be a list of multiple nodes, as more than one signal catalog node may be given the same permission.

[0056] The permission map above results in "READ_ACCESS" being assigned to the "x-read-permission" element of the "Vehicle.Speed" data entry node (located under the "Vehicle" branch node in the signal catalog). The following are the elements of the Vehicle.Speed ​​node in the signal catalog. [ka]

[0057] Assuming Vehicle.Speed ​​is a data entry node of type "sensor", please note that the "x-write-permission" element is not present in its definition.

[0058] In another example, the “WRITE_ACCESS” permission value is assigned to the “Vehicle.ADAS.CruiseControl.IsEnabled” data entry node in the signal catalog. For simplicity, only the data entry node is shown in the example. [ka]

[0059] The type of the data entry node “Vehicle.ADAS.CruiseControl.IsEnabled” is “actuator”, and therefore, the permission element “x-write-permission” with the permission value “WRITE_ACCESS” can be assigned to this node. The node can also have the permission element “x-read-permission” with the permission value “READ_ACCESS”, which can be inherited from a branch node above this data entry node (for example, the branch node Vehicle, Vehicle.ADAS, or Vehicle.ADAS.CruiseControl, etc.). The following are the elements of the node Vehicle.ADAS.CruiseControl.IsEnabled. [ka]

[0060] In another example, the "READ_ACCESS" permission value assigned to a branch node is further inherited by several subnodes of that branch node.

[0061] In a permission map, this can be structured as follows: [ka] [ka]

[0062] In the permissions map, the “READ_ACCESS” read permission and the “WRITE_ACCESS” write permission are assigned to the “Vehicle” branch node. Subnodes under the “Vehicle” branch node (including all branch nodes and data entry nodes) inherit the read permission unless they are assigned their own permission in the permissions map, which is the case for the “Vehicle.VehicleIdentification.VIN” data node. Vehicle.VehicleIdentification.VIN is assigned its own permission, the “PERSONAL_INFO” read permission.

[0063] Subnodes under the branch node "Vehicle," which includes all branch nodes and data entry nodes with the "Actuator" data type, also inherit write permissions unless they are assigned their own permissions in the permissions map. In other words, since the permissions map does not specify any values ​​for the write permission element for nodes under the branch node "Vehicle," all sub-branch nodes and data entry nodes under the branch node "Vehicle" with the "Actuator" data type inherit "WRITE_ACCESS" from the branch node "Vehicle." Since the permissions map does not specify any values ​​for the read permission element for nodes under the branch node "Vehicle," except for "Vehicle.VehicleIdentification.VIN," all nodes under the branch node "Vehicle" inherit "READ_ACCESS" from the branch node "Vehicle," except for "Vehicle.VehicleIdentification.VIN."

[0064] In another example, for simplification, the following nodes are shown.

[0065] The “Vehicle” branch node is at the top of the tree.

[0066] The “Vehicle.RoofLoad” data entry node is located directly under the “Vehicle” branch.

[0067] The “Vehicle.VehicleIdentification” branch node is located under the “Vehicle” branch.

[0068] The “Vehicle.VehicleIdentification.Model” data entry node is located under the “Vehicle.VehicleIdentification” branch.

[0069] The “Vehicle.VehicleIdentification.VIN” data entry node is located under the “Vehicle.VehicleIdentification” branch. [ka] [ka]

[0070] The "Vehicle" branch node at the top of the tree is assigned "READ_ACCESS" read permission and "WRITE_ACCESS" write permission. Therefore, all subnodes under the "Vehicle" branch node have "READ_ACCESS" permission unless some nodes are assigned read permission for themselves within the permission map (e.g., "PERSONAL_INFO"). All subnodes under the "Vehicle" branch node have "WRITE_ACCESS" permission, except for data entry nodes with "Sensor" or "Attribute" data types.

[0071] The "Vehicle.RoofLoad" data entry node directly under the "Vehicle" branch inherits the "READ_ACCESS" read permission from the "Vehicle" branch node above it, because it is not assigned read permission in its own permission map. It does not have write permission because it is neither a branch node nor an "actuator" data entry node.

[0072] The “Vehicle.VehicleIdentification” branch node under the “Vehicle” branch is not assigned either read or write permissions in the permissions map. Because it is under the “Vehicle” branch node, it inherits both read and write permissions. Therefore, it is assigned “READ_ACCESS” read permission and “WRITE_ACCESS” write permission.

[0073] Note that branch nodes cannot be written to, so write permissions are assigned solely for inheritance purposes.

[0074] The “Vehicle.VehicleIdentification.Model” data entry node cannot be assigned its own permissions within the permissions map. Therefore, it inherits the “READ_ACCESS” permission from the “Vehicle.VehicleIdentification” branch node. Since it is not an “actuator” type data entry node, it does not have write permissions. In this implementation, the vehicle model is not considered personal information.

[0075] In this implementation, the “Vehicle.VehicleIdentification.VIN” data entry node is not considered personal information. For this reason, it is assigned the “PERSONAL_INFO” read permission in the permission map. Therefore, it does not inherit the “READ_ACCESS” permission from the “Vehicle.VehicleIdentification” branch node. Since it is not an “actuator” type data entry node, it does not have a write permission.

[0076] In some implementations, under 204, the vehicle determines whether to accept an access request by comparing the permission value of the signal / node's permission element with the permission value of the application requesting the signal / node. For example, an application might be assigned the permission value "READ_ACCESS". In this case, the vehicle may decide that the application is allowed to retrieve any signal / node whose read permission element is set to "READ_ACCESS". However, if the permission value of the signal / node's read permission element is set to "PERSONAL_INFO" (e.g., "Vehicle.VehicleIdentification.VIN") and the application's permission value is set to "READ_ACCESS", which does not match the permission value of the signal / node's read permission element, in this case the vehicle may reject the request from the application. For example, if an application has only the "READ_ACCESS" permission and requests to read the "Vehicle.VehicleIdentification" branch node, the application may only receive the value of the "Vehicle.VehicleIdentification.Model" signal. If an application has both "READ_ACCESS" and "PERSONAL_INFO" permissions and requests to read the "Vehicle.VehicleIdentification" branch node, the application may receive values ​​for both the "Vehicle.VehicleIdentification.Model" signal and the "Vehicle.VehicleIdentification.VIN" signal.

[0077] In some cases, the vehicle may generate a notification after deciding in 202 whether to accept the access request. The vehicle may output the notification as part of the vehicle's user interface, send the notification to a server or a different device (e.g., an application running on the owner's device), or a combination of these. The notification may indicate whether there is an unauthorized attempt to access a vehicle signal / node. The notification may include information about the application sending the request, the requested signal / node, the permission value for the signal / node, the permission value for the application, and any combination thereof. In some cases, the vehicle may further trigger an audio or visual alarm indicating unauthorized access. In some cases, the different combinations of responses already discussed may be configured for different attempts at unauthorized access to different signals / nodes. Alternatively, or in combination, the different combinations of responses already discussed may be configured for different numbers of attempts at unauthorized access to the same signal / node.

[0078] In some cases, different sets of permission values ​​may be used. For example, a hierarchical permission value structure may be used. In such an example, different permission values ​​may represent different permission levels, and a request may be granted if the permission level of the requested party is higher than that of the signal / node. For example, an application requesting a signal / node may have a permission value for write permission as class 5. This may indicate that the application is allowed to write to signals / nodes whose write permission value is between class 1 and class 5, but not to signals / nodes whose write permission value is set to a class higher than class 5. This approach provides flexibility in protecting access to vehicle signals / nodes with varying degrees of security sensitivity.

[0079] In one implementation, when an application connects to a vehicle or logs into the vehicle at the start of a session, the application may, as part of the login process, provide its permission values ​​(or identifiers of those permission values) for read and write permissions to vehicle signals. The vehicle may store the application's permission values. Subsequently, when the application requests access to a signal / node, the application may not include the permission values ​​in the request for access, unless the session has expired. Alternatively, or in combination, the requested party's permission values ​​(or identifiers of those permission values) may be included in the request for access to each signal / node. In some cases, the vehicle may also query its permission values ​​for the requested portion of signal access. The query may be sent after receiving the request or after the vehicle has determined that previously stored permission values ​​have expired.

[0080] In some cases, authorization values ​​may be assigned to an application by the vehicle manufacturer, the vehicle's operational administrator, the vehicle owner, the vehicle driver, or any combination thereof (for example, by using an authorization server or application). Authorization values ​​may be transmitted directly within the vehicle's user interface or through a server (e.g., server 130 in Figure 1). The identifier of the authorization value may be further encrypted, signed, or both. The encrypted or signed identifier may be transmitted to the vehicle. This provides additional security and allows the vehicle to verify the authenticity of the authorization value.

[0081] In some cases, once the vehicle has decided whether to accept the request, it may send a response to the requested party. If the request is accepted, the response may indicate that the request has been accepted. In some cases, the response may further include the values ​​of the requested signal / node (for example, in a request for read permission). The values ​​of branch nodes may include the values ​​of all nodes below the branch node. If the request is rejected, the response may indicate that the request has been rejected and the reason for the rejection.

[0082] Figure 5 is a flowchart illustrating an exemplary method 500 for configuring authorization for a vehicle signal or a node in a signal catalog, as implemented. Method 500 may be performed by a vehicle manufacturer or a computing device (e.g., a server) associated with an original equipment manufacturer (OEM). The manufacturer or OEM may create an authorization map and use the authorization map to populate authorization values ​​for each node in the signal catalog. Method 500 may also be performed by entities shown in Figure 1 (e.g., including vehicle 120 or server 130). Method 500 shown in Figure 5 may also be performed using additional entities, fewer entities, or different entities. Furthermore, Method 500 shown in Figure 5 may be performed using additional actions, fewer actions, or different actions, which may be performed in the order shown or different orders. In some cases, an action or group of actions may be repeated or iterated, for example, for a specified number of iterations, or until a termination condition is reached.

[0083] In 502, the authorization map is received. As previously discussed, the authorization map may contain configured authorization values ​​for the authorization elements of nodes in the vehicle signal catalog. As previously discussed, the authorization elements may be read authorization elements, write authorization elements, or both. The configured authorization values ​​may be predefined and may represent "READ_ACCESS", "PERSONAL_INFO", "WRITE_ACCESS", or other values.

[0084] In 504, the permit value of the permit element of a node in the vehicle signal catalog is set according to the configured permit value in the permit map. As already discussed, in some operations, an inheritance approach may be used, and the configured permit value may be used to set the permit value of the permit element of a subnode. Also, as already discussed, default values ​​may be used and overridden by the permit map.

[0085] Figure 6 is a block diagram 600 illustrating an authorization configuration for nodes in a vehicle signal or signal catalog, according to the implementation. As discussed above, a signal catalog and authorization map 604 without authorization values ​​for each node 602 can be input to a tool 606 that generates a signal catalog with authorization values ​​for each node 608. Tool 606 may be a software or hardware tool on a computing device or server associated with the vehicle manufacturer or OEM. Tool 606 may also be located in the vehicle.

[0086] Figure 3 is a high-level architectural block diagram showing a computer 302 coupled with network 350, according to an implementation. The examples described are only one possible implementation of the subject matter described and are not intended to limit the disclosure to a single described implementation. Those skilled in the art will understand that the described components may be connected, combined, or used in alternative embodiments consistent with the disclosure.

[0087] Network 350 facilitates communication between computer 302 and other devices. In some cases, a user (e.g., an administrator) may access computer 302 from a remote network. In these and other cases, network 350 may be a wireless network or a wireline network. In some cases, a user may access computer 302 locally. In these and other cases, network 350 may also be a memory pipe, a hardware connection, or any internal or external communication path between components.

[0088] Computer 302 includes a computing system configured to perform the algorithms described in this disclosure. For example, computer 302 may be used to implement the server 130 shown in Figure 1. Computer 302 may be used to implement an electronic device (e.g., a laptop computer or smartphone) that runs the application 122 shown in Figure 1. Computer 302 may also be used to implement the authorization control module 112 shown in Figure 1. In some cases, the algorithms may be implemented in executable computing code (e.g., C / C++ executable code). Alternatively, or in combination, the algorithms may be implemented in an application program (e.g., Excel). In some cases, computer 302 may include a standalone LINUX® system that runs a batch application. In some cases, computer 302 may include a mobile computer or personal computer that runs an application program.

[0089] Computer 302 may include input devices (e.g., a keypad, keyboard, touchscreen, microphone, speech recognition device, or another device capable of receiving user information) and / or output devices (carrying digital data, visual and / or audio information, or information associated with the operation of Computer 302, including a GUI).

[0090] Computer 302 can function as a client, network component, server, database, or other persistence, etc. In some cases, one or more components of computer 302 may be configured to operate within a cloud computing-based environment.

[0091] At a high level, computer 302 is an electronic computing device capable of receiving, transmitting, processing, storing, or managing data and information. In some implementations, computer 302 may also include, or be coupled to, application servers, email servers, web servers, caching servers, streaming data servers, business intelligence (BI) servers, and / or other servers.

[0092] Computer 302 may respond to received requests by receiving them from client applications (e.g., running on a user device) via the network 350 and processing those requests in appropriate software applications. In addition, requests may also be sent to computer 302 from internal users (e.g., from a command console or by other appropriate access methods), external or third-party, other automated applications, and any other appropriate entities, individuals, systems, or computers.

[0093] Each component of computer 302 may communicate using the system bus 303. In some implementations, any and / or all components of computer 302 (both hardware and / or software) may interface with each other and / or with interface 304 via the system bus 303 using an application programming interface (API) 312 and / or a service layer 313. API 312 may include specifications for routines, data structures, and object classes. API 312 may be either computer language independent or computer language dependent and may refer to a complete interface, a single function, or even a set of APIs. The service layer 313 provides software services to computer 302. The functionality of computer 302 may be accessible to all service consumers using this service layer. For example, software services provided by service layer 313 provide reusable, defined business functionality through defined interfaces. For example, the interface may be software written in Java®, C++, or other suitable language that provides data in Extensible Markup Language (XML) format or other suitable format. Although exemplified as an integrated component of computer 302, alternative implementations may exemplify API 312 and / or service layer 313 as standalone components in relation to other components of computer 302. Furthermore, any or all parts of API 312 and / or service layer 313 may be implemented as child modules or submodules of other software modules or hardware modules without departing from the scope of this disclosure.

[0094] Computer 302 includes interface 304. While illustrated as a single interface 304 in Figure 3, two or more interfaces 304 may be used according to the specific needs, configuration, or implementation of computer 302. Interface 304 is used by computer 302 (whether illustrated or not) for communication with other systems in a distributed environment connected to network 350. Generally, interface 304 includes logic that is encoded in software and / or hardware in an appropriate combination and capable of operating to communicate with network 350. More specifically, interface 304 may include software supporting one or more communication protocols associated with the communication, and as a result, network 350 or the interface hardware may be capable of operating to communicate physical signals.

[0095] The computer 302 includes a processor 305. While Figure 3 illustrates a single processor 305, two or more processors may be used depending on the specific needs, configuration, or implementation of the computer 302. Generally, the processor 305 executes instructions and manipulates data to perform the operations of the computer 302. In some cases, the processor 305 may include data processing units.

[0096] Computer 302 also includes memory 306 for holding data for computer 302. Although illustrated as a single memory 306 in Figure 3, two or more memories may be used depending on the specific needs, configuration, or implementation of computer 302. Although memory 306 is illustrated as an integrated component of computer 302, in alternative implementations, memory 306 may be located outside of computer 302.

[0097] Application 307 includes an algorithmic software engine that provides functionality according to the specific needs, configuration, or implementation of computer 302. Although illustrated as a single application 307, application 307 may be implemented as multiple applications on computer 302. In addition, although illustrated as integrated with computer 302, in alternative implementations, application 307 may be external to computer 302.

[0098] Any number of computers 302 may exist that are associated with or outside of system 300 and communicate with network 350. Furthermore, the terms “client,” “user,” and other appropriate terms may be used synonymously as needed without departing from the scope of this disclosure. In addition, this disclosure is intended to show that many users may use one computer 302, or that one user may use multiple computers 302.

[0099] The implementations described in the subject may include one or more features, either individually or in combination.

[0100] For example, in a first implementation, the method includes receiving a permission map, the permission map containing configured permission values ​​for permission elements of nodes in a vehicle signal catalog, and setting permission values ​​for permission elements of nodes in a vehicle signal catalog according to the configured permission values ​​in the permission map.

[0101] Each of the above implementations and other implementations described may optionally include one or more of the following features:

[0102] The first feature is that it can be combined with any of the following features, and the vehicle signal catalog is based on the Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA).

[0103] The second feature is that it can be combined with any of the above features and the following features, and the permission element is either a read permission element or a write permission element.

[0104] The third feature can be combined with any of the above and below features, and the permitted values ​​are from a predefined set of permitted values.

[0105] The fourth feature can be combined with any of the above and below features, and the permission value indicates that read access to the node's signal values ​​is limited to a selected group of applications that have the same permission value.

[0106] The fifth feature is combinable with any of the above and below features, wherein the node is a branch node, and the method further includes setting the permission value of the permission element of the node's subnode in the vehicle signal catalog according to the configured permission value in the permission map.

[0107] The sixth feature is combinable with any of the features of the above features, and setting the permit value of the permit element of a subnode of a node in the vehicle signal catalog includes determining whether the permit map contains the permit value of the subnode's permit element, and setting the permit value of the subnode's permit element to be the same as the configured permit value in response to determining that the permit map does not contain the permit value of the subnode's permit element.

[0108] In a second implementation, the computing device comprises at least one hardware processor and one or more computer-readable storage media coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein, when executed, the programming instructions cause the computing device to perform an operation comprising receiving a permission map, the permission map containing configured permission values ​​for permission elements of nodes in a vehicle signal catalog, and setting the permission values ​​for permission elements of nodes in the vehicle signal catalog according to the configured permission values ​​in the permission map.

[0109] Each of the above implementations and other implementations described may optionally include one or more of the following features:

[0110] The first feature is that it can be combined with any of the following features, and the vehicle signal catalog is based on the Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA).

[0111] The second feature is that it can be combined with any of the above features and the following features, and the permission element is either a read permission element or a write permission element.

[0112] The third feature can be combined with any of the above and below features, and the permitted values ​​are from a predefined set of permitted values.

[0113] The fourth feature can be combined with any of the above and below features, and the permission value indicates that read access to the node's signal values ​​is limited to a selected group of applications that have the same permission value.

[0114] The fifth feature is combinable with any of the above and below features, wherein the node is a branch node, and the operation further includes setting the permission values ​​of the permission elements of the node's subnodes in the vehicle signal catalog according to the configured permission values ​​in the permission map.

[0115] The sixth feature is combinable with any of the features of the above features, and setting the permit value of the permit element of a subnode of a node in the vehicle signal catalog includes determining whether the permit map contains the permit value of the subnode's permit element, and setting the permit value of the subnode's permit element to be the same as the configured permit value in response to determining that the permit map does not contain the permit value of the subnode's permit element.

[0116] In a third implementation, a computer-readable medium stores instructions, and when executed, the instructions cause a computing device to perform an operation which includes receiving an authorization map, the authorization map containing configured authorization values ​​for nodes in a vehicle signal catalog, and setting the authorization values ​​for the authorization elements of the nodes in the vehicle signal catalog according to the configured authorization values ​​in the authorization map.

[0117] Each of the above implementations and other implementations described may optionally include one or more of the following features:

[0118] The first feature is that it can be combined with any of the following features, and the vehicle signal catalog is based on the Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA).

[0119] The second feature is that it can be combined with any of the above features and the following features, and the permission element is either a read permission element or a write permission element.

[0120] The third feature can be combined with any of the above and below features, and the permitted values ​​are from a predefined set of permitted values.

[0121] The fourth feature, which can be combined with any of the above and below features, indicates that read access to the node's signal values ​​is limited to a selected group of applications that have the same permission values.

[0122] The fifth feature is combinable with any of the above and below features, wherein the node is a branch node, and the operation further includes setting the permission values ​​of the permission elements of the node's subnodes in the vehicle signal catalog according to the configured permission values ​​in the permission map.

[0123] The sixth feature is combinable with any of the above features, and setting the permit value of a permit element of a subnode of a node in a vehicle signal catalog includes determining whether the permit map contains the permit value of the subnode's permit element, and, in response to determining that the permit map does not contain the permit value of the subnode's permit element, setting the permit value of the subnode's permit element to be the same as the configured permit value.

[0124] Some of the subject matter and operations described in this disclosure may be implemented in digital electronic circuits, or in computer software, firmware, or hardware (including the structures described in this disclosure and their structural equivalents), or in one or more combinations thereof. Some of the subject matter described in this disclosure may be implemented as one or more computer programs (i.e., one or more modules of computer program instructions) encoded on a computer storage medium for execution by a data processing device or for controlling the operation of a data processing device. Alternatively or additionally, program instructions may be encoded in artificially generated propagating signals (e.g., mechanically generated electrical, optical, or electromagnetic signals generated to encode information for transmission to a suitable receiver device for execution by a data processing device). The computer storage medium may be a machine-readable storage device, a machine-readable storage board, a random-access memory device or a serial-access memory device, or any combination of computer storage mediums.

[0125] The terms “data processing device,” “computer,” or “electronic computer device” encompass all types of devices, machines, and equipment for processing data, including, for example, programmable processors, computers, systems on a chip, or more, or combinations thereof. A device may include special-purpose logic circuits, such as FPGAs (field-programmable gate arrays) or ASICs (application-specific integrated circuits). In some implementations, a data processing device or special-purpose logic circuit (or a combination of data processing devices or special-purpose logic circuits) may be hardware-based or software-based (or a combination of both). A device may optionally include code that creates an execution environment for computer programs (e.g., processor firmware, protocol stacks, database management systems, operating systems, or code that constitutes a combination of execution environments). This disclosure intends to describe the use of a data processing device with or without a conventional operating system (e.g., LINUX®, UNIX®, WINDOWS®, MAC OS®, ANDROID®, IOS, or any other suitable conventional operating system).

[0126] A computer program (which may also be referred to or described as a program, software, software application, module, software module, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may, but does not have to, correspond to a file in a file system. A program may be stored in a single file dedicated to the program in question, in part of a file that holds other programs or data (e.g., one or more scripts stored within a markup language document), in a file that holds the program in question, or in a series of interconnected files (e.g., a file that holds one or more modules, subroutines, or parts of code). A computer program may be deployed to run on a single computer located in one place, or on multiple computers distributed across multiple locations and interconnected by a communication network. While the parts of the program illustrated in various diagrams are shown as individual modules implementing various features and functionalities through various objects, methods, or other processes, the program may instead include numerous submodules, third-party services, components, libraries, etc., as needed. Conversely, the features and functionalities of various components may be combined into a single component as needed.

[0127] Some of the processes and logic flows in this disclosure may be performed by one or more programmable processors, which may execute one or more computer programs to perform actions by acting on input data and producing outputs. Processes and logic flows may also be performed by special-purpose logic circuits (e.g., FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits)), and the devices may also be implemented as special-purpose logic circuits.

[0128] Processors suitable for executing computer programs include, for example, both general-purpose microprocessors and special-purpose microprocessors, and processors of any type of digital computer. Generally, processors can receive instructions and data from read-only memory or random-access memory, or both. Processors can include, for example, programmable processors, computers, systems on a chip, or a combination of both, or any combination of the above. Processors can also include special-purpose logic circuits, such as CPUs (Central Processing Units), FPGAs (Field-Programmable Gate Arrays), or ASICs (Application-Specific Integrated Circuits).

[0129] A computer suitable for running computer programs may be based on a general-purpose microprocessor or a special-purpose microprocessor, both, or any other type of CPU. Generally, a CPU can receive instructions and data from read-only memory (ROM) or random-access memory (RAM), or both. Essential elements of a computer are a CPU for executing or running instructions, and one or more memory devices for storing instructions and data. Generally, a computer may also include one or more mass storage devices (e.g., magnetic disks, electromagnetic disks, or optical disks) for storing data, or may be operationally coupled to receive data from one or more mass storage devices, transfer data to one or more mass storage devices, or both. However, a computer is not required to have such devices. Furthermore, a computer may be embedded within another device (e.g., a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a Universal Serial Bus (USB) flash drive)).

[0130] Computer-readable media (temporary or non-temporary, as necessary) suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices (e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM, DVD+ / -R, DVD-RAM, and DVD-ROM disks. Memory may store various objects or data (e.g., caches, classes, frameworks, applications, backup data, jobs, web pages, web page templates, database tables, repositories storing dynamic information, and any other appropriate information (including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto)). In addition, memory may contain any other appropriate data (e.g., logs, policies, security, or access data, report files, and others). The processor and memory may be supplemented by or integrated into special-purpose logic circuits. In some cases, the computer storage medium may be temporary, non-temporary, or a combination of both.

[0131] To provide user interaction, implementations of the subject matter described herein may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display), LED (light-emitting diode), or plasma monitor for providing information to the user) and a keyboard and pointing device (e.g., a mouse, trackball, or trackpad by which the user can provide input to the computer). Input may also be provided to the computer using a touchscreen (e.g., a pressure-sensitive tablet computer surface, a multi-touch screen using capacitive or electrical sensing, or other types of touchscreens). Other types of devices may also be used to provide user interaction. For example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or haptic feedback), and input from the user may be received in any form (including acoustic input, speech input, or haptic input). In addition, the computer may interact with the user by sending documents to a device used by the user, for example by sending a web page to a web browser on the user's client device in response to a request received from a web browser, and by receiving documents from a device used by the user.

[0132] The term “graphical user interface” or “GUI” may be used in the singular or plural form to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. Thus, a GUI can represent any graphical user interface (including, but not limited to, a web browser, a touchscreen, or a command-line interface (CLI) that processes information and efficiently presents the results to the user). Generally, a GUI may include multiple user interface (UI) elements (some or all of which are associated with a web browser, such as interactive fields, pull-down lists, and buttons that can be operated by a business suite user). These UI elements or other UI elements may be related to or represent the functionality of a web browser.

[0133] The terms “real-time,” “real time,” “real (fast) time (RFT),” “near(ly) real-time (NRT),” “quasi real-time,” or similar terms (as understood by those skilled in the art) mean that the action and response are in temporal proximity, and as a result, the individual perceives the action and response as occurring substantially simultaneously. For example, the time difference between an individual’s action to access data and the response to the display of data (or interaction with the display) following that action may be less than 1 millisecond, less than 1 second, less than 5 seconds, etc. The requested data does not need to be displayed (or initiated to be displayed) instantaneously, but it does not need to be displayed (or initiated to be displayed) without any intentional delay, taking into account the processing limits of the described computing system, e.g., the time required to collect, accurately measure, analyze, process, store, or transmit data.

[0134] Implementations of the subject matter described herein may be implemented in a computing system including backend components (e.g., such as a data server), or a computing system including middleware components (e.g., such as an application server), or a computing system including frontend components (e.g., such as a client computer having a graphical user interface or web browser through which a user can interact with the implementation of the subject matter described herein), or in any combination of one or more such backend, middleware, or frontend components. The components of the system may be interconnected by any form or medium of wireline or wireless digital data communication (or a combination of data communication), such as a communication network. Examples of communication networks include local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), Worldwide Interoperability for Microwave Access (WiMAX), wireless local area networks (WLANs) (e.g., using 802.11 a / b / g / n or 802.20 (or a combination of 802.11x and 802.20, or other protocols consistent with this disclosure)), all or part of the Internet, or any other communication system, or a system (or combination of communication networks) at one or more locations. Networks may communicate, for example, by Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, or other appropriate information (or combination of communication types) between network addresses.

[0135] A computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship between a client and a server arises from computer programs running on each computer, and they have a client-server relationship with each other.

[0136] In some implementations, any or all components of a computing system (either hardware or software (or a combination of hardware and software)) may interface with each other or with each other using an Application Programming Interface (API) or a Service Layer (or a combination of APIs and a Service Layer). An API may include specifications for routines, data structures, and object classes. An API can be a computer language, standalone or dependent, and may refer to a complete interface, a single function, or even a set of APIs. A Service Layer provides software services to the computing system. The functionality of various components of the computing system may be accessible to all service consumers using this Service Layer. Software services provide reusable, defined business functionality through defined interfaces. For example, an interface may be software written in Java®, C++, or another suitable language that provides data in the Extended Markup Language (XML) format or another suitable format. An API or a Service Layer (or a combination of APIs and a Service Layer) may be an integrated or standalone component in relation to other components of the computing system. Furthermore, any or all parts of the service layer may be implemented as a separate software module, or as a child module or submodule of a hardware module, without departing from the scope of this disclosure.

[0137] This disclosure includes many specific implementation details, but these should not be considered as limitations on the scope of any invention or the scope of what can be claimed, but rather as descriptions of features that may be specific to a particular implementation of a particular invention. Certain features described in this disclosure in the context of separate implementations may also be implemented in combination or in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination or in multiple implementations. Furthermore, features may be described above as acting in a particular combination, and may even be claimed as such initially, but one or more features from a claimed combination may, in some cases, be removed from the combination, and the claimed combination may be directed towards a sub-combination or a variation of a sub-combination.

[0138] A specific implementation of the subject matter has been described. Other implementations, alternatives, and permutations of the described implementation are within the scope of the following claims, as can be understood by those skilled in the art. Although the operations are depicted in a particular order in the drawings and claims, this should not be understood as requiring that such operations be performed in a particular order or sequential order shown in order to achieve the desired result, or that all exemplified operations should be performed (some operations may be considered optional). In certain circumstances, multitasking or parallel processing (or a combination of multitasking and parallel processing) may be advantageous and may be performed where deemed appropriate.

[0139] Furthermore, the separation or integration of various system modules and components in the aforementioned implementations should not be understood as requiring such separation or integration in all implementations. Rather, the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0140] Therefore, the above description of exemplary implementations does not define or limit this disclosure. Other modifications, substitutions, and alternatives are also possible without departing from the spirit and scope of this disclosure.

[0141] Furthermore, any of the claimed implementations described below are considered applicable to a computer system comprising at least a computer implementation method, a non-temporary computer-readable medium storing computer-readable instructions for performing the computer implementation method, and computer memory interoperably coupled with a hardware processor configured to perform the instructions stored on the computer implementation method or the computer-readable medium.

Claims

1. A method, wherein the said method is In a vehicle, receiving an authorization map, wherein the authorization map includes authorized values ​​configured for the authorization elements of nodes in a vehicle signal catalog, the nodes representing vehicle signals, and the authorization elements of the nodes being defined in accordance with the Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance, The vehicle sets the permission value of the permission element of the vehicle signal within the vehicle in accordance with the configured permission value in the permission map, wherein the permission value is one of a set of permission values, and the set of permission values ​​includes permission values ​​corresponding to personal information relating to the read permission element. The determination that the permission map does not include permission values ​​for permission elements of the subnodes of the node, wherein the node is a branch node as defined in the VSS of the Connected Vehicle Systems Alliance, In response to determining that the permission map does not include the permission value of the permission element of the subnode, the permission value of the permission element of the subnode is set to be the same as the configured permission value of the permission element of the node. To control at least one hardware component of the vehicle by using the vehicle signal in accordance with the permit value of the permit element of the vehicle signal. Methods that include...

2. The method according to claim 1, wherein the authorization element is a read authorization element or a write authorization element.

3. The method according to claim 1, wherein the permitted value is from a predefined set of permitted values.

4. The method according to claim 1, wherein the permission value indicates that read access to the signal value of the node is limited to a selected group of applications having the same permission value.

5. A computing device, wherein the computing device is At least one hardware processor, One or more computer-readable storage media coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein, when the programming instructions are executed, the computing device In a vehicle, receiving an authorization map, wherein the authorization map includes authorized values ​​configured for the authorization elements of nodes in a vehicle signal catalog, the nodes representing vehicle signals, and the authorization elements of the nodes being defined in accordance with the Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance, The vehicle sets the permission value of the permission element of the vehicle signal within the vehicle in accordance with the configured permission value in the permission map, wherein the permission value is one of a set of permission values, and the set of permission values ​​includes permission values ​​corresponding to personal information relating to the read permission element. The determination that the permission map does not include permission values ​​for permission elements of the subnodes of the node, wherein the node is a branch node as defined in the VSS of the Connected Vehicle Systems Alliance, In response to determining that the permission map does not include the permission value of the permission element of the subnode, the permission value of the permission element of the subnode is set to be the same as the configured permission value of the permission element of the node. To control at least one hardware component of the vehicle by using the vehicle signal in accordance with the permit value of the permit element of the vehicle signal. One or more computer-readable storage media that perform operations including A computing device equipped with [a certain feature].

6. The computing device according to claim 5, wherein the authorization element is a read authorization element or a write authorization element.

7. The computing device according to claim 5, wherein the permitted values ​​are from a predefined set of permitted values.

8. The computing device according to claim 5, wherein the permission value indicates that read access to the signal value of the node is limited to a selected group of applications having the same permission value.

9. A non-temporary computer-readable medium, the non-temporary computer-readable medium storing instructions, the instructions, when executed, to a computing device, In a vehicle, receiving an authorization map, wherein the authorization map includes authorized values ​​configured for the authorization elements of nodes in a vehicle signal catalog, the nodes representing vehicle signals, and the authorization elements of the nodes being defined in accordance with the Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance, The vehicle sets the permission value of the permission element of the vehicle signal within the vehicle in accordance with the configured permission value in the permission map, wherein the permission value is one of a set of permission values, and the set of permission values ​​includes permission values ​​corresponding to personal information relating to the read permission element. The determination that the permission map does not include permission values ​​for permission elements of the subnodes of the node, wherein the node is a branch node as defined in the VSS of the Connected Vehicle Systems Alliance, In response to determining that the permission map does not include the permission value of the permission element of the subnode, the permission value of the permission element of the subnode is set to be the same as the configured permission value of the permission element of the node. To control at least one hardware component of the vehicle by using the vehicle signal in accordance with the permit value of the permit element of the vehicle signal. A non-temporary, computer-readable medium that enables the execution of operations including [specific actions].

10. The computer-readable medium according to claim 9, wherein the authorization element is a read authorization element or a write authorization element.

11. The computer-readable medium according to claim 9, wherein the permitted value is from a predefined set of permitted values.

12. The computer-readable medium according to claim 9, wherein the permission value indicates that read access to the signal value of the node is limited to a selected group of applications having the same permission value.

Images