Patent Description:
With the constant advances in the automotive industry, the operation of modern vehicles, such as, for example, cars, trucks, motorcycles and/or the like is heavily reliant on automated systems utilizing multiple Electronic Control Units (ECU) deployed in the vehicle to control almost every aspect of the operation of the vehicle.

These ECUs may control various systems of the vehicle ranging from critical systems to user experience systems, for example, an engine control system, a transmission control system, a breaking system, a lighting system, an infotainment system, a navigation system, a communication system, a door lock system, a window lift system and/or the like.

The ECUs may be processing devices comprising one or more processors executing software, firmware and/or middleware module(s) to provide the required functionality and features. The ECUs may also include one or more programmable logic devices, for example, a Field Programmable Gate Array (FPGA) and/or the like which may be loaded with firmware to map the logic gates of the FPGA to provide the required functionality and features.

Due to the dynamic nature of the automotive industry and the features supported by the vehicles the ECUs may occasionally need to be updated after the vehicles leave the production and delivery centers. The ECUs may therefore be configured to support dynamic update of the software, firmware and/or middleware module(s) using update packages delivered to the deployed vehicles.

Document <CIT> discloses a method of updating a firmware of a vehicle while the while is being driven, comprising: broadcasting a first request for updates to vehicles having network proximity to one another; receiving an acknowledgement identifying an available update from a first vehicle of the devices; broadcasting a second request for the available update to the vehicle; receiving a portion of the available update from a second nearby vehicle of the vehicles; determining that a remaining portion of the available update other than the received portion is needed to complete the available update; broadcasting a request for the remaining portion of the available update based on the determination that the remaining portion of the available update is needed to complete the available update; and receiving at least the remaining portion of the available update from one of the devices via a connection other than the Internet.

Furthermore, document <CIT> discloses a method of managing updating of a programmable device (vehicle) that is part of a computer network comprised of multiple interconnected programmable devices, the method comprising: committing, to a distributed ledger implemented by one or more processors of the programmable device, a first configuration of a computer program installed on the programmable device, wherein the distributed ledger exists on at least two of the multiple interconnected programmable devices; receiving, by the one or more processors of the programmable device, a first request to apply a first update to the first configuration of the computer program and a second request to apply a second update to the first configuration of the computer program; receiving a second configuration of the computer program that is based on the first update and the first configuration of the computer program to generate; committing, by the one or more processors of the programmable device, the second configuration of the computer program to the distributed ledger; determining, based on the distributed ledger, that the second update cannot be applied to the first configuration of the computer program; receiving a third configuration of the computer program in response to determining that the second update cannot be applied, the third configuration being generated based on the second update and the second configuration of the computer program; and committing, by the one or more processors of the programmable device, the third configuration of the computer program to the distributed ledger.

According to a first aspect described herein there is provided a method of updating Electronic Control Units (ECUs) of vehicles using updates received via Vehicle to Vehicle (V2V) communication channels and verified by a vehicles consensus, comprising using one or more processors of a vehicle executing a code for:.

According to a second aspect described herein there is provided a system of updating Electronic Control Units (ECUs) of vehicles using updates received via Vehicle to Vehicle (V2V) communication channels and verified by a vehicles consensus, comprising:.

In a further implementation form of the first and/or second aspects, each of the V2V communication channel(s) is a short range communication channel for establishing communication between vehicles located in close proximity.

In a further implementation form of the first and/or second aspects, each of the plurality of update packages is a member of a group consisting of: a firmware update, a middleware update and a software update.

In an optional implementation form of the first and/or second aspects, each of the plurality of update packages is associated with an expiration time tag after which the respective update package is invalid.

In a further implementation form of the first and/or second aspects, each of the plurality of update packages originates from one or more trusted distribution systems adapted to transmit the plurality of update packages to at least some of the plurality of vehicles.

In a further implementation form of the first and/or second aspects, each update package is determined to be directed to respective ECU(s) by comparing between one or more package attributes extracted for the update package(s) and one or more ECU attributes associated with the respective ECU(s).

In a further implementation form of the first and/or second aspects, each of the plurality of vehicles communicates with at least some other vehicles of the plurality of vehicles to continuously update and synchronize its respective local log.

In an optional implementation form of the first and/or second aspects, the local log maintained by each of the subset of vehicles is implemented by a blockchain comprising a plurality of immutable irreversible blocks, each of the plurality immutable irreversible blocks created by one or more trusted distribution systems for a respective one of the plurality of update packages associates the identifier of the respective update package with the verification code of the respective update package.

In a further implementation form of the first and/or second aspects, an identity of each of the one or more nearby vehicles and the identity of each of the subset of vehicles is first authenticated to establish a trusted communication session prior to further data exchange.

In a further implementation form of the first and/or second aspects, the verification code is a hash value calculated for each of the one or more update packages using one or more hash functions such that a respective identifier of each of the plurality of update packages is associated in the log of each of the subset of vehicles with a respective hash value.

In a further implementation form of the first and/or second aspects, the number of vehicles of the subset is set according to one or more security parameters.

In a further implementation form of the first and/or second aspects, one or more of the received update package(s) is transmitted to one or more other nearby vehicles of the plurality of vehicles via the V2V communication channel(s).

In a further implementation form of the first and/or second aspects, the transmission of the update packages is not recorded.

In a further implementation form of the first and/or second aspects, the received update package(s) is locally stored for a predefined time period and available for transmission to one or more other nearby vehicles. The update package(s) is discarded on expiration of the predefined time period.

In an optional implementation form of the first and/or second aspects, the predefined time period is adjusted according to one or more operational parameters of the vehicle. The operational parameters may include a geographical area of the vehicle, a surrounding terrain, an ON/OFF state of the vehicle and/or a speed of the vehicle.

A predefined no-transmission period is applied between subsequent transmissions of the update package(s) during which the update package(s) is not transmitted.

A predefined no-reception period is applied following the reception of the update package(s) during which reception of update packages is prohibited.

In an optional implementation form of the first and/or second aspects, one or more of the update packages are cumulatively received in a plurality of separate reception sessions. During each of the plurality of reception sessions established with one or more of the plurality of vehicles the reception of the respective update package is resumed to receive one or more additional portion of the respective update package.

In an optional implementation form of the first and/or second aspects, one or more mobile devices associated with the vehicle receive one or more of the update packages, determine whether the update package(s) is directed to the one or more ECU of the associated vehicle, validates each of the update package(s) and initiates the update using one or more of the update package(s).

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments described herein pertain. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments described herein, exemplary methods and/or materials are described below.

Implementation of the method and/or system of some embodiments described herein can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the embodiments described herein, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments described herein could be implemented as a chip or a circuit. As software, selected tasks according to embodiments described herein could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In some exemplary embodiments described herein, one or more tasks of method and/or system are performed by a data processor, such as a computing platform for executing a plurality of instructions.

Some embodiments are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments described herein. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments described herein may be practiced.

Some embodiments described herein relate to updating ECUs of vehicles, and, more specifically, but not exclusively, to updating ECUs of vehicles using update packages received via V2V communication channels and verified according to a consensus of a community of vehicles.

According to some embodiments described herein, there are provided methods, systems and computer program products for updating ECUs of vehicles using update packages received via V2V communication channels and verified by a consensus of at least some vehicles of a community comprising a plurality of vehicles. As such the community of vehicles serves as both a data plane for distributing the update packages among the vehicles of the community and as a control plane for validating the received update packages based on a consensus of at least a majority of a subset of the vehicles to ensure the received update packages are genuine (authentic) and untampered and are thus eligible for use to update the ECUs.

The update packages, for example, a firmware update, a middleware update, a software update and/or the like which are distributed to the community of vehicles may typically originate from one or more trusted distribution systems associated with one or more trusted vendors, for example, a car manufacturer, a car maintenance service provider, an ECU provider, a software provider and/or the like.

One or more vehicles of the community may receive one or more update packages for updating one or more ECUs deployed in the respective vehicle. In particular, the vehicles may receive the update packages via one or more V2V communication channels from one or more other vehicles.

Since the V2V communication channels are typically short range communication channels having a limited reception range and hence a limited reception area, the vehicles may receive the update packages from one or more encountered nearby vehicles which are within the reception area (range) of the V2V communication channel(s). Due to the short range of the V2V communication channel(s) and the dynamic nature of the vehicles, during an encounter between two or more nearby vehicles a local Ad-Hoc network, connection and/or session (designated Ad-Hoc network herein after) may be established between the nearby vehicles over which the nearby vehicles may communicate with each other, in particular transfer one or more update packages.

Optionally, one or more of the vehicles may receive one or more update packages in a cumulative manner during a plurality of separate reception sessions established with one or more nearby vehicles. During each of the plurality of reception sessions, the vehicle may resume reception of the update package and receive one or more additional portions of the update package. The reception sessions may be repeated until the vehicle accumulates the complete update package.

After receiving an update package the vehicle, specifically an update agent executed by one or more update systems of the vehicle may check whether the received update package is applicable for the vehicle. The update agent may first check whether the received update package is directed to (targets) one or more of the ECUs deployed in the vehicle and in case the received update package is directed to ECU(s) in the vehicle whether the target ECU(s) need to be updated using the received update package.

In case the received update package is determined to be applicable for ECU(s) of the vehicle, the update agent may communicate with a group (subset) comprising at least some other vehicles of the community to validate that the received update package is valid. A valid update package is a trusted update package which is genuine (authentic) originating (released) from the trusted distribution system(s) and is untampered since released by the trusted distribution system(s).

In order to facilitate the control plane for the update packages which is essential for validating update packages in response to queries received from the vehicles receiving these update packages, the community of vehicles may employ one or more distributed computing methods, algorithms and/or protocols. Moreover, while most of the vehicles of the community may be trusted as genuine and honest members of the community, at least some of the vehicles in the community may be untrusted, for example, operated, hijacked and/or compromised by one or more malicious parties thus expose the community of vehicles to one or more cyber threats. Therefore, in order to verify that the distributed computing community of vehicles is immune to such untrusted vehicles, the community of vehicles may employ one or more distributed computing methods, algorithms and/or protocols directed to establish a trusted platform among untrusted community members, for example, a blockchain and/or the like.

As part of the trusted platform control plane, each of the vehicles in the community may therefore maintain a local log (distributed ledger in the blockchain implementation) which associated all the update packages released by the trusted distribution system(s) with respective verification data, for example, a verification code and/or the like. The verification code may include, for example, a hash value calculated for the each of the update packages using one or more hash functions such that each update package is uniquely associated with a respective hash value. Moreover, following the distributed computing paradigm, the plurality of vehicles of the community constantly update and synchronize their local logs with each other such that all logs maintained by a majority (and potentially all) of the vehicles reflect the same verification data for the released update packages.

As the update packages are released only by the trusted distribution system(s), the trusted distribution system(s) are those which generate the verification data which may propagate to all the vehicles in the community which may update and synchronize their local logs accordingly. Moreover, in order to prevent malicious manipulation and/or alteration of the local logs, the trusted distribution system(s) may apply one or more one-way cryptographic algorithms to produce immutable data blocks in the plurality of distributed local logs, for example, the distributed ledge in the blockchain.

As such, in order to validate the received update package, the update agent vehicle may communicate with the subset of vehicles each maintaining its local log and all logs are synchronized with the local logs of all other vehicles of the community.

Based on a consensus of at least a majority of the subset of vehicles achieved (decided) according to the verification data extracted from the synchronized local logs of these vehicles, the update agent may determine whether the received update package is valid or not. The number of vehicles in the subset required to establish the consensus must equal or exceed a predefined threshold, i.e. a predefined number of vehicles which may be set according to one or more security parameters of the community. Such security parameters may include, for example, overall number of vehicles in the community, geographical distribution of the vehicles, type of the community (e.g. privately owned vehicles, organization vehicles, etc.), security level of the data exchanged between the vehicles (e.g. encryption, authentication, etc.), type of the control plane protocol(s), a criticality of the queried update package and/or the like.

In case the received update package is determined to be valid, the update agent may initiate an update session for updating the ECU(s) targeted by the validated update package using the update package. However, in case the received update package is determined to be invalid the update agent may discard the update package.

Regardless of whether the received update package is directed to ECU(s) of the vehicle or not, the update agent temporarily stores the update package for transmission to one or more other vehicles of the community, in particular encountered nearby vehicles with which communication via the V2V communication channel(s) is established.

Moreover, the trusted platform control plane such as the blockchain for example, may be further used to log identification information of the vehicles, for example, an identity (ID) of the vehicles which are part of the community. For example, the Vehicle Identification Number (VIN) of each vehicle may be registered in the trusted platform after the vehicle's identify is properly verified by one or more of the trusted distribution systems.

As such, the local log stored by each vehicle may include the identification information of the vehicles of the community. Using the identification information locally available in the local log, one or more of the vehicles may authenticate each other during the communication sessions established for receiving update package(s) and/or for validating update package(s) to verify the other vehicle is a genuine member of the community.

Modern vehicles may include a very large number of ECUs of various types for controlling the vehicles systems thus an extremely large number of update packages may be released and circulated in the community of vehicles. In addition, as the vehicles of the community are dynamic and mobile they may encounter many nearby vehicles. Due to these reasons, the number of transmission sessions in which a vehicle may engage for transferring update packages to nearby vehicles may be extremely large.

However, since the vehicles ECUs, specifically the update systems executing the update agent may typically have limited storage (e.g. storage capacity), tracking (logging, recording) such extremely large numbers of update packages transmission sessions may be practically impossible. The inability to track these update packages transmissions and determine which update packages were sent to which vehicles may lead to multiple redundant transmission sessions in which the same update package is unnecessarily transmitted multiple times. For example, a certain vehicle may transmit the same update package(s) to the same nearby vehicle(s) multiple times. Also a certain vehicle may receive the same update package multiple times from multiple nearby vehicles.

These redundant and unnecessary transmission sessions may significantly increase network utilization of the V2V communication channel(s) thus significantly reducing effectivity of the communication session between the vehicles. This may further lead to a significant increase in computing resources required by the update agents to handle duplicated copies of the same update package(s).

In order to optimize network performance of the V2V communication channel(s), several network optimization measures may be applied by the vehicles of the community to significantly reduce and potentially prevent the redundant and unnecessary transmission sessions for transmitting duplicates of update packages.

On the transmission side, the update agent executed by one or more of the vehicles may be configured to disable transmission of the same update package multiple times. For example, after transmitting a certain update package, the update agent may enter a no-transmission state for a predefined no-transmission time period during which the certain update package is not transmitted.

On the reception side, the update agent executed by one or more of the vehicles may be configured to disable reception of additional update packages for a predefined no-reception time period after receiving an update package.

The no-transmission time period and/or the no-reception time period may be adjusted according to one or more operational parameters of the vehicle executing the update agent, for example, a geographical area in which the vehicle is located, a surrounding terrain of the vehicle, an ON/OFF state of the vehicle, speed of the vehicle <NUM> and/or the like.

Optionally, when communicating with one or more other vehicles to receive a certain update package the update agent may check it's local temporarily stored update packages (is exist) to check whether the certain update package was already received previously. In case the certain update package is locally available, the update agent may reject reception of the certain update package to avoid the redundant transmission session.

Distributing the update packages for the vehicles ECUs and validating these update packages according to the consensus of the community of vehicles may present significant advantages compared to currently existing methods and systems for delivering updates to the vehicles' ECUs.

First, the distribution of the update packages relies on direct delivery of the update packages between vehicles rather than delivering the update packages from a limited number of centralized distribution systems as may be done by the existing methods.

In the centralized approach, each of the vehicles may individually access the centralized distribution system(s). Due to the extremely large number of vehicles this individual access may significantly load the networks connecting the vehicles to the centralized distribution system(s). This limitation may be further increased due to the large number and high diversity of the ECUs which may require updates. Overloading the networks may naturally lead to poor service, high latency and optionally reduced reliability of the received update packages. Moreover, communicating with the centralized distribution system(s) as may be done by the existing methods may require the vehicles to infrastructure network capabilities. For example, the vehicles may be equipped with long range network capabilities, for example, cellular network and/or the like which may be costly thus increasing the cost of the update system deployed in the vehicles. In addition, the service cost of such cellular network links may be significantly high thus further increasing the cost for delivering the update packages. In another example, the vehicles may be equipped with short range wireless infrastructure network capabilities, for example, Wireless Local area Network (WLAN) and/or the like. Such network connections may require a physical connection of the vehicle to the network in case of the wired network and/or placing the vehicle in close proximity to an access point of the short range wireless infrastructure. This naturally limits the update packages delivery to certain locations and times during which the vehicles are located in these locations.

In contrast, distributing the update packages between the vehicles via the V2V communications channels may significantly reduce and potentially prevent the network overload for communicating with centralized distribution system(s) as may be done by the existing methods. Moreover, the cost and complexity of the V2V communications channels may be considerably lower than the communication means required for communicating with the centralized distribution system(s). The service cost for communicating via the V2V communications channels may also be negligible compared to the service cost of the communication means required for communicating with the centralized distribution system(s).

The update packages may rapidly and efficiently spread and distribute within the community of vehicles despite the fact that the communication range of the vehicles is limited. This is due to two main facts inherent to the vehicle and to the community. First, the vehicles are mobile and move between geographical areas and locations thus frequently encounter other vehicles of the community. Second, the large number of vehicles further increases the frequency of the vehicles encounters. As each of the extremely large number of vehicles may serve as a carrier of update package(s), during these highly frequent encounters the update packages may be exchanged to rapidly spread among the vehicles of the community.

Furthermore, applying the distributed computing methods, algorithms and/or protocols directed to establish the trusted platform among the untrusted vehicles in the community may overcome the lack of a centralized trusted entity which may be used to verify validity of the update packages as may be done by the existing methods.

While each of the vehicles of the community may need to maintain its local log, the local log may be very limited in size (volume) as it includes only an identifier of each released update package associated with the respective verification data, specifically a limited size hash value. As such, the storage resources required for marinating the local log in each vehicle may be very limited and significantly small.

In addition, applying the network optimization measures may ensure minimal utilization and hence high performance and/or low latency of the network established via the V2V communications channels while avoiding tracking (recording) the update package transmission sessions thus avoiding the need to allocate high storage resources for the update packages tracking and logging. Furthermore, applying the network optimization measures may significantly reduce the computation resources required at the vehicles to handle redundant transmission sessions for transferring duplicates copies of update packages.

Before explaining at least one embodiment described herein in detail, it is to be understood that the embodiments are not necessarily limited in their application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the examples. The embodiments described herein are capable of other embodiments or of being practiced or carried out in various ways.

The embodiment described herein may include a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the embodiment described herein.

Computer readable program instructions for carrying out operations of the embodiment described herein may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages.

In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the embodiment described herein.

Aspects of the embodiment described herein are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of described herein.

Referring now to the drawings, <FIG> is a flowchart of an exemplary process of updating ECUs of vehicles using update packages received via V2V communication channels and verified by a vehicles consensus, according to some embodiments described herein. An exemplary process <NUM> may be executed by one or more vehicles of a community comprising a plurality of vehicles for updating one or more ECUs deployed in the respective vehicle using update packages received via one or more V2V communication channels from one or more other vehicles, specifically nearby vehicles which are within the reception range of the V2V communication channel(s). The update packages, for example, a firmware update, a middleware update, a software update and/or the like distributed to the vehicles may typically originate from one or more trusted distribution systems associated with one or more trusted vendors, for example, a car manufacturer, a car maintenance service provider, an ECU provider, a software provider and/or the like.

The V2V communication channels are typically short range communication channels having a limited reception range (e.g. <NUM> meters) and hence a limited reception area. The update packages may therefore be transferred between nearby vehicles which are within the reception range of the V2V communication channels.

However, the update packages may rapidly and efficiently spread and distribute within the community of vehicles despite the fact that the communication range of the vehicles is limited. This is due to two main facts inherent to the vehicle themselves and to the community of vehicles. First, the vehicles are mobile and move between geographical areas and locations thus frequently encounter other vehicles of the community. Second, the large number of vehicles further increases the frequency of the vehicles encounters. Wherein an encounter is a period of time during which two or more vehicles of the community are nearby each other, i.e., within each other's V2V communication channel(s) reception area (range). During these encounters the nearby vehicles may establish a communication session with each other via the V2V communication channels to exchange data with each other, specifically to transfer one or more update packages. Optionally, one or more of the vehicles receive one or more of the update packages in a cumulative manner by receiving one or more portions of the update package during a plurality of reception communication sessions established with one or more nearby vehicles.

Whenever a vehicle receives an update package it first checks whether the received update package is applicable, i.e. whether the received update package is directed to (i.e., targets) one or more ECUs deployed in the vehicle and if so whether the target ECU(s) need to be updated using the received update package. In case the update package is determined to target the ECU(s) of the vehicle, the vehicle may communicate with a group (subset) comprising at least some of the other vehicles for validating that the received update package is valid, i.e., genuine and untampered as originally released by the trusted distribution system(s).

To facilitate the update packages validation, each of the vehicles in the community maintains a local log which records all the update packages released by the trusted distribution system(s), specifically identification information of all the released update packages. The local logs and further associates each of the released update packages with a verification code. The local logs of all the vehicles of the community are constantly updated and synchronized with each other such that all logs reflect the same update packages and associated verification codes.

Based on their local logs, the group of vehicles approached by the vehicle requesting validation of the update package may respond to the vehicle stating whether the update package is valid or not. The vehicle may then determine whether update package is valid based on a consensus among the members of the group of vehicles. In case the update package is determined to be valid, the vehicle may use it to update the target ECU(s). Else the vehicle may discard the update package.

Regardless of whether the update package is directed to ECU(s) of the vehicle or not, the vehicle may temporarily store the update package for transmission to one or more other vehicles of the community encountered within a certain time period.

Reference is also made to <FIG>, which is a schematic illustration of an exemplary system for updating ECUs of vehicles using updates received via V2V communication channels and verified by a vehicles consensus, according to some embodiments described herein. An exemplary update system <NUM> may be deployed in one or more vehicles <NUM> of the community of vehicles <NUM> for executing a process such as the process <NUM>. The update system <NUM> may comprise a network interface <NUM>, a processor(s) <NUM>, storage <NUM> and an Input/Output (I/O) interface <NUM>.

The network interface <NUM> may include one or more interfaces, in particular wireless interfaces for connecting to one or more V2V communication channels, for example, Wireless Local Area Network (WLAN, e.g. Wi-Fi), Dedicated Short-Range Communications (DSRC), <NUM> (<NUM>th generation) cellular networks direct Device-to-Device (D2D) side links and/or the like. The network interface <NUM> may further include one or more interfaces for connecting to one or more infrastructure networks, for example, cellular networks, WLANs, Local Area Networks (LAN), the internet and/or the like.

The processor(s) <NUM>, homogenous or heterogeneous, may include one or more processors arranged for parallel processing, as clusters and/or as one or more multi core processor(s). The storage <NUM> used for storing program code (program store) and/or data may include one or more non-transitory persistent storage devices, for example, a Read Only Memory (ROM) component, a hard drive, a Flash array and/or the like. The storage <NUM> may further include one or more volatile devices, for example, a Random Access Memory (RAM) component, a cache memory and/or the like.

The I/O interface <NUM> may include one or more wired and/or wireless interfaces for connecting to one or more ECUs <NUM> deployed in the vehicle <NUM>. The I/O interface <NUM> may include one or more network interfaces, for example, a WLAN interface, a LAN interface, a Control Area Network (CAN) bus, an Aeronautical Radio Incorporated (ARINC) network, a Bluetooth Low Energy (BLE) interface, a Radio Frequency (RF) interface and/or the like. The I/O interface <NUM> may include one or more wired interfaces for connecting one or more wired interconnections, for example, a serial bus, a Universal Serial Bus (USB) and/or the like.

The ECUs <NUM> deployed in the vehicle <NUM> may control one or more of the vehicle <NUM> systems, for example, an engine control system, a transmission control system, a breaking system, a lighting system, an infotainment system, a navigation system, a communication system, a door lock, a window lift system and/or the like. Each of the ECUs <NUM> may include a processor(s) such as the processor <NUM>, storage such as the storage <NUM>, an I/O interface such as the I/O interface <NUM> and optionally a network interface such as the network interface <NUM>.

The processor(s) <NUM> may execute one or more software modules such as, for example, a process, a script, an application, an agent, a utility, a tool and/or the like each comprising a plurality of program instructions stored in a non-transitory medium (program store) such as the storage <NUM> and executed by one or more processors such as the processor(s) <NUM>. For example, the processor(s) <NUM> may execute an update agent <NUM> for executing the process <NUM> to initiate updated to one or more of the ECUs <NUM> targeted by a package update received from one or more nearby vehicles <NUM> and verified to be a valid update package. The update agent <NUM> may further utilize one or more hardware elements, for example, a circuit, a component, an Integrated Circuit (IC), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signals Processor (DSP) and/or the like for executing the process <NUM>.

The processor(s) <NUM> may further access, maintain and/or update one or more data sets, for example, a file, a record, a table and/or the like stored in the storage <NUM>. In particular, a local log data set <NUM> may be stored in the storage <NUM> for associating each of the update packages with a respective verification code used for verifying validity of the update packages. The local log <NUM> may further include identification information, for example, a VIN of all vehicles <NUM> which are members of the community. The processor(s) <NUM> may therefore execute one or more software modules, for example, the update agent <NUM> a dedicated software module and/or a combination thereof to access, maintain and/or update the local log <NUM>.

The update system <NUM> may be a dedicated system deployed in the vehicle <NUM>. Optionally, the update system <NUM> may be integrated in one or more of the ECUs <NUM> such that the integrated ECU(s) <NUM> executes the update agent <NUM> to execute the process <NUM>.

According to some embodiments described herein, a mobile device physically independent of the vehicle <NUM> may be utilized to support execution of the process <NUM> to receive one or more update packages, validate them and initiate update of respective target ECU(s) using the validated update package(s).

Reference is now made to <FIG> and <FIG>, which are schematic illustrations of exemplary embodiments of a system using an associated mobile device for updating ECUs of vehicles using updates received via V2V communication channels and verified by a vehicles consensus, according to some embodiments described herein. One or more vehicles such as the vehicle <NUM> may be associated with one or more mobile devices <NUM>, for example, a Smartphone, a tablet, a laptop computer, a smart watch, a wearable device and/or the like which are physically independent from the respective vehicle <NUM> to support execution of a process such as the process <NUM>.

The mobile device <NUM> includes a communication interface such as the communication interface <NUM>, a processor(s) such as the processor(s) <NUM> and storage such as the storage <NUM>. The processor(s) of the mobile device <NUM> may execute one or more software modules from the storage of the mobile device <NUM>.

The mobile device <NUM> associated with a certain vehicle <NUM> may take an active part in receiving one or more update packages, validating the update package(s) and initiating update process at one or more ECUs such as the ECUs <NUM>. However, the mobile device <NUM> associated with a certain vehicle <NUM> may only serve as an intermediary, i.e. a proxy, a gateway and/or the like to provide an update system such as the update system <NUM> access to one or more networks, specifically V2V communication channels for communicating with other vehicles <NUM>.

As seen in <FIG>, the mobile device <NUM> which is physically independent from the vehicle <NUM> may be associated (paired) with the vehicle <NUM> to serve as an update system such as the update system <NUM> and may execute an update agent such as the update agent <NUM>. The associated mobile device <NUM> may further store a local log such as the local log <NUM>. Each mobile device <NUM> executing the update agent <NUM> corresponds to a specific vehicle <NUM> such the specific mobile device <NUM> is uniquely paired (one-to-one relation) with the specific vehicle <NUM> and the specific mobile device <NUM> is therefore regarded as part or extension of the specific vehicle <NUM>.

The update agent <NUM> executed by the mobile device <NUM> may communicate with one or more of the other vehicles <NUM>. The update agent <NUM> may further communicate with an access system <NUM> deployed in the vehicle <NUM> and capable of communicating with a plurality of ECUs such as the ECUs <NUM>. Optionally, the access system <NUM> is utilized by one or more of the ECUs <NUM> of the vehicle <NUM>. The mobile device <NUM> may communicate with the access system <NUM> via one or more wired and/or wireless communication channels. For example, the mobile device <NUM> may communicate with the access system <NUM> via a WLAN network established between them. In another example, the mobile device <NUM> may include a wired interconnection interface, for example, a USB port that may be connected to a USB port of the access system <NUM>. Optionally, the mobile device <NUM> directly communicates with one or more of the ECUs <NUM> via one or more wired and/or wireless channels established between the mobile device <NUM> and the ECU(s) <NUM>. For example, the mobile device <NUM> may connect to one or more of the ECUs <NUM> via a BLE channel. In another example, a serial interface of the mobile device <NUM> may be connected to one or more serial channels of the vehicle <NUM> connecting one or more of the ECUs <NUM>.

The mobile device <NUM> may be associated (paired) with the vehicle <NUM> such that a trusted and secure communication link is established between the mobile device <NUM> and the access system <NUM> to provide the mobile device <NUM> access to one or more of the ECUs <NUM>. In particular, the trusted and secure communication link is established between the update agent <NUM> executed by the mobile device <NUM> and a vehicle agent <NUM> executed by the access system <NUM>.

Pairing the mobile device <NUM> with the vehicle <NUM> may be done using one or more secure methods, techniques and/or implementations as known in the art in order to establish the trusted and secure communication link with the access system <NUM>. For example, a password based protocol may be applied in which a user of the vehicle <NUM> (e.g. driver, owner, etc.) inserts a password at both the mobile device <NUM> and the access system <NUM>. The password may be then used to establish the trusted and secure communication link between the mobile device <NUM> and the access system <NUM>.

As seen in <FIG>, the mobile device <NUM> may serve as a proxy server for an update system such as the update system <NUM> to provide the update system <NUM> access to one or more networks, specifically V2V communication channels for communicating with other vehicles <NUM>. In these deployments, the update system <NUM> executes the update agent <NUM> and typically stores the local log <NUM>. To this end, the mobile device <NUM> may execute a proxy agent <NUM> to direct network traffic exchanged between the update agent <NUM> executed by the update system <NUM> and the other vehicles <NUM>.

Reference is now made to <FIG>, which is a schematic illustration of an exemplary community of networked vehicles using V2V communication channels for distributing and validating update packages directed for ECUs of the vehicles, according to some embodiments described herein. A community <NUM> of vehicles may include a plurality of vehicles such as the vehicle <NUM> which may communicate with each other via one or more of the V2V communication channels.

The vehicles <NUM> of the community <NUM> may communicate with each other to establish two data distribution planes, the first may be regarded as a data plane for transferring the update packages and distributing them among the vehicles <NUM> of the community <NUM> and the second may be regarded as a control plane for transferring verification data relating to the update packages which may be used for validating that the update package are genuine and untampered.

The vehicles <NUM> of the community <NUM> may be vehicles manufactured by one or more vehicle manufacturers. Furthermore, the update packages may be designed and/or created by one or more vendors and distributed to the plurality of vehicles <NUM> of the community <NUM>.

The update packages distributed to the vehicles <NUM> may originate from one or more trusted distribution systems <NUM> associated with one or more trusted vendors, for example, a car manufacturer, a car maintenance service provider, an ECU provider, a software provider and/or the like.

Optionally, one or more of the update packages may be associated with an expiration and/or a (Time To Live (TTL) time tag indicating a time period since creation and/or distribution of the respective update package for which the respective update package is valid and may be applied by one or more of the vehicles <NUM> for updating one or more ECUs such as the ECU <NUM>. One or more of the vehicles <NUM>, specifically an update agent such as the update agent <NUM> executed by the respective vehicle(s) <NUM> may have access to timing information such as a current time and date, for example, based on a local Real-Time Clock (RTC), a broadcast RTC, a Global Positioning System (GPS) and/or the like. Based on the current time/data coupled with an analysis of the expiration time tag of a received update package, the update agent <NUM> may determine whether validity of the received update package. In case the expiration time of the update package is not yet reached, the update agent <NUM> may determine that the received update package is still valid while in case according to the expiration time tag the update package is expired, the update agent <NUM> may determine that the update package is no longer valid.

Each of the update packages is associated with verification data, specifically a verification code generated for the respective update package to uniquely encode the contents of respective update package such that the verification code may be used for validating that the respective update package is genuine and untampered. Generating the verification data for the update packages may be done by one or more of the parties involved in producing and/or distributing the update packages. For example, the verification code of one or more of the update packages may be generated by the vendor of the respective update package and delivered to the trusted distribution system(s) <NUM> with the respective update package for distribution to the vehicles community <NUM>. Optionally, the verification code of one or more of the update package may be generated one or more of the trusted distribution systems <NUM> prior to distributing the respective update package to the vehicles community <NUM>.

The verification code may be created using one or more methods, techniques and/or algorithms as known in the art. For example, the verification code may be generated by calculating a hash value for a respective update package using one or more hash functions.

Each of the vehicles <NUM> in the community <NUM> may maintain a local log such as the local log <NUM> in which each of the plurality of update packages released by the trusted distribution system(s) <NUM> for distribution to the vehicles <NUM> is associated with its respective verification code. In particular, the local log <NUM> associates a unique identifier assigned to each of the update packages with the respective verification code. The identifier may be assigned to each update package to differentiate the respective update package with respect to one or more attributes, for example, a functionality, a target ECU, a feature set, a version, a build, a release date and/or the like. The verification data (i.e. identifier and associated verification code) may be significantly limited comprising a small data volume (e.g. < 1KB) mainly depending on the algorithms used to create the verification codes. The verification data to be updated in the local logs <NUM> may be created only by the trusted distribution system(s) <NUM>, specifically upon release of each new update package since the newly released update package needs to be logged in the local logs <NUM> of the vehicles <NUM> of the community <NUM>.

Moreover, the local log <NUM> may be used to store the identification information of the vehicles <NUM> of the community <NUM>, for example, the (VIN) of each of the vehicles <NUM>.

To establish the control plane for validating the distributed update packages, the vehicles <NUM> of the community <NUM> may communicate with each other and optionally with the trusted distribution system(s) <NUM> to update their local logs <NUM> in order to maintain all the local logs <NUM> constantly synchronized with each other. Specifically the vehicles <NUM> may communicate with each other and optionally with the trusted distribution system(s) <NUM> to exchange the verification data relating to the newly released update packages in order to update their local logs <NUM> accordingly.

The vehicles <NUM> of the community <NUM> may attempt to communicate with each other and optionally with the trusted distribution system(s) <NUM> according to one or more communication conditions and/or rules. For example, the vehicles <NUM> may attempt to continuously establish a communication session with one or more other vehicles <NUM> and/or with the trusted distribution system(s) <NUM>. In another example, the vehicles <NUM> may attempt to establish a communication session with one or more other vehicles <NUM> and/or with the trusted distribution system(s) <NUM> at predefined time intervals, for example, every predefined time period, at a predefined time of day, at a predefined location and/or the like. In another example, the vehicles <NUM> may be manually instructed and/or operated to establish a communication session with one or more other vehicles <NUM> and/or with the trusted distribution system(s) <NUM>, for example, by an owner of the vehicle <NUM>, by a maintenance person and/or the like.

Since the vehicles <NUM> of the community <NUM> need to establish trust with each other in order to verify the exchanged verification data is genuine, the vehicles <NUM> of the community <NUM> may apply one or more distributed computing methods, algorithms and/or protocols as known in the art for utilizing the control plane and maintaining their local logs <NUM> synchronized without having a centralized trusted entity. For example, the vehicles <NUM> of the community <NUM> may constitute a blockchain network to maintain a blockchain comprising a plurality of immutable irreversible blocks created using one or more one-way cryptographic algorithms as known in the art which present an impossible computation challenge for altering the blocks in the blockchain. As such the local logs <NUM> maintained by each of the vehicles <NUM> of the community <NUM> are utilized as local copies (ledgers) of the distributed blockchain. Each of the immutable irreversible blocks associates the identifier of a certain one of the update packages released by the trusted distribution system(s) <NUM> with the verification code generated for the respective update package. In this blockchain scheme, only the trusted distribution system(s) <NUM> which is a verified and trusted entity may append (commit) a new block to the blockchain. Each block in the blockchain is chained to at least some of its preceding blocks using a cryptographic signature thus making the committed block practically immutable and irreversible since a malicious party attempting to manipulate and/or compromise the committed block may require extreme computing resources making it impractical to alter the block. Moreover, in order to compromise the block the malicious party may need to have a substantial number of the vehicles <NUM> compromised, potentially a majority of the vehicles <NUM>. Compromising such a large group of vehicles <NUM> may also be impossible thus further ensuring that the blocks in the blockchain are immutable and irreversible.

As described herein before, in order to communicate with other vehicles <NUM> and optionally with the trusted distribution system(s) <NUM> to continuously update the local log <NUM>, each of the vehicles <NUM> of the community <NUM> may execute one or more software modules, for example, the update agent <NUM>, a dedicated software module and/or a combination thereof.

Since the community <NUM> comprises the plurality of vehicles <NUM> which connect to each other on Ad-Hoc basis due to their mobility and intermittently ON and OFF state, the network formed by the vehicles <NUM> may not be fully connected at all times and may rapidly change its structure and layout. Therefore one or more local Ad-Hoc networks, connections and/or sessions (designated Ad-Hoc networks herein after) <NUM> may be established between two or more nearby vehicles <NUM> of the community <NUM> which are within the reception area defined by the reception range of the V2V communication channel(s) of the nearby vehicles <NUM>. The reception area is therefore limited by the reception range of the V2V communication channel(s) which may typically be in a range of several hundred meters, for example, <NUM> meters. For example, two or more vehicles <NUM> driving and/or parking in a parking lot may form such a local Ad-Hoc network <NUM>. In another example, two or more vehicles driving at substantially the same speed in a street, a road and/or the like may form such a local Ad-Hoc network <NUM>. In another example, two or more vehicles temporarily stopping next to each due to one or more traffic conditions, for example, a red traffic light, a traffic jam and/or the like may form such a local Ad-Hoc network <NUM>. Once a certain local AD-Hoc network <NUM> is established, the vehicles <NUM> connected to the certain local Ad-Hoc networks <NUM> may communicate with each other.

Optionally, one or more of the vehicles <NUM> may communicate with one or more other vehicles <NUM> and optionally with one or more of the trusted distribution systems <NUM> via one or more infrastructure networks, for example, a cellular network, a LAN, the internet and/or the like for exchanging the verification data and updating their local logs <NUM>. For example, a certain vehicle <NUM> may connect via its network interface such as the network interface <NUM> to one or more cellular base stations and communicate with one or more of the other vehicles <NUM> and/or with the trusted distribution systems <NUM>. In another example, a certain vehicle <NUM> may connect via its network interface <NUM> to one or more wireless access points (e.g. a Wi-Fi access point) providing access to the internet. Once connected to the internet, the certain vehicle <NUM> may communicate with one or more of the other vehicles <NUM> and/or with the trusted distribution system(s) <NUM>. Such connection to an access point may be established, for example, while the vehicle <NUM> is located in a parking lot in which one or more access points are deployed. In another example, while located near a residence and/or an office of a driver and/or an owner of the vehicle <NUM>, the vehicle <NUM> may connect to one or more access points deployed in the residence and/or the office respectively. In another example, while parked at the residence and/or the office of the driver/owner, a wired network interface provided by the network interface <NUM>, for example, the LAN interface may be connected to a LAN infrastructure available at the residence and/or the office which provides access to the internet and/or to the trusted distribution system(s) <NUM>.

Moreover, in order to establish trust between vehicles <NUM> communicating with each other, a vehicle <NUM> which communicates with one or more other vehicles <NUM> may first require the other vehicle(s) <NUM> to authenticate itself using one or more authentication methods, techniques and/or algorithms as known in the art, for example, exchanging messages encoded using asymmetric cryptography using Private-Public key pairs and/or the like. To support this each vehicle <NUM> may have a unique signature to authenticate itself as the originator of the exchanged data messages. The unique signatures may be furthermore used to verify the messages are not tampered. The local log <NUM> storing the identification information, for example, the VIN of all vehicles <NUM> of the community <NUM> may be further used to associate the VIN of each of the vehicles <NUM> with its unique signature, for example, the public key of the respective vehicle <NUM>. When communicating with each other, each of the communicating vehicles <NUM> may retrieve the public key of the other vehicle <NUM> and use the public key to decrypt the received message(s) which are encrypted by the other vehicle <NUM> using the respective private key. In this manner the communicating vehicles <NUM> may authenticate each other as well as the content of the exchanged message(s).

Reference is now made to <FIG> and <FIG>, which are schematic illustrations of exemplary control plane and data plane used by a community of networked vehicles to transfer and validate update packages directed for ECUs of the vehicles, according to some embodiments described herein.

As seen in <FIG>, an exemplary distributed blockchain <NUM> may be employed by the plurality of vehicles <NUM> of the community <NUM> such that each of the vehicles <NUM> maintains a local log such as the local log <NUM> comprising a local copy of the blockchain <NUM>. The blockchain <NUM> may include a plurality of immutable irreversible blocks <NUM> which are created and appended to the blockchain <NUM> by the trusted distribution system(s) <NUM> and associated with a plurality of update packages <NUM> distributed to the community <NUM> by the trusted distribution system(s) <NUM>. Each of the blocks <NUM> is associated with a respective one of the update packages <NUM>, for example, a block <NUM> may be associated with an update package <NUM>, a block <NUM> may be associated with an update package <NUM> and so on to block N which may be associated with an update package N. Each of the update packages <NUM> may be constructed of one or more segments, for example, a header, a body (data content) and a footer which may serve as a signature.

The vehicles <NUM> may communicate with each other and/or with the trusted distribution system(s) <NUM> for synchronizing their local copies of the blockchain <NUM> with each other via a plurality of transfers which may be regarded as a control plane while the transfer of the update packages <NUM> themselves may be regarded as a control plane. The data volume included in each of the blocks <NUM> may be significantly small and the control plane may therefore utilize a significantly low communication bandwidth compared to the data plane used for transferring the large volume update packages <NUM>.

Each of the blocks <NUM> may include one or more package attributes relating to the respective update package <NUM>. The package attributes may include attributes of the respective update package, for example, an identifier (ID), a revision, a version, a release date and/or the like. In another example, the package attributes may include attributes relating to an ECU such as the ECU <NUM> targeted by the respective update package <NUM>, for example, a model, a Part Number (P/N), a Serial Number (S/N) and/or the like.

Each of the blocks <NUM> includes a verification code of the respective update package <NUM> which may be used for validating the respective update package <NUM> is valid, i.e., genuine and untampered and optionally whether its TTL is valid. The verification code may be implemented using one or more methods as known in the art. For example, the verification code may be a hash value computed for the respective update package <NUM> using one or more hash functions.

Optionally, the hash value may serve as the identifier of the respective update package <NUM> since assuming a sufficiently complex hash function is used the hash value computed for each of the update packages <NUM> is unique to the respective update package <NUM>. In such case, upon reception of a certain update package <NUM>, an update agent such as the update agent <NUM> may calculate the hash value of the received certain update package <NUM> and may compare it against the hash value logged in the respective block <NUM> associated with the certain update package <NUM>.

As seen in <FIG>, another exemplary distributed blockchain <NUM> may be employed by the plurality of vehicles <NUM> of the community <NUM> for logging the vehicles <NUM> which are genuine members of the community <NUM>. Each of the vehicles <NUM> may maintain the vehicles blockchain <NUM> as part of its local log <NUM> as described herein above. The vehicles blockchain <NUM> may include a plurality of blocks <NUM> which may only be created and appended to the vehicles blockchain <NUM> by the trusted distribution system(s) <NUM>. Each of the blocks <NUM> may include one or more attributes of the respective vehicle, for example, a VIN, a model, a year of manufacture, a year of joining the community <NUM> and/or the like.

As described for the blockchain <NUM>, the vehicles <NUM> may communicate with each other as well as with the trusted distribution system(s) <NUM> over the control plane to constantly update and synchronize their local copies of the vehicles blockchain <NUM> to reflect vehicles <NUM> which joined the community <NUM> and/or vehicles <NUM> removed from the community <NUM>. When establishing a communication with another vehicle <NUM>, the update agent <NUM> may first authenticate an identity of the other vehicle <NUM> to verify that the other vehicle <NUM> is a genuine member of the community <NUM> and may thus be trusted.

As shown at <NUM>, the process <NUM> starts with the update agent <NUM> executed by one or more of the vehicles <NUM> receiving one or more update packages from one or more vehicles <NUM> of a community such as the community <NUM> via one or more of the V2V communication channels provided by the network interface <NUM> and/or by the mobile device <NUM>. In particular, the update agent <NUM> may receive the update package(s) from one or more nearby vehicles <NUM> which are within the reception area of the V2V communication channel(s) of the respective vehicle <NUM> and with which an AD-Hoc network such as the Ad-Hoc network <NUM> is established.

As described herein before, a certain vehicle <NUM> may establish an Ad-Hoc network <NUM> with one or more other nearby vehicles when located within the reception area of the V2V communication channel(s) of the certain vehicle <NUM>. For example, when the certain vehicle <NUM> enters a parking lot it may identify one or more nearby vehicles <NUM> of the community <NUM> and may establish the Ad-Hoc network <NUM>. In another example, example, the certain vehicle <NUM> may identify one or more nearby vehicles driving at substantially the same speed for a certain period of time allowing the certain vehicle <NUM> to establish the Ad-Hoc network <NUM> with this vehicle(s) <NUM> driving nearby. In another example, the certain vehicle <NUM> may temporarily stop and/or drive significantly slow next to one or more nearby vehicles <NUM> for a substantial period of time due to one or more traffic conditions, for example, a red traffic light, a traffic jam and/or the like. In such case, the certain vehicle <NUM> may establish the local Ad-Hoc network <NUM> with theses nearby vehicles <NUM>.

Optionally, prior to receiving the update package(s) from the nearby vehicle(s) <NUM>, the update agent <NUM> first authenticates the nearby vehicle(s) <NUM> to verify their identity, for example, using the private-public keys encryption scheme described herein before. To authenticate the nearby vehicle(s) <NUM>, the update agent <NUM> may compare the VIN received from the nearby vehicle(s) <NUM> to the VIN logged in the local log <NUM>, specifically in a vehicles blockchain <NUM>.

Optionally, the update agent <NUM> supports cumulative reception of one or more of the update packages. The update agent <NUM> may establish a plurality of separate reception communication sessions with one or more nearby vehicles and receive one or more portions of a certain update package until accumulating the entire certain update package. For example, the update agent <NUM> of a certain vehicle <NUM> may establish a first reception communication session with a first nearby vehicle <NUM>. During the first reception communication session the update agent <NUM> may receive a first portion of a certain update package before the first reception communication session is terminated. At a later time, for example, <NUM> seconds, <NUM> minutes, a day, a week and/or the like, the update agent <NUM> of the certain vehicle <NUM> may establish a second reception communication session with another nearby vehicle <NUM> which may be the first nearby vehicle <NUM> and/or another nearby vehicle <NUM>. During the second reception communication session the update agent <NUM> may resume reception of the certain update package and receive a second portion of the certain update package before the second reception communication session is terminated. The update agent may repeat the reception communication sessions until receiving all portions of the certain update package accumulated to constitute the complete certain update package.

Each update package may be directed to update one or more executable modules, for example, software, firmware, middleware and/or the like and/or one or more non-executable modules (e.g. map data, calibration information, etc.) of one or more target ECUs <NUM>. One or more of the update packages may be further directed to update a gate map of one or more hardware components, for example, an FPGA, an ASIC and/or the like of one or more of the ECUs <NUM>. Each of the update packages may include a full revision update (e.g. a new revision, a previous revision, an updated revision, etc.) for a respective ECU <NUM> or a differential update to the executable and/or non-executable module(s) already installed in the respective ECU <NUM>.

Each of the update packages originates from one or more of the trusted distribution systems such as the trusted distribution system <NUM> which are the only entities eligible for releasing the update packages to the community <NUM> of vehicle <NUM>. Therefore, while the update packages may be designed, produced and/or delivered by one or more software, firmware and/or middleware vendors, the update packages must be first provided to the trusted distribution system(s) <NUM> which may release these update packages to the community <NUM>.

Optionally, one or more of the update package may be encoded and/or encrypted using one or more encryption keys as known in the art to increase security of the update package during distribution to the community <NUM>.

As shown at <NUM>, the update agent <NUM> determines whether each of the received update package(s) is directed (targets) for one or more of the ECUs <NUM> of the certain vehicle <NUM>.

Each of the update packages <NUM> may be configured according to one or more package attributes of the target ECU(s) <NUM>, for example, a type, a variant, a vendor, a (current) revision and/or the like. For example, a certain update package may be configured to upgrade a plurality of ECUs <NUM> of a certain type and/or ECUs <NUM> produced by a certain vendor. In another example, a certain update package may be configured to upgrade every ECU <NUM> loaded with a certain software module of revisions preceding a certain revision. In another example, a certain ECU <NUM> may have multiple variants where each of the variants may have different functionality, features and/or capabilities. In such case, multiple versions of a respective update package may be created by a vendor and released by the trusted distribution system(s) <NUM> for the certain type of ECU <NUM> where each of the update package versions may be adapted and/or configured for one or more of the variants of the ECU <NUM>.

In order to uniquely identify each of the released update packages, each update package is assigned a unique identifier which uniquely and exclusively identifies the package attribute(s) of the respective update package. The identifier may identify, for example, the type of ECU(s) <NUM> targeted by the respective update package, i.e., the type of ECU(s) <NUM> that the respective update package is directed to. In another example, the identifier may identify a version of the respective update package to identify the variant of the ECU(s) <NUM> targeted by the respective update package. In another example, the identifier may identify a revision of the respective update package. The identifier may be included in the update package using one or more methods, techniques and/or implementations. For example, one or more update packages may include a header comprising the identifier of the respective update package. In another example, the identifier of one or more update packages may be included as metadata of the respective update package. Moreover, the header and/or the metadata may be encrypted using one or more encryption key as known in the art. In another example, the identifier may be implemented by a hash value computed for the respective update package using one or more hash functions configured to generate a unique hash value for each of the update packages.

The update agent <NUM> may extract the identifier of the received update package(s) and analyze the extracted identifier with respect to the ECU(s) <NUM> deployed in the vehicle <NUM> to determine whether the received update package(s) is directed (targets) for one or more of the ECUs <NUM> of the certain vehicle <NUM>. For example, assuming the identifier of the received update package is its hash value the update agent <NUM> may calculate the hash value of the received update package and compare the computed hash value to the hash values locally stored in a blockchain such as the blockchain <NUM> in the local log <NUM>. The update agent may then identify the target ECU(s) <NUM> associated in the respective block <NUM> in the blockchain <NUM> with the computed hash value. In another example, assuming the identifier of the received update package is embedded in the header of the update package, the update agent <NUM> may retrieve the identifier and compare the identifier to the identifiers locally stored in the blockchain <NUM> in the local log <NUM>. The update agent may then identify the target ECU(s) <NUM> associated in the respective block <NUM> in the blockchain <NUM> with the retrieved identifier.

For example, based on the analysis of the identifier, the update agent <NUM> may determine that a certain received update package is directed to a certain type of ECU <NUM>, for example, a certain ECU controlling a steering wheel control system, a certain ECU controlling a breaking system, a certain ECU controlling operation of the head lights and/or the like. In another example, the update agent <NUM> may determine that a certain received update package is directed for certain ECUs <NUM> loaded with an older software package revision preceding the revision of the received update package.

The update agent <NUM> may apply one or more methods to check whether one or more ECUs <NUM> targeted by the received update package are deployed in the vehicle <NUM>. For example, in a most naive implementation, the update agent <NUM> may access each of the ECUs <NUM> deployed in the vehicle <NUM> to identify the attributes (parameters) of each of the deployed ECUs <NUM>, for example, a type, a variant, a feature set, a software revision, a most recent update date, a storage capacity and/or the like. The update agent <NUM> may then analyze the package attributes identified by the identifier of the received update package with respect to the ECU attributes to check for a match indicating that the received update package is directed to one or more of the ECUs <NUM> deployed in the vehicle <NUM>. In a more efficient implementation, the update agent <NUM> may maintain a record, for example, a file, a table, a list, a database and/or the like which lists all the ECUs <NUM> deployed in the vehicle <NUM> and associated each of the listed ECUs <NUM> with its respective ECU attributes. In such case, the update agent <NUM> may analyze the package attributes identified by the identifier of the received update package with respect to the ECU attributes of all ECUs <NUM> listed in the record and to check for a match indicating that the received update package is directed to one or more of the ECUs <NUM> deployed in the vehicle <NUM>.

As shown at <NUM> which is a conditional step, for each of the received update packages, in case the update agent <NUM> determines that the update package is directed to one or more of the ECUs <NUM> deployed in the vehicle <NUM>, the process <NUM> branches to step <NUM>, otherwise the process <NUM> branches to step <NUM>.

As shown at <NUM>, after the update agent <NUM> determines that one or more of the received update package(s) are directed to ECU(s) <NUM> deployed in the vehicle <NUM>, the update agent <NUM> communicates with at least some of the vehicles <NUM> of the community <NUM> to validate that each of the received update package(s) is valid. A valid update package is a genuine update package which originates from the trusted distribution system(s) <NUM> and is untampered, i.e. the content of the update package was not altered after released by the trusted distribution system(s) <NUM>.

The update agent <NUM> may communicate with a subset of the vehicles <NUM> of the community <NUM> via the V2V communication channel(s) of the vehicle <NUM>. The subset may therefore comprise a plurality of nearby vehicles <NUM> located with the reception area of the V2V communication channel(s) and forming a local Ad-Hoc network <NUM>.

Optionally, the update agent <NUM> authenticates each of the subset of nearby vehicle(s) <NUM> prior to proceeding with validation of the received update package.

Naturally, there may be an overlap between at least some of the nearby vehicles <NUM> from which the update package(s) is received as described in step <NUM> and the nearby vehicles <NUM> of the subset that the update agent <NUM> interacts with to validate the received update package. However, such an overlap may not necessarily occur since the vehicle <NUM> (executing the update agent <NUM>) is mobile and may move between geographical locations and areas between the rime of receiving a certain update package and the time of validating the certain received update package. As the vehicle <NUM> moves it may encounter one or more other nearby vehicles <NUM> previously out of the reception area of the V2V communication channel(s) of the vehicle <NUM>. One or more new local Ad-Hoc networks <NUM> may be therefore established (formed) and the update agent <NUM> may communicate with the nearby vehicle(s) <NUM> connected to the newly formed Ad-Hoc network(s) <NUM>.

As described here in before, each of the vehicles <NUM> in the community <NUM> maintains its respective local log <NUM> in which each of the plurality of update packages released by the trusted distribution system(s) <NUM> for distribution to the vehicles <NUM> of the community <NUM> is associated with its respective verification data, for example, a respective verification code. As described, the association between the update packages and their verification codes is based on the identifiers uniquely assigned to each of the update packages as described such that each identifier of each update package is associated in the local logs <NUM> with the respective verification code, for example, the hash value calculated for the respective update package.

Since the vehicles <NUM> of the community <NUM> apply one or more of the distributed computing algorithms and/or protocols, for example, the blockchain and/or the like to communicate with each other (control plane) to continuously synchronize their local logs <NUM> these synchronized local logs <NUM> may reflect similar verification data (verification codes) for the released update packages.

The update agent <NUM> may validate the received update package according to a consensus decision negotiated among the subset of vehicles <NUM> for the queried received update package. The consensus of whether the update package is valid or not may be negotiated and reached between the subset of vehicles <NUM> using one or more methods, algorithms and/or protocols. For example, as the vehicle <NUM> executing the update agent <NUM> is part of the community <NUM>, the update agent <NUM> may engage in the distributed computing protocol, for example, a Multi-Party Computation (MPC) with the subset of vehicles <NUM> typically established using secret sharing algorithms as known in the art to produce the consensus decision. The subset of vehicles <NUM> each having its local log <NUM> may conduct the MPC session to produce the consensus decision agreed on by a majority of the subset of vehicles <NUM> according to the verification data available for the queried update package in each of the local logs <NUM> of each of the subset of vehicles <NUM>.

The number of vehicles <NUM> in the subset and optionally the type of majority (e.g. absolute majority, relational majority, etc.) required for reaching the consensus decision may be defined according to one or more security parameters of the community <NUM>. The security parameters defined for the community <NUM> may include, for example, a number of vehicles <NUM> in the community <NUM>, a geographical distribution of the vehicles <NUM> (i.e., density or frequency of encounters), a type of the community <NUM> (i.e. privately owned vehicles <NUM>, company vehicles, etc.), a security level of the data exchanged between the vehicles <NUM> (e.g. encryption, authentication, etc.), type of protocol(s) employed to maintain the control plane (i.e., the synchronized local logs <NUM>) (e.g. blockchain, etc.), a criticality of the queried update package and/or the like. For example, assuming the community <NUM> comprises an extremely large number of vehicles <NUM>. In such case the update agent <NUM> may be configured and/or instructed to communicate with a subset of vehicles <NUM> which comprises a significantly large number of vehicles <NUM>. In another example, assuming the geographical distribution of at least some of the vehicles <NUM> of the community <NUM> is limited to a significantly small geographic area such that encounters between the at least some vehicles <NUM> are highly frequent. Again, in such case the update agent <NUM> may be configured to communicate with a subset of vehicles <NUM> comprising a significantly large number of vehicles <NUM>. In another example, assuming the community <NUM> includes a plurality of vehicles <NUM> owned by a corporate and are inaccessible to outside people. Since such a community <NUM> may be significantly robust against malicious attacks, the update agent <NUM> may be configured to communicate with a subset of vehicles <NUM> comprising a relatively small number of vehicles <NUM>. In another example, assuming the vehicles <NUM> of the community <NUM> communicate with each other using highly secure communication protocols. In such case, the update agent <NUM> may be configured to communicate with a subset of vehicles <NUM> comprising a relatively small number of vehicles <NUM>. In another example, the number of vehicles <NUM> required for the subset depends on the criticality of queried update package. High criticality update packages may be directed to ECU(s) <NUM> which control critical systems, for example, the steering wheel system, the breaking system, the acceleration system, an air bag system and/or the like. Low criticality update packages may be directed to ECU(s) <NUM> which control non-critical systems, for example, the infotainment breaking system, the climate control system and/or the like. Therefore, the more critical the queried update package is the more vehicles <NUM> are required for the subset with which the update agent <NUM> communicates to validate the update package. In contrast, the less critical the queried update package is fewer vehicles <NUM> are required for the subset.

The update agent <NUM> may further verify that the received update package(s) are valid with respect to their expiration time. The update agent <NUM> may analyze the expiration time tag assigned to one or more of the received update package(s) and may determine based on comparison with the current time and date whether the received update package(s) are still valid or whether the received update package(s) are expired. The update agent <NUM> may obtain the current time and date from one or more external timing sources. For example, the update agent <NUM> may obtain the current time and date from a GPS sensor which receives the current time and date for the GPS system. In another example, the update agent <NUM> may communicate, via the network interface <NUM>, with one or more infrastructure components deployed in the environment of the vehicle <NUM> to obtain the current time and date. In another example, the update agent <NUM> may obtain the current time and date from one or more time keeping modules, for example, an RTC which is constantly or periodically synchronized with one or more of the external timing sources.

As shown at <NUM> which is a conditional step, for each of the received update package(s), in case the update agent <NUM> determines, based on the consensus of the subset of vehicles <NUM> and optionally on the expiration time, that the received update package is valid, the process <NUM> branches to step <NUM>, otherwise the process <NUM> branches to step <NUM>.

As shown at <NUM>, after the update agent <NUM> validates that one or more of the received update package(s) is valid, the update agent <NUM> may initiate an update of the target ECU(s) <NUM> using the validated update package(s). For example, the update agent <NUM> may transmit a certain validated update package to the target ECU(s) <NUM> for which the certain update package is directed. The target ECU(s) <NUM> may then use the certain update package to update its software, firmware and/or middleware as instructed by the content of the certain update package. In another example, the update agent <NUM> may transmit a certain validated update package to a central dispatcher ECU <NUM> configured to distribute update packages to target ECUs <NUM>. The central dispatcher ECU <NUM> may then transmit the certain update package to the target ECU(s) <NUM> which may use the certain update package. In another example, the update agent <NUM> may transmit a certain validated update package to an updating ECU <NUM> configured to update one or more target ECUs <NUM> using the certain update package.

As shown at <NUM>, the update agent <NUM> may locally store one or more of the received update package(s), for example, in the storage <NUM> in order to support transmission of the received update package(s) to one or more vehicles <NUM> of the community <NUM>. As seen in the process <NUM>, the update agent <NUM> may locally store one or more of the received update package(s) regardless of whether the update package(s) are directed to (target) ECUs <NUM> of the vehicle <NUM>. This means that the update agent <NUM> may locally store one or more of the update packages which are not directed to the ECUs <NUM> of the vehicle <NUM>.

However, due to the large number of ECUs <NUM> in modern vehicles <NUM>, the number of update packages released to the community <NUM> may potentially be very large and locally storing a large number of the update packages, for example, in the storage <NUM> may consume major storage resources. In order to prevent excessive utilization of storage resources of the storage <NUM>, the update agent <NUM> may store the received update package(s) for a limited predefined (storage) time period after which the respective update package is discarded and removed (deleted) from the storage <NUM>.

During the predefined storage time period, the vehicle <NUM>, in particular a software module executed by a processor(s) of the vehicle <NUM> such as the processor <NUM>, for example, the update agent <NUM> may transmit one or more of the stored update package(s) to one or more nearby vehicle(s) <NUM> encountered in the reception area of the V2V communication channel(s) of the vehicle <NUM>. When encountering such nearby vehicle(s) <NUM>, the update agent <NUM> may transmit one or more of the stored update package(s) to the nearby vehicle(s) <NUM> via a local Ad-Hoc network <NUM> established over the V2V communication channel(s) with the nearby vehicle(s) <NUM>.

The predefined storage time period may be adjusted according to one or more operational parameters of the vehicle <NUM>, for example, a geographical area where the vehicle <NUM> is located, a surrounding terrain of the vehicle <NUM>, an ON/OFF state of the vehicle <NUM>, a speed of the vehicle <NUM> and/or the like. For example, in case the vehicle <NUM> currently stores one or more update packages and is going into OFF state, i.e. the vehicle <NUM> is turned OFF, the predefined time period may be extended. Extending the predefined time period may prevent discarding the stored update package(s) while the vehicle <NUM> is not moving and may not be able to effectively circulate and share the stored update package(s) with other vehicles <NUM>. In another example, assuming the vehicle <NUM> is moving in a dense urban area and hence encounters a large number of nearby vehicles <NUM>. In such vehicle dense geographical areas the update package(s) may be easily circulated by the multitude of vehicles <NUM> driving in this area. The predefined time period may be therefore significantly reduced since the update packages may be rapidly and quickly shared (transmitted) with other vehicles <NUM>. In contrast, assuming the vehicle <NUM> is moving in a country side area, for example, an interstate highway, and hence rarely encounters other vehicles <NUM>. In such case the predefined time period may be extended to ensure that the update packages are stored during the potentially long drive on the highway and distributed to other vehicles <NUM> at a destination of the vehicle <NUM> thus expanding the circulation of the update package(s) to substantially remote geographical areas. In another example, assuming the vehicle <NUM> is driving at high speed. In such speeds there is a very low probability that another nearby vehicle <NUM> will be able to maintain an Ad-Hoc Local network <NUM> with the vehicle <NUM> for a time period sufficient for transferring the update package(s). In such case, the predefined time period may be reduced since in such high speeds the update package(s) may not be effectively distributed to other nearby vehicle(s) <NUM>.

The predefined time period may be further adjusted according to the storage capacity of the storage <NUM>. Naturally, the larger the capacity of the storage <NUM> the longer may be the predefined time period for storing the update package(s). Complementary, the smaller the capacity of the storage <NUM> the shorter may be the predefined time period for storing the update package(s). Moreover, the predefined time period may be adjusted according to a criticality of the update packages. As such one or more update packages identified as critical may be stored for longer predefined time periods while less important update packages may be stored for shorter predefined time periods.

In order to further prevent excessive utilization of the storage <NUM>, the update agent <NUM> does not record and/or maintain logs for tracking the transmission events of the stored update packages to the nearby vehicles <NUM> meaning that the update agent <NUM> does not record which update packages were transmitted to which vehicles <NUM>. Due to the large number of ECUs <NUM> in modern vehicles <NUM>, the number of update packages released to the community <NUM> may potentially be very large. Moreover, the number of vehicles <NUM> that may be encountered by each vehicle <NUM> may be extremely large. Therefore maintaining logs for all transmissions of the update packages during all encounters may consume major storage resources. As such, in order to avoid allocation of such substantial storage resources for the update agent <NUM> to record the transmission events, the update agent <NUM> does not record, track and/or log these transmission events.

However, since no record or log is made of which update packages were transmitted to which vehicles <NUM> it is highly probable that in many scenarios multiple nearby vehicles <NUM> may transmit the same update package(s) to the same vehicle(s) <NUM> and optionally to each other thus significantly increasing utilization of network resources required for the redundant transmissions of the update package(s). The redundant transmissions of the update package(s) may further consume computing resources at one or more of the vehicles <NUM> which engage in the transmission and/or reception of identical update package(s).

For example, assuming a first vehicle <NUM> enters a parking lot and establishes an Ad-Hoc network <NUM> with a second and a third nearby vehicles <NUM> and transmits a certain update package to the second and third nearby vehicles <NUM>. After receiving the certain update package, the second and third nearby vehicles <NUM> may transmit the certain update package back to the first vehicle <NUM> which naturally already has the certain update package as the certain update package was initially received from the first vehicle <NUM>. In another example, assuming a first vehicle <NUM> stops in a traffic jam next to several vehicles <NUM>, establishes an Ad-Hoc network <NUM> with a second and a third nearby vehicles <NUM> and transmits a certain update package to the second and third nearby vehicles <NUM>. After receiving the certain update package, the second and third nearby vehicles <NUM> may transmit the certain update package to a fourth nearby vehicle <NUM>. Moreover, the first vehicle <NUM> may also communicate with the fourth nearby vehicle <NUM> and may attempt to transmit the certain update package to the fourth nearby vehicle <NUM>. As such the fourth nearby vehicle <NUM> may receive the same update package from the first, second and third vehicles <NUM>.

One or more measures may be applied in order to prevent one or more of the vehicles <NUM> from engaging in the redundant transmission sessions initiated for transferring update packages already available to the respective vehicle <NUM> without the need to record and/or track the transmission sessions. These measures may be applied to improve performance of the networks established between the vehicles <NUM> and optionally reduce computing resources at the vehicles <NUM> allocated for update agent <NUM> for handling identical update packages received multiple times.

A first measure which may be applied by the update agent <NUM> executed by one or more of the vehicles <NUM> may be directed to prohibit reception of additional update packages following reception of an update package. The update agent <NUM> may be configured to wait for a predefined no-reception time period following the reception of one or more update packages. During the no-reception time period the update agent <NUM> may be disabled to receive additional update packages. The no-reception time period may be adjusted according to one or more of the operational parameters of the vehicle <NUM>, for example, the geographical area where the vehicle <NUM> is located, the surrounding terrain of the vehicle <NUM>, ON/OFF state of the vehicle <NUM>, the speed of the vehicle <NUM> and/or the like. For example, assuming the vehicle <NUM> is moving in a dense urban area and in which it is expected to encounter multiple nearby vehicles <NUM>. In such case the no-reception time period may be adjusted to be significantly long since there is a high probability that the vehicle <NUM> receive the same update package from multiple nearby vehicles <NUM> and/or multiple times from the same from nearby vehicle(s) <NUM>. Extending the no-reception time period to be significantly long may allow the vehicle <NUM> to leave the geographical area in which the same update package(s) is circulated. Moreover, during the extended no-reception time period, the nearby vehicles <NUM> attempting to transmit the update package(s) may discard their stored update package(s) due to expiration of their predefined storage time period and hence stop repeating transmission of the update package(s). In another example, assuming the vehicle <NUM> is driving at high speed. In such speeds there is a very low probability that the same nearby vehicle <NUM> is within the reception area of the vehicle <NUM> for a long period of time and the no-reception time period may be therefore reduced.

A second measure which may be applied by the update agent <NUM> is directed to prohibit repeated subsequent transmissions of the same update package(s). The update agent <NUM> may be configured to wait for a predefined no-transmission time period following transmission of a respective update package. During the no-transmission time period the update agent <NUM> may be disabled to transmit the respective update package. The no-transmit time period may be adjusted according to one or more of the operational parameters of the vehicle <NUM>, for example, the geographical area where the vehicle <NUM> is located, the surrounding terrain of the vehicle <NUM>, ON/OFF state of the vehicle <NUM>, the speed of the vehicle <NUM> and/or the like. For example, assuming the vehicle <NUM> is moving in a relatively low speed inside a parking lot such that the vehicle <NUM> is expected to encounter the same nearby vehicles <NUM> for a long period of time. In such case the update agent <NUM> which does not record or track the transmission events may initiate multiple transmission sessions to transmit the same update package(s) to the same nearby vehicle <NUM>. In such case the no-transmission time period may be adjusted to be significantly long to prevent the update agent <NUM> from transmitting the same update package multiple times during multiple transmission sessions since it is likely that at least some of these transmission sessions may be conducted with the same nearby vehicle <NUM>. In another example, assuming the vehicle <NUM> is driving at high speed where there is a very low probability that the same nearby vehicle <NUM> is within the reception area of the vehicle <NUM> for a long period of time. In such case the no-transmission time period may be significantly reduced to enable the update agent <NUM> to repeatedly transmit the same update package(s) in a plurality of transmission sessions established with nearby vehicles <NUM> since it is highly probable that each of the transmission sessions is conducted with a different nearby vehicle <NUM>.

Optionally, when communicating with one or more other vehicles <NUM> to receive a certain update package, the update agent <NUM> may check whether the certain update package is currently locally stored at the vehicle <NUM> after previously received and stored for potential transmission to other vehicles <NUM>. The update agent <NUM> may compare between the identifier of the certain update package and the identifier of each of the currently locally stored update packages to check whether the certain update package was already received at the vehicle <NUM>. In case the update agent <NUM> determines that the certain update package is locally available as it was previously received, the update agent <NUM> may terminate the communication session and reject reception of the certain update package to reduce the redundant transmission.

As shown at <NUM>, the update agent <NUM> discards the received update package(s). The received update package(s) may be discarded due to one or more reasons and execution paths of the process <NUM>. For example, the update agent <NUM> may discard one or more of the update packages determined to be invalid as described in step <NUM>. In another example, the update agent <NUM> may discard one or more of the locally stored update packages for which the predefined storage time period has expired.

It is expected that during the life of a patent maturing from this application many relevant systems, methods and computer programs will be developed and the scope of the terms ECU and V2V communication channels are intended to include all such new technologies a priori.

Throughout this application, various embodiments described herein may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the embodiments described herein.

The word "exemplary" is used herein to mean "serving as an example, an instance or an illustration".

Any particular embodiment described herein may include a plurality of "optional" features unless such features conflict.

It is appreciated that certain features of the embodiments described herein, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the embodiments described herein, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment.

Claim 1:
A method of updating Electronic Control Units (ECUs) (<NUM>) of vehicles (<NUM>) using updates received via Vehicle to Vehicle, V2V, communication channels and verified by a vehicles consensus, comprising:
using at least one processor (<NUM>) of a vehicle (<NUM>) executing a code for:
receiving from at least one nearby vehicle (<NUM>), via at least one V2V communication channel, at least one of a plurality of update packages distributed for updating a plurality of ECUs (<NUM>) deployed in a plurality of vehicles (<NUM>), the at least one nearby vehicle (<NUM>) is within a reception area of the at least one V2V communication channel;
analyzing an identifier extracted from the at least one update package;
determining, based on the analysis, whether the at least one update package is directed to at least one ECU (<NUM>) of the vehicle (<NUM>);
communicating, in case of positive determination, via the at least one V2V communication channel with at least a subset of the plurality of vehicles, wherein each of the plurality of vehicles (<NUM>) maintains a local log associating each of the plurality of update packages with a respective verification code;
validating the verification code extracted from the at least one update package according to a consensus of the subset of vehicles; and
initiating update, in case of successful validation, of the at least one ECU (<NUM>) using the at least one update package;
wherein a predefined no transmission period is applied between subsequent transmissions of the update package during which the update package is not transmitted, and a predefined no reception period is applied following the reception of the update package during which reception of update packages is prohibited.