Controlling permissions of vehicle signals

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 admission of vehicle signals. [Background technology]

[0002] A vehicle may contain numerous sensors that emit or generate signals that constantly report state changes in what they are monitoring. These signals may be used to determine the state of different aspects of the vehicle. The 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 problem]

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

[0004] In some operations, a non-native application (e.g., an application running on an external device or a third-party application installed on the vehicle) requires 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 proper permissions to access these signals.

[0005] In some implementations, reading and writing of vehicle signals may be set by using different permission values. In some cases, the permission values ​​of vehicle signals may be set based on nodes of a tree structure of a signal catalog defined using VSS. Software or hardware in the vehicle may compare the permission values ​​of the vehicle signal or node in the signal catalog with the permission values ​​of the entity requesting access (e.g., a non-native application, as already discussed) and determine whether to grant access. The approaches described in this disclosure provide an efficient way to control access to vehicle signals, prevent security breaches, and protect 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) 1. A method, comprising: receiving a permission map, the permission map including configured permission values ​​for permission elements of nodes in a vehicle signal catalog; 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; A method comprising: (Item 2) The method according to the above item, wherein the vehicle signal catalog is based on the Vehicle Signal Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA). (Item 3) 13. The method of claim 1, wherein the authorization element is a read authorization element or a write authorization element. (Item 4) 13. The method of claim 1, wherein the permission value is from a set of predefined permission values. (Item 5) 13. The method of claim 1, wherein the permission value indicates that read access to the node's signal value is limited to a select group of applications that have the same permission value. (Item 6) 2. The method of claim 1, wherein the node is a branch node, and the method further comprises setting permission values ​​of the permission elements of subnodes of the node in the vehicle signal catalogue according to the configured permission values ​​in the permission map. (Item 7) Setting permission values ​​for the permission elements of subnodes of the node in the vehicle signal catalogue includes: determining whether the permission map includes a permission value for the permission element of the subnode; in response to determining that the permission map does not include a permission value for the permission element of the subnode, setting the permission value for the permission element of the subnode to be the same as the configured permission value; The method according to any one of the above items, comprising: (Item 8) 1. A computing device, comprising: 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, the programming instructions, when executed, causing the computing device to: receiving a permission map, the permission map including configured permission values ​​for permission elements of nodes in a vehicle signal catalog; 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; one or more computer readable storage media for performing operations including A computing device comprising: (Item 9) The computing device of any one of the preceding claims, wherein the vehicle signal catalog is based on the Vehicle Signal Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA). (Item 10) 2. The computing device of claim 1, wherein the authorization element is a read authorization element or a write authorization element. (Item 11) 2. The computing device of claim 1, wherein the permission value is from a set of predefined permission values. (Item 12) 2. A computing device as described in any one of the preceding items, 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. (Item 13) The computing device of any one of the preceding claims, wherein the node is a branch node, and the operation further includes setting a permission value of the permission element of a subnode of the node in the vehicle signal catalogue in accordance with the configured permission value in the permission map. (Item 14) Setting permission values ​​for the permission elements of subnodes of the node in the vehicle signal catalogue includes: determining whether the permission map includes a permission value for the permission element of the subnode; in response to determining that the permission map does not include a permission value for the permission element of the subnode, setting the permission value for the permission element of the subnode to be the same as the configured permission value; 2. A computing device according to any one of the preceding claims, comprising: (Item 15) A computer-readable medium having instructions stored thereon that, when executed, cause a computing device to: receiving a permission map, the permission map including configured permission values ​​for permission elements of nodes in a vehicle signal catalog; 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; A computer-readable medium for causing a computer to perform operations including: (Item 16) The computer-readable medium of any one of the preceding claims, wherein the vehicle signal catalog is based on the Vehicle Signal Specification (VSS) of the Connected Vehicle Systems Alliance (COVESA). (Item 17) 2. The computer-readable medium of claim 1, wherein the authorization element is a read authorization element or a write authorization element. (Item 18) 20. The computer-readable medium of claim 19, wherein the permission value is from a set of predefined permission values. (Item 19) 2. The computer-readable medium of claim 1, wherein the permission value indicates that read access to the node's signal value is limited to a select group of applications that have the same permission value. (Item 20) The computer-readable medium of any one of the preceding items, wherein the node is a branch node, and the operation further includes setting a permission value of the permission element of a subnode of the node in the vehicle signal catalogue according to the configured permission value in the permission map. (Summary) Systems, methods, and software are used to control permissions for vehicle signals. In some aspects, one exemplary method includes receiving a permission map, the permission map including configured permission values ​​for permission elements of nodes in a vehicle signal catalog, and setting the permission values ​​for 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] [Figure 1] FIG. 1 is a schematic diagram illustrating an example communication system for controlling admission of vehicle signals according to an implementation.

[0007] [Diagram 2] FIG. 2 is a flow diagram illustrating an example method for controlling authorization of a vehicle signal, according to an implementation.

[0008] [Diagram 3] FIG. 3 is a high-level architectural block diagram of a computing system according to an implementation.

[0009] [Figure 4] FIG. 4 is a diagram illustrating an example structure of a vehicle signal, according to an implementation.

[0010] [Diagram 5] FIG. 5 is a flow diagram illustrating an example method for configuring vehicle signal permissions according to an implementation.

[0011] [Figure 6] FIG. 6 is a block diagram illustrating an authorization configuration for a vehicle signal, according to an implementation.

[0012] Like reference numbers and designations in the various drawings refer to like elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0014] The vehicle 120 may include motor vehicles (e.g., automobiles, 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.), rail vehicles (e.g., trains, trams, etc.), and other types of vehicles, including any combination of any of the above, whether existing or future. In the illustrated example, the vehicle 120 includes one or more sensors 102, a vehicle component controller 104, a vehicle systems processor 106, a communication subsystem 116, a user interface 118, a memory 114, and an admission control module 112 connected to a bus 110.

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

[0016] The vehicle 120 includes one or more sensors 102 that detect or measure information for the vehicle 120. Examples of sensors 102 may include sensors that capture environmental information outside the vehicle 120 (e.g., cameras, microphones, lasers, radar, ultrasonic, light detection and ranging (LIDAR), etc.). These sensors may provide environmental input to an automated processing platform operating on the vehicle 120 to make automated decisions. Examples of sensors 102 may also include devices that capture information inside the vehicle 120 (e.g., monitors for components of the engine, battery, fuel, electronics system, cooling system, etc.). These sensors may provide operational status and alerts to an automated processing platform operating on the vehicle 120. Examples of sensors 102 may also include acoustic sensors that may detect sound levels inside the vehicle 120. The acoustic sensors may determine the noise level inside the vehicle 120 or provide input to other signal processors that determine the noise level.

[0017] The vehicle 120 includes a vehicle component controller 104. Although illustrated as a vehicle component controller 104 in FIG. 1, the vehicle 120 may include more than one vehicle component controller 104. The vehicle component controller 104 represents a controller that controls the operation of components on the 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 the vehicle 120. For example, the vehicle component controller 104 may control the speaker system of the vehicle 120 (including controlling the volume, balance, fade, and any other settings for the audio output inside the vehicle 120). The 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, the vehicle component controller 104 may include a data processing device.

[0018] The vehicle systems processor 106 may include one or more processing components (alternatively referred to as a "processor" or "central processing unit (CPU)") configured to execute instructions related to one or more processes, steps, or actions for an autonomous processing platform operating on the vehicle 120. Generally, the vehicle systems processor 106 executes instructions and manipulates data to perform operations of the autonomous processing platform. The vehicle systems processor 106 may receive inputs from the sensors 102 and generate commands for the vehicle component controllers 104. In some cases, the vehicle systems processor 106 may perform autonomous operations. In some cases, the vehicle systems processor 106 may include a data processing device.

[0019] The communication subsystem 116 may be configured to provide wireless or wireline communication for data or control information of the vehicle 120. For example, the communication subsystem 116 may support transmissions over a wireless local area network (WLAN or WiFi), near field wireless 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), Evolved 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 communications subsystem 116 may support multiple-input multiple-output (MIMO) transmission. In some implementations, the receiver in the communications subsystem 116 may be an advanced receiver or a baseline receiver.

[0020] The user interface 118 may include, for example, any of one or more displays or touch screen displays (e.g., a liquid crystal display (LCD), light emitting diode (LED), organic light emitting diode (OLED), or microelectromechanical system (MEMS) display), a keyboard or keypad, a trackball, a speaker, or a microphone. The user interface 118 may also include an I / O interface, for example, a universal serial bus (USB) interface.

[0021] The memory 114 may be a computer-readable storage medium. Examples of the memory 114 include volatile and non-volatile memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, and the like. The memory 114 may store an 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 may be configured to control access permissions for vehicle signals of the vehicle 120. In some implementations, the authorization control module 112 may receive a request for a vehicle signal, for example from an application 122. The request may be for a read, a write, or both. The authorization control module 112 determines whether to grant the request based on the authorization factors of the requested vehicle signal. In some cases, the authorization control module 112 determines whether to grant the request further based on the authorization factors of the entity requesting the vehicle signal. FIG. 2 and its associated description provide additional details of these implementations. In some implementations, the authorization control module 112 may be implemented as a separate software program or part of a software program stored in the memory 114 and executed by the vehicle system processor 106.

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

[0024] The application 122 represents an application, a set of applications, software, a software module, hardware, or any combination thereof that requests a vehicle signal. In some cases, the application may run on an electronic device that interfaces with the vehicle 120. Such an electronic device may include, but is not limited to, an endpoint, a computing device, a mobile device, a mobile electronic device, a user device, a mobile station, a subscriber station, a portable electronic device, a mobile communication device, a wireless modem, a wireless terminal, or another electronic device. Examples of endpoints may include mobile devices, Internet of Things (IoT) devices, Enterprise of Things (EoT) 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. The electronic device may also include a peripheral device (e.g., a headset, a remote controller, or a display, etc.). The electronic device may interface with the vehicle 120 using short-range communication technology. The short-range communication technology may be wireless (e.g. BT, NFC, WLAN, etc.) The short-range communication technology may 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 operation of vehicle 120.

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

[0027] The exemplary communication system 100 includes a network 140. The network 140 represents an application, a set of applications, software, software modules, hardware, or a combination thereof that may be configured to transmit data between the server 130 and the vehicle 120 in the communication system 100. The network 140 includes a wireless network, a wireline network, or a combination thereof. For example, the network 140 may include one or more Radio Access Networks (RANs), a Core Network (CN), and an external network. The RAN may include one or more radio access technologies. In some implementations, the radio access technology may be Global System 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] The RAN is part of a wireless telecommunications system that implements a radio access technology (e.g., UMTS, CDMA2000, 3GPP LTE, 3GPP LTE-A, and 5G). In many applications, the RAN includes at least one base station. A base station may be a radio base station that may control all or at least some radio-related functions in the fixed portion of the system. A base station may provide an air interface within its coverage area or cell for mobile devices to communicate. Base stations may be distributed throughout a cellular network to provide wide area coverage. A base station communicates directly to one or more mobile devices, other base stations, and one or more core network nodes.

[0029] 1 are shown as including various component parts, portions, or modules that implement various features and functionality, these elements may instead include multiple sub-modules, third party services, components, libraries, etc., as desired. Additionally, the features and functionality of various components may be combined into fewer components, as desired.

[0030] FIG. 2 is a flow diagram illustrating an example method 200 for controlling admission of a vehicle signal or a node in a signal catalog, according to an implementation. Method 200 may be performed by the entities illustrated in FIG. 1, including, for example, vehicle 120. Method 200 illustrated in FIG. 2 may also be performed using additional entities, fewer entities, or different entities. Additionally, method 200 illustrated in FIG. 2 may be implemented using additional, fewer, or different operations that may be performed in the order shown or in a different order. In some cases, an operation or group of operations may be repeated or iterated, for example, for a specified number of iterations or until a termination condition is reached.

[0031] At 202, the vehicle receives a request to access a vehicle signal or a node in the signal catalog. As discussed below, the node in the signal catalog may be a data entry node or a branch node. In some cases, the request may be received from an application (e.g., application 122 in FIG. 1). The application may run on an electronic device external to the vehicle and the request may be transmitted by using a wireless or wireline connection (e.g., Bluetooth, NFC, WiFi, LTE, 5G, USB or any other local or wide area network communication technology). The application may also run on the vehicle (e.g., a third party application that may be installed on the vehicle's operating system).

[0032] Vehicle signals refer to 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, information related to cabin operations (e.g., air conditioning (AC) settings, seat position, etc.), and any other information related to the operation of the vehicle.

[0033] In some cases, the Vehicle Signal Specification (VSS) developed by the Connected Vehicle Systems Alliance (COVESA) may be used to provide a common format / structure for vehicle signals. The VSS introduces a domain taxonomy for vehicle signals that may be used as a standard in automotive applications to communicate information about the vehicle. The VSS defines vehicle signals in a tree-like structure in the classical attribute, sensor, and actuator sense, with raw data communicated over the vehicle bus as well as data more commonly associated with infotainment systems. COVESA defines a catalog of signals. More generally, the catalog of signals may be referred to as a "signal catalog." The signal catalog is organized into a tree structure, with data entry nodes being leaf nodes and branch nodes regrouping sets of data entry nodes and sub-branches. Each data entry node defines a particular vehicle signal, for example, using 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 is an example of a signal structure / format defined for vehicle signals according to the COVESA VSS. [Table 1]

[0035] 4 is a diagram 400 illustrating the structure of a vehicle signal according to an implementation. Each node in diagram 400 represents a vehicle signal. Node 410 is the root node for a vehicle. Node 410 has subnodes Vehicle.Cabin 420 and Vehicle.Speed ​​422. Node Vehicle.Speed ​​422 is a leaf node, which means it has no subnodes. Node Vehicle.Speed ​​422 is a floating point data type, which indicates that a floating point number is used to represent the value of node Vehicle.Speed. Vehicle.Cabin 420 is a branch node, which has 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 subnode Vehicle.Cabin.Seat.Row1.Pos1.Tilt 460. Vehicle.Cabin.Seat.Row1.Pos1.Tilt 460 is a leaf node, which has a data type of floating point. 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 data type of floating point. Although not illustrated, each of the branch nodes may have additional subnodes.

[0036] In addition to the signal type and data type, a data entry node representing a vehicle signal may include other elements (eg, min (representing the minimum value of the signal), max (representing the maximum value of the signal), etc.).

[0037] As can be seen from Table 1 above, the dots mark the name path to identify the components as branches (sets of data entries) or data entries (sensors, actuators, or attributes). A sensor represents a unidirectional signal emanating from the vehicle (e.g., generated according to measurements of one or more sensors in the vehicle). An actuator represents a bidirectional signal (i.e., the signal can indicate a current state or can be used to set a state) that can be a "set" or "acquire" value. A branch is a node in a tree structure. An attribute is typically a fixed value. A sensor / actuator may typically have a publisher (or producer) that continuously updates the signal value when a change occurs in the sensor, while an attribute typically has a set value 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) script, or another encoding format.

[0038] The request at 202 may be a read request, a write request, or a combination thereof. A read request indicates that an application requests to obtain information represented by a vehicle signal or node (e.g., the speed of the vehicle, etc.). A write request indicates that an application requests to set information represented by a vehicle signal or node (e.g., writing the volume of the speaker on the vehicle, etc.).

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

[0040] At 204, software or hardware on the vehicle determines whether to grant the request to access a vehicle signal or a node in the signal catalog. In some implementations, the determination is made based at least in part on authorization factors of the vehicle signals deployed in the vehicle or nodes in the signal catalog. If the access request is granted to a branch node in the signal catalog, access to all nodes below the branch node is granted.

[0041] In some cases, in addition to the elements (e.g., data type, min, max, etc. already discussed), one or more permission elements may be defined for each node in a vehicle signal or signal catalog. For example, the 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, one 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., a first one or more bits within the permission element represent read permission and a second one or more bits within the permission element represent write permission).

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

[0043] In some cases, permission elements may be defined as part of the VSS. Alternatively, or in combination, permission elements may be defined as unique elements (e.g., x-read-permission or x-write-permission, where "x" indicates a unique, private, extended, or special element). This approach may avoid conflicts in future definitions 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 a different permission value. Alternatively, or in combination, a set of permission values ​​may be used to control access to various sets of nodes in the signal catalog tree. For example, the following permission values ​​may be predefined and used:

[0045] "READ_ACCESS": This may be assigned to a read permission element of a node that has unrestricted access to obtain information (eg, vehicle speed).

[0046] "PERSONAL_INFO": This may be assigned to a read permission element of a node where access to obtain information is restricted to a select group of applications (e.g., signals 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 may be assigned to a read permission element.

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

[0048] When there are many vehicle signals or nodes defined in the catalog and the permission elements for each signal / node need to be defined, this can be time consuming and error prone. In some cases, inheritance can be used to take advantage of the tree structure of the VSS. This approach simplifies the assignment of permissions to many nodes. In this approach, the permission value defined for a branch node also applies to all of the subnodes of the branch node unless different permission values ​​are defined for some of the subnodes. In this aspect, it is not necessary to specify a permission value for each node in the signal catalog, instead, the permission value can be automatically assigned to the nodes via inheritance. This provides an efficient mechanism for vehicle manufacturers to define who can gain access to vehicle signals represented as nodes in the signal catalog.

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

[0050] In some cases, a permission map, as described below, may be used to define the permissions of vehicle signals for a vehicle. 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. A software tool may be implemented to walk through the signal catalog tree and add a permission element to each node and set its value according to the permission map.

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

[0052] The signal catalog may be implemented using YAML (yet another markup language), JSON (JavaScript Object Notation), or any other format.

[0053] Below are some examples for setting vehicle signal permissions using a permission map 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 the subentry is applicable to the read permission elements (that match "x-read-permission") for each node in the signal catalog specified under the "nodes" subentry.

[0055] The "permission" entry defines the permission value to be assigned. The "nodes" entry in the permission map defines the nodes to which the permission value is assigned. The "nodes" entry can be a list of multiple nodes since more than one signal catalog node can be given the same permission.

[0056] The above permission map 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 catalogue). Below are the elements of the Vehicle.Speed ​​node in the signal catalogue: [ka]

[0057] Given that Vehicle.Speed ​​is a data entry node of type "sensor", note that there is no "x-write-permission" element in its definition.

[0058] In another example, a "WRITE_ACCESS" permission value is assigned to a "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 a permission element "x-write-permission" with permission value "WRITE_ACCESS" may be assigned to this node. The node may also have a permission element "x-read-permission" with permission value "READ_ACCESS", as shown below, which may be inherited from the branch nodes above this data entry node (e.g., the branch nodes Vehicle, Vehicle.ADAS, or Vehicle.ADAS.CruiseControl, etc.). Below are the elements of the node Vehicle.ADAS.CruiseControl.IsEnabled: [ka]

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

[0061] In the permission map, this can be configured as follows: [ka] [ka]

[0062] In the permission map, the "READ_ACCESS" read permission and the "WRITE_ACCESS" write permission are assigned to the "Vehicle" branch node. Subnodes under the branch node "Vehicle" (including all branch nodes and data entry nodes) inherit the read permission unless they are assigned their own permissions in the permission 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", including all branch nodes and data entry nodes with an "Actuator" data type, also inherit the write permission unless they are assigned their own permission in the permission map. In other words, all sub-branch nodes and data entry nodes with an "Actuator" data type under the branch node "Vehicle" inherit "WRITE_ACCESS" from the branch node "Vehicle", because the permission map does not specify any values ​​for the write permission element for nodes under the branch node "Vehicle", except for "Vehicle.VehicleIdentification.VIN". All nodes under the branch node "Vehicle", except for "Vehicle.VehicleIdentification.VIN", inherit "READ_ACCESS" from the branch node "Vehicle".

[0064] In another example, for simplicity, 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 directly under the "Vehicle" branch.

[0067] The "Vehicle.VehicleIdentification" branch node is under the "Vehicle" branch.

[0068] The "Vehicle.VehicleIdentification.Model" data entry node is under the "Vehicle.VehicleIdentification" branch.

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

[0070] The "Vehicle" branch node at the top of the tree is assigned the "READ_ACCESS" read permission and the "WRITE_ACCESS" write permission. Therefore, all subnodes under the branch node "Vehicle" have the "READ_ACCESS" permission, unless some nodes have been assigned their own read permission (e.g., "PERSONAL_INFO") in the permission map. All subnodes under the branch node "Vehicle" have the "WRITE_ACCESS" permission, except for data entry nodes with a "sensor" or "attribute" data type.

[0071] The "Vehicle.RoofLoad" data entry node immediately below the "Vehicle" branch inherits the "READ_ACCESS" read permission from the "Vehicle" branch node above it because it has not been 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 permission map. Because it is under the "Vehicle" branch node, it inherits both read and write permissions. Therefore, it is assigned the "READ_ACCESS" read permission and the "WRITE_ACCESS" write permission.

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

[0074] The "Vehicle.VehicleIdentification.Model" data entry node is not assigned its own permissions in the permission 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 permission. In this implementation, the vehicle model is not considered private information.

[0075] In this implementation, the "Vehicle.VehicleIdentification.VIN" data entry node is not considered to be 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 a data entry node of type "actuator", it does not have write permission.

[0076] In some implementations, at 204, the vehicle determines whether to grant the 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, the application may be assigned a permission value of "READ_ACCESS". In this case, the vehicle may determine that the application is allowed to obtain 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 the application only has permission of "READ_ACCESS" 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 the values ​​of both the "Vehicle.VehicleIdentification.Model" and "Vehicle.VehicleIdentification.VIN" signals.

[0077] In some cases, the vehicle may further generate a notification after determining whether to grant the access request at 202. The vehicle may output the notification as a user interface of the vehicle, send the notification to a server or a different device (e.g., an application running on the owner's device, etc.), or a combination thereof. The notification may indicate whether there is an unauthorized attempt to access the vehicle signal / node. The notification may include information of the application sending the request, the requested signal / node, the permission value of the signal / node, the permission value of the application, and any combination thereof. In some cases, the vehicle may further trigger an audio or visual alarm indicating the unauthorized access. In some cases, the combination of different responses already discussed may be configured for different attempts of unauthorized access to different signals / nodes. Alternatively, or in combination, the combination of different responses already discussed may be configured for different numbers of attempts of 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 the request may be granted if the permission level of the requested party is higher than that of the permission level 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 enabled to write signals / nodes whose write permission value is between class 1 and class 5, but not signals / nodes whose write permission value is set to a class higher than class 5. This approach provides flexibility to secure access of vehicular signals / nodes with different degrees of security sensitivity.

[0079] In one implementation, when an application is connected to a vehicle or logs into a vehicle at the beginning of a session, the application may provide its permission values ​​(or an identifier of the permission values) for vehicle signal read and write permissions as part of the login process. The vehicle may store the application's permission values. Thereafter, 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 an identifier of the permission values) may be included in the request for access of each signal / node. In some cases, the vehicle may also query the requested portion of the signal access for its permission values. The query may be sent after receiving a request or may be sent after the vehicle determines that a previously stored permission value has expired.

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

[0081] In some cases, upon determining whether to grant the request, the vehicle may send a response to the requested party. If the request is granted, the response may indicate that the request was granted. In some cases, the response may further include the value of the requested signal / node (e.g., in a request for read permission). The value of a branch node may include the values ​​of all nodes under the branch node. If the request is rejected, the response may indicate that the request was rejected and the reason for the rejection.

[0082] FIG. 5 is a flow diagram illustrating an example method 500 for configuring permissions for a vehicle signal or a node in a signal catalog, according to an implementation. The method 500 may be performed by a computing device (e.g., a server, etc.) associated with a vehicle manufacturer or an original equipment manufacturer (OEM). The manufacturer or OEM may create a permission map and use the permission map to populate permission values ​​for each node in the signal catalog. The method 500 may also be performed by entities illustrated in FIG. 1 (e.g., including the vehicle 120 or the server 130). The method 500 illustrated in FIG. 5 may also be implemented using additional, fewer, or different entities. Furthermore, the method 500 illustrated in FIG. 5 may be implemented using additional, fewer, or different operations that may be performed in the order illustrated or in a different order. In some cases, an operation or group of operations may be repeated or repeated, for example, for a specified number of iterations or until a termination condition is reached.

[0083] At 502, a permission map is received. As previously discussed, the permission map may include configured permission values ​​for permission elements of nodes in the vehicle signal catalog. As previously discussed, the permission elements may be read permission elements or write permission elements or both. The configured permission values ​​may be predefined and may represent “READ_ACCESS”, “PERSONAL_INFO”, “WRITE_ACCESS”, or other values.

[0084] At 504, the permission values ​​of the permission elements of the nodes in the vehicle signal catalog are set according to the configured permission values ​​in the permission map. As previously discussed, in some operations an inheritance approach may be used and the configured permission values ​​may be used to set the permission values ​​of the permission elements of the subnodes. Also, as previously discussed, default values ​​may be used and overwritten by the permission map.

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

[0086] 3 is a high-level architectural block diagram illustrating a computer 302 coupled to a network 350 according to an implementation. The illustrated example is only one possible implementation of the described subject matter and is not intended to limit the disclosure to a single described implementation. Those skilled in the art can appreciate the fact that the described components can be connected, combined, or used in alternative embodiments consistent with the present disclosure.

[0087] Network 350 facilitates communication between computer 302 and other devices. In some cases, a user (e.g., an administrator, etc.) 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] The computer 302 includes a computing system configured to perform the algorithms described in this disclosure. For example, the computer 302 may be used to implement the server 130 shown in FIG. 1. The computer 302 may be used to implement an electronic device (e.g., a laptop computer or a smartphone, etc.) that runs the application 122 shown in FIG. 1. The computer 302 may also be used to implement the authorization control module 112 shown in FIG. 1. In some cases, the algorithm may be implemented in executable computing code (e.g., C / C++ executable code, etc.). Alternatively, or in combination, the algorithm may be implemented in an application program (e.g., EXCEL, etc.). In some cases, the computer 302 may include a standalone LINUX system that runs a batch application. In some cases, the computer 302 may include a mobile computer or a personal computer that runs an application program.

[0089] The computer 302 may include input devices (e.g., a keypad, keyboard, touch screen, microphone, speech recognition device, or another device that can accept user information) and / or output devices (that convey information associated with the operation of the computer 302, including digital data, visual and / or audio information, or a GUI).

[0090] The computer 302 may act as a client, a network component, a server, a database, or other persistence, etc. In some cases, one or more components of the 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 operable to receive, transmit, process, store, or manage data and information. According to some implementations, computer 302 may also include or be communicatively 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 receive requests over network 350 from client applications (e.g., running on a user device) and respond to the received requests by processing the requests in an appropriate software application. In addition, requests may also be sent to computer 302 from internal users (e.g., from a command console or by another suitable access method, etc.), external or third parties, other automated applications, as well as any other suitable entity, individual, system, or computer.

[0093] Each of the components of the computer 302 may communicate using a system bus 303. In some implementations, any and / or all of the components of the computer 302 (both hardware and / or software) may interface with each other and / or with the interface 304 via the system bus 303 using an application programming interface (API) 312 and / or a service layer 313. The API 312 may include specifications for routines, data structures, and object classes. The 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 the computer 302. The functionality of the computer 302 may be accessible to all service consumers using this service layer. Software services, such as those provided by the 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 illustrated as an integrated component of computer 302, alternative implementations may illustrate API 312 and / or services layer 313 as stand-alone components in relation to other components of computer 302. Additionally, any or all portions of API 312 and / or services layer 313 may be implemented as a child module or sub-module of another software or hardware module without departing from the scope of the present disclosure.

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

[0095] Computer 302 includes a processor 305. Although illustrated in FIG. 3 as a single processor 305, two or more processors may be used according to the particular needs, configuration, or particular implementation of computer 302. Generally, processor 305 executes instructions and manipulates data to perform the operations of computer 302. In some cases, processor 305 may include a data processing device.

[0096] The computer 302 also includes a memory 306 that holds data for the computer 302. Although illustrated in Figure 3 as a single memory 306, two or more memories may be used according to the particular needs, configuration, or particular implementation of the computer 302. Although the memory 306 is illustrated as an integrated component of the computer 302, in alternative implementations the memory 306 may be external to the computer 302.

[0097] The applications 307 include algorithmic software engines that provide functionality according to the particular needs, configuration, or particular implementation of the computer 302. Although illustrated as a single application 307, the applications 307 may be implemented as multiple applications on the computer 302. Additionally, while illustrated as integrated into the computer 302, in alternative implementations the applications 307 may be external to the computer 302.

[0098] There may be any number of computers 302 associated with the system 300 or external to the system 300 and in communication with the network 350. Additionally, the terms "client," "user," and other suitable terminology may be used interchangeably as appropriate without departing from the scope of this disclosure. Additionally, this disclosure contemplates that many users may use one computer 302, or that one user may use multiple computers 302.

[0099] The described implementations of the subject matter may include one or more features, either alone or in any combination.

[0100] For example, in a first implementation, the method includes receiving a permission map, the permission map including configured permission values ​​of permission elements of nodes in the 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.

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

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

[0103] The second feature may be combined with any of the above and following features, wherein the authorization element is a read authorization element or a write authorization element.

[0104] The third feature can be combined with any of the above and following features, wherein the permission value is from a predefined set of permission values.

[0105] A fourth feature, which may be combined with any of the above and following features, wherein the permission value indicates that read access to the node's signal value is limited to a selected group of applications having the same permission value.

[0106] A fifth feature may be combined with any of the above and following features, wherein the node is a branch node, and the method further includes setting permission values ​​of permission elements of subnodes of the node in the vehicle signal catalogue according to the configured permission values ​​in the permission map.

[0107] A sixth feature, which may be combined with any of the features of the preceding features, wherein setting the permission value of the permission element of a subnode of a node in the vehicle signal catalog includes determining whether the permission map includes a permission value for the permission element of the subnode, and in response to determining that the permission map does not include a permission value for the permission element of the subnode, setting the permission value of the permission element of the subnode to be the same as the configured permission value.

[0108] In a second implementation, a computing device includes 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, which, when executed, cause the computing device to perform operations including receiving a permission map, the permission map including configured permission values ​​of permission elements of nodes in the vehicle signal catalog, and setting the permission values ​​of the permission elements of the nodes in the vehicle signal catalog in accordance with the configured permission values ​​in the permission map.

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

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

[0111] The second feature may be combined with any of the above and following features, wherein the authorization element is a readable authorization element or a writeable authorization element.

[0112] The third feature can be combined with any of the above and following features, wherein the permission value is from a predefined set of permission values.

[0113] A fourth feature, which may be combined with any of the above and following features, wherein the permission value indicates that read access to the node's signal value is limited to a selected group of applications having the same permission value.

[0114] A fifth feature may be combined with any of the above and following features, wherein the node is a branch node, and the operations further include setting permission values ​​of permission elements of subnodes of the node in the vehicle signal catalogue according to the configured permission values ​​in the permission map.

[0115] A sixth feature, which may be combined with any of the features of the preceding features, wherein setting the permission value of the permission element of a subnode of a node in the vehicle signal catalog includes determining whether the permission map includes a permission value for the permission element of the subnode, and in response to determining that the permission map does not include a permission value for the permission element of the subnode, setting the permission value of the permission element of the subnode to be the same as the configured permission value.

[0116] In a third implementation, a computer-readable medium stores instructions that, when executed, cause a computing device to perform operations including receiving a permission map, the permission map including configured permission values ​​for nodes in the vehicle signal catalog, and setting permission values ​​of permission elements of the nodes in the vehicle signal catalog according to the configured permission values ​​in the permission map.

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

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

[0119] The second feature may be combined with any of the above and following features, wherein the authorization element is a read authorization element or a write authorization element.

[0120] The third feature can be combined with any of the above and following features, wherein the permission value is from a predefined set of permission values.

[0121] A fourth feature, which may be combined with any of the above and following features, indicates that read access to the node's signal value is limited to a selected group of applications having the same permission value.

[0122] A fifth feature may be combined with any of the above and following features, wherein the node is a branch node, and the operations further include setting permission values ​​of permission elements of subnodes of the node in the vehicle signal catalogue according to the configured permission values ​​in the permission map.

[0123] A sixth feature, which may be combined with any of the above features, includes: determining whether the permission map includes a permission value for the permission element of the subnode of the node in the vehicle signal catalog; and, in response to determining that the permission map does not include a permission value for the permission element of the subnode, setting the permission value of the permission element of the subnode to be the same as the configured permission value.

[0124] Some of the subject matter and operations described in this disclosure may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware (including the structures described in this disclosure and their structural equivalents), or in a combination of one or more of these. 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 or to control the operation of a data processing device. Alternatively or additionally, the program instructions may be encoded in an artificially generated propagated signal (e.g., a machine-generated electrical, optical, or electromagnetic signal 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 substrate, a random access memory device or a serial access memory device, or any combination of computer storage media.

[0125] The terms "data processing apparatus", "computer", or "electronic computing device" encompass all kinds of apparatus, devices, and machines for processing data, including, for example, programmable processors, computers, systems on chips, or combinations of the above. The apparatus may include special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). In some implementations, the data processing apparatus or special purpose logic circuitry (or a combination of data processing apparatus or special purpose logic circuitry) may be hardware-based or software-based (or a combination of both hardware-based and software-based). The apparatus may optionally include code that creates an execution environment for a computer program (e.g., processor firmware, protocol stacks, database management systems, operating systems, or code that constitutes a combination of execution environments, etc.). The present disclosure contemplates the use of a data processing apparatus with or without a conventional operating system (e.g., LINUX, UNIX, WINDOWS, MAC OS, ANDROID, IOS, or any other suitable conventional operating system, etc.).

[0126] A computer program (which may also be referred to or described as a program, software, software application, module, software module, script, or code) may be written in any form of programming language, including compiled or interpreted, or declarative or procedural, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may correspond to a file in a file system, but need not. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple associated files (e.g., a file that stores one or more modules, subroutines, or portions of code). A computer program may be deployed to be executed on one computer located at one site, or on multiple computers distributed across multiple sites and interconnected by a communication network. Although portions of the programs illustrated in the various figures are shown as individual modules that implement various features and functionality through various objects, methods or other processes, the programs may instead include multiple sub-modules, third party services, components, libraries, etc., as appropriate. Conversely, features and functionality of various components may be combined into a single component, as appropriate.

[0127] Some of the processes and logic flows in this disclosure may be performed by one or more programmable processors, executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows may also be performed by, and devices may be implemented as, special purpose logic circuitry (such as, for example, an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit)).

[0128] Processors suitable for executing computer programs include, for example, both general purpose and special purpose microprocessors, and processors of any kind of digital computer. In general, a processor may receive instructions and data from a read-only memory or a random access memory, or both. A processor may include, for example, a programmable processor, a computer, a system on a chip, or a combination of more than one, or any combination of the above. A processor may include special purpose logic circuitry, such as a CPU (Central Processing Unit), an FPGA (Field Programmable Gate Array), or an ASIC (Application Specific Integrated Circuit).

[0129] A computer suitable for executing a computer program may be based on a general-purpose or special-purpose microprocessor, both, or any other type of CPU. In general, a CPU may receive instructions and data from a read-only memory (ROM) or a random access memory (RAM), or both. The essential elements of a computer are a CPU for performing or executing instructions, and one or more memory devices for storing instructions and data. In general, a computer may also include one or more mass storage devices (e.g., magnetic, electromagnetic, or optical disks) for storing data, or may be operatively 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), to name a few).

[0130] Computer-readable media suitable for storing computer program instructions and data (either transitory or non-transient, as appropriate) include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices (such as, for example, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices), magnetic disks (such as, for example, internal hard disks or removable disks), magneto-optical disks, and CD-ROM, DVD+ / -R, DVD-RAM, and DVD-ROM disks. The memory may store various objects or data, including, for example, caches, classes, frameworks, applications, backup data, jobs, web pages, web page templates, database tables, repositories storing dynamic information, and any other suitable information, including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto. In addition, the memory may include any other suitable data, such as, for example, logs, policies, security, or access data, report files, and others. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. In some cases, computer storage media can be transitory, non-transitory, or a combination of both.

[0131] To provide interaction with a user, implementations of the subject matter described in this disclosure 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, etc., for providing information to a user) and a keyboard and pointing device (e.g., a mouse, trackball, or trackpad, by which a user may provide input to the computer). Input may also be provided to the computer using a touch screen (e.g., a tablet computer surface with pressure sensitivity, a multi-touch screen using capacitive or electrical sensing, or other types of touch screens). Other types of devices may be used to provide interaction with a user as well. For example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback, etc.), and input from the user may be received in any form (including acoustic input, speech input, or tactile input). In addition, the computer may interact with a user by sending documents to and receiving documents from a device used by the user in response to requests received from a web browser, for example, by sending a web page to a web browser on the user's client device.

[0132] The term "graphical user interface" or "GUI" may be used in the singular or plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. Thus, a GUI may represent any graphical user interface, including but not limited to a web browser, a touch screen, or a command line interface (CLI) that processes information and efficiently presents information results to a 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 acted upon by a Business Suite user. These UI elements or other UI elements may relate 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 would be understood by one of skill in the art) mean that actions and responses are close in time such that an individual perceives the actions and responses to occur substantially simultaneously. For example, the time difference between an individual's action to access data followed by a response to a display of the data (or to an interaction with the display) may be less than 1 ms, less than 1 sec, less than 5 seconds, etc. The requested data need not be displayed (or a display initiated) instantaneously, but it may be displayed (or a display initiated) without any intentional delay, taking into account the processing limitations of the described computing system, e.g., the time required to collect, accurately measure, analyze, process, store, or transmit the data.

[0134] Implementations of the subject matter described in this disclosure may be implemented in a computing system that includes a back-end component (e.g., such as a data server), or a computing system that includes a middleware component (e.g., an application server, etc.), or a computing system that includes a front-end component (e.g., a client computer having a graphical user interface or a web browser through which a user may interact with implementations of the subject matter described in this disclosure), or a computing system that includes any combination of one or more such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of wireline or wireless digital data communication (or combination of data communication), such as a communications network. Examples of communication networks include a local area network (LAN), a radio access network (RAN), a metropolitan area network (MAN), a wide area network (WAN), Worldwide Interoperability for Microwave Access (WIMAX), a wireless local area network (WLAN) (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 a portion of the Internet, or any other communication system or system (or combination of communication networks) at one or more locations. A network may communicate, for example, Internet Protocol (IP) packets, frame relay frames, asynchronous transfer mode (ATM) cells, voice, video, data, or other suitable 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 of clients and servers arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0136] In some implementations, any or all of the 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 API and service layer). An API may include specifications for routines, data structures, and object classes. An API may be either a computer language, independent 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 a computing system. The functionality of various components of a computing system may be accessible to all service consumers using this service layer. A software service provides reusable defined business functionality through a defined interface. For example, an interface may be software written in JAVA, C++, or other suitable language that provides data in Extensible Markup Language (XML) format or another suitable format. An API or service layer (or a combination of API and service layer) may be an integrated or standalone component in relation to other components of a computing system. Additionally, any or all portions of the service layer may be implemented as a child or sub-module of another software module, or a hardware module, without departing from the scope of this disclosure.

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

[0138] Particular implementations of the subject matter have been described. Other implementations, alternatives, and permutations of the described implementations are within the scope of the following claims, as will be understood by those skilled in the art. Although operations are depicted in the figures and claims in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown, or in sequential order, to achieve desired results, or that all illustrated operations 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] Further, the separation or integration of various system modules and components in the above-described implementations should not be understood as requiring such separation or integration in all implementations, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0140] Therefore, the above description of example implementations does not define or constrain the disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of the disclosure.

[0141] Furthermore, any claimed implementations below are believed to be applicable to a computer system that includes at least a computer-implemented method, a non-transitory computer-readable medium storing computer-readable instructions for performing the computer-implemented method, and a computer memory interoperably coupled with a hardware processor configured to perform the computer-implemented method or the instructions stored on the computer-readable medium.

Claims

1. 1. A method, comprising: receiving, at a vehicle, a permission map, the permission map including configured permission values ​​of permission elements of nodes in a vehicle signal catalog, the nodes representing vehicular signals, the permission elements of the nodes being defined in accordance with a Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance; the vehicle setting a permission value of the permission element of the vehicle signal in the vehicle according to the configured permission value in the permission map, the permission value being one of a set of permission values, the set of permission values ​​including a permission value corresponding to personal information related to a read permission element; determining that the permission map does not include a permission value for an authorization element of a subnode of the node, the node being a branch node as defined in a Vehicle System Alliance (VSS); in response to determining that the permission map does not include the permission value for the permission element of the subnode, setting the permission value for the permission element of the subnode to be the same as the configured permission value of the permission element of the node; controlling at least one hardware component of the vehicle by using the vehicle signal according to the permission value of the permission element of the vehicle signal; A method comprising:

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

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

4. The method of claim 1 , wherein the permission value indicates that read access to the node's signal value is limited to a select group of applications that have the same permission value.

5. 1. A computing device, comprising: 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, the programming instructions, when executed, causing the computing device to: receiving, at a vehicle, a permission map, the permission map including configured permission values ​​of permission elements of nodes in a vehicle signal catalog, the nodes representing vehicular signals, the permission elements of the nodes being defined in accordance with a Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance; the vehicle setting a permission value of the permission element of the vehicle signal in the vehicle according to the configured permission value in the permission map, the permission value being one of a set of permission values, the set of permission values ​​including a permission value corresponding to personal information related to a read permission element; determining that the permission map does not include a permission value for an authorization element of a subnode of the node, the node being a branch node as defined in a Vehicle System Alliance (VSS); in response to determining that the permission map does not include the permission value for the permission element of the subnode, setting the permission value for the permission element of the subnode to be the same as the configured permission value of the permission element of the node; controlling at least one hardware component of the vehicle by using the vehicle signal according to the permission value of the permission element of the vehicle signal; one or more computer-readable storage media for performing operations including A computing device comprising:

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

7. The computing device of claim 5 , wherein the permission value is from a set of predefined permission values.

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

9. A non-transitory computer-readable medium storing instructions that, when executed, cause a computing device to: receiving, at a vehicle, a permission map, the permission map including configured permission values ​​of permission elements of nodes in a vehicle signal catalog, the nodes representing vehicular signals, the permission elements of the nodes being defined in accordance with a Vehicle Signaling Specification (VSS) of the Connected Vehicle Systems Alliance; the vehicle setting a permission value of the permission element of the vehicle signal in the vehicle according to the configured permission value in the permission map, the permission value being one of a set of permission values, the set of permission values ​​including a permission value corresponding to personal information related to a read permission element; determining that the permission map does not include a permission value for an authorization element of a subnode of the node, the node being a branch node as defined in a Vehicle System Alliance (VSS); in response to determining that the permission map does not include the permission value for the permission element of the subnode, setting the permission value for the permission element of the subnode to be the same as the configured permission value of the permission element of the node; controlling at least one hardware component of the vehicle by using the vehicle signal according to the permission value of the permission element of the vehicle signal; A non-transitory computer-readable medium for performing operations including:

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

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

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

Images