Synthetic sensor validation for deployment in vehicles

Abstract

To provide synthetic sensor validation for deployment in vehicles.SOLUTION: There is provided a method for verifying that a synthetic sensor or other application can operate in a computing environment of a vehicle. The synthetic sensor specifies, in a manifest, from which sensors of the vehicle it will read signals. The synthetic sensor manifest can be enhanced by adding to it an extended universal extention that carries semantic information. This identifier may then be compared to unique identifiers in a signal catalog of the vehicle to ensure that the sensors of the vehicle provide information having semantics that are expected by the synthetic sensor.SELECTED DRAWING: None

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates to a method for operating an application on a vehicle, and more particularly, to a method for validating signal semantics received by the application during operation prior to installation. [Background technology]

[0002] (background) The background description includes information that may be useful in understanding the present subject matter. No admission is made that any of the information provided herein is prior art or applicant-admitted prior art or that it is relevant to the presently claimed subject matter, or that any publication specifically or implicitly referenced is prior art or applicant-admitted prior art.

[0003] Modern vehicles have many sensors, including physical and synthetic sensors. Physical sensors are devices that obtain measurements directly from their environment, such as, but not limited to, temperature, pressure, speed, and the like. Synthetic sensors are applications (software modules) that obtain information from other sensors, whether physical or synthetic, to generate "insights." In this context, the term "insights" refers to a useful piece of information derived from one or more sources of information (such as vehicle signals from physical vehicle sensors).

[0004] When synthetic sensors are used in vehicles, they may fail if they receive data with unexpected semantics. For example, a synthetic sensor that predicts speed values ​​that should be expressed in kilometers per hour (km / h) will not function correctly if it receives data expressed in miles per hour (mph). Summary of the Invention [Means for solving the problem]

[0005] (Abstract) In accordance with at least one embodiment of the present disclosure, in a computing device, a method is provided for validating an application, the method including: augmenting a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, where augmenting the manifest includes searching for a unique identifier corresponding to the node path name in a reference signal catalog and adding the node path name and the unique identifier into the augmented manifest; and validating the augmented manifest against a signal catalog, where verifying includes searching for a second unique identifier corresponding to the node path name in a second signal catalog and reporting whether the second unique identifier is identical to the unique identifier, different from the unique identifier, or missing from the second signal catalog.

[0006] In accordance with at least one other embodiment of the present disclosure, a computing device for validating an application is provided, the computing device including a communications subsystem and a processor, the communications system and the processor cooperating to: augment a manifest of the application, the manifest of the application including node path names corresponding to signals required by the application, where augmenting the manifest includes searching for a unique identifier corresponding to the node path name in a reference signal catalog and adding the node path name and the unique identifier into the augmented manifest; and verifying the augmented manifest against a signal catalog, where verifying includes searching for a second unique identifier corresponding to the node path name in a second signal catalog and reporting whether the second identifier is identical to the unique identifier, different from the unique identifier, or missing from the second signal catalog.

[0007] In accordance with yet another embodiment of the present disclosure, a computer-readable medium is provided having executable code stored thereon for execution by a processor of a computing device, the executable code comprising instructions for augmenting a manifest of an application, the application's manifest comprising node path names corresponding to signals required by the application, augmenting the manifest comprising searching for a unique identifier corresponding to the node path name in a reference signal catalog and adding the node path name and the unique identifier into the augmented manifest; and validating the augmented manifest against a signal catalog, the validating comprising searching for a second unique identifier corresponding to the node path name in a second signal catalog and reporting whether the second unique identifier is identical to the unique identifier, different from the unique identifier, or missing from the second signal catalog. The present invention provides, for example, the following items. (Item 1) 1. A method for validating an application on a computing device, the method comprising: augmenting a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, augmenting the manifest comprising: searching a reference signal catalog for a unique identifier corresponding to the node path name; adding said node path name and said unique identifier into an enhanced manifest; and Validating the enhanced manifest against a signal catalog, the validating comprising: searching the second signal catalog for a second unique identifier corresponding to the node path name; 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; Including, A method comprising: (Item 2) The method of any preceding claim, further comprising mounting the synthetic sensor on a vehicle upon determining that the second unique identifier is identical to the unique identifier. (Item 3) 2. The method of claim 1, wherein the vehicle has the second signal catalog mounted thereon. (Item 4) 2. The method of claim 1, wherein the unique identifier is unique for a combination of node path name and semantic information. (Item 5) 13. The method of claim 12, further comprising calculating, prior to said enrichment, a respective unique identifier for each respective node pathname in said reference signal catalogue and said second signal catalogue. (Item 6) 13. The method of claim 1, wherein the respective unique identifier is computed as a hash of the respective node path name and semantic information of the respective node path name. (Item 7) 2. The method of claim 1, wherein the hash is a 64-bit hash. (Item 8) 13. The method according to any one of the preceding claims, wherein the application is developed based on the reference signal catalogue. (Item 9) 13. The method of claim 1, wherein the manifest further comprises a second node path name corresponding to an optional signal for the application. (Item 10) 1. A computing device for validating an application, comprising: A communications subsystem; Processor and It is equipped with The communication subsystem and the processor include: augmenting a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, augmenting the manifest comprising: searching a reference signal catalog for a unique identifier corresponding to the node path name; adding said node path name and said unique identifier into an enhanced manifest; and Validating the enhanced manifest against a signal catalog, the validating comprising: searching the second signal catalog for a second unique identifier corresponding to the node path name; 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; Including, 2. A computing device that cooperates to perform the steps of: (Item 11) 20. The computing device of claim 19, wherein the communications subsystem and the processor further cooperate to mount the synthetic sensor on the vehicle upon determining that the second unique identifier is identical to the unique identifier. (Item 12) 2. The computing device of claim 1, wherein the vehicle has the second signal catalog mounted thereon. (Item 13) 2. The computing device of claim 1, wherein the unique identifier is unique to a combination of node path name and semantic information. (Item 14) The computing device of any one of the preceding items, wherein the communications subsystem and the processor further cooperate to calculate, prior to the enhancing, a respective unique identifier for each respective node pathname in the reference signal catalog and the second signal catalog. (Item 15) 20. The computing device of claim 19, wherein the respective unique identifier is computed as a hash of the respective node pathname and semantic information of the respective node pathname. (Item 16) 2. The computing device of claim 1, wherein the hash is a 64-bit hash. (Item 17) 2. The computing device of claim 1, wherein the application is developed based on the reference signal catalog. (Item 18) 20. The computing device of claim 19, wherein the manifest further comprises a second node pathname corresponding to an optional signal for the application. (Item 19) 1. A computer-readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising: augmenting a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, augmenting the manifest comprising: searching a reference signal catalog for a unique identifier corresponding to the node path name; adding said node path name and said unique identifier into an enhanced manifest; and Validating the enhanced manifest against a signal catalog, the validating comprising: searching the second signal catalog for a second unique identifier corresponding to the node path name; 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; Including, A computer-readable medium comprising instructions for performing the steps of: (Item 20) 20. The computer-readable medium of claim 1, wherein the executable code further comprises instructions for mounting the synthetic sensor on a vehicle upon determining that the second unique identifier is identical to the unique identifier. (Summary) A method is provided for verifying that a synthetic sensor or other application can operate in a vehicle's computing environment. A synthetic sensor specifies in a manifest which sensors on the vehicle it reads signals from. The synthetic sensor manifest can be enhanced by adding to it an extended universal extension with semantic information. This identifier can then be compared to unique identifiers in the vehicle's signal catalog to ensure that the vehicle's sensors provide information with the semantics expected by the synthetic sensor. [Brief description of the drawings]

[0008] BRIEF DESCRIPTION OF THE DRAWINGS The present disclosure may be better understood with reference to the following drawings.

[0009] [Figure 1] FIG. 1 is a graphical representation of a signal catalog as a tree structure in accordance with at least one embodiment of the present disclosure.

[0010] [Diagram 2] FIG. 2 is a graphical representation of signals being converted between different applications in accordance with at least one embodiment of the present disclosure.

[0011] [Diagram 3] FIG. 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]FIG. 4 is a graphical representation of a process of converting a signal in a signal connector in accordance with at least one embodiment of the present disclosure.

[0013] [Diagram 5] FIG. 5 is a graphical representation of a process for enhancing a synthetic sensor manifestation in accordance with at least one embodiment of the present disclosure.

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

[0015] [Figure 7] FIG. 7 is a block diagram of a method for validating an application in accordance with at least one embodiment of the present disclosure.

[0016] [Figure 8] FIG. 8 is a block diagram of a method for validating an application in accordance with at least one embodiment of the present disclosure.

[0017] [Figure 9] FIG. 9 is a block diagram of a simplified computing device that may be used with embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] Detailed Description of the Drawings This disclosure shows how to verify that a synthetic sensor receives properly normalized data when deployed in a vehicle. Verification can be done prior to deployment, thereby facilitating the development process for the synthetic sensor.

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

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

[0021] "Node Pathname": The name of a node in the form of a path to the node. A node pathname comprises the names 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 pathname, where Vehicle is the root node and Speed ​​is the data node directly connected to the root node.

[0022] "EUUID": Extended UUID. VSS assigns Universally Unique IDentifiers (UUIDs) to each node based on their pathname. These UUIDs are extended to include semantic information for the node, creating an EUUID.

[0023] "Signal Catalog Origin": Information indicating where the signal catalog was published. For example, the catalog may be published by COVESA, by the vehicle manufacturer (OEM), or by another provider.

[0024] "Signal Catalog Version": A number or collection of numbers indicating the version of a signal catalog. Along with the signal catalog origin, the signal catalog version uniquely identifies a signal catalog.

[0025] "Signaling Service": A service operating in the vehicle's Electric Control Unit (ECU) that is responsible for managing the signals in the vehicle, the access to those signals and the signal catalogue.

[0026] "Fleet Management System" (FMS): OEM software infrastructure used to manage vehicles, vehicle models, vehicle types and the like.

[0027] "Fleet Manager": A human actor that uses the FMS to manage a fleet of vehicles.

[0028] "Synthetic Sensor": An application that synthesizes insights from a collection of signals available in a vehicle. In some cases, a synthetic sensor may use machine learning models to perform the synthesis.

[0029] "Application": A software module that obtains signals from a signal service. A synthetic sensor is a type of application.

[0030] "Insight": A synthesized signal created by a synthetic sensor based on received signals.

[0031] "Signal Definition": Information on a signal from the signal catalog, including the path of the node that produces the signal and the VSS element that describes the signal (such as description, type, data type, units, tolerances, etc.).

[0032] "Signal Semantic": Part of a signal definition that relates to the semantics of the signal, e.g., the data types and units that are required for a program to correctly interpret the signal.

[0033] The evolution of in-vehicle applications is further complicated by the lack of standardization of vehicle data sources and how signals should be consumed. For example, a synthetic sensor that is designed to work with signal definitions from a specific version of a signal catalog of a given publisher may not work with a different version of the signal catalog, or with a signal catalog of a different origin, if the signal definitions in other signal catalogs are semantically different. It is inefficient for an application to check the signal catalog origin and signal catalog version for each signal it processes and then adapt to its specific signal catalog.

[0034] Furthermore, it must be ensured that only secure access to the signals is provided.

[0035] This disclosure provides a solution to the above problems by leveraging EUUID, which is built on top of COVESA's VSS to quickly identify semantic differences between signals and enable efficient verification of applications.

[0036] Referring now to FIG. 1, a portion of the signal catalog is illustrated.

[0037] 1, a catalog 100 defined according to VSS includes a root node 110 named Vehicle. For purposes of simplicity, only two nodes are shown that are child nodes of the root node 110, namely, Vehicle.Cabin 120 and Vehicle.Speed ​​130. Vehicle.Cabin 120 is further shown as having two child nodes, namely, Vehicle.Cabin.Door 140 and Vehicle.Cabin.Seat 150. Other nodes are omitted for simplicity.

[0038] In this example, Vehicle.Speed ​​120 is a data node, depicting a traffic light indicating the speed of the vehicle, while all other nodes are branching nodes. Vehicle.Speed ​​120 may have a JSON representation as follows: [ka]

[0039] As can be seen from above, the JSON representation of Vehicle.Speed120 comprises a data type that is a float, a description "Vehicle.Speed", a type "Sensor", and units "km / h". The JSON representation further includes a UUID, an EUUID, and read permissions.

[0040] A permission labeled "x-read-permission" allows control over whether an application has read access to a signal from a node. For example, some nodes may provide signals that contain personal identification information, such as a vehicle identification number (VIN). Thus, in accordance with at least some embodiments of the present disclosure, each node may have associated with it their read permissions, indicating whether an application has permission to receive signal values ​​from that node. In accordance with at least some embodiments of the present disclosure, each writable node may have associated with it their write permissions, indicating whether an application has permission to write signal values ​​to the node.

[0041] In accordance with 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. This may be implemented, for example, by the following JSON representation in a Permission File (320), which is provided as a non-limiting example: [ka]

[0042] In the above example, Vehicle.READ is defined on the root node, Vehicle node. In order to have access to any signal from any node that inherits this permission from the Vehicle node, a client is required to be granted the Vehicle READ permission.

[0043] The above example further includes a Vehicle.PII.READ permission defined for the Vehicle.VehicleIdentification and Vehicle.Driver.Identifier nodes. In this case, to have access to these nodes, or their child nodes, a client needs to be granted the Vehicle.PII.READ permission. Although these nodes are child nodes of the vehicle node, they do not inherit the Vehicle.READ permission because they have been assigned their own read permission in the permission file. Other child nodes that do not have their own read permission assigned inherit their permission from their parent node.

[0044] A similar mechanism as described above can be used to provide write permission.

[0045] In general terms, when a permission is defined for a given node, a client will need to be granted that permission in order to read or write to the given node or any child nodes of the given node.

[0046] In accordance with at least some embodiments of the present disclosure, nodes are assigned an EUUID that uniquely identifies a node from a particular signal catalog of a given version and a given origin. Each EUUID is therefore unique and uniquely identifies a node with its particular semantic information.

[0047] In accordance with at least some embodiments of the present disclosure, the EUUID for a given node may be created by a hash function of the node's VSS signal definition, and includes the node path name and semantically related elements that define the signal. As non-limiting examples, the semantically related elements may comprise the type (whether the node is a branch, sensor, actuator, or attribute), the data type (unsigned integer, integer, floating point, double, string, etc.), the units of the values ​​in the signal (e.g., km / h, mph, degrees Celsius, etc.), the minimum value, the maximum value, or a limited set of values ​​the signal can take.

[0048] Reference is now made to Figure 2, which illustrates the problems with prior art systems. Looking at Figure 2, a vehicle data source 210 reports a signal (mph). An application is interested in this signal and also expects the signal's value to be expressed in mph. This signal is received by a signal connector 220, which then normalizes the signal to km / h before passing the signal to a signal service 230. The signal service 230 then passes the signal to a composite sensor 240, which then converts the value back to mph for the application 250.

[0049] As can be appreciated, converting from mph to km / h and then back to mph can be inefficient and introduce rounding errors. In at least some embodiments of the present disclosure, the original signal from the data source 210 is preferably conveyed through the signal service 230 in the units expected by the synthetic sensor 240, preventing a double conversion.

[0050] Reference is now made to Figure 3. As seen in Figure 3, the original signal catalog 310 is combined with the permission file 320 in a conversion tool 330 to produce the enhanced signal catalog 340. Specifically, for each node in the original signal catalog 310, an EUUID is created and new nodes with EUUIDs are added to the enhanced signal catalog 340. In accordance with at least one embodiment of the present disclosure, the EUUIDs are created by a hash of the node path name and semantic information for the node. In at least some embodiments, the hash is a 64-bit hash.

[0051] Among other things, this means that if a node from a first signal catalog has the same pathname and the same semantics as a node from a second signal catalog, then both nodes will have the same EUUID. This implies that unless a node has changed semantics between two different signal catalogs, it will produce the same EUUID.

[0052] In accordance with at least some embodiments of the present disclosure, the enhanced signal catalog further comprises permissions for each node. The permission information may be provided in a permission file 320, as illustrated in FIG. 3. For example, the permission file 320 may include a JSON representation of the permissions, as described above, which may be used by the conversion tool 330 to add the required permission elements to each node.

[0053] The above can be illustrated based on the following example, where the following JSON snippet displays nodes in the original signal catalog 310: [ka]

[0054] After transformation by the transformation tool 330, the corresponding nodes in the enhanced signal catalog 340 become: [ka]

[0055] As can be seen, the corresponding node in the enriched signal catalog 340 is modified with respect to the original node in that it includes the elements "x-euuid" and "x-read-permission". The EUUID element is created based on the node path name, in this case Vehicle.Speed, and a hash of the semantics information, in this case including the data type, type and units. The permission element is based on the contents of the permission file.

[0056] The EUUID uniquely identifies a signal definition and semantics across different origins and versions of the signal catalog, and can be used to verify that a received signal matches its expected semantics.

[0057] Specifically, applications that use a signal's value need to know the exact definition of the signal in advance. The EUUID simplifies the process for this validation.

[0058] For example, the semantic information for a node may change over time based on the origin or version of the signal catalog. In one scenario, an Original Equipment Manufacturer (OEM) making vehicles in the United States may use sensors that report vehicle speed in mph. However, if the signal catalog is based on VSS, the vehicle speed would need to be converted to km / h to match the VSS semantics.

[0059] OEM applications and synthetic sensors will likely also use mph units and therefore there will be a need to convert values ​​from km / h back to mph as illustrated above with respect to FIG.

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

[0061] However, in that case, a third-party synthetic sensor specified based on VSS installed on one such vehicle with a modified signal catalog would receive data in mph when it predicts km / h, potentially leading to an undetected error. When having an EUUID, the EUUID generated for the Vehicle.Speed ​​node based on VSS will be different from the EUUID generated for the OEM signal catalog because of the difference in semantics (units of mph instead of km / h).

[0062] Therefore, the use of EUUIDs provides a convenient mechanism to verify that expected signals match those being received. While the above is illustrated with respect to the Vehicle.Speed ​​node, the same verification can be performed for all data nodes in the signal catalogue.

[0063] In the absence of an EUUID, validation of an application can be performed by comparing each element of each signal definition in the reference signal catalog against the corresponding element in the signal catalog for which the application is being validated. However, this is a costly and time-consuming operation. By leveraging the semantic information encoded in the EUUID, validation is greatly simplified, as described in detail below.

[0064] Referring now to FIG. 4, it illustrates how a signal connector may use the EUUID when normalizing signal values ​​in a vehicle 460.

[0065] 4, input data 410 is received at a signal connector 440. The input data represents signals reported by various data sources in the vehicle, such as sensors. According to at least one embodiment, the input data may be organized in tuples of (SigID, Value), where SigID represents an identifier of the data source that identifies the vehicle manufacturer, and Value is the value being reported.

[0066] A signal connector 440 is created from the OEM signal catalog 420 using a mapping table 430 to convert an input tuple as an output tuple of (EUUID, F(Value)), where EUUID is the EUUID corresponding to the SigID, and F(Value) is the received value transformed by a function F, which normalizes the value into the semantics defined by the vehicle's signal catalog. In some cases, no conversion is necessary and F(x)=x. However, in other cases, conversion is necessary, and in those cases F is selected to perform the appropriate conversion.

[0067] The function F may normalize any type of value being received to another type of value expected by the application. For example, in some cases, signals displaying in mph are converted to values ​​in km / h. Alternatively, or in addition, signals expressed as integers may be converted to floating point. Other possibilities exist and are contemplated within the scope of this disclosure.

[0068] Specifically, the mapping table 430 comprises multiple mappings between SigIDs, EUUIDs, and functions F. Upon receiving a tuple (SigID, Value) from a data source, the mapping table is used to find the EUUID and function F that corresponds to the received SigID. As described above, the function F may perform one or a series of transformations on the received Value. Then, as illustrated in FIG. 2 described above, the signal connector 440 reports the tuple (EUUID, F(Value)) to a signal service, which may then report it to a synthetic sensor and ultimately to an insight consumer.

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

[0070] The mapping table is based on information from the signal catalog 420. According to at least some embodiments, this information may comprise, but is not limited to, node path names, EUUIDs, and semantics information, as described above.

[0071] In some embodiments, the signal catalog 420 is different from the signal catalog used by the signal service to which the signal connector 440 is connected. This is the case, for example, when third party suppliers to the vehicle manufacturer provide signal connectors based on their own signal catalogs, which have a different origin or version than the signal catalog used by the vehicle manufacturer. The signal connectors may be validated against the signal catalogs using techniques described below.

[0072] The EUUIDs may also be used to enrich a composite sensor manifest, as illustrated in FIG. 5. With reference to FIG. 5, a composite sensor manifest 510 comprises a list of sensors of interest represented as node path names. A translation tool 530 takes as input the sensor manifest 510 and a signal catalog 520. The signal catalog 520 may comprise information about all signals in the catalog in JSON format. The translation tool 530 may then take the node path names from the sensor manifest 510 and, for each of them, find a corresponding EUUID from the signal catalog 520. The translation tool 530 may then output an enriched sensor manifest 540, each of which is associated with an associated EUUID.

[0073] Thus, conversion tool 530 simplifies the work of application developers by freeing them from having to manually handle EUUIDs and instead letting them work with node path names that are designed to be human readable. Thus, a manifest for an application can be initialized with required node path names, which are then automatically augmented with EUUIDs by conversion tool 530 to generate an augmented manifest.

[0074] Thus, a synthetic sensor developer can obtain the semantic specification for each signal from the signal catalog and code the synthetic sensor accordingly. The origin and version of the signal catalog does not matter because the EUUID uniquely corresponds to the exact semantic information. Therefore, synthetic sensors can be deployed "as is" on any vehicle that supports these EUUIDs.

[0075] Reference is now made to FIG. 6, which illustrates the use of the EUUID to validate a synthetic sensor manifest against a signal catalog.

[0076] As seen in Figure 6, the validation tool 630 takes as input the enriched composite sensor manifest 610, which includes a list of node path names for sensors of interest and their corresponding EUUIDs. The enriched composite sensor manifest 610 may be created based on the process illustrated in Figure 5 described above.

[0077] The validation tool 630 further takes as input a signal catalog 620. The signal catalog 620 may correspond, for example and without limitation, to an OEM signal catalog produced by vehicle manufacturers and installed on their vehicles. Notably, the signal catalog is typically different than the signal catalog used to create the enhanced synthetic sensor manifest 610.

[0078] The validation tool 630 may then compare each EUUID for a given node pathname from the enriched composite sensor manifest 610 with the EUUIDs stored in the signal catalog 620 for the same node pathname. If both EUUIDs match, this may be indicated in the validation report 640 output by the validation tool 630. Similarly, if an EUUID is found in the signal catalog 620 for a given pathname that does not match the EUUID of the pathname from the enriched composite sensor manifest 610, this may also be indicated in the validation report 640. In other cases, if no EUUID is found that corresponds to the pathname from the enriched composite sensor manifest 610, this may also be indicated in the validation report 640.

[0079] According to at least some embodiments, the validation tool 630 may launch a manifest editing tool (not shown) to allow the application developer to specify whether some signals are optional or whether some signals can be replaced by other signals.

[0080] From the report 640, a determination can be made as to whether the composite sensor can be installed on the vehicle. Specifically, if the validation report 640 indicates that all EUUIDs from the enriched composite sensor manifest were found in the signal catalog 620, then the composite sensor can be deployed on the vehicle on which the signal catalog 620 is installed. Alternatively, if the validation report indicates that there are some mismatches or missing EUUIDs, the composite sensor may need to be modified prior to installation on the vehicle.

[0081] This procedure facilitates the deployment of synthetic sensors across different platforms without placing undue burden on developers. Specifically, a developer of a synthetic sensor can be assured that the semantics of data received from any sensor will match the semantics expected by the synthetic sensor without having to be concerned about the origin or version of the signal catalog for which the synthetic sensor was developed, or the origin or version of the signal catalog installed in the vehicle. While the origins and versions of both of these signal catalogs may be different, if the EUUIDs of the sensors of interest match, the synthetic sensor will function correctly.

[0082] If verification indicates that a mismatch exists, a number of approaches can be taken to remedy the situation.

[0083] In accordance with at least one embodiment of the present disclosure, a synthetic sensor may be capable of converting signals that use different semantics into signals that are formatted according to expected semantics, for example, as illustrated with respect to FIG. 4 described above.

[0084] According to at least some embodiments, converting the signal may include converting the received signal from a first unit to a second unit, e.g., between mph and km / h. Converting the signal may include converting the data type of the signal to a different data type, e.g., from floating point to integer or vice versa.

[0085] In accordance with at least some embodiments, a synthetic sensor may be modified to deliver functionality available from a subset of all signals it would normally require. In this situation, the synthetic sensor has a list of signals it requires, as well as a list of signals it is not required to require. The list of required and optional sensors may be specified in an enhanced synthetic sensor manifest, and the validation tool described above with respect to FIG. 6 may report on whether these sensors are available on a given vehicle.

[0086] For example, a synthetic sensor may be able to deliver usable functionality when a signal is missing by instead utilizing numerical or other signals, combining those values ​​into something meaningful, and substituting the value of the originally required signal.

[0087] According to some embodiments, a synthetic sensor may be modified to ignore values ​​outside of the range of expected values ​​without reporting an error.

[0088] According to at least some embodiments, a synthetic sensor may be modified to use an introspection-like mechanism that requests information about the signal from a signal service. For example, a synthetic sensor may be modified to function regardless of whether the vehicle speed is reported in mph or km / h by obtaining the units being reported from the signal service and adapting accordingly.

[0089] In such cases, while introspection may be useful, performing run-time operations is expensive and it would be inefficient to perform this check at run-time for all signals of interest to the synthetic sensor, especially given that most signals are compliant with normalization and will not change between signal catalog versions or origins.

[0090] Therefore, the use of EUUIDs makes it possible to omit such run-time checks entirely, or to use such run-time checks only in the few isolated situations where the EUUID of a synthetic sensor does not match the EUUID in the signal catalog or is missing from the signal catalog.

[0091] Below is an example of a portion of an enhanced synthetic sensor manifest in accordance with at least one embodiment of the present disclosure. [ka]

[0092] In the above example, the required EUUIDs include EUUID-A, one of EUUID-B, EUUID-C or EUUID-D, and either EUUID-E, or both EUUID-F and EUUID-G. Additionally, if EUUID-H or EUUID-I, or both, are available, the synthetic sensor can provide enhanced services.

[0093] Specifically, the first element in the list of EUUIDs is an "allOf" tag, which is used to indicate that all of the listed elements are required. In this case, the required elements are listed as EUUID-A, anyOf:[EUUID-B,EUUID-C,EUUID-D], and oneOf:[EUUID-E,{allOf:[“EUUID-F”,“EUUID-G”]}]. The "anyOf" tag indicates that any one of the listed elements is required, in this case, EUUID-B, EUUID-C, and EUUID-D. The "oneOf" tag is used to indicate that only one of the listed elements is required. Based on this syntax, an enhanced composite sensor manifest can indicate which combination of sensors is required and which is optimal.

[0094] When deployed in a vehicle, the signal catalog can match the exact set of signals supported by the data connectors in that vehicle to either a superset of these signals or a subset thereof. With an exact match, it is easier for a synthetic sensor to determine, prior to deployment or dynamically at run-time, whether a signal is supported in the vehicle. However, requiring an exact match significantly hampers the ability to dynamically modify the set of signals supported in the vehicle.

[0095] For example, some vehicle services may be offered 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, an associated signal becomes available in the vehicle. This may be implemented in a variety of ways.

[0096] In one embodiment, a signal may be added indicating whether a subscription has been purchased, while a signal indicating heated seats is always present in the vehicle's signal catalog.

[0097] In other embodiments, a separate permission may be assigned to the signals required by the heated seat service, and this permission may be granted to the appropriate instance of the composite sensor.

[0098] In yet another embodiment, a new signal catalog with the additional signals required by the seat heater service can be delivered to the vehicle.

[0099] In yet another embodiment, the signal service queries the signal connectors as to what signals are supported by each signal connector. The signal service then generates a signal catalog that matches the signals supported by the signal connectors. The downside of this approach is that other applications on the vehicle must also validate against this signal catalog to make sure they function properly. In yet 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).

[0100] Vehicle manufacturers manage fleets of these versions based on vehicle make, vehicle model, vehicle trim, as well as vintage. Managing an exact signal catalog for each collection of vehicles, or even for each individual instance of a vehicle, can prove unwieldy. For that reason, vehicle manufacturers may wish to maintain a smaller set of signal catalogs, each with a superset of signals corresponding to what any particular vehicle, make, or model may support. Such signal catalogs can be statically deployed in vehicles, along with a mechanism for clients of the signal service to dynamically determine at run-time whether a signal is available in the vehicle.

[0101] In accordance with at least one embodiment, a signal service can dynamically create an accurate signal catalog from a set of EUUIDs reported by a set of data connectors by extracting relevant nodes from a superset of the signal catalog.

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

[0103] The first case, where the two sets match exactly, can be achieved by either generating a signal catalog from the EUUIDs supported by the data connector, or by creating a signal catalog that is expected to contain a set of signals and then verifying that the sets of EUUIDs supported by the set of data connectors match.

[0104] The second case may be used in situations where vehicle manufacturers want to minimize the number of signal catalogs they have to manage. In this scenario, a single signal catalog with a superset of signals is installed across different vehicles, even if each of these vehicles does not use each signal in the signal catalog.

[0105] The third case may create an error situation where some signals supported by the Data Connector are not supported in the signal catalog, however this situation may be useful if a manufacturer wants to limit the set of signals available for a composite sensor.

[0106] A fourth case occurs when the signal catalog contains a superset of signals expected to be supported in the vehicle and the data connector supports a different but overlapping set. When this occurs, it generally indicates an error that should be corrected.

[0107] Referring now to FIG. 7, a method for validating an application is illustrated.

[0108] The method begins at block 700 and proceeds to block 710 where the node path names in the manifest for the application are processed. The node path names in the manifest indicate signals that are required for the application to function properly. The method then proceeds to block 720 where a signal catalog is referenced to look up the node path names. The reference signal catalog may be a signal catalog used to develop the application being verified. Upon finding the node path name by referencing the signal catalog, a corresponding EUUID has been identified.

[0109] The method then proceeds to block 730, where the EUUID is added to the manifest for the application in association with the node path name.

[0110] Once all node pathnames in the application manifest have been processed, the application manifest is an "enhanced application manifest" with an EUUID corresponding to each node pathname.

[0111] The method then proceeds to block 740 where each node path name in the augmented manifest is processed. At block 750, a second signal catalog is searched for the node path name. This second signal catalog may be the signal catalog used by the vehicle in which the application is to be installed. If the node path name is found in the second signal catalog, the EUUID from the second signal catalog is recorded and compared to the EUUID from the augmented manifest.

[0112] 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.

[0113] Once all node pathnames have been verified against the second signal catalog, the method proceeds to block 770 and checks if all EUUIDs match. If yes, the method proceeds to block 780 and the application may be loaded onto the vehicle. If not, modifications to the application may be made prior to loading and the demonstration methods described herein may be repeated with the modified application. The method then ends at block 790.

[0114] Referring now to FIG. 8, another method of validating an application against a signal catalog is illustrated.

[0115] While this method is simpler than the method illustrated in Figure 7, it is suitable when the application developer can provide the reference signal catalog used to develop the application to the OEM. Therefore, to perform the method of Figure 8, we need the reference signal catalog, the OEM signal catalog, and a list of the node path names used by the application. The reference signal catalog is the signal catalog used to develop the application, and the OEM signal catalog is the signal catalog used by the OEM for that vehicle.

[0116] In some embodiments, the application manifest may be replaced by a list of signals of interest to the application, which may be provided through a graphical user interface (GUI) according to at least some embodiments.

[0117] The method begins at block 800 and proceeds to block 810 where each node path name in the manifest for the application is processed. The method then proceeds to block 820 where the node path name is looked up in a reference signal catalog, and then proceeds to block 830 where the node path name is looked up in an OEM signal catalog.

[0118] The method then proceeds to block 840 where an EUUID for the signal catalog is calculated and then to block 850 where an EUUID for the OEM signal catalog is calculated. In some embodiments, the signal catalog may already include EUUIDs for all signals, in which case the EUUIDs are not recalculated but are simply obtained from the signal catalog.

[0119] At block 860, the two EUUIDs from each signal catalog are compared and the result of the comparison is reported. For example, the result of the comparison may be a match, no match, or missing in the EUUID. Optionally, at block 860, an enriched application manifest may also be created that includes the EUUIDs for each signal.

[0120] Then, if there are more node pathnames to be processed, the method returns to block 810, or alternatively, when all node pathnames have been processed, the method proceeds to block 870 where it is determined whether all pairs of EUUIDs match. If all pairs of EUUIDs match, the application may be loaded onto the vehicle at block 880, after which the method ends at block 890. If the EUUIDs do not match, the application may be modified as described above and the verification method may then be repeated.

[0121] The above may be implemented using any computing device, one simplified diagram of which is shown with respect to Figure 9. The computing device of Figure 9 can be any fixed or mobile computing device.

[0122] 9, the device 910 includes a processor 920 and a communication subsystem 930, which cooperate to perform the methods of the embodiments described above. The communication subsystem 930 enables the device 910 to communicate with other devices or network elements and may vary based on the type of communication being performed. Additionally, the communication subsystem 930 may comprise multiple communication technologies, including any wired or wireless communication technology.

[0123] The processor 920 is configured to execute programmable logic, which may be stored on the device 910 along with data and may be illustrated in the example of FIG. 9 as memory 932. The memory 932 may 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 may be a tangible or transitory / non-transitory medium, such as an optical memory (e.g., CD, DVD, etc.), a magnetic memory (e.g., tape), a flash drive memory, a hard drive memory, or other memory known in the art.

[0124] Alternatively, or in addition to the memory 932, the device 910 may access data or programmable logic from an external storage medium, for example through the communications subsystem 930.

[0125] 9, one or more sensors 940 may be associated with the computing device, however, this is optional and in some cases the computing device 910 will not be associated with any sensors.

[0126] Communication between the various elements of the device 910 may, in one embodiment, be through an internal bus 960. However, other forms of communication are possible.

[0127] The embodiments described herein are examples of structures, systems, or methods having elements that correspond to elements of the technology of the present application. The description written herein may enable one of ordinary skill in the art to make and use embodiments having alternative elements that similarly correspond to elements of the technology of the present application. The intended scope of the technology of the present application therefore includes other structures, systems, or methods that do not differ from the technology of the present application described herein, and further includes other structures, systems, or methods that have substantial differences from the technology of the present application described herein.

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

[0129] Additionally, the techniques, systems, subsystems, and methods described and illustrated in various implementations as separate or distinct may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or described as being coupled or directly coupled or in communication with each other may be indirectly coupled or in communication through some interface, device, or intermediate component, whether electrical, mechanical, or otherwise. Other examples of modifications, substitutions, and alternatives can be ascertained and made by those skilled in the art.

[0130] While the above detailed description illustrates, describes, and points out the fundamental novel features of the present disclosure as applied to various implementations, it will be understood that various omissions, substitutions, and changes in the form and details of the illustrated systems may be made by those skilled in the art. In addition, no order of method steps is implied by the order in which they appear in the claims.

[0131] In the preceding description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details set forth above. The appended claims may cover such modifications and variations.

Claims

1. 1. A method for validating an application on a computing device, the method comprising: augmenting a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, augmenting the manifest comprising: searching a reference signal catalog for a unique identifier corresponding to the node path name; adding the node path name and the unique identifier into an enriched manifest; and Validating the enriched manifest against a signal catalog, the validating comprising: searching the second signal catalog for a second unique identifier corresponding to the node path name; 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; Including, A method comprising:

2. The method of claim 1 , further comprising mounting the synthetic sensor on a vehicle upon determining that the second unique identifier is identical to the unique identifier.

3. The method of claim 2 , wherein the vehicle has the second signal catalog mounted thereon.

4. 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 of claim 1 , further comprising: prior to said enrichment, computing a respective unique identifier for each respective node path name in said reference signal catalog and said second signal catalog.

6. The method of claim 5 , wherein the respective unique identifier is computed as a hash of the respective node path name and semantics information of the respective node path name.

7. The method of claim 6 , wherein the hash is a 64-bit hash.

8. 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 that corresponds to an optional signal for the application.

10. 1. A computing device for validating an application, comprising: A communications subsystem; Processor and It is equipped with The communication subsystem and the processor include: augmenting a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, augmenting the manifest comprising: searching a reference signal catalog for a unique identifier corresponding to the node path name; adding the node path name and the unique identifier into an enriched manifest; and Validating the enriched manifest against a signal catalog, the validating comprising: searching the second signal catalog for a second unique identifier corresponding to the node pathname; 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; Including, 2. A computing device that cooperates to perform the steps of:

11. The computing device of claim 10 , wherein the communications subsystem and the processor further cooperate to mount the synthetic sensor on a vehicle upon determining that the second unique identifier is identical to the unique identifier.

12. The computing device of claim 11 , wherein the vehicle has the second signal catalog mounted thereon.

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. 11. The computing device of claim 10, wherein the communications subsystem and the processor further cooperate to calculate, prior to the enhancing, a respective unique identifier for each respective node pathname in the reference signal catalog and the second signal catalog.

15. The computing device of claim 14 , wherein the respective unique identifier is computed as a hash of the respective node pathname and semantic information of the respective node pathname.

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

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. 1. A computer-readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising: augmenting a manifest of the application, the manifest of the application comprising node path names corresponding to signals required by the application, augmenting the manifest comprising: searching a reference signal catalog for a unique identifier corresponding to the node path name; adding the node path name and the unique identifier into an enriched manifest; and Validating the enriched manifest against a signal catalog, the validating comprising: searching the second signal catalog for a second unique identifier corresponding to the node pathname; 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; Including, A computer-readable medium comprising instructions for performing the steps of:

20. 20. The computer readable medium of claim 19, wherein the executable code further comprises instructions for mounting the synthetic sensor on a vehicle upon determining that the second unique identifier is identical to the unique identifier.

Images