Upgrading method and device

Abstract

The invention discloses an upgrading method and device.The method comprises the steps that first equipment sends an upgrading request to a server, the upgrading request comprises an identifier of a to-be-upgraded component and a fresh factor corresponding to the to-be-upgraded component, and the fresh factor is at least used for identifying one-time upgrading of the to-be-upgraded component; the server sends upgrading information to the first device, the upgrading information comprises signature information corresponding to the to-be-upgraded component, and the signature information is generated by the server based on the identifier of the to-be-upgraded component and a fresh factor; and finally, the first equipment sends upgrading information. In this way, the signature information can be used for at least one time of upgrading of the specific component, and car refreshing attacks of attackers and abuse of upgrading files can be avoided.

Description

Technical Field

[0001] The present application relates to the field of vehicle-mounted upgrades, and in particular to an upgrade method and device. Background Art

[0002] The upgrade of vehicle-mounted components can repair defects in existing functions of the vehicle and / or introduce new functions, which is conducive to improving the user's car experience. The upgrade method of vehicle-mounted components can be, for example, over-the-air technology (OTA) upgrade, near-field upgrade of diagnostic instrument, etc.

[0003] Taking OTA upgrade as an example, the current verification of OTA upgrade only focuses on the legitimacy of the source of the upgrade file and / or whether the upgrade file has been tampered with. It cannot resist attackers who use old version upgrade files or privileged version upgrade files or upgrade files of other vehicles to perform vehicle flashing attacks, resulting in the abuse of upgrade files. Summary of the invention

[0004] The present application discloses an upgrade method and device, which can prevent the abuse of upgrade files through signature information, and effectively avoid the attacker's car brushing attack.

[0005] In a first aspect, the present application provides an upgrade method, the method comprising: sending a first upgrade request to a server, the first upgrade request comprising an identifier of a component to be upgraded in a vehicle and a first freshness factor corresponding to the component to be upgraded, the first freshness factor being used to identify at least one upgrade of the component to be upgraded; receiving first upgrade information from the server, the first upgrade information comprising first signature information corresponding to the component to be upgraded, the first signature information being associated with the identifier of the component to be upgraded and the first freshness factor corresponding to the component to be upgraded; and sending the first upgrade information.

[0006] Exemplarily, the first freshness factor may also be used to identify multiple upgrades of the component to be upgraded. Taking the three upgrades of component 1 (i.e., the component to be upgraded) as an example, the freshness factors corresponding to the first two upgrades of component 1 in the three upgrades are the same, or the freshness factors corresponding to the last two upgrades of component 1 in the three upgrades are the same, or the freshness factors corresponding to component 1 in the three upgrades are all the same. Exemplarily, the first freshness factor may also be associated only with the component to be upgraded.

[0007] Exemplarily, the first signature information is also associated with an identifier of an upgrade file corresponding to the component to be upgraded, and the identifier of the upgrade file corresponding to the component to be upgraded is used to verify the integrity of the upgrade file corresponding to the component to be upgraded.

[0008] Exemplarily, the first freshness factor is a random number or the value of the first freshness factor has a unidirectional growth characteristic. Here, the value of the first freshness factor has a unidirectional growth characteristic, for example, the first freshness factor is a value generated by a unidirectional growth counter.

[0009] In the above method, the upgrade request carries the identifier of the component to be upgraded and the freshness factor corresponding to the component to be upgraded, so that the signature information corresponding to the component to be upgraded is bound to the identifier of the component to be upgraded and the freshness factor corresponding to the component to be upgraded, which can increase the difficulty of subsequent attackers to verify the signature information corresponding to the component to be upgraded, thereby effectively avoiding the attacker's car brushing attack and preventing the abuse of upgrade files. Here, the attacker refers to a user who obtains illegitimate benefits by abusing software obtained from formal channels (that is, the source of the upgrade file is formal).

[0010] Optionally, there are multiple components to be upgraded, and the multiple components to be upgraded include a first component and a second component, wherein the first freshness factor corresponding to the first component is a third freshness factor, and the first freshness factor corresponding to the second component is a fourth freshness factor, and when the second component and the third component belong to different domain controllers, the third freshness factor is different from the fourth freshness factor.

[0011] By implementing the above implementation, the components to be upgraded in different functional domains have different freshness factors, which increases the difficulty for attackers to carry out vehicle flashing attacks and improves the security of the components to be upgraded in different functional domains.

[0012] Exemplarily, the first freshness factors corresponding to the components to be upgraded that belong to the same functional domain may be the same or different.

[0013] Exemplarily, the first freshness factors corresponding to various components to be upgraded of the same vehicle during one upgrade may also be the same.

[0014] Here, when the component to be upgraded is, for example, a domain controller, its corresponding freshness factor can be generated by itself; when the component to be upgraded is, for example, an ECU, the freshness factor corresponding to the ECU can be generated by itself or by the domain controller to which the ECU belongs. In another implementation, the object for generating the freshness factor may not be limited.

[0015] Optionally, the component to be upgraded includes a first component, and the number of upgrade files corresponding to the first component is one or more. When the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files of the current upgrade and upgrade files of historical upgrades that have not been executed.

[0016] For example, suppose that the first component missed the first upgrade but did not miss the second upgrade, wherein the upgrade request received by the server during the second upgrade includes the identifier of the first component. In this case, the first component corresponds to two upgrade files, namely, upgrade file 1 corresponding to the first upgrade and upgrade file 2 corresponding to the second upgrade, wherein upgrade file 1 is different from upgrade file 2 in that different defects are repaired and / or different newly introduced functions are introduced.

[0017] That is to say, a component to be upgraded may have missed several previous upgrade tasks. Therefore, during a certain upgrade, there may be multiple upgrade files corresponding to the component to be upgraded. In this way, the component to be upgraded can be upgraded to the latest version through one upgrade, thereby improving the upgrade efficiency of the component to be upgraded.

[0018] Optionally, there are multiple components to be upgraded, and sending the first upgrade information includes: based on sequence information, sending signature information corresponding to each of the multiple components to be upgraded in the first upgrade information to the corresponding components to be upgraded, wherein the sequence information is used to indicate the upgrade execution order of each of the multiple components to be upgraded.

[0019] By implementing the above implementation method, the sending order of the signature information corresponding to each component to be upgraded is determined by the sequence information. In this way, the component to be upgraded that receives the signature information first can perform the decryption first. When the decryption fails, the sending of subsequent unsent signature information can be stopped in time. This can reduce the consumption of network resources and coordinate the upgrade of multiple vehicle-mounted components.

[0020] Exemplarily, the components to be upgraded include component 1 and component 2. Assuming that the sequence information indicates that the upgrade execution sequence of component 1 is earlier than the upgrade execution sequence of component 2, based on the sequence information, the signature information corresponding to component 1 is first sent to component 1, and when it is determined that the upgrade of component 1 is successful, the signature information corresponding to component 2 is then sent to component 2. In another implementation, the sending sequence of the signature information corresponding to each component to be upgraded may not be limited, for example, the signature information corresponding to component 1 and the signature information corresponding to component 2 are sent at the same time, and the upgrade execution sequence of component 1 and component 2 is coordinated through control information.

[0021] Exemplarily, only some of the multiple components to be upgraded may be associated with each other. In this case, the sequence information may also be used only to indicate the relative upgrade execution order between the associated components to be upgraded among the multiple components to be upgraded. For example, the number of components to be upgraded is q, q is an integer greater than 1, and the sequence information only indicates the relative upgrade execution order of p associated components to be upgraded among the q components to be upgraded, which means that there is no restriction on the upgrade execution order of the remaining (qp) components to be upgraded among the q components to be upgraded.

[0022] Optionally, the sequence information comes from the server, or the sequence information is generated locally. Exemplarily, the sequence information comes from the server, which means that the sequence information is included in the upgrade information, or the sequence information is sent separately by the server.

[0023] Optionally, the method further includes: when the third component in the vehicle is replaced by a fourth component, sending replacement information to the server, the replacement information including the upgrade file version information currently used by the fourth component, and the replacement information is used to indicate that the third component is replaced by the fourth component. Exemplarily, the newly replaced vehicle-mounted component (such as the fourth component) may also be included in the components to be upgraded carried in the first upgrade request.

[0024] By implementing the above implementation, the server can timely grasp the update status of the newly replaced vehicle-mounted components through the replacement information. In the case where the third component is replaced by the fourth component, if the next upgrade is not yet started, the sending of the replacement information also facilitates the server to count the components to be upgraded for the next upgrade.

[0025] Optionally, the first functional module is associated with the fifth component in the components to be upgraded, and the first functional module is deployed on the cloud platform of the server. The method also includes: sending indication information to the server, the indication information including the identifier of the first functional module, and the indication information is used to indicate that the first functional module needs to be upgraded.

[0026] Exemplarily, the first functional module is associated with the fifth component, which can be understood as the first functional module and the fifth component working in coordination, or the functional operation of the first functional module depends on at least part of the business data of the fifth component.

[0027] Exemplarily, the first functional module may be implemented by hardware, software, or a combination of hardware and software.

[0028] That is to say, when a certain vehicle-mounted component in the vehicle needs to be upgraded, the above implementation can realize the synchronous upgrade of the functional modules associated with the vehicle-mounted component to be upgraded on the cloud platform.

[0029] Exemplarily, the components to be upgraded include a first component and a second component, the first component is associated with the second component, and the method further includes: receiving first feedback information and second feedback information, wherein the first feedback information is used to indicate that the upgrade of the first component is successful, and the second feedback information is used to indicate that the upgrade of the second component fails; based on the first feedback information and the second feedback information, sending rollback information, the rollback information is used to instruct the first component to execute the upgrade file used before the current upgrade.

[0030] Here, the first component is associated with the second component, for example, it can be understood that the first component and the second component work together, or the functional operation of the first component depends on at least part of the business data of the second component, or the functional operation of the second component depends on at least part of the business data of the first component.

[0031] By implementing the above implementation method, for the associated components to be upgraded, if one of the associated components to be upgraded fails to be upgraded, the other components to be upgraded that are associated with the component to be upgraded that failed to be upgraded and have completed the upgrade can be controlled to each execute the upgrade file used before the upgrade (i.e., the old upgrade file), so that the versions of the upgrade files used by the associated components to be upgraded are consistent, which is conducive to the normal operation of the business.

[0032] Optionally, the upgrade information further includes at least one of the following information: an upgrade file corresponding to the component to be upgraded and an identifier of the upgrade file corresponding to the component to be upgraded.

[0033] Here, the identifier of the upgrade file corresponding to the component to be upgraded may be, for example, a hash value obtained based on the upgrade file corresponding to the component to be upgraded. The integrity of the upgrade file corresponding to the component to be upgraded may be verified through the identifier of the upgrade file corresponding to the component to be upgraded.

[0034] Optionally, the method is applied to an OTA manager or a diagnostic instrument. Exemplarily, the method can also be applied to a control device integrated with an OTA manager.

[0035] By implementing the above implementation method, the upgrade method provided in this application is not only applicable to remote upgrades involving OTA managers, but also to near-field upgrades involving vehicle diagnostic instruments, and has good applicability.

[0036] Exemplarily, the first upgrade request also includes at least one of the vehicle identification and the configuration information of the component to be upgraded. The configuration information of the component to be upgraded includes, for example, the upgrade file version information currently used by the component to be upgraded. Optionally, the configuration information of the component to be upgraded also includes information such as the model of the component to be upgraded and the manufacturer of the component to be upgraded.

[0037] Here, when the server does not store the configuration information of the vehicle's onboard components, the upgrade request carries the configuration information of the component to be upgraded, so that the server can accurately determine the upgrade file corresponding to the component to be upgraded based on the configuration information of the component to be upgraded.

[0038] Optionally, the method also includes: sending a second upgrade request to the server, the second upgrade request including an identifier of the component to be upgraded and a second freshness factor corresponding to the component to be upgraded, the second freshness factor being used at least to identify another upgrade of the component to be upgraded; receiving second upgrade information from the server, the second upgrade information including second signature information corresponding to the component to be upgraded, the second signature information being associated with the identifier of the component to be upgraded and the second freshness factor corresponding to the component to be upgraded, the first freshness factor being different from the second freshness factor; and sending the second upgrade information.

[0039] By implementing the above implementation method, for the same component to be upgraded, the corresponding freshness factors are different in different upgrade scenarios, so that the signature information can only be used for a certain upgrade of a specific component, which increases the difficulty for attackers to verify the signature and can effectively reduce the success rate of attackers' car-brushing attacks.

[0040] In a second aspect, the present application provides an upgrade method, the method comprising: receiving a first upgrade request, the first upgrade request comprising an identification of a component to be upgraded in a vehicle and a first freshness factor corresponding to the component to be upgraded, the first freshness factor being used to identify at least one upgrade of the component to be upgraded; in response to the first upgrade request, sending first upgrade information, the first upgrade information comprising first signature information corresponding to the component to be upgraded, the first signature information being generated based on the identification of the component to be upgraded and the first freshness factor corresponding to the component to be upgraded.

[0041] Exemplarily, the method can be applied to a network-side device. The network-side device can be, for example, a server deployed on the network side (e.g., an OTA server, a car factory cloud server, etc.), or a component or chip in the server, or a system-level device composed of multiple servers. The network-side device can be deployed in a cloud environment or an edge environment, which is not specifically limited here.

[0042] Exemplarily, the first signature information is also generated based on an identifier of an upgrade file corresponding to the component to be upgraded, and the identifier of the upgrade file corresponding to the component to be upgraded is used to verify the integrity of the upgrade file corresponding to the component to be upgraded.

[0043] Here, the first freshness factor can refer to the description of the first freshness factor in the first aspect above, which will not be repeated here.

[0044] In the above method, signature information is generated for the component to be upgraded based on the identifier of the component to be upgraded in the upgrade request and the freshness factor corresponding to the component to be upgraded, that is, the signature information is bound to the component to be upgraded and the freshness factor corresponding to the component to be upgraded, so that the signature information is used for at least one upgrade of the specific component, which can effectively prevent attackers from performing car-brushing attacks.

[0045] Optionally, in the vehicle, when different components to be upgraded belong to different domain controllers, the first freshness factors corresponding to the different components to be upgraded are different.

[0046] Optionally, the first upgrade information also includes an upgrade file corresponding to the component to be upgraded.

[0047] Exemplarily, the first upgrade information may not carry the upgrade file, but carry the download address indication information of the upgrade file corresponding to the component to be upgraded, and the download address indication information is used to indicate the download address of the upgrade file corresponding to the component to be upgraded. The download address indication information may be, for example, the unified resource locator (URL) of the upgrade file corresponding to the component to be upgraded.

[0048] Optionally, the component to be upgraded includes a first component, and the number of upgrade files corresponding to the first component is one or more, wherein when the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files for the current upgrade and upgrade files for historical upgrades that have not been executed. It can be seen that this is also applicable to the scenario where a component to be upgraded has missed several previous upgrade tasks. In this case, the component to be upgraded has multiple upgrade files. In this way, the component to be upgraded can be upgraded to the latest version through one upgrade, thereby improving the upgrade efficiency of the component to be upgraded.

[0049] Optionally, when there are multiple components to be upgraded, the first upgrade information further includes sequence information, wherein the sequence information is used to indicate the upgrade execution order of the multiple components to be upgraded. The sequence information is helpful to assist the vehicle side in coordinating the upgrade of multiple components to be upgraded, so as to improve the upgrade efficiency of the whole vehicle.

[0050] Exemplarily, the first signature information corresponding to the component to be upgraded is also generated based on at least one of the identification of the vehicle and the identification of the upgrade file corresponding to the component to be upgraded. Here, if the signature information is also generated based on the identification of the vehicle, the signature information is used for at least one upgrade of a specific component of a certain vehicle. If the signature information is also generated based on the identification of the upgrade file corresponding to the component to be upgraded, when the signature information is subsequently verified, it can also be determined whether the upgrade file corresponding to the component to be upgraded has been maliciously tampered with during the download process, so as to ensure the integrity of the upgrade file.

[0051] Optionally, the method further includes: receiving replacement information, the replacement information being used to indicate that a second component in the vehicle is replaced with a third component, the replacement information including upgrade file version information currently used by the third component; and updating locally recorded component configuration information of the vehicle based on the replacement information.

[0052] By implementing the above implementation, the update status of the vehicle-mounted components in the vehicle can be known based on the replacement information, and the configuration information of the vehicle-mounted components of the vehicle can be aligned with the component configuration information of the vehicle stored locally on the server.

[0053] Optionally, the method is applied to a server, the cloud platform of the server includes a first functional module, the first functional module is associated with one of the components to be upgraded, and the method further includes: receiving indication information, the indication information including an identifier of the first functional module, the indication information being used to indicate that the first functional module needs to be upgraded; and upgrading the first functional module according to the indication information.

[0054] By implementing the above implementation, if a functional module on the cloud platform is associated with a component to be upgraded in the vehicle, the functional module on the cloud platform associated with the vehicle component to be upgraded can be synchronously upgraded through the received indication information.

[0055] Optionally, the method is applied to a first server, and the first signature information is obtained by the first server based on signature information generated by each server in a plurality of servers, and the signature information generated by each server is generated based on an identifier of the component to be upgraded and a sub-freshness factor corresponding to each server, wherein the sub-freshness factor corresponding to each server is obtained by splitting the first freshness factor, and the plurality of servers include the first server.

[0056] Exemplarily, each of the multiple servers can generate corresponding signature information using part of the data in the freshness factor corresponding to the component to be upgraded, and the signature information generated by each server can be used as part of the signature information corresponding to the component to be upgraded. Exemplarily, the first server can obtain the first signature information based on the signature information generated by each of the multiple servers, or can obtain the first signature information based on the signature information generated by some of the multiple servers.

[0057] By implementing the above implementation method, multiple servers jointly participate in the generation of signature information corresponding to the components to be upgraded. This distributed signature method can improve credibility and transparency, and can also enhance security.

[0058] Exemplarily, the first upgrade request also includes at least one of the identification of the vehicle and the configuration information of the component to be upgraded. The configuration information of the component to be upgraded includes, for example, the version information of the upgrade file currently used by the component to be upgraded. Optionally, the configuration information of the component to be upgraded also includes information such as the model of the component to be upgraded and the manufacturer of the component to be upgraded. In this way, when the network-side device does not locally store the configuration information of the vehicle-mounted components of the vehicle, the upgrade request carries the configuration information of the component to be upgraded, and the network-side device can quickly determine the upgrade file corresponding to the component to be upgraded based on the configuration information of the component to be upgraded.

[0059] Optionally, the method also includes: receiving a second upgrade request, the second upgrade request including an identifier of the component to be upgraded and a second freshness factor corresponding to the component to be upgraded, the second freshness factor being used at least to identify another upgrade of the component to be upgraded; in response to the second upgrade request, sending second upgrade information, the second upgrade information including second signature information corresponding to the component to be upgraded, the second signature information being generated based on the identifier of the component to be upgraded and the second freshness factor corresponding to the component to be upgraded.

[0060] By implementing the above implementation method, for the same component to be upgraded, the corresponding freshness factors in different upgrade scenarios are different, and the signature information corresponding to the component to be upgraded generated twice by the network-side device is different. Even if the attacker can obtain the signature information, the verification difficulty is greatly increased, which can effectively reduce the success rate of the attacker's car-brushing attack.

[0061] In a third aspect, the present application provides an upgrade method, applied to a target component, the method comprising: receiving first signature information corresponding to a first component from a first device, the first signature information being associated with an identifier of the first component and a first freshness factor corresponding to the first component, wherein the first freshness factor is used to identify at least one upgrade of the first component, the first component being the target component or the first component being connected to the target component; and determining that the first component performs an upgrade when the first signature information is successfully verified based on the first freshness factor.

[0062] Here, the first component is connected to the target component, and "connection" can be understood as a physical connection or a logical connection, that is, there is a data transmission relationship between the first component and the target component. For example, from a structural point of view, the first component and the target component are connected to each other, which means that the first component is hung below the target component; from a logical relationship point of view, the first component and the target component are connected to each other, which means that the first component is controlled by the target component.

[0063] Here, the first component is the component to be upgraded.

[0064] Exemplarily, the target component is a domain controller. The first component is the target component, that is, the component to be upgraded is a domain controller; the first component is connected to the target component, that is, the component to be upgraded is an ECU.

[0065] Here, the first fresh factor can refer to the relevant description of the first fresh factor in the first aspect above, which will not be repeated here.

[0066] In the above method, the target component verifies the signature information corresponding to the first component in the functional domain. Only when the verification is successful can the first component be upgraded. The signature information corresponding to the first component is at least associated with the identifier of the first component and the freshness factor corresponding to the component to be upgraded, so that the signature information can only be used for at least one upgrade of a specific component. This effectively avoids the car-swiping attack performed by attackers using old versions of software or privileged versions of software, and also prevents the abuse of upgrade files.

[0067] Exemplarily, the method further includes: receiving an identifier of an upgrade file corresponding to the first component from the first device, and determining that the first component executes an upgrade when the signature information is successfully verified based on the first freshness factor, including: determining that the first component executes an upgrade when the signature information is successfully verified based on the first freshness factor and the identifier of the upgrade file corresponding to the first component.

[0068] By implementing the above implementation, the identifier of the upgrade file corresponding to the first component is introduced to verify the signature information corresponding to the first component, and it is also possible to determine whether the upgrade file corresponding to the first component has been tampered with during the transmission process.

[0069] Optionally, the method further includes: receiving an upgrade file corresponding to the first component from a second device; when the first signature information is successfully verified based on the first freshness factor and the first component is the target component, performing an upgrade according to the upgrade file corresponding to the first component; or, when the first signature information is successfully verified based on the first freshness factor and the first component is connected to the target component, sending trigger information to the first component, the trigger information including the upgrade file corresponding to the first component, the trigger information being used to instruct the first component to perform an upgrade according to the upgrade file corresponding to the first component.

[0070] Here, the second device may be the same as or different from the first device.

[0071] By implementing the above implementation method, the first component is triggered to perform an upgrade based on the upgrade file corresponding to the first component only when the target component successfully verifies the signature information, thereby preventing abuse of the upgrade file and effectively avoiding the attacker's vehicle flashing attack.

[0072] Optionally, the number of upgrade files corresponding to the first component is one or more, wherein, when the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files of current upgrade and upgrade files of historical upgrade that have not been executed.

[0073] Exemplarily, the method further includes: sending feedback information to the first device, wherein the feedback information is used to indicate the upgrade result of the first component. In this way, the first device can know the upgrade result of the first component in a timely manner based on the feedback information, which is conducive to ensuring the normal operation of the business involved in the first component.

[0074] Optionally, the freshness factor corresponding to the first component is generated by the target component. In this way, the freshness factor corresponding to the first component is uniformly managed by the target component, which also facilitates the target component to perform verification of the signature information corresponding to the first component.

[0075] Optionally, the method also includes: receiving second signature information corresponding to the first component from the first device, the second signature information being generated based on an identifier of the first component and a second freshness factor corresponding to the first component, wherein the second freshness factor is at least used to identify another upgrade of the first component, and the second freshness factor is different from the first freshness factor; and when the second signature information is successfully verified based on the second freshness factor, determining that the first component performs an upgrade.

[0076] By implementing the above implementation method, for the same component to be upgraded, the corresponding freshness factors in different upgrade scenarios are different, and the signature information corresponding to the component to be upgraded generated twice by the network side device is different, which can improve the security of the signature information and avoid the attacker's car brushing attack.

[0077] In a fourth aspect, the present application provides a device for upgrading, the device comprising: a sending unit, used to send a first upgrade request to a server, the first upgrade request comprising an identifier of a component to be upgraded in a vehicle and a first freshness factor corresponding to the component to be upgraded, the first freshness factor being used to identify at least one upgrade of the component to be upgraded; a receiving unit, used to receive first upgrade information from the server, the first upgrade information comprising first signature information corresponding to the component to be upgraded, the first signature information being associated with the identifier of the component to be upgraded and the first freshness factor corresponding to the component to be upgraded; the sending unit is also used to send the first upgrade information.

[0078] Optionally, the first signature information is further associated with an identifier of an upgrade file corresponding to the component to be upgraded, and the identifier of the upgrade file corresponding to the component to be upgraded is used to verify the integrity of the upgrade file corresponding to the component to be upgraded.

[0079] Optionally, the first freshness factor is a random number or the value of the first freshness factor has a unidirectional growth characteristic.

[0080] Optionally, there are multiple components to be upgraded, and the multiple components to be upgraded include a first component and a second component, wherein the first freshness factor corresponding to the first component is a third freshness factor, and the first freshness factor corresponding to the second component is a fourth freshness factor, and when the second component and the third component belong to different domain controllers, the third freshness factor is different from the fourth freshness factor.

[0081] Optionally, the component to be upgraded includes a first component, and the number of upgrade files corresponding to the first component is one or more. When the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files of the current upgrade and upgrade files of historical upgrades that have not been executed.

[0082] Optionally, there are multiple components to be upgraded, and the sending unit is specifically used to: based on sequence information, send the signature information corresponding to each of the multiple components to be upgraded in the first upgrade information to the corresponding components to be upgraded, wherein the sequence information is used to indicate the upgrade execution order of each of the multiple components to be upgraded.

[0083] Optionally, the sequence information comes from the server, or the sequence information is generated locally.

[0084] Optionally, the sending unit is also used to: when a third component in the vehicle is replaced by a fourth component, send replacement information to the server, the replacement information including upgrade file version information currently used by the fourth component, and the replacement information is used to indicate that the third component is replaced by the fourth component.

[0085] Optionally, the first functional module is associated with the fifth component in the components to be upgraded, and the first functional module is deployed on the cloud platform of the server. The sending unit is also used to: send indication information to the server, the indication information includes an identifier of the first functional module, and the indication information is used to indicate that the first functional module needs to be upgraded.

[0086] Exemplarily, the component to be upgraded includes a first component and a second component, the first component is associated with the second component, and the receiving unit is further used to: receive first feedback information and second feedback information, wherein the first feedback information is used to indicate that the upgrade of the first component is successful, and the second feedback information is used to indicate that the upgrade of the second component fails; the sending unit is also used to: send rollback information based on the first feedback information and the second feedback information, and the rollback information is used to instruct the first component to execute the upgrade file used before the current upgrade.

[0087] Optionally, the upgrade information further includes at least one of the following information: an upgrade file corresponding to the component to be upgraded and an identifier of the upgrade file corresponding to the component to be upgraded.

[0088] Optionally, the device is an OTA manager or is included in an OTA manager.

[0089] Optionally, the device is a diagnostic instrument or is included in a diagnostic instrument.

[0090] Exemplarily, the first upgrade request also includes at least one of the vehicle identification and the configuration information of the component to be upgraded. The configuration information of the component to be upgraded includes, for example, the upgrade file version information currently used by the component to be upgraded. Optionally, the configuration information of the component to be upgraded also includes information such as the model of the component to be upgraded and the manufacturer of the component to be upgraded.

[0091] Optionally, the sending unit is further used to: send a second upgrade request to the server, the second upgrade request including the identifier of the component to be upgraded and a second freshness factor corresponding to the component to be upgraded, the second freshness factor being used at least to identify another upgrade of the component to be upgraded; the receiving unit is further used to: receive second upgrade information from the server, the second upgrade information including second signature information corresponding to the component to be upgraded, the second signature information being associated with the identifier of the component to be upgraded and the second freshness factor corresponding to the component to be upgraded, the first freshness factor being different from the second freshness factor; the sending unit is further used to: send the second upgrade information.

[0092] In a fifth aspect, the present application provides a device for upgrading, the device comprising: a receiving unit, for receiving a first upgrade request, the first upgrade request comprising an identification of a component to be upgraded in a vehicle and a first freshness factor corresponding to the component to be upgraded, the first freshness factor being used to identify at least one upgrade of the component to be upgraded; a sending unit, for sending first upgrade information in response to the first upgrade request, the first upgrade information comprising first signature information corresponding to the component to be upgraded, the first signature information being generated based on the identification of the component to be upgraded and the first freshness factor corresponding to the component to be upgraded.

[0093] Exemplarily, the first signature information is also generated based on an identifier of an upgrade file corresponding to the component to be upgraded, and the identifier of the upgrade file corresponding to the component to be upgraded is used to verify the integrity of the upgrade file corresponding to the component to be upgraded.

[0094] Optionally, in the vehicle, when different components to be upgraded belong to different domain controllers, the first freshness factors corresponding to the different components to be upgraded are different.

[0095] Optionally, the first upgrade information also includes an upgrade file corresponding to the component to be upgraded.

[0096] Optionally, the component to be upgraded includes a first component, and the number of upgrade files corresponding to the first component is one or more. When the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files of the current upgrade and upgrade files of historical upgrades that have not been executed.

[0097] Optionally, when there are multiple components to be upgraded, the first upgrade information further includes sequence information, wherein the sequence information is used to indicate the upgrade execution sequence of each of the multiple components to be upgraded.

[0098] Exemplarily, the first signature information corresponding to the component to be upgraded is also generated based on at least one of an identifier of the vehicle and an identifier of an upgrade file corresponding to the component to be upgraded.

[0099] Optionally, the receiving unit is also used to: receive replacement information, the replacement information is used to indicate that the second component in the vehicle is replaced by a third component, the replacement information includes upgrade file version information currently used by the third component; the device also includes a processing unit, the processing unit is used to update the locally recorded component configuration information of the vehicle according to the replacement information.

[0100] Optionally, the device is a server or is included in a server, the cloud platform of the server includes a first functional module, the first functional module is associated with one of the components to be upgraded, and the receiving unit is also used to: receive indication information, the indication information includes an identifier of the first functional module, and the indication information is used to indicate that the first functional module needs to be upgraded; the processing unit of the device is also used to: upgrade the first functional module according to the indication information.

[0101] Optionally, the device is a first server or is included in the first server, and the first signature information is obtained by the device based on signature information generated by each server in a plurality of servers, and the signature information generated by each server is generated based on an identifier of the component to be upgraded and a sub-freshness factor corresponding to each server, wherein the sub-freshness factor corresponding to each server is obtained by splitting the first freshness factor, and the plurality of servers include the first server.

[0102] Exemplarily, the first upgrade request also includes at least one of the vehicle identification and the configuration information of the component to be upgraded. The configuration information of the component to be upgraded includes, for example, the upgrade file version information currently used by the component to be upgraded. Optionally, the configuration information of the component to be upgraded also includes information such as the model of the component to be upgraded and the manufacturer of the component to be upgraded.

[0103] Optionally, the receiving unit is further used to: receive a second upgrade request, the second upgrade request including an identifier of the component to be upgraded and a second freshness factor corresponding to the component to be upgraded, the second freshness factor being at least used to identify another upgrade of the component to be upgraded; the sending unit is further used to: send second upgrade information in response to the second upgrade request, the second upgrade information including second signature information corresponding to the component to be upgraded, the second signature information being generated based on the identifier of the component to be upgraded and the second freshness factor corresponding to the component to be upgraded.

[0104] In a sixth aspect, the present application provides an apparatus for upgrading, which is a target component or is included in a target component, and the apparatus comprises: a receiving unit, used to receive first signature information corresponding to a first component from a first device, the first signature information being associated with an identifier of the first component and a first freshness factor corresponding to the first component, wherein the first freshness factor is used to identify at least one upgrade of the first component, the first component being the target component or the first component being connected to the target component; a processing unit, used to determine that the first component performs an upgrade when the first signature information is successfully verified based on the first freshness factor.

[0105] Exemplarily, the receiving unit is further used to: receive an identifier of an upgrade file corresponding to the first component from the first device, and the processing unit is specifically used to: determine that the first component is to be upgraded when the signature information is successfully verified based on the first freshness factor and the identifier of the upgrade file corresponding to the first component.

[0106] Optionally, the receiving unit is also used to: receive an upgrade file corresponding to the first component from a second device; the processing unit is specifically used to: when the first signature information is successfully verified based on the first freshness factor and the first component is the target component, perform an upgrade according to the upgrade file corresponding to the first component; or, the device also includes a sending unit, and the sending unit is used to: when the first signature information is successfully verified based on the first freshness factor and the first component is connected to the target component, send trigger information to the first component, the trigger information including the upgrade file corresponding to the first component, and the trigger information is used to instruct the first component to perform an upgrade according to the upgrade file corresponding to the first component.

[0107] Optionally, the number of upgrade files corresponding to the first component is one or more, wherein, when the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files of current upgrade and upgrade files of historical upgrade that have not been executed.

[0108] Exemplarily, the sending unit is further used to: send feedback information to the first device, where the feedback information is used to indicate an upgrade result of the first component.

[0109] Optionally, the freshness factor corresponding to the first component is generated by the target component.

[0110] Optionally, the receiving unit is further used to: receive second signature information corresponding to the first component from the first device, the second signature information being generated based on an identifier of the first component and a second freshness factor corresponding to the first component, wherein the second freshness factor is at least used to identify another upgrade of the first component, and the second freshness factor is different from the first freshness factor; the processing unit is further used to: determine that the first component performs an upgrade when the second signature information is successfully verified based on the second freshness factor.

[0111] In a seventh aspect, the present application provides a chip, the device comprising the chip including at least one processor and a communication interface, the communication interface being used to provide information input and / or output for the at least one processor. The chip is used to implement the method in the first aspect or any possible embodiment of the first aspect, or the chip is used to implement the method in the second aspect or any possible embodiment of the second aspect, or the chip is used to implement the method in the third aspect or any possible embodiment of the third aspect.

[0112] In an eighth aspect, the present application provides a server, wherein the server is used to implement the method in the above-mentioned second aspect or any possible implementation manner of the second aspect.

[0113] In the ninth aspect, the present application provides an upgrade system, which includes a first device, a second device and a third device, wherein the third device is used to implement the method in the second aspect or any possible embodiment of the second aspect, the first device is used to implement the method in the first aspect or any possible embodiment of the first aspect, and the second device is used to implement the method in the third aspect or any possible embodiment of the third aspect.

[0114] In the tenth aspect, the present application provides an upgrade system, which includes a first device and a second device, wherein the first device is used to implement the method in the above-mentioned first aspect or any possible embodiment of the first aspect, and the second device is used to implement the above-mentioned third aspect or any possible embodiment of the third aspect.

[0115] In the eleventh aspect, the present application provides a vehicle, which includes one or more of the device of the fourth aspect or any possible implementation of the fourth aspect and the device of the sixth aspect or any possible implementation of the sixth aspect, or includes the system described in the tenth aspect.

[0116] In the twelfth aspect, the present application provides a computer-readable storage medium, comprising computer instructions, which, when executed by a processor, implement the method in the above-mentioned first aspect or any possible implementation of the first aspect, or implement the method in the second aspect or any possible implementation of the second aspect, or implement the method in the third aspect or any possible implementation of the third aspect.

[0117] In the thirteenth aspect, the present application provides a computer program product, which, when executed by a processor, implements the method in the first aspect or any possible embodiment of the first aspect, or implements the method in the second aspect or any possible embodiment of the second aspect, or implements the method in the third aspect or any possible embodiment of the third aspect.

[0118] Exemplarily, the computer program product may be a software installation package. BRIEF DESCRIPTION OF THE DRAWINGS

[0119] Figure 1A is a schematic diagram of an upgrade system provided in an embodiment of the present application;

[0120] Figure 1B is a schematic diagram of another upgrading system provided in an embodiment of the present application;

[0121] Figure 2 is a flowchart of an upgrade method provided in an embodiment of the present application;

[0122] Figure 3 It is a schematic diagram of a scenario of multiple components to be upgraded provided by an embodiment of the present application;

[0123] Figure 4 is a flowchart of an upgrade method provided in an embodiment of the present application;

[0124] Figure 5 It is a structural schematic diagram of an upgrading device provided in an embodiment of the present application;

[0125] Figure 6 It is a structural schematic diagram of another upgrading device provided in an embodiment of the present application;

[0126] Figure 7 It is a structural schematic diagram of another upgrading device provided in an embodiment of the present application;

[0127] Figure 8 It is a structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0128] It should be noted that the prefixes such as "first" and "second" used in this application are only used to distinguish different description objects, and have no limiting effect on the position, order, priority, quantity or content of the described objects. For example, if the described object is a "field", the ordinal number before the "field" in the "first field" and the "second field" does not limit the position or order between the "fields". "First" and "second" do not limit whether the "fields" they modify are in the same message, nor do they limit the order of the "first field" and the "second field". For another example, if the described object is a "level", the ordinal number before the "level" in the "first level" and the "second level" does not limit the priority between the "levels". For another example, the number of described objects is not limited by the prefix and can be one or more. Taking "first device" as an example, the number of "devices" can be one or more. In addition, the objects modified by different prefixes can be the same or different. For example, if the object being described is a "device", then the "first device" and the "second device" can be the same device, the same type of device, or different types of devices; for another example, if the object being described is "information", then the "first information" and the "second information" can be information of the same content or information of different contents. In short, the use of prefixes used to distinguish the described objects in the embodiments of the present application does not constitute a limitation on the described objects. For the statement of the described objects, refer to the description in the context of the claims or embodiments, and no unnecessary limitation should be constituted due to the use of such prefixes.

[0129] It should be noted that the description methods such as "at least one of a1, a2, ... and an" used in the embodiments of the present application include the situation where any one of a1, a2, ... and an exists alone, and also include any combination of any multiple of a1, a2, ... and an, and each situation can exist alone. For example, the description method of "at least one of a, b and c" includes the situation where a is alone, b is alone, c is alone, a combination of a and b, a combination of a and c, b and c, or a combination of abc.

[0130] In the embodiments of the present application, descriptions such as “when…, send…” can be understood as a prerequisite for the occurrence or generation of the action of “sending”, rather than emphasizing that the action of “sending” must be performed at the same time as this scenario occurs. It is also possible that the action of “sending” is performed after the scenario occurs.

[0131] The technical solution in this application will be described below in conjunction with the accompanying drawings.

[0132] See also Figure 1A , Figure 1A Schematic diagram of an upgrade system provided in an embodiment of the present application. The upgrade system is used to upgrade vehicle-mounted components. Figure 1A As shown, the upgrade system includes network-side equipment and vehicles, wherein an OTA manager (OTA Manager), at least one domain controller, and an electronic control unit (ECU) connected to the domain controller are deployed on the vehicle, and each domain controller has at least one ECU hung up and down. The network-side equipment communicates with the OTA manager wirelessly, the OTA manager communicates with at least one domain controller in a wired or wireless manner, and the domain controller communicates with the ECU in a wireless or wired manner.

[0133] In the embodiment of the present application, the ECU is connected to the domain controller, and the "connection" can be understood as a physical connection or a logical connection, that is, there is a data transmission relationship between the ECU and the domain controller. For example, from a structural point of view, the connection between the ECU and the domain controller can be that the ECU is hung under the domain controller; from a logical point of view, the connection between the ECU and the domain controller can be that the ECU is controlled by the domain controller.

[0134] The network-side device is used to obtain upgrade files for each component from the vehicle-mounted component developer, and to send information such as upgrade files of the components to be upgraded to the vehicle. For example, the network-side device can be a server deployed on the network side (such as an OTA server, a car factory cloud server, etc.), or a component or chip in the server, or a system-level device composed of multiple servers. The network-side device can be deployed in a cloud environment or an edge environment, which is not specifically limited here.

[0135] As the vehicle-side interface for vehicle upgrades, the OTA manager can interact with network-side devices, such as uploading vehicle asset information (such as software and hardware version information) and upgrade requests to network-side devices, and receiving responses from network-side devices to upgrade requests. After the OTA manager obtains the upgrade information carrying the upgrade file from the network-side device, it can connect to the domain controller in the vehicle and coordinate the domain controller to download and install the upgrade file.

[0136] For example, a domain controller (DC) serves a functional domain in a vehicle. In this case, the DC can be a hardware-software integrated platform for supporting intelligent driving, i.e., a vehicle computing platform, such as a mobile data center (MDC), or a hardware-software integrated platform for supporting body control and chassis control, such as a vehicle domain controller (VDC), or a hardware-software integrated platform for providing in-vehicle multimedia services, such as a cockpit domain controller (CDC).

[0137] In some possible embodiments, a domain controller may also serve multiple functional domains in a vehicle. In this case, the DC may be a domain controller that integrates VDC functions and MDC functions, or a domain controller that integrates VDC functions and CDC functions, or a domain controller that integrates MDC functions and CDC functions, or a domain controller that integrates VDC functions, MDC functions, and CDC functions.

[0138] In some possible embodiments, the domain controller further includes a domain update controller (domain update controller, DUC) and a domain installer (domain installer, DI). For example, the DUC can be responsible for downloading upgrade files of all vehicle components in the domain, verifying the legitimacy of the downloaded upgrade files, and overall control of the upgrade process of the vehicle components in the domain; the DI is responsible for the pre-condition check (voltage, vehicle speed, etc.) before upgrading and flashing, and the legitimacy verification of the upgrade files before flashing, as well as the upgrade flashing operation of the vehicle components in the domain.

[0139] Here, the number of domain controllers deployed in the vehicle is not limited. For example, three domain controllers can be deployed in the vehicle, namely the MDC, VDC and CDC mentioned above. For another example, only one domain controller can be deployed in the vehicle, but the domain controller integrates the functions of MDC, VDC and CDC.

[0140] In the embodiments of the present application, the OTA manager can be deployed separately or integrated into a domain controller in the vehicle. In one implementation, the OTA manager is deployed independently of the domain controller, and the domain controller can interact with the network side device through the OTA manager. In another implementation, the OTA manager is integrated into a domain controller in the vehicle (e.g. Figure 1AIf the OTA manager and the domain controller 1 are used as a whole, for example, they can be called a control device. In this case, the ECU originally hung on the domain controller 1 can directly interact with the network-side device through the control device, and other domain controllers (if any) can interact with the network-side device through the control device.

[0141] Exemplarily, the OTA manager sends an upgrade request to the network-side device, which includes the identifier of the component to be upgraded and the freshness factor corresponding to the component to be upgraded, wherein the freshness factor is used to identify at least one upgrade of the component to be upgraded; in response to the upgrade request, the network-side device sends upgrade information to the OTA manager, and the upgrade information includes signature information corresponding to the component to be upgraded, and the signature information is associated with the identifier of the component to be upgraded and the freshness factor corresponding to the component to be upgraded. The OTA manager sends the upgrade information to the component to be upgraded. Here, the component to be upgraded includes at least one of a domain controller and an ECU. The interaction between the network-side device, the OTA manager, the domain controller, and the ECU during the upgrade process can be specifically referred to the description of the following method embodiment, which will not be repeated here.

[0142] The upgrade method provided in the embodiment of the present application is not only applicable to Figure 1A As shown in the remote OTA upgrade, in some possible embodiments, the upgrade method provided in the embodiments of the present application is also applicable to near-field upgrade.

[0143] See also Figure 1B , Figure 1B Schematic diagram of another upgrade system provided in an embodiment of the present application. The upgrade system is used to upgrade vehicle-mounted components. Figure 1B As shown, the upgrade system includes a network-side device, a diagnostic instrument, and a vehicle, wherein at least one domain controller is deployed on the vehicle, and each domain controller has at least one ECU mounted on it. The network-side device communicates with the diagnostic instrument wirelessly, and the diagnostic instrument communicates with at least one domain controller in the vehicle by wire or wirelessly. For details about the network-side device and the domain controller, please refer to Figure 1A The description of the corresponding content will not be repeated here.

[0144] Here, the diagnostic instrument can also be called a vehicle diagnostic instrument. The diagnostic instrument not only has the vehicle diagnostic function, but also can replace the OTA manager in the vehicle to assist in the upgrade of the vehicle's onboard components. In this case, the interaction between the network-side device, the diagnostic instrument, the domain controller and the ECU during the upgrade process can be specifically referred to the description of the following method embodiment, which will not be repeated here.

[0145] Figure 1A or Figure 1BThe communication system shown can be applied to a variety of network types, for example, one or more of the following network types: SparkLink, long term evolution (LTE) network, fifth generation mobile communication technology (5G), wireless local area network (e.g., Wi-Fi), Bluetooth (BT), Zigbee, or vehicle-mounted short-range wireless communication network, etc.

[0146] The upgrade method provided in the embodiment of the present application is not only applicable to the upgrade of vehicles, but also to the upgrade of internal components of other means of transportation (such as trains, subways, ships, etc.) that have the same or similar architecture as the vehicle.

[0147] It should be noted that Figure 1A or Figure 1B This is only an exemplary architecture diagram, but not limited to Figure 1A or Figure 1B The system shown includes the number of network elements. Figure 1A or Figure 1B Not shown, but except Figure 1A or Figure 1B In addition to the functional entities shown, Figure 1A or Figure 1B Other functional entities may also be included. In addition, the method provided in the embodiment of the present application can be applied to Figure 1A or Figure 1B The upgrade system shown, of course, the method provided in the embodiment of the present application can also be applied to other upgrade systems, and the embodiment of the present application is not limited to this.

[0148] See also Figure 2 , Figure 2 It is a flowchart of an upgrade method provided in an embodiment of the present application.

[0149] Figure 2 The method shown is applied between a network-side device and a first device. Here, the network-side device takes a server as an example, that is, it is applied between the server and the first device, but the embodiment of the present application does not limit the network-side device to only a server. For example, the network-side device may also be a component in a server, or a system-level device composed of multiple servers. Here, the first device may be, for example, the above-mentioned OTA manager or diagnostic instrument, or a component in the OTA manager or a component in the diagnostic instrument. In some possible embodiments, the first device may also be a control device in a vehicle that is integrated with an OTA manager.

[0150] The method includes but is not limited to the following steps:

[0151] S201: The first device sends an upgrade request to a server, where the upgrade request includes an identifier of a component to be upgraded and a freshness factor corresponding to the component to be upgraded.

[0152] In the embodiment of the present application, before the first device sends an upgrade request, the first device needs to first determine the component to be upgraded and obtain the freshness factor corresponding to the component to be upgraded.

[0153] In the embodiment of the present application, the first device can determine the component to be upgraded by at least one of the following methods: Method 1, after the server obtains the latest upgrade file of the component to be upgraded from the component software supplier, it informs the first device of the identification of the component to be upgraded through indication information; Method 2, the first device actively determines the identification of the component to be upgraded through vehicle upgrade query; Method 3, the first device detects that a vehicle-mounted component in the vehicle has been replaced. In this case, when the first device knows the component to be upgraded, before the first device sends an upgrade request to the server, the first device can obtain the freshness factor corresponding to the component to be upgraded from the domain controller to which the component to be upgraded belongs. The first device can also determine the component to be upgraded by other methods, which are not specifically limited in the embodiment of the present application.

[0154] Exemplarily, the first device may obtain the freshness factor corresponding to the component to be upgraded by at least one of the following methods:

[0155] Method (1) The first device generates a freshness factor corresponding to the component to be upgraded; and

[0156] Method (2) The first device receives the freshness factor corresponding to the component to be upgraded sent by the domain controller.

[0157] For method (2), when the component to be upgraded is, for example, a domain controller, its corresponding freshness factor can be generated by itself; when the component to be upgraded is, for example, an ECU, the freshness factor corresponding to the ECU can be generated by itself or by the domain controller to which the ECU belongs. In some possible embodiments, a domain controller in the vehicle can also be pre-specified to generate a freshness factor for the component to be upgraded in the vehicle.

[0158] It can be understood that when the first device generates the fresh factor corresponding to the component to be upgraded, if the first device is deployed separately, the first device also needs to send the fresh factor corresponding to the component to be upgraded to the domain controller to which the component to be upgraded belongs. If the ECU can generate the fresh factor, then after the ECU generates the fresh factor, the ECU also needs to send the fresh factor corresponding to itself to the domain controller to which the ECU belongs. In this way, it is convenient for the domain controller to which the component to be upgraded belongs to perform the signature verification operation later. The first device can also obtain the fresh factor corresponding to the component to be upgraded by other means, and the embodiments of the present application do not specifically limit this.

[0159] Here, the freshness factor corresponding to the component to be upgraded is used to identify at least one upgrade of the component to be upgraded. Exemplarily, the freshness factor can be a random number or a value generated by a unidirectional growth counter.

[0160] In one implementation, when there are multiple upgrade requirements for the same component to be upgraded, the freshness factor corresponding to the component to be upgraded may be different in different upgrade scenarios.

[0161] Taking the two upgrades of component 1 as an example, component 1 is the component to be upgraded. During the first upgrade, the first device sends an upgrade request 1 to the server, wherein upgrade request 1 includes the identifier of component 1 and the freshness factor corresponding to component 1, recorded as freshness factor 1, and freshness factor 1 is used to identify an upgrade of component 1; during the second upgrade, the first device sends an upgrade request 2 to the server, wherein upgrade request 2 includes the identifier of component 1 and the freshness factor corresponding to component 1, recorded as freshness factor 2, and freshness factor 2 is used to identify another upgrade of component 1, and freshness factor 2 is different from freshness factor 1.

[0162] In another implementation, the freshness factor corresponding to the component to be upgraded can also be used for multiple upgrades of the component to be upgraded. Taking the three upgrades of component 1 as an example, the freshness factors corresponding to the first two upgrades of component 1 in the three upgrades are the same, or the freshness factors corresponding to the last two upgrades of component 1 in the three upgrades are the same, or the freshness factors corresponding to component 1 in the three upgrades are all the same.

[0163] In another implementation, the freshness factor may also be associated only with the component to be upgraded. For example, for any upgrade scenario, the freshness factor corresponding to component 1 is always freshness factor 1, and the freshness factor corresponding to component 2 is always freshness factor 2, wherein freshness factor 1 is different from freshness factor 2.

[0164] Here, the components to be upgraded include at least one of at least one domain controller and at least one ECU. That is, the number of components to be upgraded can be one or more.

[0165] In one implementation, the freshness factors corresponding to the components to be upgraded belonging to different domain controllers are different, and the freshness factors corresponding to the components to be upgraded belonging to the same domain controller may be the same or different, which is not specifically limited here.

[0166] For example, assuming that multiple components to be upgraded include domain controller 1, ECU1 and ECU2, where ECU1 is attached to domain controller 1 and ECU2 is attached to domain controller 2. It can be seen that the domain controller to which ECU1 belongs is different from the domain controller to which ECU2 belongs. For a certain upgrade, the freshness factor corresponding to ECU1 is different from the freshness factor corresponding to ECU2, and the freshness factor corresponding to domain controller 1 and the freshness factor corresponding to ECU1 may be the same or different, and no specific limitation is made here.

[0167] In another implementation, for multiple components to be upgraded in the same vehicle that need to be upgraded at a certain time, the freshness factors corresponding to the multiple components to be upgraded can also be the same. For example, assuming that the multiple components to be upgraded at a certain time include domain controller 1, ECU1 and ECU2, where ECU1 is connected to domain controller 1 and ECU2 is connected to domain controller 2, then for this upgrade, the freshness factors corresponding to domain controller 1, ECU1 and ECU2 can be the same.

[0168] In some possible embodiments, the upgrade request may further include at least one of the vehicle identification and the configuration information of the component to be upgraded. The configuration information of the component to be upgraded may include, for example, the upgrade file version information currently used by the component to be upgraded. Optionally, the configuration information of the component to be upgraded may also include information such as the model of the component to be upgraded and the manufacturer of the component to be upgraded.

[0169] Here, when the server does not store the configuration information of the vehicle's onboard components, the upgrade request carries the configuration information of the component to be upgraded, so that the server can accurately determine the upgrade file corresponding to the component to be upgraded based on the configuration information of the component to be upgraded.

[0170] S202: The server generates signature information corresponding to the component to be upgraded based on the upgrade request.

[0171] In one implementation, the server generates signature information corresponding to the component to be upgraded based on the identifier of the component to be upgraded and the freshness factor corresponding to the component to be upgraded. Accordingly, in the case where there are multiple components to be upgraded, taking any component to be upgraded (e.g., component C) among the multiple components to be upgraded as an example, the signature information corresponding to component C can be generated based on the identifier of component C and the freshness factor corresponding to component C. In this case, the signature information is associated with the identifier of the component to be upgraded and the freshness factor corresponding to the component to be upgraded, so that the signature information can be used for a single upgrade of a specific component.

[0172] In another implementation, the upgrade request carries the vehicle's ID, and the server can generate signature information corresponding to the component to be upgraded based on the vehicle's ID, the ID of the component to be upgraded, and the freshness factor corresponding to the component to be upgraded. Accordingly, when there are multiple components to be upgraded, for any component to be upgraded among the multiple components to be upgraded, such as component C, the signature information corresponding to component C can also be generated based on the vehicle's ID, the ID of component C, and the freshness factor corresponding to component C. In this case, the signature information is associated with the vehicle's ID, the ID of the component to be upgraded, and the freshness factor corresponding to the component to be upgraded, so that the signature information can be used for a single upgrade of a specific component in a certain vehicle.

[0173] In some possible embodiments, before generating signature information corresponding to the component to be upgraded, the server may determine the upgrade file corresponding to the component to be upgraded based on the current configuration information of the component to be upgraded stored locally or the configuration information of the component to be upgraded carried in the upgrade request received this time.

[0174] In another implementation, the server may generate signature information corresponding to the component to be upgraded based on the identifier of the component to be upgraded, the freshness factor corresponding to the component to be upgraded, and the identifier of the upgrade file corresponding to the component to be upgraded. Here, the identifier of the upgrade file may be, for example, a hash value obtained based on the upgrade file. In this way, when generating the signature information corresponding to the component to be upgraded, the identifier of the upgrade file corresponding to the component to be upgraded is also used as the factor, which can not only realize the use of the signature information for a one-time upgrade of a specific component, but also determine whether the upgrade file corresponding to the component to be upgraded has been maliciously tampered with during the download process when the signature information is subsequently verified.

[0175] In some possible embodiments, the server may also generate a freshness factor corresponding to the component to be upgraded in other ways. For example, the server also generates signature information corresponding to the component to be upgraded based on the vehicle identification, the identification of the component to be upgraded, the freshness factor corresponding to the component to be upgraded, and the identification of the upgrade file corresponding to the component to be upgraded.

[0176] Accordingly, when there are multiple components to be upgraded, for any component to be upgraded among the multiple components to be upgraded, such as component C, based on the identification of component C and the freshness factor corresponding to component C, signature information corresponding to component C can also be generated based on at least one of the identification of the vehicle and the identification of the upgrade file corresponding to component C.

[0177] Here, the number of upgrade files corresponding to the component to be upgraded is not specifically limited. Exemplarily, the component to be upgraded includes component C, and the number of upgrade files corresponding to component C is one or more. Among them, when the number of upgrade files corresponding to component C is multiple, the upgrade files corresponding to component C include upgrade files for the current upgrade and upgrade files for historical upgrades that have not been executed. The scenario where component C corresponds to multiple upgrade files can be: component C missed the previous upgrade tasks. During this upgrade, it can be determined that component C corresponds to multiple upgrade files, and the multiple upgrade files corresponding to component C will be installed during one upgrade process, so that component C can be upgraded directly to the latest version. This is conducive to improving the upgrade efficiency of the component to be upgraded.

[0178] For example, suppose component C missed the first upgrade but did not miss the second upgrade, that is, the upgrade request received by the server during the second upgrade contained the identifier of component C. In this case, component C corresponds to two upgrade files, namely upgrade file 1 corresponding to the first upgrade and upgrade file 2 corresponding to the second upgrade, wherein upgrade file 1 is different from upgrade file 2 in that the defects repaired are different and / or the newly introduced functions are different.

[0179] In an embodiment of the present application, the server stores a first key, which is one of a pair of keys, the pair of keys including a private key and a public key corresponding to the private key. The first key is a private key or the first key is a public key, which is not specifically limited here. Furthermore, the server also needs to use the first key in the process of generating signature information corresponding to the component to be upgraded.

[0180] For example, the server generates signature information corresponding to the component to be upgraded based on the identifier of the component to be upgraded and the freshness factor corresponding to the component to be upgraded, including: the server uses the first key to sign the identifier of the component to be upgraded and the freshness factor corresponding to the component to be upgraded to generate signature information corresponding to the component to be upgraded.

[0181] S203: The server sends upgrade information to the first device, where the upgrade information includes signature information corresponding to the component to be upgraded.

[0182] In one implementation, the upgrade information also includes the upgrade file corresponding to the component to be upgraded. In some possible embodiments, the upgrade file corresponding to the component to be upgraded may not be included in the upgrade information, that is, sent independently of the upgrade information.

[0183] In another implementation, the server may not send the upgrade file corresponding to the component to be upgraded to the first device, but may send download address indication information to the first device, where the download address indication information is used to indicate the download address of the upgrade file corresponding to the component to be upgraded. The download address indication information may be, for example, a unified resource locator (URL) of the upgrade file corresponding to the component to be upgraded. Exemplarily, the download address indication information may be included in the upgrade information, or may be sent independently of the upgrade information, which is not specifically limited herein.

[0184] In another implementation, the upgrade information further includes at least one of an identification of the vehicle and an identification of an upgrade file corresponding to the component to be upgraded.

[0185] In an embodiment of the present application, when there are multiple components to be upgraded, the server can also obtain sequence information based on the association relationship between the multiple components to be upgraded, and send the sequence information to the first device, wherein the sequence information is used to indicate the upgrade execution order of each of the multiple components to be upgraded.

[0186] Exemplarily, the sequence information may be included in the upgrade information, or may be sent independently of the upgrade information.

[0187] Exemplarily, component 1 is associated with component 2, which can be understood as component 1 and component 2 working together, or the functional operation of component 1 depends on at least part of the business data of component 2, or the functional operation of component 2 depends on at least part of the business data of component 1.

[0188] Exemplarily, the upgrade execution order can be indicated by numbers. For example, the smaller the number, the earlier the upgrade execution order of the corresponding component to be upgraded is. For example, assuming that the sequence information indicates that the upgrade indication order of component 1, component 2, and component 3 is 1, 1, and 2 respectively, it means that component 1 and component 2 are upgraded at the same time, and component 1 and component 2 are upgraded before component 3. Exemplarily, component 1 is upgraded before component 3, which can be understood as the upgrade result of component 1 will affect the execution of the upgrade of component 2.

[0189] In some possible embodiments, only some of the multiple components to be upgraded may be associated with each other. In this case, the sequence information may also be used only to indicate the relative upgrade execution order between the associated components to be upgraded among the multiple components to be upgraded. For example, the number of components to be upgraded is q, q is an integer greater than 1, and the sequence information only indicates the relative upgrade execution order of the associated p components to be upgraded among the q components to be upgraded, which means that there is no restriction on the upgrade execution order of the remaining (qp) components to be upgraded among the q components to be upgraded.

[0190] S204: The first device sends upgrade information.

[0191] In some possible embodiments, sending the upgrade information by the first device may also be an optional step.

[0192] against Figure 1A A possible variation of the shown architecture is that, for example, only one domain controller is deployed in the vehicle, and the domain controller integrates the functions of MDC, VDC and MDC, and the OTA manager is integrated with the domain controller. In this case, the first device can be regarded as a control device that integrates the OTA manager and the domain controller. If the component to be upgraded is the domain controller, the first device does not need to send upgrade information.

[0193] against Figure 1A A possible variation of the shown architecture is that the OTA manager is integrated into the domain controller 1. In this case, if the component to be upgraded is the domain controller 1, the first device does not need to send upgrade information.

[0194] In an embodiment of the present application, the first device is a diagnostic instrument, or the first device is an OTA manager and the OTA manager is deployed independently of the domain controller, and the first device sends the upgrade information, including at least one of the following:

[0195] If the component to be upgraded is a domain controller, the first device sends upgrade information to the component to be upgraded; and

[0196] If the component to be upgraded is an ECU, the first device sends the upgrade information to the component to be upgraded through the domain controller to which the component to be upgraded belongs, that is, the first device can directly send the upgrade information to the domain controller to which the component to be upgraded belongs.

[0197] In some possible embodiments, there are multiple components to be upgraded, and the first device sends the upgrade information, including: the first device sends the signature information corresponding to each component to be upgraded in the upgrade information to the corresponding component to be upgraded based on the sequence information, wherein the sequence information is used to indicate the upgrade execution order of each of the multiple components to be upgraded. Here, the first device can coordinate the upgrade of multiple vehicle-mounted components in the vehicle through the sequence information, which is conducive to improving the upgrade efficiency of the entire vehicle.

[0198] Exemplarily, if the upgrade information also includes upgrade files corresponding to the components to be upgraded, the first device sends the upgrade information, including: the first device sends signature information and upgrade files corresponding to each component to be upgraded in the upgrade information to the corresponding component to be upgraded based on the sequence information.

[0199] Exemplarily, the sequence information comes from the server. Further, the sequence information comes from the server, including: the sequence information is included in the upgrade information, or the sequence information is sent separately by the server. In some possible embodiments, the sequence information can also be generated locally by the first device based on the association relationship between multiple vehicle-mounted components, or the first device pre-stores it locally, which is not specifically limited here.

[0200] Exemplarily, assuming that the sequence information indicates that the upgrade execution order of component 1 is earlier than the upgrade execution order of component 2, it is sufficient to ensure that the moment when component 1 completes the upgrade based on the upgrade file corresponding to component 1 is earlier than the moment when component 2 completes the upgrade based on the upgrade file corresponding to component 2. Alternatively, component 2 can only start to execute the upgrade when component 1 is upgraded successfully.

[0201] In some possible embodiments, the order in which the first device sends the signature information and / or upgrade files corresponding to each component to be upgraded may not be limited. Instead, the first device can control each component to be upgraded to perform the upgrade in sequence based on the sequence information, which is not specifically limited here.

[0202] The above upgrade method is described below using an upgrade scenario of multiple components to be upgraded.

[0203] See also Figure 3 , Figure 3 This is a scenario diagram of multiple components to be upgraded provided in an embodiment of the present application. The first device takes an OTA manager as an example, but the first device is not limited to being only an OTA manager.

[0204] exist Figure 3 In the figure, the dotted box represents the components to be upgraded, that is, the components to be upgraded this time include ECU1, ECU2, domain controller 2, domain controller 3 and ECU3, among which ECU1 and ECU2 are hung under domain controller 1, and ECU3 is hung under domain controller 3.

[0205] See Table 1, which exemplarily provides Figure 3 The specific content of the upgrade request sent by the OTA manager to the server. As can be seen from Table 1, the upgrade request includes the identification of each component to be upgraded among multiple components to be upgraded, the freshness factor corresponding to each component to be upgraded, the configuration information of each component to be upgraded, and the identification of the vehicle. It can be understood that if the server knows the configuration information of the vehicle's on-board components in advance, the configuration information of the components to be upgraded in the upgrade request can be omitted.

[0206] Table 1

[0207] Vehicle logo (optional) ECU1's ID, ECU1's corresponding freshness factor, ECU1's configuration information (optional) ECU2's ID, ECU2's corresponding freshness factor, ECU2's configuration information (optional) ECU3 identification, ECU3 corresponding freshness factor, ECU3 configuration information (optional) The ID of domain controller 2, the freshness factor corresponding to domain controller 2, and the configuration information of domain controller 2 (optional) The ID of domain controller 3, the freshness factor corresponding to domain controller 3, and the configuration information of domain controller 3 (optional)

[0208] It can be understood that Table 1 is only an example for clearly presenting the content in the upgrade request, and the content in the upgrade request is not limited to that shown in Table 1.

[0209] See Table 2, which exemplarily provides Figure 3 The specific content of the upgrade information received by the OTA manager from the server. As can be seen from Table 2, the upgrade information includes the vehicle identification, the signature information corresponding to each of the multiple components to be upgraded, the upgrade file, and the identifier of the upgrade file. Among them, the upgrade file corresponding to the component to be upgraded and the identifier of the upgrade file are both optional information in the upgrade information. For example, the upgrade file can be obtained through other means. In one implementation, it can also be understood that one component to be upgraded corresponds to one sub-upgrade package. For example, the sub-upgrade package of ECU1 includes the signature information corresponding to ECU1, the upgrade file (optional), and the identifier of the upgrade file (optional).

[0210] Table 2

[0211]

[0212]

[0213] It can be understood that Table 2 is only an example for clearly presenting the content in the upgrade information, and the content in the upgrade information is not limited to that shown in Table 2. In some possible embodiments, the upgrade information may further include sequence information.

[0214] exist Figure 3 The way the OTA manager sends upgrade information can be found in the following methods A to D:

[0215] Method A: Send the sub-upgrade package of ECU1 and the sub-upgrade package of ECU2 to domain controller 1, send the sub-upgrade package of domain controller 2 to domain controller 2, and send the sub-upgrade package of domain controller 3 and the sub-upgrade package of ECU3 to domain controller 3. Here, the sending order of each sub-upgrade package is not limited, for example, they can be sent simultaneously, or sent at intervals of a preset time, or sent randomly within a certain time.

[0216] Method B: Assume that the sequence information indicates that the upgrade execution order of the components to be upgraded, ECU1, ECU2, domain controller 2, domain controller 3 and ECU3, is 1, 1, 2, 2, 3 respectively. The smaller the number, the earlier the upgrade execution order of the corresponding component. In this case, the sub-upgrade package of ECU1 and the sub-upgrade package of ECU2 are sent to domain controller 1 first, and then the sub-upgrade package of domain controller 2 is sent to domain controller 2 and the sub-upgrade package of domain controller 3 is sent to domain controller 3 at the same time. Finally, the sub-upgrade package of ECU3 is sent to domain controller 3.

[0217] Method C: Based on method B, the sub-upgrade package of ECU1 and the sub-upgrade package of ECU2 are sent to domain controller 1; upon receiving feedback information from domain controller 1 indicating that the upgrade of ECU1 and ECU2 is successful, the sub-upgrade package of domain controller 2 is sent to domain controller 2 and the sub-upgrade package of domain controller 3 is sent to domain controller 3; upon receiving feedback information from domain controller 2 indicating that the upgrade of domain controller 2 is successful and feedback information from domain controller 3 indicating that the upgrade of domain controller 3 is successful, the sub-upgrade package of ECU3 is sent to domain controller 3 at last.

[0218] Method D: Assume that the sequence information only indicates that the relative upgrade execution order of domain controller 2 and domain controller 3 is 1 and 2 respectively. The smaller the number, the earlier the upgrade execution order of the corresponding component to be upgraded. Based on the sequence information, it can be known that among the above-mentioned components to be upgraded: ECU1, ECU2, domain controller 2, domain controller 3 and ECU3, it is only necessary to satisfy: the sending time of the sub-upgrade package of domain controller 2 is earlier than the sending time of the sub-upgrade package of domain controller 3. For example, the sub-upgrade package of domain controller 3 is sent to domain controller 3 only after receiving the feedback information sent by domain controller 2 indicating that the upgrade of domain controller 2 is successful. In this upgrade, there is no restriction on the sending time of the sub-upgrade packages of the remaining components to be upgraded.

[0219] In the embodiment of the present application, after the domain controller to which the component to be upgraded belongs receives the sub-upgrade package of the component to be upgraded sent by the first device (for example, the OTA manager), the subsequent processing method of the domain controller can be specifically referred to in Figure 4 The description of the embodiments will not be repeated here.

[0220] In some possible embodiments, the first device may also receive feedback information, wherein the feedback information is used to indicate the upgrade result of the component to be upgraded. Exemplarily, when the component to be upgraded is a domain controller, the first device receives feedback information from the component to be upgraded; when the component to be upgraded is an ECU, the first device receives feedback information from the domain controller to which the component to be upgraded belongs.

[0221] Furthermore, since the versions of the upgrade files required to be used by the associated components to be upgraded are unified, when the upgrade results of the associated components to be upgraded are inconsistent, the first device can coordinate and control in time to ensure that the versions of the upgrade files used by the associated components to be upgraded are unified. For example, the components to be upgraded include components C and components D, wherein component C is associated with component D, and the first device receives feedback information 1 and feedback information 2, wherein feedback information 1 is used to indicate that component C is successfully upgraded this time, and feedback information 2 is used to indicate that component D fails to upgrade this time, then the first device sends rollback information to component C based on feedback information 1 and feedback information 2, wherein the rollback information is used to indicate that component C executes the upgrade file used before this upgrade. It can be seen from this that for the associated components to be upgraded, if one of the associated components to be upgraded fails to upgrade this time, the first device can control the other components to be upgraded that are associated with the component to be upgraded that failed to upgrade this time and have completed this upgrade to each execute the upgrade file used before this upgrade (i.e., the old upgrade file), so that the versions of the upgrade files used by the associated components to be upgraded are consistent, which is conducive to the normal operation of the business.

[0222] It can be seen that when implementing the embodiment of the present application, the server generates signature information corresponding to the component to be upgraded based on at least the identifier of the component to be upgraded in the upgrade request and the freshness factor corresponding to the component to be upgraded. The freshness factor is used to identify an upgrade of the component to be upgraded. The introduction of the freshness factor in the signature information can prevent the abuse of the upgrade file corresponding to the component to be upgraded. Even if the attacker can obtain the upgrade file of a certain component during a certain upgrade, the signature information cannot be successfully verified because the attacker cannot know the freshness factor of a certain component of a vehicle during the upgrade, thereby effectively avoiding the attacker's vehicle-brushing attack.

[0223] In an embodiment of the present application, the first device is a diagnostic instrument, or the first device is a control device integrated with an OTA manager and there is also a separately deployed domain controller. Based on the distribution of multiple components to be upgraded, at least one domain controller can obtain signature information, upgrade files (optional) and upgrade file identifiers (optional) corresponding to at least one component to be upgraded from the first device. Here, a domain controller is taken as an example to illustrate the upgrade method performed by the domain controller during an upgrade process.

[0224] See also Figure 4 , Figure 4 This is a flowchart of an upgrade method provided by an embodiment of the present application. The method can be applied, for example, between a target component and a first device, or between a target component, a first device, and a first component. Here, the target component is not the first device, but a domain controller, and the first device can be an OTA manager or a diagnostic instrument. The method includes but is not limited to the following steps:

[0225] S401: The first device sends signature information corresponding to the first component to the target component.

[0226] Here, the first component is the component to be upgraded.

[0227] The first component is a target component or the first component is connected to the target component. The first component is a target component, that is, the first component is a domain controller; the first component is connected to the target component, that is, the first component is an ECU and the target component is a domain controller.

[0228] Here, the first component is connected to the target component, and "connection" can be understood as a physical connection or a logical connection, that is, there is a data transmission relationship between the first component and the target component. For example, from a structural point of view, the first component and the target component are connected to each other, which means that the first component is hung below the target component; from a logical relationship point of view, the first component and the target component are connected to each other, which means that the first component is controlled by the target component.

[0229] In one implementation, the signature information corresponding to the first component is generated based on the identifier of the first component and the freshness factor corresponding to the first component. The generation method of the signature information corresponding to the first component can also refer to Figure 2 The relevant description of S202 in the embodiment will not be repeated here.

[0230] In some possible embodiments, the first device may also send the upgrade file corresponding to the first component to the target component, or send download address indication information corresponding to the first component to the target component, where the download address indication information is used to indicate the download address of the upgrade file corresponding to the first component.

[0231] S402: When the target component successfully verifies the signature information corresponding to the first component based on the freshness factor corresponding to the first component, the target component determines that the first component is to be upgraded.

[0232] Here, the process of the target component verifying the signature information corresponding to the first component may also be referred to as signature verification.

[0233] Exemplarily, since the server uses the first key when generating the signature information corresponding to the first component, the signature verification method is specifically as follows: when the signature information corresponding to the first component is generated based on the identifier of the first component and the freshness factor corresponding to the first component, the signature information corresponding to the first component is verified based on the second key, the identifier of the first component and the freshness factor corresponding to the first component to obtain a verification result, wherein the second key corresponds to the first key. Here, the judgment method of whether the verification result is a successful verification or a failed verification has been widely used in the field of digital signatures and will not be repeated here.

[0234] Here, the second key corresponds to the first key, which may be: if the first key is a private key, the second key is a public key corresponding to the first key. In some possible embodiments, the first key may also be a public key, and the second key is a private key corresponding to the first key.

[0235] It can be understood that if the signature information corresponding to the first component is generated based on the identifier of the first component, the freshness factor corresponding to the first component, and the identifier of the upgrade file corresponding to the first component, the target component needs to verify the signature information corresponding to the first component based on the second key, the identifier of the first component, the freshness factor corresponding to the first component, and the identifier of the upgrade file corresponding to the first component to obtain a verification result. In some possible embodiments, the target component can also verify the signature information corresponding to the first component in other ways, which is not specifically limited in the embodiments of the present application.

[0236] It can be understood that the successful signature verification also means that the signature information corresponding to the first component has not been damaged during the transmission process, and also ensures the legitimacy of the signature information of the first component during this upgrade. In addition, if the signature information corresponding to the first component is also generated based on the identifier of the upgrade file corresponding to the first component, the successful signature verification also means that the upgrade file corresponding to the first component has not been tampered with during the transmission process.

[0237] S403: The target component determines whether its own identifier is the same as the identifier of the first component.

[0238] In one implementation, if the identifier of the first component is the same as the identifier of the target component, S404 is executed; if the identifier of the first component is different from the identifier of the target component, S405 is executed.

[0239] S404: The target component performs an upgrade according to the upgrade file corresponding to the first component.

[0240] Exemplarily, the upgrade file corresponding to the first component can be directly received by the target component from the first device, or downloaded by the target component based on the download address indication information sent by the first device, or received by the target component from the server, which is not specifically limited here.

[0241] The first component is the target component, that is, the component to be upgraded is the domain controller. After the target component is upgraded, an upgrade result can be obtained, and the process jumps to S407.

[0242] Exemplarily, when the upgrade result is an upgrade failure, the target component further performs a rollback operation to run the upgrade file used by the target component before executing the current upgrade.

[0243] S405: The target component sends trigger information to the first component, where the trigger information includes an upgrade file corresponding to the first component.

[0244] Here, the trigger information is used to instruct the first component to perform an upgrade according to an upgrade file corresponding to the first component.

[0245] In some possible embodiments, the trigger information may not carry the upgrade file corresponding to the first component, that is, the upgrade file corresponding to the first component is directly obtained by the first component from the server, or the first component downloads the upgrade file based on the download address indication information carried by the trigger information, which is not specifically limited here.

[0246] S406: In response to the trigger information, the first component performs an upgrade according to the upgrade file corresponding to the first component.

[0247] Here, the acquisition of the upgrade file corresponding to the first component may refer to the description of the corresponding content in S405.

[0248] Further, after the first component executes this upgrade, an upgrade result is obtained, and the first component sends feedback information to the target component. The feedback information is used to indicate the upgrade result of the first component, and S407 is executed.

[0249] Exemplarily, when the upgrade result is an upgrade failure, the first component further performs a rollback operation to run the upgrade file used by the first component before performing the current upgrade.

[0250] S407: The target component sends feedback information to the first device, where the feedback information is used to indicate an upgrade result of the first component.

[0251] In one implementation, the first component is a target component, and the target component directly sends the feedback information to the first device.

[0252] In another implementation, the first component is connected to the target component, and the target component sends feedback information to the first device, including: the target component receives the feedback information from the first component and forwards the feedback information to the first device.

[0253] It can be seen that the first device can know the upgrade result of the first component in time through feedback information. In this way, the first device can also quickly grasp the upgrade results of each component to be upgraded in this upgrade, which is conducive to the first device coordinating the upgrade of multiple components to be upgraded.

[0254] Below Figure 3 Description of the scenario shown Figure 4 An application of an embodiment, wherein Figure 3 The scenes shown are not described in detail here.

[0255] for Figure 3In the domain controller 1, the target component is the domain controller 1, and the first component includes ECU1 and ECU2. If there is no restriction on the upgrade execution order of ECU1 and ECU2, the domain controller 1 can verify the signature information corresponding to ECU1 and the signature information corresponding to ECU2 at the same time or one after the other. For example, the domain controller 1 first verifies the signature information corresponding to ECU1. If the verification is successful, the domain controller 1 can send the upgrade file corresponding to ECU1 to ECU1, so that ECU1 executes the upgrade according to the upgrade file corresponding to ECU1 and feeds back the upgrade result of ECU1 to the domain controller 1; then, the domain controller 1 verifies the signature information corresponding to ECU2. If the verification is successful, the domain controller 1 sends the upgrade file corresponding to ECU2 to ECU2, so that ECU2 executes the upgrade according to the upgrade file corresponding to ECU2 and feeds back the upgrade result of ECU2 to the domain controller 1; finally, the domain controller 1 can feed back the upgrade result of ECU1 and the upgrade result of ECU2 to the OTA manager.

[0256] for Figure 3 The domain controller 2 in the target component and the first component are both domain controller 2. When the signature information corresponding to domain controller 2 is successfully verified, domain controller 2 performs the upgrade according to the upgrade file corresponding to domain controller 2 and feeds back its own upgrade result to the OTA manager.

[0257] for Figure 3 The domain controller 3 in the target component is the domain controller 3. The first component includes the domain controller 3 and the ECU 3. If there is no restriction on the upgrade execution order of the domain controller 3 and the ECU 3, the domain controller 3 can, for example, first process the signature information corresponding to the domain controller 3. For example, refer to the above Figure 3 The relevant description of domain controller 2 in the middle, and then process the signature information corresponding to ECU3, please refer to the above Figure 3 In some possible embodiments, the domain controller 3 may first receive the signature information and upgrade file corresponding to the domain controller 3, and then receive the signature information and upgrade file corresponding to ECU3. Then the domain controller 3 may receive the signature information and upgrade file corresponding to ECU3 based on Figure 4 The upgrade method shown executes the upgrade of the domain controller 3 first and then executes the upgrade of the ECU 3.

[0258] It can be seen that, in the implementation of the embodiment of the present application, the domain controller verifies the signature information corresponding to the components to be upgraded in the domain. Only when the verification is successful can the components to be upgraded in the domain be upgraded based on the corresponding upgrade files, and the signature information corresponding to the upgrade of the components to be upgraded is at least associated with the identification of the components to be upgraded and the freshness factor corresponding to the upgrade of the components to be upgraded, so that the signature information can only be used for one upgrade of a specific component in the vehicle. This prevents the abuse of upgrade files, effectively avoids vehicle flashing attacks performed by attackers using old versions of software or privileged versions of software, and is beneficial to improving the safety of vehicles.

[0259] In some possible embodiments, for Figure 3 A variation of the scene shown, in Figure 3 In the example, if the OTA manager is integrated with the domain controller 3, that is, the first device is a control device that integrates the OTA manager and the domain controller 3, and ECU3 is hung under the first device. In this case, since the domain controller 3 is integrated with the OTA manager, the first device does not need to send the signature information corresponding to the domain controller 3 and the signature information corresponding to ECU3 to the domain controller 3. The first device verifies the signature information corresponding to the domain controller 3, and performs the upgrade based on the upgrade file corresponding to the domain controller 3 if the verification is successful; and the first device verifies the signature information corresponding to ECU3, and if the verification is successful, it can send the upgrade file corresponding to ECU3 to ECU3, so that ECU3 performs the upgrade based on the upgrade file corresponding to ECU3, and receives the upgrade result fed back by ECU3. In addition, the first device and Figure 3 The remaining components to be upgraded: Domain Controller 2, ECU1 and the interaction between ECU2 can be referred to above Figure 4 The description of the embodiments will not be repeated here.

[0260] In some possible embodiments, the upgrade method provided by the embodiments of the present application can also be applied to the scenario where the vehicle-mounted components in the vehicle are replaced. In the case where the above-mentioned components to be upgraded include newly replaced components (such as component A), the first device can also send replacement information to the server, and the replacement information includes the configuration information of component A. The configuration information of component A can be, for example, the upgrade file version information currently used by component A, and the replacement information is used to indicate that component B of the vehicle is replaced by component A. Exemplarily, the replacement information can be included in the upgrade request, or it can be sent independently of the upgrade request. In this way, the server can promptly grasp the configuration of the newly replaced component A, so that it can determine the upgrade file corresponding to component A based on the configuration information of component A.

[0261] In another implementation, when component B in the vehicle is replaced by component A, the first device may not have started the next upgrade. In this case, the first device can be directly triggered to send the above replacement information to the server. The replacement information includes the upgrade file version information currently used by component A. The replacement information is used to indicate that component B in the vehicle is replaced by component A. In this way, the first device can promptly inform the server of the update status of the vehicle-mounted components in the vehicle through the replacement information, which is also convenient for the server to count the components to be upgraded in the next upgrade.

[0262] Accordingly, if the server receives the replacement information sent by the first device, the server can update the locally stored component configuration information of the vehicle according to the replacement information. For example, "update" means deleting the configuration information of component B in the component configuration information of the vehicle and adding the configuration information of component A to the component configuration information of the vehicle. In this way, the configuration information of the vehicle's onboard components can be aligned with the component configuration information of the vehicle stored locally on the server in a timely manner.

[0263] In some possible embodiments, the upgrade method provided in the embodiments of the present application can also be applied to the scenario where the vehicle and the cloud platform work together. For example, the cloud platform is deployed on the server side, component E in the vehicle is associated with the first functional module on the cloud platform, and the first device sends an upgrade request to the server. If the identifier of the component to be upgraded carried in the upgrade request includes the identifier of component E, the first device can also send indication information 1 to the server, where indication information 1 includes the identifier of the first functional module, and indication information 1 is used to indicate that the first functional module needs to be upgraded. Accordingly, the server receives indication information 1 sent by the first device, and upgrades the locally deployed first functional module according to indication information 1.

[0264] Exemplarily, component E is associated with the first functional module, which can be understood as the first functional module and component E working in coordination, or the functional operation of the first functional module depends on at least part of the business data of component E.

[0265] Here, the first functional module can be implemented by hardware, software, or a combination of hardware and software, and is not specifically limited here.

[0266] In this way, when a certain vehicle-mounted component in the vehicle needs to be upgraded, the functional modules associated with the vehicle-mounted component to be upgraded can be synchronously upgraded on the cloud platform through this method.

[0267] In some possible embodiments, in order to increase the security of the server, the signature information corresponding to the component to be upgraded can also be obtained by multiple servers using a threshold digital signature scheme. In this case, Figure 2The network side device in the embodiment is a system-level device composed of multiple servers.

[0268] For example, assuming that the network side equipment includes server 1, server 2, ..., server n, where n is an integer greater than 1, the signature information of each component to be upgraded can be jointly generated by at least t servers among these n servers, where t is an integer greater than 1 and less than or equal to n.

[0269] In one implementation, the first device only needs to interact with one server (for example, server 1) among the n servers. In this case, the interaction between the first device and server 1 can refer to Figure 2 The description of the interaction process between the first device and the server in the embodiment is different in that Figure 2 In the embodiment, the signature information corresponding to the component to be upgraded is generated by a server, and here the signature information corresponding to the component to be upgraded is jointly generated by multiple servers. Therefore, after server 1 receives the upgrade request sent by the first device, server 1 can share the upgrade request with other (n-1) servers. For any component to be upgraded, for example, each of the n servers generates a piece of signature information, and the other (n-1) servers send a piece of signature information generated by each server to server 1. Server 1 obtains the signature information corresponding to the component to be upgraded based on the received multiple pieces of signature information, and server 1 sends the signature information corresponding to the component to be upgraded to the first device. In some possible embodiments, when server 1 obtains the n pieces of signature information corresponding to the component to be upgraded, it can also obtain the signature information corresponding to the component to be upgraded based on the t pieces of signature information among the n pieces of signature information.

[0270] In another implementation, the first device may also interact with each of the n servers equally. For example, the first device sends the upgrade request to each of the n servers. For any component to be upgraded, such as component C, the first device may obtain a piece of signature information generated by the corresponding server from each of the n servers, and the first device obtains the signature information corresponding to component C based on the obtained pieces of signature information.

[0271] Taking the signature information corresponding to component C generated by n servers as an example, the following method can be referred to in the process of generating signature information:

[0272] Method 1: Each of the n servers corresponds to a pair of keys, for example, server 1 corresponds to key pair 1, server 2 corresponds to key pair 2, ..., server n corresponds to key pair n. Each pair of keys includes a private key and a public key, for example, the private key is used for signing, and the public key is used for subsequent signature verification. Exemplarily, the freshness factor corresponding to component C is split into n sub-freshness factors and stored by n servers respectively. Taking the i-th server as an example, i is a positive integer less than or equal to n. The i-th server locally stores the i-th freshness factor and the i-th server corresponds to key pair i. The i-th server uses the private key in key pair i to sign the identifier of component C and the i-th freshness factor to generate the i-th signature information corresponding to component C. In this way, n servers can generate n-segments of signature information corresponding to component C, and one of the servers can obtain the signature information corresponding to component C based on the t-segment signature information in the n-segments of signature information corresponding to component C, where t is an integer greater than 1 and less than or equal to n.

[0273] Method 2: n servers correspond to a pair of keys, and the pair of keys includes a first key and a second key, wherein the first key is used for signing and the second key is used for subsequent signature verification. For example, the first key is a private key and the second key is a public key corresponding to the first key. Exemplarily, the above-mentioned first key is split into n sub-keys and stored by n servers respectively. Taking the i-th server as an example, i is a positive integer less than or equal to n. The i-th server locally stores the i-th sub-key. The i-th server, for example, uses the i-th sub-key to sign the identifier of component C and the freshness factor corresponding to component C to generate the i-th signature information corresponding to component C. In this way, n servers can generate n-segments of signature information corresponding to component C, and one of the servers can obtain the signature information corresponding to component C based on the t-segment signature information in the n-segments of signature information corresponding to component C, where t is an integer greater than 1 and less than or equal to n.

[0274] Accordingly, based on the above-mentioned method 1, when the signature information corresponding to the component to be upgraded is generated, the above-mentioned target component or the first device needs to first obtain from multiple servers the t-molecule freshness factor used by the servers that jointly participated in generating the signature information corresponding to component C, and the target component or the first device locally knows the public key corresponding to the private key used by the above-mentioned n servers when signing. Taking component C as an ECU and component C being mounted under a target component as an example, the process of the target component verifying the signature information corresponding to component C can be, for example: the signature information corresponding to component C includes t segments of signature information. Taking the first segment of signature information in the t segments of signature information as an example, the first segment of signature information is generated by server 1, and the target component verifies the first segment of signature information based on the public key in the key pair 1 corresponding to server 1, the identifier of component C and the first molecular freshness factor stored locally on server 1, and obtains verification result 1. In this way, the t segments of signature information are verified in turn to obtain t verification results. In addition, the target component also obtains an estimated freshness factor corresponding to component C based on the obtained t molecular freshness factors. If the above t verification results are all successful, and the estimated freshness factor corresponding to component C is the same as the freshness factor corresponding to component C, then the verification is successful.

[0275] Accordingly, based on the above-mentioned method 2, the signature information corresponding to the component to be upgraded is generated. When the above-mentioned target component or the first device verifies the signature information corresponding to the component to be upgraded, the second key can be used to verify the signature information corresponding to the component to be upgraded to obtain a verification result. Here, the second key corresponds to the first key, and the first key and the second key can refer to the description in the above-mentioned method 2, which will not be repeated here.

[0276] It can be understood that when the signature information is generated based on the above method 1 or method 2, the signature information corresponding to component C can be associated with at least one of the vehicle identification and the identification of the upgrade file corresponding to component C in addition to the identification of component C and the freshness factor corresponding to component C. For details, please refer to Figure 2 The relevant description of Example S202 is not repeated here.

[0277] See also Figure 5 , Figure 5 Schematic diagram of the structure of an upgrade device provided in an embodiment of the present application. Figure 5 In the embodiment, the upgrading device 30 includes a sending unit 310 and a receiving unit 312. The upgrading device 30 can be implemented by hardware, software or a combination of hardware and software.

[0278] Among them, the sending unit 310 is used to send a first upgrade request to the server, the first upgrade request includes the identification of the component to be upgraded in the vehicle and the first freshness factor corresponding to the component to be upgraded, and the first freshness factor is used to identify an upgrade of the component to be upgraded; the receiving unit 312 is used to receive first upgrade information from the server, the first upgrade information includes first signature information corresponding to the component to be upgraded, and the first signature information is associated with the identification of the component to be upgraded and the first freshness factor corresponding to the component to be upgraded; the sending unit 310 is also used to send the first upgrade information.

[0279] The upgrading device 30 can be used to implement Figure 2 The method on the first device side described in the embodiment. Figure 2 In the embodiment, the sending unit 310 can be used to execute S201 and S204, and the receiving unit 312 can be used to execute S203. The upgrading device 30 can also be used to implement Figure 4 For the sake of brevity, the method on the first device side described in the embodiment will not be repeated here.

[0280] See also Figure 6 , Figure 6 Schematic diagram of another upgrading device provided in the embodiment of the present application. Figure 6 In the embodiment, the upgrading device 40 includes a receiving unit 410 and a sending unit 412. The upgrading device 40 can be implemented by hardware, software or a combination of hardware and software.

[0281] Among them, the receiving unit 410 is used to receive a first upgrade request, the first upgrade request includes an identification of a component to be upgraded in the vehicle and a first freshness factor corresponding to the component to be upgraded, and the first freshness factor is used to identify an upgrade of the component to be upgraded; the sending unit 412 is used to send first upgrade information in response to the first upgrade request, the first upgrade information includes first signature information corresponding to the component to be upgraded, and the first signature information is generated based on the identification of the component to be upgraded and the first freshness factor corresponding to the component to be upgraded.

[0282] The upgrading device 40 can be used to implement Figure 2 The server-side method described in the embodiment. Figure 2 In the embodiment, the receiving unit 410 may be used to execute S201, and the sending unit 412 may be used to execute S203. In some possible embodiments, the upgrading device 40 further includes a generating unit (not shown), and the generating unit may be used to execute S202.

[0283] See also Figure 7 , Figure 7 Schematic diagram of another upgrading device provided in the embodiment of the present application. Figure 7In the embodiment, the upgrading device 50 includes a receiving unit 510 and a processing unit 512. The upgrading device 50 can be implemented by hardware, software or a combination of hardware and software.

[0284] Among them, the receiving unit 510 is used to receive first signature information corresponding to the first component from the first device, the first signature information is associated with the identifier of the first component and the first freshness factor corresponding to the first component, wherein the first freshness factor is used to identify an upgrade of the first component, the first component is a target component or the first component is connected to the target component; the processing unit 512 is used to determine that the first component performs an upgrade when the first signature information is successfully verified based on the first freshness factor.

[0285] Furthermore, the upgrading device 50 also includes a sending unit 514, which is used for the first component to be hung under the target component and send trigger information to the first component, the trigger information includes the upgrade file corresponding to the first component, and the trigger information is used to instruct the first component to perform the upgrade according to the upgrade file corresponding to the first component.

[0286] The upgrading device 50 can be used to implement Figure 4 The method on the target component side is described in the embodiment. Figure 4 In the embodiment, the receiving unit 510 may be used to execute S401 , the processing unit 512 may be used to execute S402 , S403 , and S404 , and the sending unit 514 may be used to execute S405 and S407 .

[0287] It should be understood that the division of the various units in the above upgrade device (for example, the upgrade device 30, the upgrade device 40 or the upgrade device 50) is only a division of logical functions, and in actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. In addition, the units in the device can be implemented in the form of a processor calling software; for example, the device includes a processor, the processor is connected to a memory, the memory stores instructions, and the processor calls the instructions stored in the memory to implement any of the above methods or implement the functions of the various units of the device, wherein the processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is a memory inside the device or a memory outside the device. Alternatively, the units in the device can be implemented in the form of hardware circuits, and the functions of some or all of the units can be realized by designing the hardware circuits, and the hardware circuits can be understood as one or more processors; for example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC), and the functions of some or all of the above units are realized by designing the logical relationship of the components in the circuit; for another example, in another implementation, the hardware circuit can be realized by a programmable logic device (PLD), taking a field programmable gate array (FPGA) as an example, which can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured by a configuration file, so as to realize the functions of some or all of the above units. All units of the above devices can be realized in the form of a processor calling software, or in the form of hardware circuits, or in part by a processor calling software, and the rest by hardware circuits.

[0288] In the embodiment of the present application, the processor is a circuit with signal processing capability. In one implementation, the processor can be a circuit with instruction reading and running capability, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP), etc.; in another implementation, the processor can realize certain functions through the logical relationship of the hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by a processor as an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the processor loads a configuration document to implement the process of hardware circuit configuration, which can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.

[0289] It can be seen that each unit in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0290] In addition, all or part of the units in the above device can be integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of each unit of the device. The type of the at least one processor may be different, for example, including a CPU and an FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.

[0291] See also Figure 8 , Figure 8 Schematic diagram of the structure of a communication device provided in an embodiment of the present application. Figure 8As shown, the communication device 60 includes: a processor 601, a communication interface 602, a memory 603 and a bus 604. The processor 601, the memory 603 and the communication interface 602 communicate with each other via the bus 604. It should be understood that the present application does not limit the number of processors and memories in the communication device 60.

[0292] In one implementation, the communication device 60 may be a network-side device. The network-side device may be, for example, a server deployed on the network side (e.g., an OTA server, a car factory cloud server, etc.), or a component or chip in the server, or a system-level device composed of multiple servers. The network-side device may be deployed in a cloud environment or an edge environment, which is not specifically limited here.

[0293] In another implementation, the communication device 60 may be a vehicle-side general interface for upgrading the entire vehicle, such as an OTA manager, or may be a vehicle diagnostic instrument or a component within the vehicle diagnostic instrument, such as a chip, an integrated circuit, etc.

[0294] In another implementation, the communication device 60 may be a domain controller or a component within the domain controller, such as a chip, an integrated circuit, etc. Here, the domain controller may be a hardware and software integrated platform for supporting intelligent driving, i.e., an on-board computing platform, such as a mobile data center MDC, or a hardware and software integrated platform for supporting body control and chassis control, such as a vehicle domain controller VDC, or a hardware and software integrated platform for providing on-board multimedia services, such as a cockpit domain controller CDC. In some possible embodiments, the domain controller may also be any one of a domain controller that integrates VDC functions and MDC functions, a domain controller that integrates VDC functions and CDC functions, a domain controller that integrates MDC functions and CDC functions, and a domain controller that integrates VDC functions, MDC functions, and CDC functions.

[0295] In another implementation, the communication device 60 may also be an ECU.

[0296] The bus 604 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 The bus 604 is represented by only one line, but it does not mean that there is only one bus or one type of bus. The bus 604 may include a path for transmitting information between various components of the communication device 60 (for example, the memory 603, the processor 601, and the communication interface 602).

[0297] The processor 601 can refer to the related description of the processor in the above embodiment, which will not be repeated here.

[0298] The memory 603 is used to provide a storage space, in which data such as an operating system and a computer program can be stored. The memory 603 can be a random access memory (RAM), an erasable programmable read only memory (EPROM), a read-only memory (ROM), or a portable read-only memory (CD-ROM), etc., or a combination of multiple types. The memory 603 can exist alone or be integrated into the processor 601.

[0299] The communication interface 602 may be used to provide information input or output for the processor 601. Alternatively, the communication interface 602 may be used to receive data sent externally and / or send data externally, and may be a wired link interface such as an Ethernet cable, or a wireless link interface (such as Wi-Fi, Bluetooth, general wireless transmission, etc.). Alternatively, the communication interface 602 may also include a transmitter (such as a radio frequency transmitter, an antenna, etc.) coupled to the interface, or a receiver, etc.

[0300] The processor 601 in the communication device 60 is used to read the computer program stored in the memory 603 to execute the aforementioned method, for example Figure 2 or Figure 4 Any of the described upgrade methods on the execution entity side.

[0301] In a possible design, the communication device 60 may be a device for executing Figure 2 One or more modules in the execution subject (e.g., server) of the method shown, the processor 601 can be used to read one or more computer programs stored in the memory to perform the following operations:

[0302] Receiving a first upgrade request through the receiving unit 410, the first upgrade request including an identifier of a component to be upgraded in the vehicle and a first freshness factor corresponding to the component to be upgraded, the first freshness factor being used to identify an upgrade of the component to be upgraded;

[0303] In response to the first upgrade request, the sending unit 412 sends first upgrade information, the first upgrade information including first signature information corresponding to the component to be upgraded, the first signature information being generated based on the identifier of the component to be upgraded and the first freshness factor corresponding to the component to be upgraded.

[0304] In a possible design, the communication device 60 may be a device for executing Figure 2 One or more modules in the execution subject (e.g., the first device) of the method shown, the processor 601 can be used to read one or more computer programs stored in the memory to perform the following operations:

[0305] Sending a first upgrade request to the server through the sending unit 310, the first upgrade request including an identifier of the component to be upgraded in the vehicle and a first freshness factor corresponding to the component to be upgraded, the first freshness factor being used to identify an upgrade of the component to be upgraded;

[0306] Receiving first upgrade information from the server through the receiving unit 312, the first upgrade information including first signature information corresponding to the component to be upgraded, the first signature information being associated with an identifier of the component to be upgraded and a first freshness factor corresponding to the component to be upgraded;

[0307] The first upgrade information is sent through the sending unit 310.

[0308] In a possible design, the communication device 60 may be a device for executing Figure 4 One or more modules in the execution body (e.g., target component) of the method shown, the processor 601 can be used to read one or more computer programs stored in the memory to perform the following operations:

[0309] Receiving, through the receiving unit 510, first signature information corresponding to the first component from the first device, the first signature information being associated with an identifier of the first component and a first freshness factor corresponding to the first component, wherein the first freshness factor is used to identify an upgrade of the first component, the first component being a target component or the first component being connected to the target component;

[0310] When the first signature information is successfully verified based on the first freshness factor, it is determined that the first component performs an upgrade.

[0311] In the above-mentioned embodiments of this invention, the description of each embodiment has its own emphasis. For the part that is not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. In addition, in the various embodiments of this application, if there is no special explanation and logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced to each other. The technical features in different embodiments can be combined to form a new embodiment according to their internal logical relationship.

[0312] It should be noted that, a person skilled in the art can see that all or part of the steps in the various methods of the above embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, and the storage medium includes a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electrically-erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0313] The essence of the technical solution of the present application or the part that makes the contribution or all or part of the technical solution can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes a number of instructions for enabling a device (which can be a personal computer, a server, or a network device, a robot, a single-chip microcomputer, a chip, a robot, etc.) to execute all or part of the steps of the method described in each embodiment of the present application.

Claims

1. An upgrade method, It is characterized in that The method comprises: Sending a first upgrade request to a server, the first upgrade request including an identifier of a component to be upgraded in the vehicle and a first freshness factor corresponding to the component to be upgraded, the first freshness factor being used to identify at least one upgrade of the component to be upgraded; receiving first upgrade information from the server, the first upgrade information including first signature information corresponding to the component to be upgraded, the first signature information being associated with an identifier of the component to be upgraded and a first freshness factor corresponding to the component to be upgraded; The first upgrade information is sent.

2. The method according to claim 1, It is characterized in that The number of the components to be upgraded is multiple, and the multiple components to be upgraded include a first component and a second component, wherein the first freshness factor corresponding to the first component is a third freshness factor, and the first freshness factor corresponding to the second component is a fourth freshness factor, When the second component and the third component belong to different domain controllers, the third freshness factor is different from the fourth freshness factor.

3. The method according to claim 1 or 2, It is characterized in that The component to be upgraded includes a first component, and the number of upgrade files corresponding to the first component is one or more. When the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files of the current upgrade and upgrade files of the historical upgrade that have not been executed.

4. The method according to any one of claims 1 to 3, It is characterized in that There are multiple components to be upgraded, and sending the first upgrade information includes: Based on the sequence information, signature information corresponding to each of the multiple components to be upgraded in the first upgrade information is sent to the corresponding components to be upgraded, wherein the sequence information is used to indicate the upgrade execution order of each of the multiple components to be upgraded.

5. The method according to claim 4, It is characterized in that The sequence information comes from the server, or the sequence information is generated locally.

6. The method according to any one of claims 1 to 5, It is characterized in that The method further comprises: When the third component in the vehicle is replaced by a fourth component, replacement information is sent to the server, the replacement information including the upgrade file version information currently used by the fourth component, and the replacement information is used to indicate that the third component is replaced by the fourth component.

7. The method according to any one of claims 1 to 6, It is characterized in that A first functional module is associated with a fifth component in the components to be upgraded, and the first functional module is deployed on a cloud platform of the server, and the method further includes: Sending indication information to the server, where the indication information includes an identifier of the first functional module, and the indication information is used to indicate that the first functional module needs to be upgraded.

8. The method according to any one of claims 1 to 7, It is characterized in that The first freshness factor is a random number or the value of the first freshness factor has a unidirectional growth characteristic.

9. The method according to any one of claims 1 to 8, It is characterized in that The first upgrade information further includes at least one of the following information: an upgrade file corresponding to the component to be upgraded and an identifier of the upgrade file corresponding to the component to be upgraded.

10. The method according to any one of claims 1 to 9, It is characterized in that The method is applied to an OTA manager or a diagnostic instrument.

11. The method according to any one of claims 1 to 10, It is characterized in that The method further comprises: Sending a second upgrade request to the server, the second upgrade request including an identifier of the component to be upgraded and a second freshness factor corresponding to the component to be upgraded, the second freshness factor being used to at least identify another upgrade of the component to be upgraded; receiving second upgrade information from the server, the second upgrade information including second signature information corresponding to the component to be upgraded, the second signature information being associated with an identifier of the component to be upgraded and a second freshness factor corresponding to the component to be upgraded, the first freshness factor being different from the second freshness factor; The second upgrade information is sent.

12. An upgrade method, It is characterized in that The method comprises: receiving a first upgrade request, the first upgrade request including an identifier of a component to be upgraded in the vehicle and a first freshness factor corresponding to the component to be upgraded, the first freshness factor being used to identify at least one upgrade of the component to be upgraded; In response to the first upgrade request, first upgrade information is sent, the first upgrade information including first signature information corresponding to the component to be upgraded, the first signature information being generated based on an identifier of the component to be upgraded and a first freshness factor corresponding to the component to be upgraded.

13. The method according to claim 12, It is characterized in that In the vehicle, when different components to be upgraded belong to different domain controllers, the first freshness factors corresponding to the different components to be upgraded are different.

14. The method according to claim 12 or 13, It is characterized in that The first upgrade information also includes an upgrade file corresponding to the component to be upgraded.

15. The method according to any one of claims 12 to 14, It is characterized in that The component to be upgraded includes a first component, and the number of upgrade files corresponding to the first component is one or more. When the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files of the current upgrade and upgrade files of the historical upgrade that have not been executed.

16. The method according to any one of claims 12 to 15, It is characterized in that When there are multiple components to be upgraded, the first upgrade information further includes sequence information, wherein the sequence information is used to indicate the upgrade execution sequence of each of the multiple components to be upgraded.

17. The method according to any one of claims 12 to 16, It is characterized in that The method further comprises: receiving replacement information, the replacement information being used to indicate that the second component in the vehicle is replaced with a third component, the replacement information including version information of an upgrade file currently used by the third component; Based on the replacement information, the locally recorded component configuration information of the vehicle is updated.

18. The method according to any one of claims 12 to 17, It is characterized in that The method is applied to a server, wherein a cloud platform of the server includes a first functional module, wherein the first functional module is associated with one of the components to be upgraded, and the method further includes: receiving indication information, the indication information including an identifier of the first functional module, the indication information being used to indicate that the first functional module needs to be upgraded; The first functional module is upgraded according to the instruction information.

19. The method according to any one of claims 12 to 18, It is characterized in that The method is applied to a first server, wherein the first signature information is obtained by the first server based on signature information generated by each server in a plurality of servers, wherein the signature information generated by each server is generated based on an identifier of the component to be upgraded and a sub-freshness factor corresponding to each server, wherein the sub-freshness factor corresponding to each server is obtained by splitting the first freshness factor, and the plurality of servers include the first server.

20. The method according to any one of claims 12 to 19, It is characterized in that The method further comprises: receiving a second upgrade request, the second upgrade request including an identifier of the component to be upgraded and a second freshness factor corresponding to the component to be upgraded, the second freshness factor being used to at least identify another upgrade of the component to be upgraded; In response to the second upgrade request, second upgrade information is sent, the second upgrade information including second signature information corresponding to the component to be upgraded, the second signature information being generated based on the identifier of the component to be upgraded and a second freshness factor corresponding to the component to be upgraded.

21. An upgrade method, It is characterized in that Applied to a target component, the method comprises: receiving first signature information corresponding to a first component from a first device, wherein the first signature information is associated with an identifier of the first component and a first freshness factor corresponding to the first component, wherein the first freshness factor is used to identify at least one upgrade of the first component, and the first component is the target component or is connected to the target component; In a case where the first signature information is successfully verified based on the first freshness factor, it is determined that the first component performs an upgrade.

22. The method according to claim 21, It is characterized in that The method further comprises: receiving an upgrade file corresponding to the first component from a second device; If the first signature information is successfully verified based on the first freshness factor and the first component is the target component, performing an upgrade according to an upgrade file corresponding to the first component; or When the first signature information is successfully verified based on the first freshness factor and the first component is connected to the target component, trigger information is sent to the first component, the trigger information including an upgrade file corresponding to the first component, and the trigger information is used to instruct the first component to perform an upgrade according to the upgrade file corresponding to the first component.

23. The method according to claim 21 or 22, It is characterized in that The number of upgrade files corresponding to the first component is one or more. When the number of upgrade files corresponding to the first component is multiple, the upgrade files corresponding to the first component include upgrade files of current upgrade and upgrade files of historical upgrade that have not been executed.

24. The method according to any one of claims 21 to 23, It is characterized in that The freshness factor corresponding to the first component is generated by the target component.

25. The method according to any one of claims 21 to 24, It is characterized in that The method further comprises: receiving, from the first device, second signature information corresponding to the first component, where the second signature information is generated based on an identifier of the first component and a second freshness factor corresponding to the first component, where the second freshness factor is at least used to identify another upgrade of the first component, and the second freshness factor is different from the first freshness factor; In a case where the second signature information is successfully verified based on the second freshness factor, it is determined that the first component performs an upgrade.

26. A device for upgrading, It is characterized in that The device comprises: a sending unit, configured to send a first upgrade request to a server, wherein the first upgrade request includes an identifier of a component to be upgraded in the vehicle and a first freshness factor corresponding to the component to be upgraded, wherein the first freshness factor is used to identify at least one upgrade of the component to be upgraded; A receiving unit, configured to receive first upgrade information from the server, wherein the first upgrade information includes first signature information corresponding to the component to be upgraded, and the first signature information is associated with an identifier of the component to be upgraded and a first freshness factor corresponding to the component to be upgraded; The sending unit is further configured to send the first upgrade information.

27. A device for upgrading, It is characterized in that The device comprises: A receiving unit, configured to receive a first upgrade request, wherein the first upgrade request includes an identifier of a component to be upgraded in the vehicle and a first freshness factor corresponding to the component to be upgraded, wherein the first freshness factor is used to identify at least one upgrade of the component to be upgraded; A sending unit is used to send first upgrade information in response to the first upgrade request, where the first upgrade information includes first signature information corresponding to the component to be upgraded, and the first signature information is generated based on the identifier of the component to be upgraded and a first freshness factor corresponding to the component to be upgraded.

28. A device for upgrading, It is characterized in that The device is a target component or is included in the target component, and the device comprises: a receiving unit, configured to receive first signature information corresponding to a first component from a first device, wherein the first signature information is associated with an identifier of the first component and a first freshness factor corresponding to the first component, wherein the first freshness factor is used to identify at least one upgrade of the first component, and the first component is the target component or the first component is connected to the target component; The processing unit is configured to determine that the first component is to be upgraded if the first signature information is successfully verified based on the first freshness factor.

29. A chip, It is characterized in that The chip includes at least one processor and a communication interface; The communication interface is used to receive and / or send data, and / or the communication interface is used to provide input and / or output for the processor; The at least one processor is used to implement the method of any one of claims 1-11, or to implement the method of any one of claims 12-20, or to implement the method of any one of claims 21-25.

30. An upgrade system, It is characterized in that The system includes a first device and a second device, or includes a first device, a second device and a third device, wherein the first device is used to execute the method described in any one of claims 1 to 11, the second device is used to indicate the method described in any one of claims 21 to 25, and the third device is used to execute the method described in any one of claims 12 to 20.

31. A vehicle, It is characterized in that The vehicle comprises a first device and a second device, wherein the first device is used to execute the method according to any one of claims 1 to 11, and the second device is used to indicate the method according to any one of claims 21 to 25.

32. A computer-readable storage medium, It is characterized in that The computer-readable storage medium stores instructions, and when the instructions are executed on at least one processor, the method according to any one of claims 1 to 11 is implemented, or the method according to any one of claims 12 to 20 is implemented, or the method according to any one of claims 21 to 25 is implemented.

Images