Synthetic sensor verification for deployment in vehicle

Abstract

Embodiments of the present disclosure relate to synthetic sensor verification for deployment in a vehicle. A method for verifying that a synthetic sensor or other application may operate in a computing environment of a vehicle is provided. The composite sensor specifies, in a manifest, which sensors of the vehicle from which it will read signals. The synthetic sensor manifest is enhanced by adding an extended generic identifier carrying semantic information to the synthetic sensor manifest. The identifier may then be compared to a unique identifier in a signal directory of the vehicle to ensure that a sensor of the vehicle will provide information with semantics desired by the synthetic sensor.

Description

Technical Field

[0001] The present disclosure relates to a method of operating an application on a vehicle. More specifically, the present disclosure relates to a method for verifying the semantics of signals received by an application during operation prior to installation. Background Art

[0002] The background description includes information that may be helpful in understanding the subject matter of the present invention. Any information provided herein is not prior art or admitted by the applicant to be prior art, nor is it information related to the subject matter of the present invention, nor is it an admission that any specific or implicitly referenced publication is prior art or admitted by the applicant to be prior art.

[0003] Modern vehicles have many sensors, both physical and synthetic. Physical sensors are devices that take direct measurements from their environment, such as, but not limited to, temperature, pressure, speed, etc. Synthetic sensors are applications (software modules) that take information from other sensors (whether physical or synthetic) to produce "insights." In this context, the term "insight" refers to useful information obtained from one or more information sources (such as vehicle signals from physical vehicle sensors).

[0004] When synthetic sensors are used in a vehicle, failures may occur if the synthetic sensor receives data with unexpected semantics. For example, a synthetic sensor that expects speed values ​​in kilometers per hour (km / h) will not function properly if it receives data in miles per hour (mph). Summary of the invention

[0005] According to at least one embodiment of the present disclosure, a method for verifying an application at a computing device is provided, the method comprising: enhancing a manifest of the application, the manifest of the application including node path names corresponding to signals required by the application, wherein the enhanced manifest comprises: searching a reference signal directory for a unique identifier corresponding to the node path name; and adding the node path name and the unique identifier to the enhanced manifest; verifying the enhanced manifest against the signal directory, wherein the verification comprises: searching a second signal directory for a second unique identifier corresponding to the node path name; and reporting whether the second unique identifier is the same as the unique identifier, different from the unique identifier, or missing from the second signal directory.

[0006] According to at least another embodiment of the present disclosure, a computing device for verifying an application is provided, the computing device comprising: a communication subsystem; and a processor; wherein the communication subsystem and the processor collaborate to: enhance a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, wherein the enhanced manifest comprises: searching a reference signal directory for a unique identifier corresponding to the node path name; and adding the node path name and the unique identifier to the enhanced manifest; verifying the enhanced manifest against the signal directory, wherein the verification comprises: searching a second signal directory for a second unique identifier corresponding to the node path name; and reporting whether the second unique identifier is the same as the unique identifier, different from the unique identifier, or missing from the second signal directory.

[0007] According to another embodiment of the present disclosure, a computer-readable medium is provided, on which executable code is stored for execution by a processor of a computing device, the executable code including instructions for: enhancing a manifest of an application, the manifest of the application including node path names corresponding to signals required by the application, wherein the enhanced manifest includes: searching a reference signal directory for a unique identifier corresponding to the node path name; and adding the node path name and the unique identifier to the enhanced manifest; verifying the enhanced manifest against the signal directory, wherein the verification includes: searching a second signal directory for a second unique identifier corresponding to the node path name; and reporting whether the second unique identifier is the same as the unique identifier, different from the unique identifier, or missing from the second signal directory. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The present disclosure will be better understood in light of the accompanying drawings, in which:

[0009] Figure 1 is a graphical representation of a signal catalog as a tree structure according to at least one embodiment of the present disclosure;

[0010] Figure 2 is a graphical representation of signals converted between different applications according to at least one embodiment of the present disclosure;

[0011] Figure 3 is a graphical representation of a process for creating an enhanced signal catalog from an original signal catalog in accordance with at least one embodiment of the present disclosure;

[0012] Figure 4 is a graphical representation of a process for converting a signal at a signal connector in accordance with at least one embodiment of the present disclosure;

[0013] Figure 5 is a graphical representation of a process for enhancing a synthetic sensor inventory in accordance with at least one embodiment of the present disclosure;

[0014] Figure 6 is a graphical representation of a process for validating an enhanced synthetic sensor inventory against a signal catalog in accordance with at least one embodiment of the present disclosure;

[0015] Figure 7 is a block diagram of a method for verifying an application according to at least one embodiment of the present disclosure;

[0016] Figure 8 is a block diagram of a method for verifying an application according to at least one embodiment of the present disclosure; and

[0017] Fig. 9 is a block diagram of a simplified computing device that can be used with embodiments of the present disclosure. DETAILED DESCRIPTION

[0018] The present disclosure relates to a method for verifying that a synthetic sensor will receive properly normalized data after being deployed in a vehicle. This verification can be performed prior to deployment, thereby facilitating the development process of the synthetic sensor.

[0019] For purposes of this disclosure, the following terminology will be used.

[0020] "Signal Catalog": A set of signals used in a vehicle. According to the Connected Vehicle Systems Alliance (COVESA) Vehicle Signal Specification (VSS), the signal catalog is represented as a tree structure.

[0021] "node path name": the name of a node, expressed as a path to the node. A node path name includes the name of each node in the path from the root of the tree to the node in question, separated by periods. For example, Vehicle.Speed ​​is a node path name, where Vehicle is the root node and Speed ​​is a data node that is directly connected to the root node.

[0022] "EUUID": Extended UUID. VSS assigns a Universally Unique Identifier (UUID) to each node based on the path name of each node. These UUIDs are extended to create EUUIDs to include semantic information of the node.

[0023] "Signal catalog origin": Information indicating where the signal catalog originates from. For example, the catalog may originate from COVESA, an automobile manufacturer (OEM), or another supplier.

[0024] "Signal Directory Version": A number or a set of numbers indicating the version of a signal directory. The signal directory version, together with the signal directory origin, uniquely identifies the signal directory.

[0025] “Signal Service”: a service running within the Vehicle’s Electronic Control Unit (ECU) responsible for managing the signals within the Vehicle, access to those signals and the signal catalog.

[0026] “Fleet Management System” (FMS): OEM software infrastructure for managing vehicles, models, vehicle types, etc.

[0027] “Fleet Manager”: A human actor who uses an FMS to manage a fleet of vehicles.

[0028] “Synthetic sensors”: Applications that synthesize insights from a set of signals available in the vehicle. In some cases, synthetic sensors can use machine learning models to perform synthesis.

[0029] "Application": A software module that obtains signals from a signal service. Synthetic sensors are a type of application.

[0030] “Insight”: A synthetic signal created by a synthetic sensor based on a received signal.

[0031] "Signal Definition": Information about a signal from a signal catalog, including the path to the node that produces the signal and the VSS elements that describe the signal (such as description, type, data type, units, allowed values, etc.).

[0032] "Signal semantics": The portion of a signal definition that is related to the semantics of the signal. For example, it is needed to correctly interpret the signal's data type and units programmatically.

[0033] The development of in-vehicle applications is further complicated by the lack of standardization of vehicle data sources and how signals are to be consumed. For example, a synthetic sensor designed to work with a specific version of a signal definition in a given source's signal catalog may not work properly with a different version of a signal catalog or a signal catalog from a different source if the signal definition in another signal catalog is semantically different. It is inefficient for an application to check the signal catalog source and signal catalog version for each signal it handles and then adapt to the specific signal catalog.

[0034] Additionally, you need to ensure that only safe access to signals is provided.

[0035] The present disclosure provides a solution to the above problems by utilizing EUUID. EUUID is built on top of COVESA's VSS and allows for rapid identification of semantic differences between signals and efficient verification of applications.

[0036] Reference now Figure 1 , which illustrates a portion of the signal catalog.

[0037] like Figure 1As shown, a directory 100 defined in accordance with VSS includes a root node 110 named Vehicle. For simplicity, only two nodes are shown as child nodes of the root node 110, namely Vehicle.Cabin 120 and Vehicle.Speed ​​130. Vehicle.Cabin 120 is also shown as having two child nodes, namely Vehicle.Cabin.Door 140 and Vehicle.Cabin.Seat 150. For simplicity, other nodes are omitted.

[0038] In this example, Vehicle.Speed ​​130 is a data node that describes a signal representing the speed of a vehicle, while all other nodes are branch nodes. Vehicle.Speed ​​130 may have a JSON representation as follows:

[0039] "Speed":{

[0040] "datatype":"float",

[0041] "description":"Vehicle speed.",

[0042] "type":"sensor",

[0043] "unit":"km / h",

[0044] "uuid":"efe50798638d55fab18ab7d43cc490e9",

[0045] "x-euuid":"86e92e0ee67d30dd",

[0046] "x-read-permission":"Vehicle.Speed.READ"

[0047] }

[0048] As can be seen above, the JSON representation of Vehicle.Speed ​​130 includes: a data type (datatype) of floating point, a description (description) of "vehicle speed", a type (type) of "sensor", and a unit (unit) of "km / h". The JSON representation also includes UUID, EUUID, and read permissions.

[0049] Permissions marked "x-read-premission" allow control over which applications can read access to signals from a node. For example, some nodes may provide signals containing personally identifiable information, such as a vehicle identification number (VIN). Therefore, in accordance with at least some embodiments of the present disclosure, each node may have a read permission associated with it that indicates which applications have permission to receive signal values ​​from the node. In accordance with at least some embodiments of the present disclosure, each writable node may have a write permission associated with it that indicates which applications have permission to write signal values ​​to the node.

[0050] According to at least some embodiments of the present disclosure, a node inherits the permissions of its parent node unless the node has an explicit permission set. For example, this can be achieved by the following JSON representation in the permissions file (320), which is provided as a non-limiting example below:

[0051] "x-read-permission":[

[0052] {

[0053] "permission":"Vehicle.READ",

[0054] "nodes":[

[0055] "Vehicle" ]

[0057] },

[0058] {

[0059] "permission":"Vehicle.PII.READ",

[0060] "nodes":[

[0061] "Vehicle.VehicleIdentification",

[0062] "Vehicle.Driver.Identifier" ]

[0064] } ]

[0066] In the above example, Vehicle.READ is defined for the Vehicle node, which is the root node. In order to be able to access any signal from any node that has inherited this permission from the Vehicle node, the client needs to be granted the Vehicle.READ permission.

[0067] The above example also includes the Vehicle.PII.READ permission, which is defined for the Vehicle.VehicleIdentification node and the Vehicle.Driver.Identifier node. In this case, in order to be able to access these nodes or any of their child nodes, the client needs to be granted the Vehicle.PII.READ permission. Although these nodes are children of the Vehicle node, they do not inherit the Vehicle.READ permission because they are assigned their own read permissions in the permissions file. Other child nodes that are not assigned their own read permissions inherit their permissions from their parent node.

[0068] A similar mechanism as above can be used to provide write permissions.

[0069] Generally speaking, when a permission is defined for a given node, a client needs to be granted that permission in order to read or write to the given node or a child of the given node.

[0070] According to at least some embodiments of the present disclosure, nodes are assigned EUUIDs. EUUIDs uniquely identify nodes from a specific signal catalog of a given version and a given source. Therefore, each EUUID is unique and uniquely identifies a node with its specific semantic information.

[0071] According to at least some embodiments of the present disclosure, the EUUID for a given node may be created by a hash function defined by the node's VSS signal, including the node path name and semantically relevant elements that define the signal. As non-limiting examples, the semantically relevant elements may include a type (whether the node is a branch, sensor, actuator, or attribute), a data type (unsigned integer, integer, floating point, double precision, string, etc.), units of values ​​in the signal (e.g., km / h, mph, degrees Celsius, etc.), a minimum value, a maximum value, or a set of restricted values ​​that the signal may take.

[0072] Reference now Figure 2 , which illustrates the problem of the prior art system. Figure 2 As shown, vehicle data source 210 reports a signal in mph. The application is interested in the signal and wants the signal value to be expressed in mph. The signal is received by signal connector 220, which then normalizes the signal to km / h and then passes it to signal service 230. Signal service 230 then passes the signal to synthetic sensor 240, which then converts the value back to mph for application 250.

[0073] It will be appreciated that converting mph to km / h and then back to mph is inefficient and may introduce rounding errors. In at least some embodiments of the present disclosure, preferably, the raw signal from the data source 210 is transmitted through the signal service 230 in the units expected by the synthetic sensor 240 to avoid double conversion.

[0074] Reference now Figure 3 .like Figure 3 As shown, the original signal directory 310 is combined with the authority file 320 in the conversion tool 330 to generate an enhanced signal directory 340. Specifically, for each node in the original signal directory 310, an EUUID is created, and a new node with the EUUID is added to the enhanced signal directory 340. According to at least one embodiment of the present disclosure, the EUUID is created by a hash value of the node path name and the semantic information of the node. In at least some embodiments, the hash value is a 64-bit hash value.

[0075] Notably, this means that if a node from a first signal directory has the same path name and the same semantics as a node from a second signal directory, then the two nodes will have the same EUUID. This means that unless a node changes semantics between two different signal directories, it will generate the same EUUID.

[0076] According to at least some embodiments of the present disclosure, the enhanced signal directory may also include permissions for each node. The permissions information may be provided in the permissions file 320, such as Figure 3 For example, the permissions file 320 may include a JSON representation of permissions, as described above, and this may be used by the conversion tool 330 to add the necessary permissions elements to each node.

[0077] The above can be explained based on the following example, where the following JSON fragment represents a node in the original signal catalog 310:

[0078] "Speed":{

[0079] "datatype":"float",

[0080] "description":"Vehicle speed.",

[0081] "type":"sensor",

[0082] "unit":"km / h",

[0083] "uuid":"efe50798638d55fab18ab7d43cc490e9"'

[0084] }

[0085] After conversion by conversion tool 330, the corresponding node in enhanced signal catalog 340 will be as follows:

[0086] "Speed":{

[0087] "datatype":"float",

[0088] "description":"Vehicle speed.",

[0089] "type":"sensor",

[0090] "unit":"km / h",

[0091] "uuid":"efe50798638d55fab18ab7d43cc490e9",

[0092] "x-euuid":"86e92e0ee67d30dd",

[0093] "x-read-permission":"Vehicle.Speed.READ"

[0094] }

[0095] It can be seen that the corresponding node in the enhanced directory 340 has changed relative to the original node because it includes the elements "x-euuid" and "x-read-premission". The EUUID element is created based on the hash value of the node path name (which in this case is Vehicle.Speed) and the semantic information (which in this case includes the data type, type, and unit). The permissions element is based on the content of the permissions file.

[0096] The EUUID can be used to uniquely identify signal definitions and semantics across different sources and versions of signal catalogs, and to verify that a received signal matches its expected semantics.

[0097] In particular, applications that utilize signal values ​​need to know a priori the exact definition of the signal. EUUID simplifies the process for this verification.

[0098] For example, the semantic information of a node can change over time, depending on the source or version of the signal catalog. In one scenario, an original equipment manufacturer (OEM) that manufactures vehicles in the United States may use a sensor that reports vehicle speed in mph. However, if the signal catalog is based on VSS, the vehicle speed needs to be converted to km / h to match the VSS semantics.

[0099] OEM applications and synthetic sensors may also use mph units, so the values ​​need to be converted from km / h back to mph as described above. Figure 2 shown.

[0100] This can be avoided by changing the definition of the Vehicle.Speed ​​node in the signal catalog used by the OEM to use mph instead of km / h.

[0101] However, in this case, a third-party synthetic sensor designed based on VSS installed on one such vehicle where the signal catalog has been modified will receive data in mph when km / h is expected, resulting in a possible undetected error. In the case of EUUIDs, the EUUID generated based on VSS for the Vehicle.Speed ​​node will be different from the EUUID generated for the OEM signal catalog due to the difference in semantics (mph instead of km / h).

[0102] Therefore, using the EUUID provides a convenient mechanism to verify that the expected signal matches the signal being received. While the above is illustrated for the Vehicle.Speed ​​node, the same verification can be performed for each data node of the signal directory.

[0103] In the absence of the EUUID, verification of an application can be performed by comparing each element of each signal definition of the reference signal catalog with the corresponding element in the signal catalog against which the application is being verified. However, this is an expensive and time consuming operation. By leveraging the semantic information encoded in the EUUID, verification is greatly simplified, as described below.

[0104] Reference now Figure 4 , which illustrates how signal connectors use EUUIDs when standardizing signal values ​​in a vehicle 460 .

[0105] like Figure 4 As shown, input data 410 is received at signal connector 440. The input data represents signals reported by various data sources (such as sensors) in the vehicle. According to at least one embodiment, the input data can be organized as a tuple (SigID, Value), where SigID represents an identifier of a data source specific to the vehicle manufacturer, and Value is the value being reported.

[0106] The signal connector 440 uses the mapping table 430 created from the OEM signal catalog 420 to convert the input tuple to an output tuple (EUUID, F(Value)), where EUUID is the EUUID corresponding to the SigID, and F(Value) is the received value transformed by the function F, where F normalizes the value to the semantics defined by the vehicle's signal catalog. In some cases, no conversion is required and F(x)=x. However, in other cases, conversion is required, and in these cases, F is selected to perform the appropriate conversion.

[0107] Function F can normalize any type of value being received to any other type of value that the application is expecting. For example, in some cases, a signal representing values ​​in mph is converted to values ​​in km / h. Alternatively or additionally, a signal represented as an integer can be converted to floating point. Other possibilities exist and are considered to be within the scope of the present disclosure.

[0108] Specifically, the mapping table 430 includes multiple mappings between SigID, EUUID, and function F. When a tuple (SigID, Value) is received from a data source, the mapping table is used to look up the EUUID corresponding to the received SigID, and the function F. As described above, the function F can perform one or a series of transformations on the received Value. The signal connector 440 then reports the tuple (EUUID, F(Value)) to the signal service, which can then report it to the synthetic sensor and ultimately to the insight consumer, such as Figure 2 As shown above.

[0109] According to one non-limiting embodiment, SigID may be a node path name, a UUID, or an EUUID. When the tuple (SigID, Value) is received, SigID may be converted to an EUUID by looking up the mapping table 430, if necessary.

[0110] The mapping table is based on information from signal directory 420. According to at least some embodiments, this information may include, but is not limited to, node path names, EUUIDs, and semantic information, as described above.

[0111] In some embodiments, the signal catalog 420 may be different from the signal catalog used by the signal service to which the signal connector 440 is connected. This may occur, for example, when a third-party supplier to a vehicle manufacturer provides a signal connector based on its own signal catalog that is different in origin or version from the signal catalog used by the vehicle manufacturer. The signal connector may be validated against the signal catalog using the techniques described below.

[0112] EUUID can also be used to enhance synthetic sensor inventories, such as Figure 5 Reference Figure 5 , the synthesized sensor list 510 includes a list of sensors of interest (represented as node path names). The conversion tool 530 takes as input the sensor list 510 and the signal catalog 520. The signal catalog 520 may include information about all signals in a catalog in JSON format. The conversion tool 530 may then obtain the node path names from the sensor list 510, and for each node path name, look up the corresponding EUUID from the signal catalog 520. The conversion tool 530 may then output an enhanced sensor list 540, in which each node path name is associated with a related EUUID.

[0113] Thus, the conversion tool 530 simplifies the work of application developers, so that they do not have to manually handle EUUIDs, but instead let them work with node path names designed to be human-readable. Thus, the manifest of an application can be initialized with the required node path names, and then such node path names are automatically enhanced with EUUIDs by the conversion tool 530, thereby generating an enhanced manifest.

[0114] Therefore, developers of synthetic sensors can take the semantic specifications of each signal from the signal catalog and code the synthetic sensor accordingly. The source and version of the signal catalog is not important, because the EUUID uniquely corresponds to the correct semantic information. Therefore, synthetic sensors can be deployed "as is" on any vehicle that supports these EUUIDs.

[0115] Reference now Figure 6 , which illustrates how a synthetic sensor inventory can be validated against a signal catalog using the EUUID.

[0116] like Figure 6 As shown, the verification tool 630 receives as input an enhanced synthetic sensor list 610, which includes a list of node path names of sensors of interest and their corresponding EUUIDs. The enhanced synthetic sensor list 610 can be based on the above Figure 5 Created using the process shown.

[0117] Verification tool 630 also receives as input a signal catalog 620. Signal catalog 620 may correspond to, for example, but not limited to, an OEM signal catalog created by a vehicle manufacturer and installed on its vehicles. It is worth noting that this signal catalog is typically different from the signal catalog used to create enhanced synthetic sensor list 610.

[0118] Verification tool 630 may then compare each EUUID for a given node path name from enhanced synthetic sensor inventory 610 to the EUUID for the same node path name stored in signal directory 620. If the two EUUIDs match, this may be indicated in a verification report 640 output by verification tool 630. Similarly, if an EUUID is found in signal directory 620 for a given path name that does not match the EURID of the path name from enhanced synthetic sensor inventory 610, this may also be indicated in verification report 640. In other cases, if no EUUID corresponding to the path name from enhanced synthetic sensor inventory 610 is found, this may also be indicated in verification report 640.

[0119] According to at least some embodiments, verification tool 630 may invoke a manifest editing tool (not shown) to allow application developers to specify whether some signals are optional or whether some signals may be replaced with other signals.

[0120] Based on report 640, a decision may be made as to whether the synthetic sensor may be installed on the vehicle. Specifically, if validation report 640 indicates that all EUUIDs from the enhanced synthetic sensor inventory are found in signal catalog 620, the synthetic sensor may be deployed on the vehicle with signal catalog 620 installed. Alternatively, if validation report indicates that certain EUUIDs do not match or are missing, the synthetic sensor may need to be modified before installing the synthetic sensor on the vehicle.

[0121] This process facilitates the deployment of synthetic sensors across different platforms without placing an undue burden on developers. Specifically, developers of synthetic sensors can ensure that the semantics of data received from any sensor will match the semantics expected by the synthetic sensor without having to worry about the source or version of the signal catalog based on which the synthetic sensor was developed, or the source or version of the signal catalog installed in the vehicle. Although the sources and versions of the two signal catalogs can be different, if the EUUID of the sensor of interest matches, the synthetic sensor will work correctly.

[0122] If verification indicates a mismatch, there are a number of different approaches that can be taken to correct the situation.

[0123] According to at least one embodiment of the present disclosure, a synthetic sensor is capable of converting signals using different semantics into signals formatted according to desired semantics, as discussed above. Figure 4 shown.

[0124] According to at least some embodiments, conversion of a signal may include converting a signal received in a first unit to a second unit, such as between mph and km / h.Conversion of a signal may include converting a data type of the signal to a different data type, such as from a floating point number to an integer, or vice versa.

[0125] According to at least some embodiments, a synthetic sensor may be modified to deliver usable functionality from a subset of all the signals it normally requires. In this case, the synthetic sensor has a list of signals it requires and a list of signals it may optionally not require. The list of required sensors and optional sensors may be specified in an enhanced synthetic sensor manifest and described above with respect to Figure 6 The validation tools discussed can report which sensors are available on a given vehicle.

[0126] For example, when a signal is missing, a synthetic sensor may be able to provide usable functionality by using digital or other signals, combining their values ​​into a meaningful value, and replacing the value of the original desired signal.

[0127] In accordance with at least some embodiments, a synthetic sensor may be modified to ignore values ​​outside of an expected range of values ​​without reporting an error.

[0128] According to at least some embodiments, a synthetic sensor can be modified to request information about a signal from a signal service using a mechanism such as a self-test, etc. For example, a synthetic sensor can be modified to function properly regardless of whether vehicle speed is reported in mph or km / h by obtaining the units reported from the signal service and adapting accordingly.

[0129] While the self-check can be useful in cases such as this, it is a runtime operation that is expensive to perform, and performing this check on every signal of interest from a synthetic sensor at runtime is inefficient, especially given that most signals will follow normalization and will not vary between signal catalog versions or sources.

[0130] Therefore, using EUUIDs allows such runtime checks to be eliminated entirely, or to be used only in the few isolated cases where the EUUID of a synthetic sensor does not match that of a signal catalog or is missing from the signal catalog.

[0131] The following is an example of a portion of an enhanced synthetic sensor manifest in accordance with at least one embodiment of the present disclosure:

[0132] {

[0133] "EUUIDs":{

[0134] "allOf":["EUUID-A",

[0135] {"anyOf":["EUUID-B","EUUID-C","EUUID-D"]},

[0136] {"oneOf":["EUUID-E",{allOf:["EUUID-F","EUUID-G"]}]}],

[0137] "anyOf":[

[0138] "EUUID-H","EUUID-I" ]

[0140] }

[0141] }

[0142] In the above example, the required EUUIDs include (1) EUUID-A, (2) one of EUUID-B, EUUID-C, or EUUID-D, and (3) EUUID-E, or one of EUUID-F and EUUID-G. In addition, if EUUID-H or EUUID-I or both are available, the synthetic sensor can provide enhanced services.

[0143] Specifically, the first element in the EUUID list is the "allOf" tag, which is used to indicate that all listed elements are required. In this case, the required elements are listed as (1) EUUID-A, (2) anyOf:[EUUID-B,EUUID-C,EUUID-D], and (3) oneOf:[EUUID-E,{allOf:["EUUID-F","EUUID-G"]}]. The "anyOf" tag indicates any one of the elements that need to be listed, in this case, any one of EUUID-B, EUUID-C, and EUUID-D. The "oneOf" tag is used to indicate that only one of the elements that need to be listed is required. Based on this syntax, the enhanced synthetic sensor list can indicate which sensor combinations are required and which are optional.

[0144] When deployed in a vehicle, the signal catalog can match the exact set of signals supported by the data connectors in the vehicle, a superset of those signals, or a subset thereof. With exact matching, it is easier for synthetic sensors to determine whether a signal is supported in a vehicle before deployment or dynamically at runtime. However, requiring exact matching severely hinders the ability to dynamically modify the set of supported signals in a vehicle.

[0145] For example, some vehicle services may be provided on a subscription basis. In a non-limiting example, a vehicle may allow its owner to subscribe to a heated seat service. When the owner subscribes to the heated seat service, a related signal is made available in the vehicle. This may be accomplished in a variety of ways.

[0146] In one embodiment, a signal may be added to indicate whether a subscription has been purchased, while a signal indicating heated seats is always present in the inventory of signals in the vehicle.

[0147] In another embodiment, a separate permission may be assigned for the signals required for heated seat service, and that permission may be granted to the appropriate instance of the synthetic sensor.

[0148] In another embodiment, a new signal catalog may be delivered to the vehicle including additional signals required for heated seat service.

[0149] In another embodiment, the signal service asks the signal connector which signals each signal connector supports. The signal service can then generate a signal catalog that matches the signals supported by the signal connector. The disadvantage of this approach is that other applications on the vehicle also need to be validated against this signal catalog to ensure that they work properly. In another embodiment, the pre-deployed signal catalog already supports the signals required by the heated seat service, but reports them as unavailable until the data connector makes them available (after the owner purchases a subscription).

[0150] Vehicle manufacturers manage fleets of vehicle brands, vehicle models, vehicle trims, and versions based on years. Managing an exact signal catalog for each group of vehicles or even for individual vehicle instances may prove to be inconvenient. Therefore, vehicle manufacturers may wish to maintain a set of smaller signal catalogs, each with a superset of signals that any particular vehicle, brand, or model can support. Such a signal catalog, and a mechanism for clients of a signal service to dynamically determine at runtime whether a signal is available in a vehicle, may be statically deployed in the vehicle.

[0151] In accordance with at least one embodiment, the signal service may dynamically create a refined signal directory from the set of EUUIDs reported by the set of data connectors by extracting relevant nodes from the superset signal directory.

[0152] In general, there are four possibilities to consider when comparing the set of signals supported by a data connector to the set of signals supported by a signal catalog. In the first case, the two sets match exactly. In the second case, the set of signals supported by the signal catalog is a superset of the signals supported by the data connector. In the third case, the set of signals supported by the signal catalog is a subset of the signals supported by the data connector. In the fourth case, the set of signals supported by the signal catalog and the set of signals supported by the data connector do not match.

[0153] The first case (ie, both sets fully match) can be achieved by generating a signal directory from the EUUIDs supported by the data connectors, or by creating a signal directory that is expected to contain a set of signals and then verifying that the EUUIDs supported by the set of data connectors match.

[0154] The second case can be used when a vehicle manufacturer wants to minimize the number of signal catalogs it must manage. In this case, a single signal catalog with a superset of signals is installed across different vehicles, even if each of these vehicles does not use every signal in the signal catalog.

[0155] The third case may generate an error condition when some signals supported by the data connector are not supported in the signal catalog. However, this case can be useful if the manufacturer wants to limit the set of signals available to the synthetic sensor.

[0156] The fourth situation occurs when the signal catalog contains a superset of the signals expected to be supported in the vehicle and the data connector supports a different but overlapping set. When this happens, it usually indicates an error that needs to be corrected.

[0157] Reference now Figure 7 , which illustrates a method for authenticating an application.

[0158] The method begins at block 700 and proceeds to block 710 where each node path name in the manifest for the application is processed. The node path names of the manifest represent signals required for the application to function properly. The method then proceeds to block 720 to search for the node path name in a reference signal directory. The reference signal directory can be a signal directory used to develop the application being verified. After looking up the node path name in the reference signal directory, the corresponding EUUID is identified.

[0159] The method then proceeds to block 730 where the EUUID associated with the node path name is added to the manifest for the application.

[0160] After all node path names in the application manifest are processed, the application manifest is an "enhanced application manifest" in which each node path name corresponds to an EUUID.

[0161] The method then proceeds to box 740, where each node path name in the enhanced list is processed. At box 750, the node path name is searched in the second signal directory. The second signal directory can be a signal directory used by the vehicle on which the application is installed. If the node path name is found in the second signal directory, the EUUID in the second signal directory is recorded and compared with the EUUID in the enhanced list.

[0162] The method then proceeds to block 760 where the result of block 750 is reported. Either the two EUUIDs match, the two EUUIDs do not match, or the EUUID is not found in the second signal catalog.

[0163] After verifying all node path names against the second signal directory, the method proceeds to box 770 to check whether all EUUIDs match. If so, the method proceeds to box 780 where the application can be installed on the vehicle. Otherwise, the application is modified before installation, and the verification method described herein can be repeated for the modified application. The method then ends at box 790.

[0164] Reference now Figure 8 , which illustrates another method of verifying an application against a signal catalog.

[0165] Although this method is Figure 7 The method shown is simpler, but it is suitable when the application developer can provide the OEM with a catalog of reference signals for developing the application. Figure 8 The method requires a reference signal directory, an OEM signal directory, and a list of node path names used by the application. The reference signal directory is a signal directory used to develop applications, and the OEM signal directory is a signal directory used by the OEM for its vehicles.

[0166] In some embodiments, the application manifest may be replaced with a list of signals of interest for the applications. According to at least some embodiments, the list may be provided via a graphical user interface (GUI).

[0167] The method starts at block 800 and proceeds to block 810 where each node path name in the application's manifest is processed. The method then proceeds to block 820 where the node path name is searched in the reference signal directory and then to block 830 where the node path name is searched in the OEM signal directory.

[0168] The method then proceeds to block 840 where the EUUID for the signal catalog is calculated, and then to block 850 where the EURID for the OEM signal catalog is calculated. In some embodiments, the signal catalog may already include the EUUID for each signal, and in these cases, the EUUID is not recalculated but simply retrieved from the signal catalog.

[0169] At block 860, the two EUUIDs from each signal directory are compared and the comparison result is reported. For example, the comparison may result in a match, mismatch, or missing EUUID. Optionally, at block 860, an enhanced application manifest including the EUUID for each signal may also be created.

[0170] If there are more node path names to process, the method then returns to block 810, or alternatively, when all node path names have been processed, the method proceeds to block 870 where it is determined whether all EUUID pairs match. If all EUUID pairs match, the application can be installed on the vehicle at block 880, after which the method ends at block 890. Otherwise, the method ends at block 890. When the EUUIDs do not match, the application can be modified as described above, and the verification method can then be repeated.

[0171] The above content can be implemented using any computing device. Fig. 9 A simplified diagram of a computing device is shown. Fig. 9 The computing device may be any fixed or mobile computing device.

[0172] exist Fig. 9 In the embodiment, the device 910 includes a processor 920 and a communication subsystem 930, wherein the processor 920 and the communication subsystem 930 cooperate to perform the method of the above embodiment. The communication subsystem 930 allows the device 910 to communicate with other devices or network elements and can vary based on the type of communication being performed. In addition, the communication subsystem 930 can include a variety of communication technologies, including any wired or wireless communication technology.

[0173] Processor 920 is configured to execute programmable logic that may be stored on device 910 along with data and Fig. 9 In the example of , the memory 932 is shown. The memory 932 can be any tangible, non-transitory computer-readable storage medium that stores instruction codes that, when executed by the processor 920, cause the device 910 to perform the methods of the present disclosure. The computer-readable storage medium can be a tangible or transient / non-transitory medium, such as an optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art.

[0174] As an alternative or in addition to memory 932 , device 910 may access data or programmable logic from an external storage medium, such as through communication subsystem 930 .

[0175] exist Fig. 9 In the example of , one or more sensors 940 can be associated with the computing device. However, this is optional, and in some cases, the computing device 910 will not be associated with a sensor.

[0176] In one embodiment, communication between the various elements of device 910 may occur via internal bus 960. However, other forms of communication are possible.

[0177] The embodiments described herein are examples of structures, systems or methods with elements corresponding to the elements of the present application technology. This written description can enable those skilled in the art to make and use embodiments of replacement elements with elements similar to the technology of the present application. Therefore, the desired scope of the technology of the present application includes other structures, systems or methods that are not different from the technology of the present application described herein, and also includes other structures, systems and methods that are not substantially different from the technology of the present application described herein.

[0178] Although operations are described in a particular order in the accompanying drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in sequence, or that all of the operations shown be performed to achieve a desired result. In some cases, multitasking and parallel processing may be employed. In addition, the separation of various system components in the above implementations should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0179] In addition, techniques, systems, subsystems, and methods described and illustrated as discrete or separate in various implementations may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations may be determined and may be made by those skilled in the art.

[0180] Although the above detailed description has shown, described and pointed out the basic novel features of the present disclosure as applied to various implementations, it should be understood that various omissions, substitutions and changes in the form and details of the system shown may be made by those skilled in the art. In addition, the order of the method steps is not implied by the order in which they appear in the claims.

[0181] In the above description, many details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without these details. Other implementations may include modifications and variations to the above details. The appended claims are intended to cover such modifications and variations.

Claims

1. A method at a computing device for authenticating an application, comprising: enhancing a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, wherein enhancing the manifest comprises: searching a reference signal directory for a unique identifier corresponding to the node path name; and adding the node path name and the unique identifier to an enhanced manifest; validating the enhanced manifest against a signal catalog, wherein the validating comprises: searching the second signal directory for a second unique identifier corresponding to the node path name; and Reporting whether the second unique identifier is the same as the unique identifier, different from the unique identifier, or missing from the second signal catalog.

2. The method according to claim 1, further comprising: Upon determining that the second unique identifier is the same as the unique identifier, installing a synthetic sensor on the vehicle. The method according to claim 2 , wherein the second signal catalog is installed on the vehicle. The method of claim 1 , wherein the unique identifier is unique to a combination of a node path name and semantic information.

5. The method according to claim 1, further comprising: Prior to said enhancing, a respective unique identifier is calculated for each respective node path name in said reference signal directory and said second signal directory. 6 . The method according to claim 5 , wherein the corresponding unique identifier is calculated as a hash value of the corresponding node path name and semantic information of the corresponding node path name. The method of claim 6 , wherein the hash value is a 64-bit hash value. The method of claim 1 , wherein the application is developed based on the reference signal catalog.

9. The method of claim 1, wherein the manifest further comprises a second node path name corresponding to an optional signal for the application.

10. A computing device for verifying an application, comprising: Communication subsystem; processor; wherein the communication subsystem and the processor cooperate to: enhancing a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, wherein enhancing the manifest comprises: searching a reference signal directory for a unique identifier corresponding to the node path name; and adding the node path name and the unique identifier to an enhanced manifest; validating the enhanced manifest against a signal catalog, wherein the validating comprises: searching the second signal directory for a second unique identifier corresponding to the node path name; and Reporting whether the second unique identifier is the same as the unique identifier, different from the unique identifier, or missing from the second signal catalog.

11. The computing device of claim 10, wherein the communication subsystem and the processor further cooperate to: install a synthetic sensor on a vehicle upon determining that the second unique identifier is the same as the unique identifier.

12. The computing device of claim 11, wherein the second signal catalog is installed on the vehicle.

13. The computing device of claim 10, wherein the unique identifier is unique to a combination of a node path name and semantic information.

14. The computing device of claim 10, wherein the communication subsystem and the processor further cooperate to: calculate a respective unique identifier for each respective node path name in the reference signal directory and the second signal directory prior to the enhancing. 15 . The computing device of claim 14 , wherein the corresponding unique identifier is calculated as a hash value of the corresponding node path name and semantic information of the corresponding node path name.

16. The computing device of claim 15, wherein the hash value is a 64-bit hash value.

17. The computing device of claim 10, wherein the application is developed based on the reference signal catalog.

18. The computing device of claim 10, wherein the manifest further comprises a second node path name corresponding to an optional signal for the application.

19. A computer readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising instructions for: enhancing a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, wherein enhancing the manifest comprises: searching a reference signal directory for a unique identifier corresponding to the node path name; as well as adding the node path name and the unique identifier to an enhanced manifest; validating the enhancement manifest against a signal catalog, wherein the validating comprises: searching the second signal directory for a second unique identifier corresponding to the node path name; as well as Reporting whether the second unique identifier is the same as the unique identifier, different from the unique identifier, or missing from the second signal catalog.

20. The computer readable medium of claim 19, the executable code comprising further instructions for installing a synthetic sensor on a vehicle upon determining that the second unique identifier is the same as the unique identifier.

Images