Patent Description:
Electronic systems employing software are widespread in the automobiles, and the uses to which they are put in vehicles are constantly expanding. Meanwhile, vehicles in use may encounter security issues or safety issues pertaining to their electronic systems, which may be addressable through software updates.

Software of individual vehicles may be relatively easily updated, such as by taking the individual vehicles into a repair shop. However, for a fleet of vehicles, which may number in the thousands or even in the tens of thousands, management of software updates (such as software updates, firmware updates, and security patches) across the fleet may be resource intensive. Planning for and managing the software updates across the fleet may itself be time consuming and may potentially require manual review of available information. Building a prioritized plan for software updates, and performing the software updates, may accordingly be very difficult, and potentially not feasible. This may leave fleets of vehicles without software updates to protect them against emerging security threats and safety problems, and may also leave update systems overly loaded.

Document <CIT> discloses a method that provides for user authentication, access to data or software applications and/or control of various electronic devices based on hand gesture recognition. The hand gesture recognition can be based on acquiring, by an HD depth sensor, biometrics data associated with user hand gesture including 3D coordinates of virtual skeleton joints, user finger and/or finger cushions. The biometrics data can be processed by machine-learning algorithms to generate an authentication decision and/or a control command. The authentication decision and/or control command can be used to activate a user device, run software or provide access to local or online resources.

Disclosed herein are methods and mechanisms for updating applications for electronic systems of vehicles, which may be well-suited to address the problems of keeping applications well-updated across fleets of vehicles. When an issue is observed related to a reference vehicle-for example, a safety problem, or a recently-observed type of attack, or a newly-discovered security vulnerability-a recommendation system may comprehensively analyze the hardware configurations, hardware versions, software configurations, and software versions of vehicles in the fleet to determine which vehicles may be most similar to the reference vehicle. Those vehicles may subsequently be prioritized for receiving appropriate software updates.

In some embodiments, which may be related to security vulnerabilities, a recommendation system may take into account specific attack paths between "attack surfaces" of the vehicle (e.g., interfaces which may be vulnerable to infiltration, which may also be referred to herein as "entry points" or "attack entry points") and the various electronic devices of a vehicle. Accordingly, the recommendation systems may take into account which vehicles in a fleet of vehicles have attack paths that are similar to the attack paths of a reference vehicle.

For example, if a security vulnerability is detected on a software component of a vehicle, the recommendation system may determine which vehicles in the fleet have that software component and may prioritize those vehicles for updating, or may determine which of those vehicles may be most vulnerable (e.g., because they share the relevant attack path with the reference vehicle) and may prioritize those vehicles.

In some embodiments, the issues described above may be addressed by a method including establishing a first vector of weighted presences of a set of vehicle features in a first vehicle, and establishing a second vector of weighted presences of the set of vehicle features in a second vehicle. A value of a distance function, such as an inner product of the vectors, is calculated based on an inner product of the first vector and the second vector, wherein the value of the distance function establishes a similarity score between the first vehicle and the second vehicle, and an update is recommended for the second vehiclewhen the similarity score exceeds a predetermined threshold value, wherein the update includes at least one of software update, firmware update, or security patch. In this way, the degree to which the first vehicle resembles the second vehicle may be analyzed, and action taken based upon how similar the vehicles are.

A method may comprise establishing a first vector of weighted presences of a set of vehicle features in a reference vehicle, and establishing a set of second vectors of weighted presences of the set of vehicle features across a fleet of vehicles. A distance (e.g., a distance function) between the first vector and the set of second vectors may be calculated to establish a set of similarity scores between the reference vehicle and the fleet of vehicles, and a set of actions may be taken for the fleet of vehicles based at least in part upon the set of similarity scores. In this way, the degree to which each vehicle across a fleet of vehicles is similar to a reference vehicle may be analyzed, and action (such as software updates, firmware updates, and security patches) may be taken depending upon which vehicles of the fleet are sufficiently similar to the reference vehicle.

Another method may comprise establishing a first vector including weighted presences of a set of vehicle features in a first vehicle, and a second vector of weighted presences of the set of vehicle features in a second vehicle. The set of vehicle features may include one or more possible attack paths between a set of attack surfaces, and a set of potential target devices, such as Electronic Control Units (ECUs). A distance between the first vector and the second vector may be calculated (e.g., based on differences between the first vector and the second vector) to establish a similarity score between the first vehicle and the second vehicle, and an action for the second vehicle may be recommended at least in part upon the similarity score. In this way, similarities between specific attack paths through hardware components may be used to find and prioritize vehicles within a fleet for receiving updates.

It should be understood that the summary above is provided to introduce in simplified form a selection of concepts that are further described in the detailed description. It is not meant to identify key or essential features of the claimed subject matter, the scope of which is defined uniquely by the claims that follow the detailed description. Furthermore, the claimed subject matter is not limited to implementations that solve any disadvantages noted above or in any part of this disclosure.

The disclosure may be better understood from reading the following description of non-limiting embodiments, with reference to the attached drawings, wherein below:.

Disclosed herein are mechanisms and methods for establishing similarity scores among vehicles within a fleet of vehicles, which may then be used to prioritize software updates or application updates to the vehicles in the fleet (e.g., software updates, firmware updates, security patches, and so on). <FIG> and <FIG> illustrate relationships between vehicles, records carrying information about vehicle features, and vectors based upon the records. <FIG> shows a block diagram of an internal network topology of a vehicle related to the records and vectors of <FIG> and <FIG>. <FIG> shows a chart of similarity scores between a reference vehicle and the other vehicles of the fleet, in accordance with a first analytical mode. <FIG> shows an interconnection diagram of a network topology of a vehicle, in which various devices at nodes of the diagram may be endpoints for an attack path or nodes through which an attack path passes. <FIG> shows a chart of similarity scores between a reference vehicle and other vehicles of the fleet, in accordance with a second, more topological analytical mode, based upon network topologies of the sort depicted in <FIG>. <FIG> show flow charts for methods of establishing similarity scores, as discussed herein.

<FIG> illustrates a relationship <NUM> between a vehicle <NUM> and an associated record <NUM>, the entries of which may contain a set of features <NUM> that are present in vehicle <NUM>. Features <NUM> may include, for example, one or more devices of vehicle <NUM>, such as one or more Electronic Control Units (ECU) of vehicle <NUM>. Features <NUM> may also include other devices incorporated in the vehicle, such as sensors and actuators. Various devices included in features <NUM> may be capable of intercommunicating through one or more in-vehicle networks and/or interconnects, such as Controller Area Network (CAN) bus interconnects, Local Interconnect Network (LIN) interconnects, FlexRay interconnects, or any other vehicle networks and/or busses.

Features <NUM> may also include one or more applications and/or software programs of the devices incorporated in the vehicle. The applications may provide instructions and/or other control to the devices, and may include code at any of a variety of levels of a software stack (e.g., firmware, operating systems (OSes), and/or software). Each device may be associated with one or more applications, and record <NUM> may indicate associations between the applications of features <NUM> and the devices of features <NUM>.

The entries of record <NUM> may also contain version information <NUM> pertaining to features <NUM>. For example, record <NUM> may contain information indicating a type (e.g., make and/or model) of each device and/or a hardware version for each device (e.g., a revision identification, a manufacturing date, a series number, and/or a sub-model identification). Similarly, record <NUM> may contain information indicating a software version for each application (e.g., a revision identification and/or a release date).

<FIG> illustrates a relationship <NUM> between a vehicle <NUM>, a record <NUM>, a first vector <NUM>, and a second vector <NUM>. Vehicle <NUM> may be substantially similar to vehicle <NUM>. Record <NUM> may have entries corresponding with a super-set of features encompassing all features, and all versions of each feature, that may be present across a fleet of vehicles. In other words, record <NUM> may have a number of entries encompassing all the distinct combinations of features (e.g., devices and applications) and version information (e.g., hardware type, hardware version, and software version) present in all the vehicles of the fleet. Accordingly, record <NUM> may include every possible feature of all the vehicles of the fleet, and every possible version of each feature.

A first vector <NUM> is established for vehicle <NUM>, e.g., based upon record <NUM>. First vector <NUM> may have a number of elements equivalent to the number of vehicle features in record <NUM> (e.g., the number of feature/version combinations present across the fleet of vehicles). The elements of first vector <NUM> may respectively carry a set of parameters, expressed as binary values (e.g., values of "<NUM>" or "true" and values of "<NUM>" or "false"), which indicate the presence, within vehicle <NUM>, of a corresponding sub-set of the vehicle features in record <NUM>. Thus, first vector <NUM> carries parameters indicating which features, and which versions of each feature, are present in vehicle <NUM>.

A second vector <NUM> is also established for vehicle <NUM>. Second vector <NUM> may have a number of elements equivalent to the number of elements of first vector <NUM> (which, in turn, is equivalent to the number of feature/version combinations in record <NUM>). The elements of second vector <NUM> respectively carry a set of predetermined weights respectively corresponding with the vehicle features of record <NUM>. The weights may include or may be, for example, security-related weights.

In some embodiments, second vector <NUM> may merely carry a set of predetermined weights applicable for vehicle <NUM>, but other implementations are possible. For some embodiments, second vector <NUM> may carry a set of predetermined weights applicable for a subset of vehicles in the fleet, or for all the vehicles in the fleet.

Turning from <FIG> for a moment, <FIG> shows a block diagram of an internal network topology <NUM> of a vehicle (which may be substantially similar to vehicle <NUM> and/or vehicle <NUM>). Topology <NUM> may comprise a central network portion <NUM>, a first sub-network <NUM>, a second sub-network <NUM>, a third sub-network <NUM>, a fourth sub-network <NUM>, and a fifth sub-network <NUM>.

Each of the sub-networks of topology <NUM> may couple a number of devices to central network portion <NUM>. In some sub-networks, switch devices may connect individually to other devices by dedicated interconnect, such as in first sub-network <NUM> and second sub-network <NUM>. In some sub-networks, domain gateway devices may connect to shared interconnect, which may then connect to other devices, such as in third sub-network <NUM>, fourth sub-network <NUM>, and fifth sub-network <NUM>. Various devices of the sub-networks may be, or may include, ECUs. Some of the devices of the sub-networks may pertain, for example, to advanced driver assistance capabilities of the vehicle (e.g., Light Detection and Ranging (LIDAR) devices, Radio Detection and Ranging (RADAR) devices, cameras, various sensors, and/or various actuators). Other devices of the sub-networks may pertain to other capabilities, such as infotainment capabilities, a powertrain of the vehicle, a chassis of the vehicle, and/or a body of the vehicle.

Topology <NUM> may encompass a set of devices which may be part of a set of features of the corresponding vehicle. In the context of <FIG> and <FIG>, an internal network topology of either vehicle <NUM> or vehicle <NUM> may be substantially similar to topology <NUM>.

Returning to <FIG>, the devices of topology <NUM>, and the software applications of topology <NUM>, may be indicated as present in vehicle <NUM> by first vector <NUM>. Moreover, the weights of second vector <NUM> may reflect the significance of each feature/version combination present in vehicle <NUM> (and potentially feature/version combinations present in other vehicles of the fleet) with respect to an over-arching metric by which the vehicles of the fleet may be analyzed, as discussed herein. In various embodiments, the metric may be safety, or security, or update suitability, for example.

The elements of first vector <NUM> may then be multiplied by the respectively corresponding elements of second vector <NUM> to create a vector of weighted presences for vehicle <NUM>. The resulting vector of weighted presences may then have significance with respect to the over-arching metric by which the fleet is to be analyzed.

Since a fleet may include a very large number of vehicles, updates to the vehicles of the fleet for various purposes (for example, software-application updates) may be resource-intensive. The weighted presences may advantageously support prioritized management of updates to the fleet.

So, for example, the metric may be security, and the weights of second vector <NUM> may be predetermined security-related weights, e.g., values reflecting security scores for each feature/version combination. These security scores may be manually determined by a security expert, for example, or may be automatically produced. One or more devices (e.g., ECUs) may get security scores, or risk scores, from a security expert, which may relate to the probabilities of the one or more devices to be targets of attacks. For some embodiments, low-security feature/version combinations may have greater weights.

If there is an attack on one car in the fleet, the weights of second vector <NUM> may be established (or adjusted from default values, potentially) to indicate which feature/version combinations may be more vulnerable to the attack. A vector of weighted presences (e.g., of the set of feature/version combinations in record <NUM>) may then be established for each vehicle in the fleet, including the attacked vehicle. In the subsequent analysis, the attacked vehicle may serve as a reference vehicle.

For a first analytical mode, a distance function of the vector of weighted presences of the attacked vehicle and the vector of weighted presences of another vehicle is calculated for some portion of, or all of, the other vehicles in the fleet. The values of the distance functions (e.g., the distances between vehicles in a vector space) establish similarity scores between the attacked vehicle and the other vehicles of the fleet. The similarity scores of all vehicles in the fleet may optionally be normalized, or scaled (e.g., to a range between <NUM> and <NUM>) for analysis. Although a similarity or similarity score between vehicles is determined according to a distance between their vector representations as established by inner products, in various other examples, a similarity or similarity score between vehicles may be determined according to a distance between their vector representations as established in a variety of other ways.

For example, <FIG> shows a chart <NUM> of similarity scores between a reference vehicle and other vehicles of the fleet, using the first analytical mode. Updates to address the attack mode may be made available (e.g., by a push rollout process and/or a pull rollout process) based upon a combination of the similarity score and the count of vehicles with that similarity score. Updates may preferentially be rolled out to vehicles with the highest similarity scores, for example, and in this way, updates for more vulnerable vehicles may be prioritized over updates less vulnerable vehicles. In some embodiments, updates may preferentially be rolled out to a certain percentage of the vehicles in the fleet.

For example, updates may preferentially be rolled out to vehicles with a similarity score of at least <NUM>, or <NUM>, or may preferentially be rolled out to the vehicles having similarity scores in the top ten percentiles (e.g., the most similar ten percent of the fleet). The use of these mechanisms and methods may advantageously automate much of the analysis to support update process, while the prioritization of updates on the basis of similarity scores may advantageously optimize the use of remote computing resources employed in the update process.

In various embodiments, substantially similar analyses may be conducted for other metrics, including for safety, or for update suitability (e.g., identification of old feature/version combinations, for general maintenance purposes). Similar analyses may be conducted for any other metric by which it may be desirable to prioritize updates to more-suitable portions of a vehicle fleet over less-suitable portions of a vehicle fleet.

A second analytical mode may take into account deeper similarities between vehicles. With regards to security metrics, for example, an attack may enter a vehicle's network topology through one of the vehicle's interfaces, which may be referred to herein as an attack surface. Having gained entry to the network topology, the attack may proceed along a particular route through the network from the attack surface to a target device (e.g., a target ECU).

However, network topologies may vary from vehicle to vehicle. Accordingly, in various scenarios, it may be advantageous to take into account not merely the similarities between vehicles features, but relationships between different devices within the network (e.g., topological relationships). For example, it may be advantageous to take into account similarities in potential paths between vehicles features that are identified as significant for a particular attack (e.g., paths between attack surfaces and target devices).

<FIG> shows an interconnection diagram for a network topology <NUM> of a vehicle network. Topology <NUM> encompasses a variety of devices, represented as nodes in the interconnection diagram. Some devices may present attack surfaces <NUM> (e.g., devices providing accessible interfaces), while other devices may present ECUs <NUM> capable of being targeted for attack. Attack surfaces may include, for example, diagnostic ports, or entertainment units (which may themselves include, or may themselves be, ECUs). Other ECUs may be potential target devices.

In various embodiments, a first portion of this analysis may list of potential attack-surface/target-device pairs within topology <NUM> may be generated. For example, topology <NUM> is depicted as having <NUM> attack surfaces and <NUM> target devices. Thus, there are a total of <NUM> attack-surface/target-device pairs.

The next portion of the analysis may consider the attack-surface/target-device pairs one at a time. An algorithm (such a Breadth First Search (BFS) algorithm) may be used to identify all possible routes between the attack surface and the target device of the pair. Once all the routes are identified, an attack vector for the attack-surface/target-device pair may be generated. The attack vector may have a number of elements equal to the number of nodes within topology <NUM> (e.g., the total number of attack surfaces and potential target devices). For example, the <NUM> attack surfaces and <NUM> target devices of topology <NUM> would lead to the vectors for each attack-surface/target-device pair having <NUM> elements. This may be a minimal case, which may apply which there is merely one feature per ECU (e.g., features which indicate whether particular hardware versions of particular ECUs exist or not). In various embodiments, for ECUs associated with multiple features (e.g., multiple applications and/or software programs), the various features of the ECUs may lead to the vectors having additional elements, up to and including an additional element for each feature of every ECU.

The value of each element of the attack vector may then be set to a weight that is inversely proportional to the number of hops between the attack-surface/target-device pair, along the shortest possible path. In <FIG>, for example, when considering the paths between attack surface #<NUM> of attack surfaces <NUM> and target ECU #<NUM> of ECUs <NUM>, the following weights may apply:.

In some embodiments, individual attack vectors may be compared between a reference vehicle and vehicles within a fleet. As discussed herein, the values of the elements for the attack vector may be scaled by a predetermined weighting factor (e.g., a security-related weighting factor, whether manually or automatically determined). In comparing individual attack vectors for two different vehicles, a positive distance operator Dpos as defined in equation <NUM> below may be used: <MAT> In accordance with equation <NUM>, the value of the elements of vector v are subtracted from the values of the corresponding elements of vector u. Dpos may then be set equal to the sum of those differences, for the cases in which those differences are greater than zero.

Dpos is therefore an asymmetrical operator, and the value to which it evaluates depends upon which vehicle's attack vector is u and which vehicle's attack vector is v. This asymmetry may have various advantages. One advantage may be that differences between vehicles are not counted (or accounted for) twice. Since two vehicles may have different versions of a given vehicle feature, and since different versions of a given feature a may show up as distinct elements within each vehicle's attack vector, different versions of a vehicle feature would show up as a mathematical difference between more than one element of the attack vector. Having the differences included in the sum be greater than zero may lead to counting a different version of a vehicle feature a single time.

Another advantage may be that the analysis elides over vehicle features missing in a particular vehicle. Since the elements of a vehicle's attack vector may encompass vehicle features that are present within the fleet of vehicles, but are not present within a vehicle being analyzed, not including such features will permit the analysis to avoid penalizing a vehicle's similarity score on that basis. Yet another advantage may be that the asymmetry reflects real world situations in which there are differences between a first vehicle and a second vehicle.

In some embodiments, a set of attack vectors may be compared between a reference vehicle and vehicles within a fleet. In comparing a set of attack vectors for two different vehicles, the positive distance operator Dpos of equation <NUM> may be used in determining a total distance, which may be a weighted average of all positive distances between all of the attack vectors in the set of attack vectors, as defined in equation <NUM> below. <MAT> Where i is an index indicating the attack surface, and j is an index indicating the target device. So, for example, in calculating Dtotal for topology <NUM>, the index i would iterate through the <NUM> attack surfaces, and the index j would iterate through the <NUM> target devices.

For two vehicles, or groups of vehicles, the similarity score across a set of attack vectors may then be in accordance with equation <NUM> below. <MAT> Where Dmax may be calculated as an L1 norm of all the attack vectors of the reference vehicle.

<FIG> shows a chart <NUM> of similarity scores between a reference vehicle and other vehicles of the fleet, using the second analytical mode. In comparison with chart <NUM>, the similarity scores of chart <NUM> are more tightly clustered. This may advantageously serve to further focus updates to a vehicle fleet, by permitting a more precise update prioritization (e.g., relative to specific attacks).

Once a prioritization has been established for updates to a fleet of vehicles, in some embodiments, the updates may be delivered via an over-the-air mechanism (e.g., via wireless transmission). For some embodiments, the updates may be made directly (e.g., as in a repair shop). In various embodiments, updates may be delivered in any appropriate manner.

In some embodiments, the mechanisms and methods disclosed herein may also receive dynamic inputs related to various current parameters of the vehicle fleet. These parameters may include safety and/or security events related to the geolocation of the vehicle and/or neighboring vehicles, intensity of vehicle usage, and so on. For some embodiments, a fleet of vehicles may be divided into clusters of vehicles with similar levels of targeted robustness to safety-related threats and/or security-related threats. In various embodiments, software updates may be delivered over-the-air and/or in repair shops.

The mechanisms and methods disclosed herein may also be applicable in contexts outside of vehicle fleets, in which deployed devices include hardware and/or software that may be susceptible to safety or security problems, such as with highly-distributed systems of connected devices. Some such systems may include medical equipment, smart grid units, "vehicle-to-everything" (V2X) road-side units, wearable units, home appliances, computer networks, and so on.

<FIG> show a flow chart for a method <NUM> of establishing similarity scores among vehicles. Method <NUM> comprises an establishing <NUM>, an establishing <NUM>, a calculating <NUM>, and a recommending <NUM>. Method <NUM> may also comprise a performing <NUM>, an establishing <NUM>, a calculating <NUM>, a recommending <NUM>, an identifying <NUM>, an establishing <NUM>, a calculating <NUM>, and/or a recommending <NUM>.

In establishing <NUM>, a first vector of weighted presences of a set of vehicle features in a first vehicle is established. The set of vehicle features may be, for example, the super-set of feature/version combinations discussed herein. In establishing <NUM>, a second vector of weighted presences of the set of vehicle features in a second vehicle is established. In calculating <NUM>, a distance function of the first vector and the second vector is calculated (as discussed herein, for example) to establish a similarity score between the first vehicle and the second vehicle. In recommending <NUM>, an action (such as an update) is recommended for the second vehicle based at least in part upon the similarity score.

In some embodiments, the establishment of weighted presences of vehicle features may include multiplying a set of parameters indicating a presence of each vehicle feature by a predetermined weight for the corresponding vehicle feature (as discussed herein). For some embodiments, the set of vehicle features may include one or more ECUs and/or one or more software applications. In some embodiments, weights corresponding with one or more software applications of the set of vehicle features may be predetermined security-related weights (e.g., weights determined manually by a security expert, or produced automatically). The recommended action includes at least one of a software update, a firmware update, and a security patch, and so forth. In some embodiments, method <NUM> may comprise performing <NUM>, in which the recommended update is performed.

In some embodiments, the second vehicle may be one of a set of second vehicles, the second vector may be one of a set of second vectors respectively corresponding with the set of second vehicles, the distance function may be one of a set of distance functions respectively corresponding with the set of second vectors, and the similarity score may be one of a set of similarity scores. For some embodiments, in establishing <NUM>, the set of second vectors of weighted presences of the set of vehicle features in the set of second vehicles may be established. In calculating <NUM>, the set of distance functions of the first vector and the set of second vectors may be calculated (as discussed herein) to establish the set of similarity scores between the first vehicle and the set of second vehicles. In recommending <NUM>, an action (e.g., an update) may be recommended for one or more vehicles of the set of second vehicles based at least in part upon the corresponding similarity scores.

For some embodiments, the set of second vehicles may be a fleet of vehicles. In some embodiments, in identifying <NUM>, the vehicles of the fleet of vehicles whose similarity scores exceed a predetermined threshold value may be identified as a portion of the fleet of vehicles that is of interest with respect to the set of vehicle features. That is, vehicles whose similarity scores exceed a predetermined threshold similarity score may be identified as being of interest with respect to the set of vehicle features. For some embodiments, the action (e.g., an update) may be recommended for the second vehicle based upon the similarity score exceeding a predetermined threshold value. In some embodiments, the set of vehicle features includes one or more possible attack paths between a set of attack entry points and a set of ECUs in a network architecture.

For some embodiments, the possible attack paths may be weighted based upon attack scores between the corresponding attack entry points and the corresponding ECUs. In various embodiments, an attack score may merely be related to a number of ECUs in the corresponding attack path (e.g., a number of hops). For example, an attack score may be inversely proportional to the number of ECUs in the path. However, the methods and mechanisms disclosed herein may employ different attack scores.

In some embodiments, an attack score for a path may represent a difficulty of performing an attack via that path. Attack scores may be established based on, for example, a number of hops (e.g., between an attack surface and a target ECU), a severity of one or more vulnerabilities of the path and/or along the path, and so on. For some embodiments, the possible attack paths may be weighted based on a reciprocal of the number of ECUs in the path (e.g., a number of hops), a difficulty of accessing the attack surface, a difficulty of overcoming or passing the various ECUs in the path, and so on.

In some embodiments, the similarity score may be a first similarity score. In some embodiments, in establishing <NUM>, a third vector of weighted presences of the set of vehicle features in the second vehicle may be established. For some embodiments, in calculating <NUM>, a distance function of the first vector and the third vector may be calculated (as discussed herein) to establish a second similarity score between the first vehicle and the second vehicle. In some embodiments, in recommending <NUM>, an action for the second vehicle (e.g., an update) may be recommended based upon the similarity score exceeding a predetermined threshold value.

In various embodiments, method <NUM> may comprise a scheduling, in which actions (e.g., recommended actions) for one or more vehicles may be scheduled. In various embodiments, method <NUM> may comprise an updating, in which updates (e.g., recommended updates and/or scheduled updates) for one or more vehicles may be performed. For various embodiments, an action and/or update may be recommended by a first system or party, and the recommended action or update may be scheduled or performed by a second system or party different than the first.

<FIG> shows a flow chart for a method <NUM> of establishing similarity scores among vehicles within a fleet of vehicles, in accordance with the first analytical mode. Method <NUM> may comprise an establishing <NUM>, an establishing <NUM>, a calculating <NUM>, and a recommending <NUM>. In some embodiments, method <NUM> may comprise an identifying <NUM>.

In establishing <NUM>, a first vector of weighted presences of a set of vehicle features in a reference vehicle may be established. In establishing <NUM>, a set of second vectors of weighted presences of the set of vehicle features in the fleet of vehicles may be established, the set of second vectors respectively corresponding with the fleet of vehicles. In calculating <NUM>, a set of distance functions of the first vector and the set of second vectors may be calculated (as discussed herein) to establish a set of similarity scores between the reference vehicle and the fleet of vehicles, the set of similarity scores respectively corresponding with the set of second vectors. In recommending <NUM>, a set of actions (e.g., updates) for the fleet of vehicles may be recommended based at least in part upon the set of similarity scores.

In some embodiments, the set of vehicle features may include one or more ECUs and/or one or more software applications, and weights corresponding with one or more software applications of the set of vehicle features are predetermined security-related weights. For some embodiments, the recommended action may include an update (e.g., a software update, a firmware update, a security patch, and so forth).

For some embodiments, in identifying <NUM>, the vehicles of the fleet of vehicles whose similarity scores exceed a predetermined threshold value may be identified as a portion of the fleet of vehicles that is of interest with respect to the set of vehicle features.

<FIG> shows a flow chart for a method <NUM> of establishing similarity scores among vehicles within a fleet of vehicles, in accordance with the second analytical mode. Method <NUM> may comprise an establishing <NUM>, an establishing <NUM>, a calculating <NUM>, and a recommending <NUM>.

In establishing <NUM>, a first vector including weighted presences of a set of vehicle features in a first vehicle may be established. In establishing <NUM>, a second vector of weighted presences of the set of vehicle features in a second vehicle may be established. In calculating <NUM>, differences between the first vector and the second vector may be calculated (as discussed herein) to establish a similarity score between the first vehicle and the second vehicle. In recommending <NUM>, an action may be recommended for the second vehicle based at least in part upon the similarity score.

For some embodiments, the set of vehicle features includes one or more possible attack paths between a set of attack entry points and a set of ECUs. In some embodiments, the first vehicle may be a reference vehicle, and/or the second vehicle may be one of a fleet of vehicles. For some embodiments, the possible attack paths may be weighted based upon a number of hops between the corresponding attack entry point and the corresponding ECU.

The description of embodiments has been presented for purposes of illustration and description. Suitable modifications and variations to the embodiments may be performed in light of the above description or may be acquired from practicing the methods. For example, unless otherwise noted, one or more of the described methods may be performed by a suitable device and/or combination of devices. The methods may be performed by executing stored instructions with one or more logic devices (e.g., processors) in combination with one or more additional hardware elements, such as storage devices, memory, image sensors/lens systems, light sensors, hardware network interfaces/antennas, switches, actuators, clock circuits, and so on. The described methods and associated actions may also be performed in various orders in addition to the order described in this application, in parallel, and/or simultaneously.

Note that the example control and estimation routines included herein can be used with various engine and/or vehicle system configurations. The control methods and routines disclosed herein may be stored as executable instructions in non-transitory memory and may be carried out by the control system including the controller in combination with the various sensors, actuators, and other engine hardware. The specific routines described herein may represent one or more of any number of processing strategies such as event-driven, interrupt-driven, multi-tasking, multi-threading, and the like. As such, various actions, operations, and/or functions illustrated may be performed in the sequence illustrated, in parallel, or in some cases omitted. Likewise, the order of processing is not necessarily required to achieve the features and advantages of the example embodiments described herein, but is provided for ease of illustration and description. One or more of the illustrated actions, operations, and/or functions may be repeatedly performed depending on the particular strategy being used. Further, the described actions, operations, and/or functions may graphically represent code to be programmed into non-transitory memory of the computer readable storage medium in the engine control system, where the described actions are carried out by executing the instructions in a system including the various engine hardware components in combination with the electronic controller.

The description of embodiments has been presented for purposes of illustration and description. Suitable modifications and variations to the embodiments may be performed in light of the above description or may be acquired from practicing the methods. For example, unless otherwise noted, one or more of the described methods may be performed by a suitable device and/or combination of devices, such as one or more processors executing instructions stored on one or more memory devices. The methods may be performed by executing stored instructions with one or more logic devices (e.g., processors) in combination with one or more additional hardware elements, such as storage devices, memory, image sensors/lens systems, light sensors, hardware network interfaces/antennas, switches, actuators, clock circuits, and so on. The described methods and associated actions may also be performed in various orders in addition to the order described in this application, in parallel, and/or simultaneously. The described systems are exemplary in nature, and may include additional elements and/or omit elements. The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various systems and configurations, and other features, functions, and/or properties disclosed.

As used in this application, an element or step recited in the singular and proceeded with the word "a" or "an" should be understood as not excluding plural of said elements or steps, unless such exclusion is stated. Terms such as "first," "second," "third," and so on are used merely as labels, and are not intended to impose numerical requirements or a particular positional order on their objects. The following claims particularly point out subject matter from the above disclosure that is regarded as novel and non-obvious.

The technical effect of implementing such methods is that updates to a plurality of vehicles may advantageously be recommended based on which vehicles have attack paths that are most similar to relevant attack paths of a reference vehicle design for a particular metric (e.g., security, safety, and so on).

As used in this application, an element or step recited in the singular and proceeded with the word "a" or "an" should be understood as not excluding plural of said elements or steps, unless such exclusion is stated. Furthermore, references to "one embodiment" or "one example" of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features. Terms such as "first," "second," "third," and so on are used merely as labels, and are not intended to impose numerical requirements or a particular positional order on their objects. The following claims particularly point out subject matter from the above disclosure that is regarded as novel and non-obvious.

Claim 1:
A method comprising:
establishing a first vector (<NUM>) of weighted presences of a set of vehicle features in a first vehicle;
establishing a second vector (<NUM>) of weighted presences of the set of vehicle features in a second vehicle;
calculating a value of a distance function based on an inner product of the first vector (<NUM>) and the second vector (<NUM>), wherein the value of the distance function establishes a similarity score between the first vehicle and the second vehicle; and
recommending an update for the second vehicle when the similarity score exceeds a predetermined threshold value, wherein the update includes at least one of a software update, a firmware update, and a security patch.