Diagnostic method and apparatus

Abstract

The embodiment of the invention provides a diagnosis method and device.The method comprises the steps that a first diagnosis strategy file sent by diagnosis equipment is received, the diagnosis strategy file comprises access control strategy information, and the diagnosis equipment comprises a remote diagnosis platform or a near-end diagnosis instrument; verifying the authenticity and integrity of the first diagnosis strategy file; and under the condition that the authenticity and integrity verification of the first diagnosis strategy file is passed, verifying whether a diagnosis command has access control authority or not according to the access control strategy information. Through the method, the vehicle can be prevented from executing wrong or illegal diagnosis commands during diagnosis, and property and privacy safety of a vehicle owner is guaranteed.

Description

Diagnostic methods and devices Technical Field

[0001] The embodiments of the present application relate to the field of security, and more specifically, to a diagnostic method and apparatus. Background Art

[0002] With the evolution of network technology and the widespread adoption of vehicles, vehicle diagnostics are bringing significant benefits to vehicle users. Vehicle diagnostics involves determining the cause of a vehicle malfunction. This involves assessing the vehicle's technical condition, identifying the location and cause of the malfunction, and ensuring it remains in the vehicle without disassembling. This diagnostic scope encompasses the powertrain, chassis, body, and accessories, as well as exhaust emissions, noise, and safety testing.

[0003] However, during the vehicle diagnosis process, since the diagnostic platform or diagnostic instrument needs to send diagnostic commands to the vehicle, once the diagnostic platform or diagnostic instrument is abused or maliciously diagnosed by illegal personnel and issues erroneous or malicious diagnostic commands, after the vehicle executes the erroneous or illegal diagnostic commands, the user's privacy, property and life safety may be violated.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a diagnostic method and device that can prevent a vehicle from executing erroneous or illegal diagnostic commands during diagnosis, thereby protecting the property and privacy of the vehicle owner.

[0006] In a first aspect, a diagnostic method is provided, which includes: receiving a first diagnostic policy file sent by a diagnostic device, the first diagnostic policy file including: access control policy information, and the diagnostic device including: a remote diagnostic platform or a proximal diagnostic instrument; verifying the authenticity and integrity of the first diagnostic policy file; and if the authenticity and integrity of the first diagnostic policy file are verified, verifying whether the diagnostic command has access control authority based on the access control policy information.

[0007] The diagnostic command may be a diagnostic command to be executed by the vehicle and may be sent by a diagnostic device. Diagnostic commands may include, but are not limited to, reading fault codes, clearing fault codes, full vehicle scanning, and component diagnosis. Access control policy information may include one or more of: authorization type, validity period, vehicle identity information, identification ID, timestamp, version, signature, and certificate. The fact that a diagnostic command has access control permission indicates that the diagnostic command is legal and valid and can be executed by the vehicle.

[0008] In this embodiment of the present application, before a vehicle executes a diagnostic command, it can use the access control policy information in the first diagnostic policy file to verify whether the diagnostic command has access control permissions. The diagnostic command is only executed if it has access control permissions. This prevents the vehicle from executing erroneous or illegal diagnostic commands, protecting the user's property and privacy.

[0009] In combination with the first aspect, in certain implementations of the first aspect, the access control policy information includes: a validity period, and verifying whether the diagnostic command has access control authority based on the access control policy information includes: within the validity period, using the access control policy information to verify whether the diagnostic command has access control authority.

[0010] In the embodiment of the present application, only when the diagnosis policy file is within the validity period, the access control policy information in the diagnosis policy file is used to verify whether the diagnosis command has the access control authority. In this way, the diagnosis policy file can be prevented from being used after it expires, thereby improving the security of the use of the diagnosis policy file.

[0011] In combination with the first aspect, in certain implementations of the first aspect, the access control policy information also includes: first vehicle identity information, and verifying whether the diagnostic command has access control authority based on the access control policy information includes: verifying whether the first vehicle identity information is consistent with the second vehicle identity information, and the diagnostic command includes the second vehicle identity information.

[0012] Among them, the first vehicle identity information can be information used to represent the vehicle identity, which may include but is not limited to the vehicle identification number. When the first vehicle identity information in the access control policy information is consistent with the diagnostic command, it can be determined that the diagnostic command has access control authority.

[0013] In an embodiment of the present application, by verifying whether the first vehicle identity information is consistent with the second vehicle identity information, it is verified whether the diagnostic command has access control authority, which can further ensure the user's property safety and privacy security.

[0014] In combination with the first aspect, in certain implementations of the first aspect, the first vehicle identity information and / or the second vehicle identity information is a vehicle identification number.

[0015] In combination with the first aspect, in certain implementations of the first aspect, the access control policy information also includes: a first identification ID, the first identification ID includes: at least one of: a first electronic control unit ID, a first CAN ID, a first diagnostic service ID, and a first diagnostic data ID; the use of the access control policy information to verify whether the diagnostic command has access control authority includes: verifying whether the first identification ID is consistent with the second identification ID, the second identification ID is the identification ID in the diagnostic command, and the second identification ID includes: at least one of: a second electronic control unit ID, a second CAN ID, a second diagnostic service ID, and a second diagnostic data ID.

[0016] Only when the first identification ID and the second identification ID are consistent, the diagnostic command can be effective for the corresponding electronic control unit or the vehicle can use the corresponding diagnostic service or diagnostic data.

[0017] Among them, the second electronic control unit ID can be the ID of the electronic control unit targeted by the diagnostic command, the second CAN ID can represent the address or name of the CAN node that sends and receives the diagnostic command, the second diagnostic service ID can be the service ID required for performing the diagnostic command, and the second diagnostic data ID can be the data ID required for performing the diagnostic service or diagnostic command.

[0018] In an embodiment of the present application, the diagnostic command can only take effect on the corresponding electronic control unit or the vehicle can use the corresponding diagnostic service or diagnostic data when the first identification ID in the diagnostic command and the second identification ID in the access control policy information are consistent. In this way, a diagnostic access control mechanism for vehicles and components and an access mechanism for diagnostic services are provided, thereby ensuring the security and effectiveness of the diagnostic commands.

[0019] In combination with the first aspect, in some implementations of the first aspect, the access control policy information further includes: a first timestamp, and the use of the access control policy information to verify whether the diagnostic command has access control authority includes: verifying whether a second timestamp is greater than the first timestamp, and the second timestamp is the timestamp of the diagnostic command.

[0020] Wherein, when the second timestamp is greater than the first timestamp, the diagnostic command has access control authority; when the second timestamp is less than the first timestamp, the diagnostic command does not have access control authority.

[0021] Optionally, in this implementation, it can be set that when the second timestamp is greater than the first timestamp and the execution time of the diagnostic task is within the validity period of the access control policy information, the diagnostic command has the access control permission.

[0022] It should be understood that the purpose of ensuring that the timestamp of the diagnostic task is greater than the timestamp of the access control policy information in this step is to prevent the diagnostic task from being reused or replayed, that is, it is necessary to ensure that the time when the vehicle receives the diagnostic command is later than the time when it receives the diagnostic policy file.

[0023] In the embodiment of the present application, by verifying whether the second timestamp is greater than the first timestamp, the diagnostic task is prevented from being reused or replayed, which can further ensure the user's property safety and privacy security.

[0024] In combination with the first aspect, in certain implementations of the first aspect, the diagnostic device includes: a proximal diagnostic instrument, the first diagnostic strategy file includes: a first key, and the method further includes: storing the first key in a vehicle, the vehicle being the vehicle on which the diagnostic command is to be executed; verifying whether the first key is consistent with the second key, the second key being the key stored in the proximal diagnostic instrument; and establishing a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

[0025] Only when the first key and the second key are consistent can a secure access service be established between the vehicle and the proximal diagnostic instrument. After the secure access service is established, the proximal diagnostic instrument can use the access control policy information in the diagnostic policy file to verify whether the diagnostic command has diagnostic control authority.

[0026] Among them, both the first key and the second key can be temporary keys, and the application process of the first key and the second key can be: first, the key management system generates the second key and sends the second key to the authorization management system. After generating the first diagnostic strategy file, the authorization management system sends the second key along with the first diagnostic strategy file to the proximal diagnostic instrument. After the proximal diagnostic instrument obtains the second key, it can save the second key to the proximal diagnostic instrument. Then the proximal diagnostic instrument sends the first key along with the first diagnostic strategy file to the vehicle, and the vehicle saves the first key. When verifying the key, if the first key and the second key are consistent, that is, the first key is the second key, it means that the second key has not been tampered with by the proximal diagnostic instrument during the transmission process. If the first key and the second key are inconsistent, it means that the second key may be tampered with and the diagnostic process is not safe.

[0027] There are multiple ways to verify whether the first key and the second key are consistent.

[0028] In a possible implementation, the proximal diagnostic instrument may send a ciphertext to the vehicle, and the vehicle may verify the ciphertext to determine whether the first key and the second key are consistent.

[0029] In one possible implementation, after the first key is saved in the vehicle through the first diagnostic strategy file, the proximal diagnostic instrument may directly send the saved second key to the vehicle, and the vehicle verifies whether the first key and the second key are consistent.

[0030] It should be understood that the reason for verifying whether the first key and the second key are consistent is to be compatible with the old version of the proximal diagnostic instrument. If the diagnostic user uses the old version of the proximal diagnostic instrument to diagnose the vehicle, failure to perform key verification may cause the execution of the diagnostic command to fail.

[0031] In combination with the first aspect, in certain implementations of the first aspect, the diagnostic device includes: a proximal diagnostic instrument, and the method further includes: receiving a first key sent by the proximal diagnostic instrument; storing the first key in a vehicle, which is a vehicle to execute the diagnostic command; verifying whether the first key is consistent with a second key, which is a key stored in the proximal diagnostic instrument; and establishing a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

[0032] Among them, both the first key and the second key can be temporary keys, and the application process of the first key and the second key can be: first, the key management system generates the second key and sends the second key to the proximal diagnostic instrument, which is then saved by the proximal diagnostic instrument. Then, the proximal diagnostic instrument directly sends the first key to the vehicle, and the vehicle saves the first key. When verifying the key, if the first key and the second key are consistent, that is, the first key is the second key, it means that the second key has not been tampered with by the proximal diagnostic instrument during the transmission process. If the first key and the second key are inconsistent, it means that the second key may have been tampered with and the diagnostic process is not safe.

[0033] In an embodiment of the present application, whether a secure access service is established between the vehicle and the diagnostic platform is determined by verifying whether the first key and the second key are consistent. Only after the secure access service is established can the vehicle use the access control policy information to verify whether the diagnostic command has access control authority. In this way, the security and legality of the execution of the diagnostic command can be further guaranteed.

[0034] In combination with the first aspect, in certain implementations of the first aspect, establishing a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key includes: establishing a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key and the first key is within the validity period.

[0035] The validity period may be the validity period in the access control policy information or the validity period of the first key. If the validity period is exceeded, the first key will become invalid.

[0036] In an embodiment of the present application, the vehicle can establish a secure access service with the proximal diagnostic instrument only when the first key and the second key are consistent and the first key is within the validity period. In this way, the use of the invalid first key for consistency verification can be avoided, further improving the security of key use.

[0037] In combination with the first aspect, in certain implementations of the first aspect, the access control policy information includes: a certificate and a signature, and the verification of the authenticity and integrity of the first diagnostic policy file includes: using the public key of the certificate to decrypt the signature to obtain a first digital summary; performing a hash calculation on the access control policy information to obtain a second digital summary; and verifying whether the first digital summary is consistent with the second digital summary.

[0038] Optionally, before using the certificate to decrypt the signature, the method further includes verifying the authenticity and validity of the certificate.

[0039] Optionally, a symmetric key can be used to verify the authenticity and integrity of the first diagnostic policy file. The symmetric key is used to encrypt the access control policy information to obtain a second digital digest; and the consistency of the first digital digest and the second digital digest is verified. In this verification method, the access control policy information can include the first digital digest, without having to use a public key to decrypt the signature to obtain the first digital digest.

[0040] In an embodiment of the present application, the access control policy information can be hashed to obtain a second digital digest, and the second digital digest can be compared with the first digital digest to verify the authenticity and integrity of the first diagnostic policy file. In this way, only when the authenticity and integrity verification of the first diagnostic policy file are passed, the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control authority, which can further protect the user's property and privacy security.

[0041] In combination with the first aspect, in certain implementations of the first aspect, verifying the authenticity and integrity of the first diagnostic strategy file includes: verifying whether the first vehicle identity information matches the vehicle, and the vehicle is the vehicle on which the diagnostic command is to be executed.

[0042] For example, the first vehicle identification information is a vehicle identification number. The first vehicle identification number can be compared with the vehicle identification code to determine whether the first vehicle identification number matches the vehicle. If the two match, verification is successful; if the two do not match, verification fails. The vehicle identification code can be viewed on the front bulkhead of the vehicle's engine compartment or on the vehicle's dashboard.

[0043] In an embodiment of the present application, the authenticity and integrity of the first diagnostic strategy file can be verified by determining whether the first vehicle identity information matches the vehicle. In this way, only when the authenticity and integrity of the first diagnostic strategy file are verified, the access control policy information in the first diagnostic strategy file is used to verify whether the diagnostic command has access control authority, which can further protect the user's property and privacy security.

[0044] In combination with the first aspect, in some implementations of the first aspect, before receiving the first diagnostic strategy file sent by the diagnostic device, the method also includes: receiving a second diagnostic strategy file sent by the diagnostic device, the second diagnostic file including: a third timestamp; verifying the authenticity and integrity of the first diagnostic strategy file includes: verifying whether the first timestamp is greater than the third timestamp.

[0045] Among them, the time when the vehicle receives the second diagnostic strategy file is earlier than the time when the first diagnostic strategy file is received. The second diagnostic strategy file can be the diagnostic strategy file used when the diagnostic command was last executed, or it can be a diagnostic strategy file that has not been used yet. The purpose of verifying whether the first timestamp is greater than the third timestamp is to determine whether the first diagnostic strategy file has been reused or replayed. If the first timestamp is less than the third timestamp, it means that the first diagnostic strategy file may have been reused or replayed, and the strategy file is not authentic. If the first timestamp is greater than the third timestamp, the authenticity and integrity verification of the first diagnostic strategy file is passed.

[0046] In this embodiment of the present application, the relationship between the first and third timestamps is verified to determine whether the first diagnostic policy file has been reused or subjected to a replay attack. If the verification is successful, the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permission, thereby further protecting the user's property and privacy.

[0047] In combination with the first aspect, in some implementations of the first aspect, verifying the authenticity and integrity of the first diagnostic strategy file includes: determining whether the difference between the first timestamp and the vehicle local time is less than or equal to a preset threshold.

[0048] If the difference between the first timestamp and the vehicle's local time is less than or equal to a preset threshold, the authenticity and integrity verification of the first diagnostic strategy file passes. If the difference between the first timestamp and the vehicle's local time is greater than a preset threshold, it indicates that the first diagnostic strategy file may be reused or replayed.

[0049] In this embodiment, the relationship between the first timestamp and the vehicle's local time is verified to determine whether the first diagnostic policy file has been reused or subjected to a replay attack. If verification is successful, the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, further protecting the user's property and privacy.

[0050] In combination with the first aspect, in some implementations of the first aspect, receiving the first diagnostic strategy file sent by the diagnostic device includes: receiving the first diagnostic strategy file sent by the diagnostic device with authorization from the vehicle owner.

[0051] Among them, the car owner's authorization can be authorized for a certain period of time through an online / offline service agreement or a call to meet the requirements of privacy compliance. For example, the car owner is required to sign or check the diagnostic service agreement before the diagnosis begins. The vehicle can only perform the diagnostic task after the vehicle detects that the car owner has signed or checked the diagnostic service agreement. Among them, the diagnostic service agreement may include but is not limited to: the object of diagnosis, the authority of diagnosis, and the resources that the vehicle needs to call to perform the diagnostic task, etc. For another example, before the diagnosis begins, the car owner can request a vehicle diagnosis by phone. In this case, it can be assumed that the car owner agrees to the diagnostic service agreement. For another example, the car owner can trigger the diagnostic process through the application on the vehicle.

[0052] In the embodiment of the present application, the vehicle can receive the first diagnostic strategy file only if the vehicle owner authorizes it, so as to subsequently verify through the first diagnostic strategy file whether the diagnostic command has access control authority.

[0053] In a second aspect, a diagnostic method is provided, which is applied to a diagnostic device, wherein the diagnostic device includes: a remote diagnostic platform or a proximal diagnostic instrument, and the method includes: sending a first request message to an authorization management system, wherein the first request message is used to request the authorization management system to generate a first diagnostic policy file, wherein the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; receiving the first diagnostic policy file sent by the authorization management system; and sending the first diagnostic policy file to a vehicle, wherein the vehicle is a vehicle on which the diagnostic command is to be executed.

[0054] In an embodiment of the present application, the diagnostic device receives a first diagnostic strategy file from the authorization management system and forwards it to the vehicle, so that subsequent vehicles can use the first diagnostic strategy file to verify whether the diagnostic command has access rights.

[0055] In combination with the second aspect, in certain implementations of the second aspect, before sending the first request information to the authorization management system, the method also includes: obtaining the identity information of the diagnostic personnel; sending the identity information of the diagnostic personnel to the authorization management system; sending the first request information to the authorization management system includes: upon receiving the first response information sent by the authorization management system, sending the first request information to the authorization management system, the first response information being used to indicate that the identity authentication of the diagnostic personnel is successful.

[0056] Among them, the identity information of the diagnostician can have various forms. For example, the identity information of the diagnostician can be account information. The account information can be created by the original equipment manufacturer (OEM), and the account and password are assigned to the diagnostician, who enters the account and password on the diagnostic platform or diagnostic instrument. For another example, the identity information can be the facial feature information of the diagnostician. The OEM can pre-enter the facial feature information of qualified diagnosticians into the diagnostic instrument or diagnostic platform, and the diagnostician needs to log in by verifying the facial feature information on the diagnostic platform or diagnostic instrument. In addition, the identity information can also be the iris feature information or voiceprint feature information of the diagnostician, etc., which will not be repeated here.

[0057] In an embodiment of the present application, a diagnostician needs to log in to the diagnostic platform before conducting a diagnosis. The diagnostic device needs to send the diagnostician's identity information to the authorization management system for verification. After receiving the successful verification information from the authorization management system, the diagnostic device can request the authorization management system to send the first diagnostic policy file. In this way, an identity verification mechanism for diagnosticians is provided, which can prevent the diagnostic platform or diagnostic instrument from being abused or maliciously diagnosed by illegal personnel, resulting in infringement of the user's privacy, property, and life safety.

[0058] In combination with the second aspect, in certain implementations of the second aspect, the first diagnostic strategy file includes: a second key, and before sending the first diagnostic strategy file to the vehicle, the method also includes: saving the second key in the diagnostic device, and the diagnostic device is the proximal diagnostic instrument.

[0059] In the embodiment of the present application, the diagnostic device can obtain the second key from the first diagnostic strategy file and save the second key to the diagnostic device to facilitate subsequent vehicle verification of the consistency of the first key and the second key.

[0060] In combination with the second aspect, in certain implementations of the second aspect, the method further includes: receiving a second key sent by a key management system, storing the second key in the diagnostic device, and sending the first key to a vehicle, where the vehicle is the vehicle on which the diagnostic command is to be executed.

[0061] In a third aspect, a diagnostic method is provided, which is applied to an authorization management system. The method includes: receiving a first request message sent by a diagnostic device, generating a first diagnostic policy file based on the first request message, and the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; and sending the first diagnostic policy file to the diagnostic device.

[0062] In combination with the third aspect, in certain implementations of the third aspect, before receiving the first request information sent by the diagnostic device, the method also includes: receiving the identity information of the diagnostic personnel sent by the diagnostic device; and when the identity information of the diagnostic personnel is consistent with the identity information preset in the authorization management system, sending a first response information to the diagnostic device, the first response information being used to indicate that the identity authentication of the diagnostic personnel is successful.

[0063] Verifying the diagnostician's identity information can also be done in a variety of ways. For example, if the diagnostician's identity information is account information, the authorization management system needs to verify the account number and password entered by the diagnostician. Upon successful verification, it sends a first response message to the diagnostic device to inform the diagnostician that the identity verification is successful. For another example, if the diagnostician's identity information is facial feature information, the authorization management system can compare the facial feature information with facial feature information preset in the system. Upon successful verification, it sends a first response message to the diagnostic device to inform the diagnostician that the identity verification is successful.

[0064] In an embodiment of the present application, after receiving the identity information of the diagnostic personnel sent by the diagnostic platform, the authorization management system can verify the identity information and then identify the legitimacy of the diagnostic user. Only when the identity of the diagnostic user is legitimate will the first diagnostic strategy file be sent to the diagnostic device. In this way, an identity authentication mechanism for the diagnostic personnel is provided before the diagnosis is performed, which can prevent the diagnostic platform or diagnostic instrument from being abused or maliciously diagnosed by illegal persons, resulting in infringement of the user's privacy, property and life safety.

[0065] In a fourth aspect, a diagnostic device is provided, which includes: a transceiver unit for receiving a first diagnostic strategy file sent by a diagnostic device, the first diagnostic strategy file including: access control policy information, and the diagnostic device including: a remote diagnostic platform or a proximal diagnostic instrument; a processing unit for verifying the authenticity and integrity of the first diagnostic strategy file; the processing unit is also used to verify whether the diagnostic command has access control authority according to the access control policy information when the authenticity and integrity verification of the first diagnostic strategy file is passed.

[0066] It should be understood that the transceiver unit provided in the embodiments of the present application can be a communication interface on a diagnostic module (diagnostic device), through which the diagnostic module can receive the first diagnostic strategy file from an intelligent vehicle-mounted terminal (telematics-box, T-BOX) or other device. The transceiver unit can also be a communication interface on a T-BOX in the vehicle, which receives the first diagnostic strategy file and sends the first diagnostic strategy file to the diagnostic module for processing.

[0067] In combination with the fourth aspect, in certain implementations of the fourth aspect, the access control policy information includes: a validity period; and the processing unit is specifically used to use the access control policy information to verify whether the diagnostic command has access control authority within the validity period.

[0068] In combination with the fourth aspect, in certain implementations of the fourth aspect, the access control policy information also includes: first vehicle identity information; the processing unit is specifically used to verify whether the first vehicle identity information is consistent with the second vehicle identity information, and the diagnostic command includes the second vehicle identity information.

[0069] In combination with the fourth aspect, in certain implementations of the fourth aspect, the first vehicle identity information and / or the second vehicle identity information is a vehicle identification number.

[0070] In combination with the fourth aspect, in certain implementations of the fourth aspect, the access control policy information also includes: a first identification ID, the first identification ID includes: at least one of: a first electronic control unit ID, a first CAN ID, a first diagnostic service ID, and a first diagnostic data ID; the processing unit is specifically used to verify whether the first identification ID is consistent with the second identification ID, the second identification ID is the identification ID in the diagnostic command, and the second identification ID includes: at least one of: a second electronic control unit ID, a second CAN ID, a second diagnostic service ID, and a second diagnostic data ID.

[0071] In combination with the fourth aspect, in some implementations of the fourth aspect, the access control policy information also includes: a first timestamp; the processing unit is specifically used to verify whether the second timestamp is greater than the first timestamp, and the second timestamp is the timestamp of the diagnostic command.

[0072] In combination with the fourth aspect, in certain implementations of the fourth aspect, the diagnostic device includes: a proximal diagnostic instrument, the first diagnostic strategy file includes: a first key; the processing unit is further used to store the first key in a vehicle, and the vehicle is the vehicle on which the diagnostic command is to be executed; the processing unit is further used to verify whether the first key is consistent with the second key, and the second key is the key stored in the proximal diagnostic instrument; the processing unit is further used to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

[0073] In combination with the fourth aspect, in certain implementations of the fourth aspect, the diagnostic device includes: a proximal diagnostic instrument; the transceiver unit is further used to receive a first key sent by the proximal diagnostic instrument; the processing unit is further used to store the first key in a vehicle, which is a vehicle on which the diagnostic command is to be executed; the processing unit is further used to verify whether the first key is consistent with a second key, which is a key stored in the proximal diagnostic instrument; the processing unit is further used to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

[0074] In combination with the fourth aspect, in certain implementations of the fourth aspect, the processing unit is specifically configured to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key and the first key is within a validity period.

[0075] In combination with the fourth aspect, in certain implementations of the fourth aspect, the access control policy information also includes: a certificate and a signature; the processing unit is specifically used to decrypt the signature using the public key of the certificate to obtain a first digital summary; perform a hash calculation on the access control policy information to obtain a second digital summary; and verify whether the first digital summary is consistent with the second digital summary.

[0076] In combination with the fourth aspect, in certain implementations of the fourth aspect, the processing unit is specifically used to verify whether the first vehicle identity information matches the vehicle, and the vehicle is the vehicle on which the diagnostic command is to be executed.

[0077] In combination with the fourth aspect, in some implementations of the fourth aspect, the transceiver unit is further used to receive a second diagnostic strategy file sent by the diagnostic device, and the second diagnostic file includes: a third timestamp; the processing unit is specifically used to verify whether the first timestamp is greater than the third timestamp.

[0078] In combination with the fourth aspect, in certain implementations of the fourth aspect, the transceiver unit is specifically configured to receive the first diagnostic strategy file sent by the diagnostic device upon obtaining authorization from the vehicle owner.

[0079] In a fifth aspect, a diagnostic device is provided, which includes: a transceiver unit for sending a first request message to an authorization management system, wherein the first request message is used to request the authorization management system to generate a first diagnostic policy file, wherein the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; the transceiver unit is also used to receive the first diagnostic policy file sent by the authorization management system; the transceiver unit is also used to send the first diagnostic policy file to a vehicle, wherein the vehicle is the vehicle on which the diagnostic command is to be executed. In combination with the fifth aspect, in certain implementations of the fifth aspect, the device further includes: an acquisition unit for acquiring the identity information of the diagnostic personnel; the transceiver unit is also used to send the identity information of the diagnostic personnel to the authorization management system; the transceiver unit is specifically used to send the first request message to the authorization management system upon receiving the first response message sent by the authorization management system, wherein the first response message is used to indicate that the identity authentication of the diagnostic personnel is successful.

[0080] In conjunction with the fifth aspect, in certain implementations of the fifth aspect, the first diagnostic strategy file includes: a second key, and the apparatus further includes: a processing unit for storing the second key in the diagnostic device.

[0081] In combination with the fifth aspect, in certain implementations of the fifth aspect, the transceiver unit is further used to receive a second key sent by the key management system; the processing unit is further used to store the second key in the diagnostic device, which is the proximal diagnostic instrument; and send the first key to the vehicle.

[0082] In the sixth aspect, a diagnostic device is provided, which includes: a transceiver unit for receiving a first request information sent by a diagnostic device, a processing unit for generating a first diagnostic strategy file based on the first request information, and the first diagnostic strategy file is used to verify whether the diagnostic command has access control authority; the transceiver unit is also used to send the first diagnostic strategy file to the diagnostic device.

[0083] In the sixth aspect, in certain implementations of the sixth aspect, the transceiver unit is further used to receive the identity information of the diagnostic personnel sent by the diagnostic device; the transceiver unit is further used to send a first response message to the diagnostic device when the identity information of the diagnostic personnel is consistent with the identity information preset in the authorization management system, and the first response message is used to indicate that the identity authentication of the diagnostic personnel is successful.

[0084] In a seventh aspect, a diagnostic device is provided, which includes: at least one processor and a memory, wherein the at least one processor is coupled to the memory and is used to read and execute instructions in the memory, and the device is used to execute the methods in the above aspects.

[0085] In an eighth aspect, a computer-readable medium is provided, wherein the computer-readable medium stores a program code, and when the computer program code is run on a computer, the computer executes the methods in the above aspects.

[0086] In a ninth aspect, a chip is provided, comprising: at least one processor and a memory, wherein the at least one processor is coupled to the memory and is configured to read and execute instructions in the memory, and the device is configured to execute the methods in the above aspects.

[0087] In a tenth aspect, a computer program product is provided, comprising: a computer program, which enables a computer to execute the methods in the above aspects when the computer program is run.

[0088] In an eleventh aspect, a vehicle is provided, comprising: at least one processor and a memory, wherein the at least one processor is coupled to the memory and is configured to read and execute instructions in the memory, and the vehicle is configured to execute the method in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] FIG1 is a diagnostic system 100 provided in an embodiment of the present application.

[0090] FIG2 is a functional schematic diagram of a vehicle provided in an embodiment of the present application.

[0091] FIG3 is a diagnostic scheme provided in an embodiment of the present application.

[0092] FIG4 is another diagnostic scheme provided in an embodiment of the present application.

[0093] FIG5 is a diagnostic method 500 provided in an embodiment of the present application.

[0094] FIG6 is a system architecture 600 applicable to a diagnostic method provided in an embodiment of the present application.

[0095] FIG7 is a schematic diagram of a role creation provided in an embodiment of the present application.

[0096] FIG8 is a remote diagnosis method 800 provided in an embodiment of the present application.

[0097] FIG9 is a method 900 for generating and issuing a diagnostic strategy file during a remote diagnosis process provided by an embodiment of the present application.

[0098] FIG10 is a method 1000 for issuing and executing diagnostic tasks during a remote diagnosis process provided by an embodiment of the present application.

[0099] FIG11 is a proximal diagnosis method 1100 provided in an embodiment of the present application.

[0100] FIG12 is a method 1200 for generating and issuing a diagnostic strategy file during a proximal diagnosis process provided by an embodiment of the present application.

[0101] FIG13 is a method 1300 for issuing and executing diagnostic tasks during a proximal diagnosis process provided by an embodiment of the present application.

[0102] FIG14 is a schematic diagram of a policy file format provided in an embodiment of the present application.

[0103] FIG15 is a flow chart 1500 of authenticity and integrity verification of a policy file provided in an embodiment of the present application.

[0104] FIG16 is a method 1600 for managing diagnostic tasks or diagnostic commands using a policy file, provided in an embodiment of the present application.

[0105] FIG17 is a specific implementation of a policy file provided in an embodiment of the present application.

[0106] FIG18 is a diagnostic device 1800 provided in an embodiment of the present application.

[0107] FIG19 is another diagnostic device 1900 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0108] The technical solution in this application will be described below with reference to the accompanying drawings.

[0109] FIG1 is a diagnostic system 100 provided in an embodiment of the present application.

[0110] As shown in (a) of Figure 1 , the system 100 may include a cloud server 110, a diagnostic instrument 120, a diagnostic module 130, and a vehicle 140. The cloud server 110 may include a diagnostic platform 111 and other services 112. The cloud server 110 may be a physical server or a virtual server. When the cloud server 110 is a virtual server, it may be located anywhere in the world, providing services to vehicles in different countries and regions. The diagnostic platform 111 may connect to the vehicle 140 via a 4G / 5G network and directly issue diagnostic commands to the vehicle 140 for vehicle diagnosis. This diagnostic method may also be referred to as remote diagnosis. Other services 112 may include: collecting and analyzing vehicle component operating data or providing data value-added services such as software upgrades to the vehicle. The diagnostic instrument 120 may synchronize information with the cloud server 110 via a 4G / 5G network, and may send diagnostic commands to diagnose the vehicle by connecting to the vehicle's on-board diagnostics (OBD) interface. This diagnostic method is also referred to as near-end diagnosis.

[0111] As shown in (b) of Figure 1, the diagnostic module 130 is located in the vehicle 140. The diagnostic module 130 may include: a diagnostic client module 131, a diagnostic strategy module 132, and a diagnostic agent module 133. The diagnostic client module 131 is capable of receiving diagnostic commands from the cloud server 110 or the diagnostic instrument 120 and verifying the diagnostic commands using a diagnostic strategy file. The diagnostic strategy module 132 is capable of checking the diagnostic strategy file and performing vehicle status monitoring. When the vehicle's status meets a preset condition, the diagnostic strategy module 132 is capable of sending the diagnostic command to the electronic control unit (ECU) via the diagnostic agent module 133. For example, it can be set that when the vehicle's driving speed is less than 3 km / h, the diagnostic strategy module 132 can send the diagnostic command to the diagnostic agent module 133. The diagnostic agent module 133 can forward the diagnostic command sent by the diagnostic strategy module 132 to the ECU via a controller area network (CAN) or Ethernet processing.

[0112] It should be understood that when the vehicle is set at a lower speed (for example, 3 km / h), the diagnostic strategy module 132 sends the diagnostic command to the diagnostic agent module 133 for vehicle safety considerations. Since the vehicle needs to call certain resources when performing diagnostic tasks, performing diagnostic tasks when the vehicle is traveling at high speed may affect other functions of the vehicle.

[0113] FIG2 is a functional diagram of a vehicle provided in an embodiment of the present application. The vehicle 200 in FIG2 may be the vehicle 140 in FIG1. ​​It should be understood that FIG2 and the related description are merely examples and do not limit the vehicle in the embodiment of the present application.

[0114] During implementation, the vehicle 200 can be configured in a fully or partially autonomous driving mode, or can be manually driven by a user.

[0115] Vehicle 200 may include various subsystems, such as a computing platform 210 and a display device 220. Alternatively, vehicle 200 may include more or fewer subsystems, and each subsystem may include one or more components. Furthermore, each subsystem and component of vehicle 200 may be interconnected via wired or wireless means.

[0116] Some or all functions of vehicle 200 may be controlled by a computing platform 210. Computing platform 210 may include processors 211 to 21n (n is a positive integer). A processor is a circuit capable of processing signals. In one implementation, the processor may be a circuit capable of reading and executing instructions, 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). In another implementation, the processor may implement certain functions through the logical relationships of a hardware circuit. The logical relationships of the hardware circuit are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration file to implement the hardware circuit configuration 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. In addition, the computing platform 210 can also include a memory for storing instructions. Some or all of the processors 211 to 21n can call the instructions in the memory and execute them to achieve corresponding functions.

[0117] The computing platform 210 may control the functionality of the vehicle 200 based on input received from the various subsystems. In some embodiments, the computing platform 210 may be operable to provide control over many aspects of the vehicle 200 and its subsystems.

[0118] Optionally, the above components are only an example. In actual applications, the components in the above modules may be added or deleted according to actual needs. Figure 2 should not be understood as a limitation to the embodiments of the present application.

[0119] Optionally, the vehicle 200 or a perception and computing device associated with the vehicle 200 (e.g., a computing platform 210) can predict the behavior of the identified objects based on the characteristics of the identified objects and the state of the surrounding environment (e.g., traffic, rain, ice on the road, etc.). Optionally, each identified object depends on the behavior of each other, so all identified objects can also be considered together to predict the behavior of a single identified object. The vehicle 200 can adjust its speed based on the predicted behavior of the identified objects. In other words, the autonomous vehicle can determine what stable state the vehicle will need to adjust to (e.g., accelerate, decelerate, or stop) based on the predicted behavior of the objects. In this process, other factors can also be considered to determine the speed of the vehicle 200, such as the lateral position of the vehicle 200 in the road it is traveling on, the curvature of the road, the proximity of static and dynamic objects, etc.

[0120] In addition to providing instructions to adjust the speed of the autonomous vehicle, the computing device may also provide instructions to modify the steering angle of vehicle 200 so that the autonomous vehicle follows a given trajectory and / or maintains a safe lateral and longitudinal distance from objects near the autonomous vehicle (e.g., cars in adjacent lanes on the road).

[0121] The vehicle 200 may be a car, truck, motorcycle, bus, ship, airplane, helicopter, lawn mower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, etc., and the embodiments of the present application do not impose any particular limitation thereto.

[0122] FIG3 is a diagnostic solution provided in an embodiment of the present application. The diagnostic solution shown in FIG3 can be applied to the diagnostic system 100 of FIG1 . The diagnostic solution shown in FIG3 can include the following steps.

[0123] S301, the client sends a "client hello" message to the server, which includes password information and a character string "client random".

[0124] The client may refer to the diagnostic platform 111 or the diagnostic instrument 120 in FIG. 1 , and the server may refer to the diagnostic module 130 in FIG. 1 .

[0125] S302, the server responds with a "server hello" message, which includes a password combination, a digital certificate, and a random character string "server random".

[0126] Among them, the digital certificate may include: public key, issuing agency information, company name, domain name and validity period, etc.

[0127] S303, the client verifies the digital certificate and obtains the public key from the certificate, generates the next random string premaster secret (pre-master secret) and encrypts it with the public key.

[0128] S304: The client sends the encrypted “premaster secret” to the server.

[0129] S305: The server uses the private key to decrypt and obtain the "premaster secret".

[0130] S306: The client and the server use the same algorithm and use "client random", "server random" and "premaster secret" to generate the same key KEY for symmetric encryption in the subsequent process.

[0131] S307: The client sends a "finished" message to the server.

[0132] S308: The server sends a "finished" message to the client.

[0133] S309: A secure connection is successfully established, and the client and server use a common key KEY for symmetric encryption to communicate securely.

[0134] Among them, steps S301 to S309 are the specific process of authenticating the communication equipment outside the vehicle through the transport layer security protocol (TLS). Although this method can verify the authenticity of the diagnostic platform and diagnostic instrument, it cannot authenticate the authenticity of the diagnostic user. Once the diagnostic platform or diagnostic instrument is abused or maliciously diagnosed by illegal personnel, the user's privacy, property and life safety may be violated.

[0135] For example, the diagnostic platform or diagnostic instrument may be attacked by hackers. After infiltrating the client, hackers may steal or tamper with diagnostic instructions. Since the above methods cannot verify the user's identity, if the vehicle executes the hacked diagnostic instructions, it may cause financial losses to the user.

[0136] For example, the equipment operation and maintenance personnel of the diagnostic platform or diagnostic instrument may perform operations beyond the scope of their responsibilities, resulting in diagnostic instructions that do not meet the user's intentions. Since this situation cannot be identified through the above method, once the vehicle executes a diagnostic instruction that does not meet the user's operating intentions, the user's privacy and property safety may not be protected.

[0137] FIG4 is another diagnostic solution provided in an embodiment of the present application. The diagnostic solution shown in FIG4 can be applied to the diagnostic system 100 of FIG1 . The diagnostic solution shown in FIG4 can include the following steps.

[0138] S401, the client requests a seed from the server

[0139] S402, the server sends a random seed to the client

[0140] S403, the client sends the calculated KEY to the server

[0141] Specifically, the server can compare the KEY stored in its own storage with the KEY sent by the client. If the two are the same, it can send an unlocking success instruction to the client in step S404. If the two are different, it can send an unlocking failure instruction in step S404.

[0142] S404: The server responds to the client whether the unlocking is successful.

[0143] Steps S401 to S404 are the specific process performed using the unified diagnostic services 27 (UDS 27). The USD 27 primarily uses a seed and key to provide a protection mechanism for ECUs. The target ECU controls access to sensitive diagnostic services (e.g., writing data to the ECU) through secure access services. Only after secure access is granted can the ECU execute sensitive diagnostic services.

[0144] However, UDS 27 security access services are service-oriented, meaning they only protect pre-defined sensitive diagnostic services. Therefore, when using this method to execute services other than sensitive diagnostic services, diagnostic commands are vulnerable to malicious diagnosis and illegal manipulation by diagnosticians or hackers. Furthermore, because this method lacks vehicle- and component-specific diagnostic access control mechanisms, it can easily be used by diagnosticians or hackers to maliciously diagnose specific vehicle components.

[0145] It can be seen that in actual applications of the diagnostic solutions of FIG3 or FIG4, the diagnostic platform and diagnostic instrument are easily abused or maliciously diagnosed by illegal persons, thereby infringing the privacy, property and life safety of users.

[0146] The embodiments of the present application provide a diagnostic method that can prevent a vehicle from executing erroneous or illegal diagnostic commands, thereby protecting the user's property and privacy.

[0147] FIG5 is a diagnostic method 500 provided in an embodiment of the present application. The method 500 may include the following steps:

[0148] S501: Receive a first diagnostic policy file sent by a diagnostic device, where the first diagnostic policy file includes access control policy information.

[0149] The diagnostic equipment may include a remote diagnostic platform or a proximal diagnostic instrument.

[0150] Access control policy information may include: one or more of: authorization type, validity period, vehicle identity information, identification ID, timestamp, version, signature and certificate. Among them, the authorization type may refer to the type of diagnostic policy file, for example, remote diagnosis type or proximal diagnosis type. Vehicle identity information and identification ID can be used to check the legitimacy of the diagnostic target, and the validity period can be used to monitor the effectiveness of the diagnostic time. The version may refer to the format version of the first diagnostic policy file, and the record of the version can facilitate future updates to the format file. The signature may refer to the signature of the cloud-based authorization management system, which can be verified in the vehicle. If the verification is passed, the authenticity and integrity of the diagnostic policy file itself are guaranteed.

[0151] In a possible implementation, the receiving the first diagnostic strategy file sent by the diagnostic device includes: receiving the first diagnostic strategy file sent by the diagnostic device with authorization from the vehicle owner.

[0152] Among them, the car owner's authorization can be authorized for a certain period of time through an online / offline service agreement or a call to meet the requirements of privacy compliance. For example, the car owner is required to sign or check the diagnostic service agreement before the diagnosis begins. The vehicle can only perform the diagnostic task after the vehicle detects that the car owner has signed or checked the diagnostic service agreement. Among them, the diagnostic service agreement may include but is not limited to: the object of diagnosis, the authority of diagnosis, and the resources that the vehicle needs to call to perform the diagnostic task, etc. For another example, before the diagnosis begins, the car owner can request a vehicle diagnosis by phone. In this case, it can be assumed that the car owner agrees to the diagnostic service agreement. For another example, the car owner can trigger the diagnostic process through the application on the vehicle.

[0153] In an embodiment of the present application, the vehicle can receive the first diagnostic strategy file only if the vehicle owner authorizes it, so as to subsequently verify whether the diagnostic command has access control authority through the access control strategy information in the first diagnostic strategy file.

[0154] In one possible implementation, the diagnostic device includes: a proximal diagnostic instrument, the first diagnostic strategy file includes: a first key, and the method further includes: storing the first key in a vehicle, the vehicle being the vehicle on which the diagnostic command is to be executed; verifying whether the first key is consistent with a second key, the second key being the key stored in the proximal diagnostic instrument; and establishing a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

[0155] Only when the first key and the second key are consistent can a secure access service be established between the vehicle and the proximal diagnostic instrument. After the secure access service is established, the proximal diagnostic instrument can use the access control policy information in the diagnostic policy file to verify whether the diagnostic command has diagnostic control authority.

[0156] Among them, both the first key and the second key can be temporary keys, and the application process of the first key and the second key can be: first, the key management system generates the second key and sends the second key to the authorization management system. After generating the first diagnostic strategy file, the authorization management system sends the second key along with the first diagnostic strategy file to the proximal diagnostic instrument. After the proximal diagnostic instrument obtains the second key, it can save the second key to the proximal diagnostic instrument. Then the proximal diagnostic instrument sends the first key along with the first diagnostic strategy file to the vehicle, and the vehicle saves the first key. When verifying the key, if the first key and the second key are consistent, that is, the first key is the second key, it means that the second key has not been tampered with by the proximal diagnostic instrument during the transmission process. If the first key and the second key are inconsistent, it means that the second key may be tampered with and the diagnostic process is not safe.

[0157] There are multiple ways to verify whether the first key and the second key are consistent.

[0158] In a possible implementation, the proximal diagnostic instrument may send a ciphertext to the vehicle, and the vehicle may verify the ciphertext to determine whether the first key and the second key are consistent.

[0159] In one possible implementation, after the first key is saved in the vehicle through the first diagnostic strategy file, the proximal diagnostic instrument may directly send the saved second key to the vehicle, and the vehicle verifies whether the first key and the second key are consistent.

[0160] It should be understood that the reason for verifying whether the first key and the second key are consistent is to be compatible with the old version of the proximal diagnostic instrument. If the diagnostic user uses the old version of the proximal diagnostic instrument to diagnose the vehicle, failure to perform key verification may cause the execution of the diagnostic command to fail.

[0161] In one possible implementation, the diagnostic device includes: a proximal diagnostic instrument, and the method further includes: receiving a first key sent by the proximal diagnostic instrument; storing the first key in a vehicle, which is a vehicle to execute the diagnostic command; verifying whether the first key is consistent with a second key, which is a key stored in the proximal diagnostic instrument; and establishing a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

[0162] Among them, both the first key and the second key can be temporary keys, and the application process of the first key and the second key can be: first, the key management system generates the second key and sends the second key to the proximal diagnostic instrument, which is then saved by the proximal diagnostic instrument. Then, the proximal diagnostic instrument directly sends the first key to the vehicle, and the vehicle saves the first key. When verifying the key, if the first key and the second key are consistent, that is, the first key is the second key, it means that the second key has not been tampered with by the proximal diagnostic instrument during the transmission process. If the first key and the second key are inconsistent, it means that the second key may have been tampered with and the diagnostic process is not safe.

[0163] In an embodiment of the present application, whether a secure access service is established between the vehicle and the diagnostic platform is determined by verifying whether the first key and the second key are consistent. Only after the secure access service is established can the vehicle use the access control policy information to verify whether the diagnostic command has access control authority. In this way, the security and legality of the execution of the diagnostic command can be further guaranteed.

[0164] S502: Verify the authenticity and integrity of the first diagnostic strategy file

[0165] There are many ways to verify the authenticity and integrity of the first diagnostic strategy file.

[0166] In one possible implementation, the access control policy information includes: a certificate and a signature, and the verification of the authenticity and integrity of the first diagnostic policy file includes: using the public key of the certificate to decrypt the signature to obtain a first digital summary; performing a hash calculation on the access control policy information to obtain a second digital summary; and verifying whether the first digital summary is consistent with the second digital summary.

[0167] Optionally, before using the certificate to decrypt the signature, the method further includes verifying the authenticity and validity of the certificate.

[0168] Optionally, a symmetric key can be used to verify the authenticity and integrity of the first diagnostic policy file. The symmetric key is used to encrypt the access control policy information to obtain a second digital digest; and the consistency of the first digital digest and the second digital digest is verified. In this verification method, the access control policy information can include the first digital digest, without having to use a public key to decrypt the signature to obtain the first digital digest.

[0169] In an embodiment of the present application, the access control policy information can be hashed to obtain a second digital digest, and the second digital digest can be compared with the first digital digest to verify the authenticity and integrity of the first diagnostic policy file. In this way, only when the authenticity and integrity verification of the first diagnostic policy file are passed, the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control authority, which can further protect the user's property and privacy security.

[0170] In combination with the first aspect, in certain implementations of the first aspect, verifying the authenticity and integrity of the first diagnostic strategy file includes: verifying whether the first vehicle identity information matches the vehicle, and the vehicle is the vehicle on which the diagnostic command is to be executed.

[0171] For example, the first vehicle identification information is a vehicle identification number. The first vehicle identification number can be compared with the vehicle identification code to determine whether the first vehicle identification number matches the vehicle. If the two match, verification is successful; if the two do not match, verification fails. The vehicle identification code can be viewed on the front bulkhead of the vehicle's engine compartment or on the vehicle's dashboard.

[0172] In an embodiment of the present application, the authenticity and integrity of the first diagnostic strategy file can be verified by determining whether the first vehicle identity information matches the vehicle. In this way, only when the authenticity and integrity of the first diagnostic strategy file are verified, the access control policy information in the first diagnostic strategy file is used to verify whether the diagnostic command has access control authority, which can further protect the user's property and privacy security.

[0173] In combination with the first aspect, in some implementations of the first aspect, before receiving the first diagnostic strategy file sent by the diagnostic device, the method also includes: receiving a second diagnostic strategy file sent by the diagnostic device, the second diagnostic file including: a third timestamp; verifying the authenticity and integrity of the first diagnostic strategy file includes: verifying whether the first timestamp is greater than the third timestamp.

[0174] Among them, the time when the vehicle receives the second diagnostic strategy file is earlier than the time when the first diagnostic strategy file is received. The second diagnostic strategy file can be the diagnostic strategy file used when the diagnostic command was last executed, or it can be a diagnostic strategy file that has not been used yet. The purpose of verifying whether the first timestamp is greater than the third timestamp is to determine whether the first diagnostic strategy file has been reused or replayed. If the first timestamp is less than the third timestamp, it means that the first diagnostic strategy file may have been reused or replayed, and the strategy file is not authentic. If the first timestamp is greater than the third timestamp, the authenticity and integrity verification of the first diagnostic strategy file is passed.

[0175] In this embodiment of the present application, the relationship between the first and third timestamps is verified to determine whether the first diagnostic policy file has been reused or subjected to a replay attack. If the verification is successful, the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permission, thereby further protecting the user's property and privacy.

[0176] In combination with the first aspect, in some implementations of the first aspect, verifying the authenticity and integrity of the first diagnostic strategy file includes: determining whether the difference between the first timestamp and the vehicle local time is less than or equal to a preset threshold.

[0177] If the difference between the first timestamp and the vehicle's local time is less than or equal to a preset threshold, the authenticity and integrity verification of the first diagnostic strategy file passes. If the difference between the first timestamp and the vehicle's local time is greater than a preset threshold, it indicates that the first diagnostic strategy file may be reused or replayed.

[0178] In this embodiment, the relationship between the first timestamp and the vehicle's local time is verified to determine whether the first diagnostic policy file has been reused or subjected to a replay attack. If verification is successful, the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, further protecting the user's property and privacy.

[0179] It should be understood that the above-mentioned methods of verifying the authenticity and integrity of the first diagnostic strategy file can be used individually or in combination. For example, the method of verifying whether the first vehicle identity information matches the vehicle can be used alone. When used alone, if it is determined that the first vehicle identity information matches the vehicle, the authenticity and integrity verification of the first diagnostic strategy file passes. For another example, the consistency verification of the first digital digest and the second digital digest can be performed first, and then the verification of whether the first vehicle identification number matches the vehicle can be performed. If both verifications pass, the authenticity and integrity verification of the first diagnostic strategy file passes.

[0180] It should also be understood that when different verification methods are used in combination, the execution order of each verification method can be sequential or simultaneous.

[0181] S503: If the authenticity and integrity of the first diagnosis policy file are verified, verify whether the diagnosis command has access control authority according to the access control policy information.

[0182] In this embodiment of the present application, before a vehicle executes a diagnostic command, it can use the access control policy information in the first diagnostic policy file to verify whether the diagnostic command has access control permissions. The diagnostic command is only executed if it has access control permissions. This prevents the vehicle from executing erroneous or illegal diagnostic commands, protecting the user's property and privacy.

[0183] There are many implementation methods for using the access control policy information to verify whether the diagnostic command has the access control permission.

[0184] In one possible implementation, the access control policy information includes: a validity period, and verifying whether the diagnostic command has access control authority based on the access control policy information includes: using the access control policy information to verify whether the diagnostic command has access control authority within the validity period.

[0185] In the embodiment of the present application, only when the diagnosis policy file is within the validity period, the access control policy information in the diagnosis policy file is used to verify whether the diagnosis command has the access control authority. In this way, the diagnosis policy file can be prevented from being used after it expires, thereby improving the security of the use of the diagnosis policy file.

[0186] In one possible implementation, the access control policy information also includes: first vehicle identity information, and verifying whether the diagnostic command has access control authority based on the access control policy information includes: verifying whether the first vehicle identity information is consistent with the second vehicle identity information, and the diagnostic command includes the second vehicle identity information.

[0187] Among them, the first vehicle identity information can be information used to represent the vehicle identity, which may include but is not limited to the vehicle identification number. When the first vehicle identity information in the access control policy information is consistent with the diagnostic command, it can be determined that the diagnostic command has access control authority.

[0188] In an embodiment of the present application, by verifying whether the first vehicle identity information is consistent with the second vehicle identity information, it is verified whether the diagnostic command has access control authority, which can further ensure the user's property safety and privacy security.

[0189] In a possible implementation, the first vehicle identity information and / or the second vehicle identity information is a vehicle identification number.

[0190] In one possible implementation, the access control policy information also includes: a first identification ID, the first identification ID includes: at least one of: a first electronic control unit ID, a first CAN ID, a first diagnostic service ID and a first diagnostic data ID; the use of the access control policy information to verify whether the diagnostic command has access control authority includes: verifying whether the first identification ID is consistent with a second identification ID, the second identification ID is the identification ID in the diagnostic command, and the second identification ID includes: at least one of: a second electronic control unit ID, a second CAN ID, a second diagnostic service ID and a second diagnostic data ID.

[0191] Only when the first identification ID and the second identification ID are consistent, the diagnostic command can be effective for the corresponding electronic control unit or the vehicle can use the corresponding diagnostic service or diagnostic data.

[0192] Among them, the second electronic control unit ID can be the ID of the electronic control unit targeted by the diagnostic command, the second CAN ID can represent the address or name of the CAN node that sends and receives the diagnostic command, the second diagnostic service ID can be the service ID required for performing the diagnostic command, and the second diagnostic data ID can be the data ID required for performing the diagnostic service or diagnostic command.

[0193] In an embodiment of the present application, the diagnostic command can only take effect on the corresponding electronic control unit or the vehicle can use the corresponding diagnostic service or diagnostic data when the first identification ID in the diagnostic command and the second identification ID in the access control policy information are consistent. In this way, a diagnostic access control mechanism for vehicles and components and an access mechanism for diagnostic services are provided, thereby ensuring the security and effectiveness of the diagnostic commands.

[0194] In a possible implementation, the access control policy information further includes: a first timestamp, and the use of the access control policy information to verify whether the diagnostic command has access control authority includes: verifying whether a second timestamp is greater than the first timestamp, and the second timestamp is the timestamp of the diagnostic command.

[0195] Wherein, when the second timestamp is greater than the first timestamp, the diagnostic command has access control authority; when the second timestamp is less than the first timestamp, the diagnostic command does not have access control authority.

[0196] Optionally, in this implementation, it can be set that when the second timestamp is greater than the first timestamp and the execution time of the diagnostic task is within the validity period of the access control policy information, the diagnostic command has the access control permission.

[0197] It should be understood that the purpose of ensuring that the timestamp of the diagnostic task is greater than the timestamp of the access control policy information in this step is to prevent the diagnostic task from being reused or replayed, that is, it is necessary to ensure that the time when the vehicle receives the diagnostic command is later than the time when it receives the diagnostic policy file.

[0198] In the embodiment of the present application, by verifying whether the second timestamp is greater than the first timestamp, the diagnostic task is prevented from being reused or replayed, which can further ensure the user's property safety and privacy security.

[0199] It should be understood that method 500 introduces the process of verifying the validity of the diagnostic command using the first diagnostic strategy file with the vehicle as the main body. The vehicle can be a shared taxi or a private car, or the vehicle in method 500 can also be replaced with a charging station for home or commercial smart cars.

[0200] The following describes the process of generating and issuing the first diagnostic strategy file based on the diagnostic platform or authorization management system.

[0201] An embodiment of the present application provides another diagnostic method, which is applied to a diagnostic device, wherein the diagnostic device includes: a remote diagnostic platform or a proximal diagnostic instrument, and the method includes: sending a first request message to an authorization management system, wherein the first request message is used to request the authorization management system to generate a first diagnostic policy file, wherein the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; receiving the first diagnostic policy file sent by the authorization management system; and sending the first diagnostic policy file to a vehicle, wherein the vehicle is the vehicle on which the diagnostic command is to be executed.

[0202] In an embodiment of the present application, the diagnostic device receives a first diagnostic strategy file from the authorization management system and forwards it to the vehicle, so that subsequent vehicles can use the first diagnostic strategy file to verify whether the diagnostic command has access rights.

[0203] In one possible implementation, before sending the first request information to the authorization management system, the method also includes: obtaining the identity information of the diagnostic personnel; sending the identity information of the diagnostic personnel to the authorization management system; sending the first request information to the authorization management system includes: upon receiving the first response information sent by the authorization management system, sending the first request information to the authorization management system, the first response information being used to indicate that the identity authentication of the diagnostic personnel is successful.

[0204] The diagnostician's identity information can take various forms. For example, the diagnostician's identity information can be account information. This account information can be created by the OEM, and the account and password can be assigned to the diagnostician, who then enters the account and password on the diagnostic platform or instrument. Another example is the diagnostician's facial feature information. The OEM can pre-enter the facial feature information of qualified diagnosticians into the diagnostic instrument or platform, and the diagnostician needs to log in by verifying the facial feature information on the diagnostic platform or instrument. Furthermore, this identity information can also be the diagnostician's iris feature information or voiceprint feature information, etc., which will not be elaborated here.

[0205] In an embodiment of the present application, a diagnostician needs to log in to the diagnostic platform before conducting a diagnosis. The diagnostic device needs to send the diagnostician's identity information to the authorization management system for verification. After receiving the successful verification information from the authorization management system, the diagnostic device can request the authorization management system to send the first diagnostic policy file. In this way, an identity verification mechanism for diagnosticians is provided, which can prevent the diagnostic platform or diagnostic instrument from being abused or maliciously diagnosed by illegal personnel, resulting in infringement of the user's privacy, property, and life safety.

[0206] In one possible implementation, the first diagnostic strategy file includes: a second key. Before sending the first diagnostic strategy file to the vehicle, the method further includes: storing the second key in the diagnostic device, which is the proximal diagnostic instrument.

[0207] In the embodiment of the present application, the diagnostic device can obtain the second key from the first diagnostic strategy file and save the second key to the diagnostic device to facilitate subsequent vehicle verification of the consistency of the first key and the second key.

[0208] In one possible implementation, the method further includes: receiving a second key sent by a key management system, storing the second key in the diagnostic device, and sending the first key to a vehicle, where the vehicle is to execute the diagnostic command.

[0209] An embodiment of the present application provides another diagnostic method, which is applied to an authorization management system. The method includes: receiving a first request message sent by a diagnostic device, generating a first diagnostic policy file based on the first request message, the first diagnostic policy file being used to verify whether the diagnostic command has access control authority; and sending the first diagnostic policy file to the diagnostic device.

[0210] In one possible implementation, before receiving the first request information sent by the diagnostic device, the method further includes: receiving the identity information of the diagnostic personnel sent by the diagnostic device; and when the identity information of the diagnostic personnel is consistent with the identity information preset in the authorization management system, sending a first response information to the diagnostic device, wherein the first response information is used to indicate that the identity authentication of the diagnostic personnel is successful.

[0211] Verifying the diagnostician's identity information can also be done in a variety of ways. For example, if the diagnostician's identity information is account information, the authorization management system needs to verify the account number and password entered by the diagnostician. Upon successful verification, it sends a first response message to the diagnostic device to inform the diagnostician that the identity verification is successful. For another example, if the diagnostician's identity information is facial feature information, the authorization management system can compare the facial feature information with facial feature information preset in the system. Upon successful verification, it sends a first response message to the diagnostic device to inform the diagnostician that the identity verification is successful.

[0212] In an embodiment of the present application, after receiving the identity information of the diagnostic personnel sent by the diagnostic platform, the authorization management system can verify the identity information and then identify the legitimacy of the diagnostic user. Only when the identity of the diagnostic user is legitimate will the first diagnostic strategy file be sent to the diagnostic device. In this way, an identity authentication mechanism for the diagnostic personnel is provided before the diagnosis is performed, which can prevent the diagnostic platform or diagnostic instrument from being abused or maliciously diagnosed by illegal persons, resulting in infringement of the user's privacy, property and life safety.

[0213] FIG6 is a system architecture 600 applicable to a diagnostic method provided in an embodiment of the present application. The system architecture 600 may be a system architecture applicable to the method 500 .

[0214] As shown in FIG6 , the system architecture 600 may include: a cloud server 610 , a remote diagnostician 620 , a diagnostic instrument 630 , a local diagnostician 640 , a vehicle-side authorization module 650 and a vehicle 660 .

[0215] The cloud server 610 may also include a remote diagnostic platform 611 and an authorization management system 612. The remote diagnostic platform 611 includes a user login module 613, and the authorization management system 612 includes a user management module 614 and a policy generation module 615. The diagnostic instrument 630 includes a user login module 631. The vehicle 660 includes a policy management module 661. Vehicle 600 may be vehicle 200 in FIG. 2 .

[0216] Before implementing the diagnostic method through the system architecture 600, the following settings need to be performed:

[0217] (1) Create a character

[0218] OEMs can create roles using the role creation method shown in Figure 7. As shown in Figure 7, OEMs can create roles based on a role-based access control (RBAC) system 700. The RBAC system may include: system administrator 701, security administrator 702, and audit administrator 703. System administrator 701 may be responsible for creating roles, security administrator 702 may be responsible for authorizing created roles, and audit administrator 703 may be responsible for verifying role creation and authorization. In other words, the authorization of these three roles in the RBAC system represents a separation of powers.

[0219] In the process of creating roles using the RBAC system, the system management administrator 701 can create the role type, the security administrator 702 can grant corresponding permissions to different types of roles, and then the audit administrator 703 can check them.

[0220] For example, a remote diagnosis role and a local diagnosis role can be created through the RBAC system. The remote diagnosis role grants diagnostic service permissions with only read functions (for example, read-only security identifier (SID) permissions), and the local diagnosis role grants diagnostic service permissions that can both read and write (for example, read and write SID permissions).

[0221] It should be understood that RBAC is a type of authorization management system 612 in FIG. 6 . RBAC is merely an exemplary description, and other authorization management systems may also be used to create roles.

[0222] (2) Create a user

[0223] OEMs can create user accounts for diagnosticians and assign them roles when creating them. These roles grant them access to the corresponding diagnostic services. OEMs can also configure vehicle resource permissions for each account, defining which vehicle models and components the user can diagnose.

[0224] For example, it can be set that an OEM-type diagnostician can diagnose the entire vehicle components of a first model, while a supplier-type diagnostician can diagnose specific components of the first model.

[0225] (3) Owner authorization

[0226] Before the diagnosis begins, the car owner can provide authorization for a certain period of time through online / offline service agreements or by phone to meet privacy compliance requirements.

[0227] For example, before a diagnosis begins, the vehicle owner must sign or select a diagnostic service agreement. Only after the vehicle detects that the owner has signed or selected the agreement can the vehicle perform the diagnostic task. The diagnostic service agreement may include, but is not limited to, the diagnostic object, diagnostic permissions, and the resources required to perform the diagnostic task.

[0228] For another example, before the diagnosis begins, the vehicle owner may request a vehicle diagnosis by phone, in which case it can be assumed that the vehicle owner agrees to the diagnostic service agreement.

[0229] In the actual application of the diagnostic method 500 system architecture, remote diagnostician 620 needs to log in through user login module 631 and have their identity verified by user management module 614. After successful authentication, policy generation module 615 can generate a diagnostic policy file and distribute it to vehicle 600 via remote diagnostic platform 611. Similarly, local diagnostician 640 needs to log in through user login module 631 and have their identity verified by user management module 614. After successful authentication, policy generation module 615 generates a diagnostic policy file and distributes it to vehicle 600 via diagnostic instrument 630.

[0230] After the vehicle 600 receives the diagnostic policy file, the diagnostic policy file can be checked by the policy control module 661. At the same time, before performing the diagnosis, the owner can manage the diagnostic policy file from the perspective of privacy compliance through the owner authorization module 650.

[0231] In the embodiment of the present application, when the diagnostic personnel conducts diagnosis, they need to log in to the corresponding account on the diagnostic platform or diagnostic instrument, and the identity of the diagnostic personnel is verified by the authorized platform. Only after the identity authentication is successful can the diagnostic platform or diagnostic instrument issue a diagnostic strategy file to the vehicle. In this way, the risk of the diagnostic platform or diagnostic instrument being abused or maliciously diagnosed by illegal persons can be reduced, thereby protecting the user's privacy, property and life safety.

[0232] The execution process of remote diagnosis is described in detail below with reference to FIG8 to FIG10.

[0233] FIG8 is a remote diagnosis method 800 provided in an embodiment of the present application. The method 800 can be applied to the system architecture of FIG6 .

[0234] Before executing method 800, vehicle information synchronization and diagnostic data configuration are required. Vehicle information synchronization may include the vehicle sending vehicle model data, individual vehicle data, and component data to a cloud server, which then completes vehicle information synchronization. The diagnostic data configuration process may include the diagnostic platform determining the corresponding vehicle model based on this data, generating a diagnostic script, and generating diagnostic data.

[0235] The diagnostic script may include a diagnostic script for a vehicle component and / or a diagnostic script for a vehicle model, and the diagnostic data may include at least one of a component diagnostic data ID, a diagnostic fault code, and a component diagnostic parameter.

[0236] After completing the above preparations, method 800 may be executed. Method 800 may include the following steps:

[0237] S801, the diagnostic user enters the user name and password to log in

[0238] Specifically, the diagnostic user enters the account username and password created by the OEM on the diagnostic platform to log in.

[0239] S802: The authorization management system authenticates the user name and password

[0240] Specifically, the authorization management system 612 can authenticate the user name and password entered by the diagnostician in step S801. If the authentication is successful, step S803 is performed. If the authentication fails, the diagnostic user is prompted with a login failure and the diagnostic process ends.

[0241] S803, after successful login, the diagnostic user enters the menu of corresponding authority

[0242] Specifically, the diagnostic user can view the diagnostic permissions in the permission menu. The diagnostic user can only issue diagnostic policies within the permissions. Diagnostic policies issued beyond the permissions are invalid.

[0243] S804, select the vehicle model and parts to be diagnosed

[0244] Specifically, the diagnostic user selects the vehicle model and components that need to be diagnosed.

[0245] S805: The authorization management system generates a diagnosis policy file based on the diagnosis user's selection and sends it to the vehicle.

[0246] The diagnostic policy file can be used to check the authenticity and integrity of the diagnostic instructions.

[0247] S806: The user selects a diagnostic function and the system generates a corresponding diagnostic task.

[0248] The diagnostic function may be generated by a diagnostic script, and the diagnostic function may include: reading fault codes, clearing fault codes, scanning the entire vehicle, component judgment, and one or more of other diagnoses.

[0249] S807: The diagnostic task is sent to the vehicle and executed

[0250] Specifically, in step S806, after the diagnostic user selects the diagnostic function, the diagnostic platform generates a diagnostic task and sends the diagnostic task to the vehicle side for execution.

[0251] S808: The execution result is returned to the diagnosis platform.

[0252] Specifically, after completing the diagnostic task, the vehicle can report the execution results and execution data to the diagnostic platform, which will compare the execution results and diagnostic data to analyze the vehicle's execution of the diagnostic task.

[0253] In this embodiment of the application, the identity of the diagnostician must be verified before remote diagnosis can be performed. Only if the diagnostician's identity meets the requirements can the diagnostician issue diagnostic instructions or diagnostic strategy files to the vehicle through the diagnostic platform within the scope of their authority. This prevents unauthorized manipulation of the vehicle and its components by personnel outside of their diagnostic authority, thereby improving the security of remote diagnosis.

[0254] FIG9 is a method 900 for generating and issuing a diagnostic strategy file during a remote diagnosis process provided by an embodiment of the present application. The method 900 may be the specific process of step S805 in FIG8 , and the method 900 may include the following steps.

[0255] S901, the diagnostic platform generates a diagnostic strategy request scope

[0256] Specifically, the diagnosis policy request scope may include: authorization type, diagnosis target, diagnosis validity period, etc.

[0257] S902: The diagnostic platform submits an authorization request to the authorization management system.

[0258] Specifically, the diagnosis platform sends authorization request information to the authorization management system, which is used to request the diagnosis authorization management system to generate and return a diagnosis policy file according to the diagnosis policy request scope. The authorization request information can be the first request information in method 500.

[0259] S903: The authorization management system generates a diagnostic strategy file

[0260] Specifically, the authorization management system generates a diagnosis policy file according to the authorization request information. The specific content of the diagnosis policy file is introduced in detail in FIG. 14 .

[0261] S904: Perform integrity protection on the diagnostic strategy file

[0262] The purpose of integrity protection of the diagnosis policy file is to prevent the diagnosis policy file from being illegally tampered with. The integrity protection of the diagnosis policy file can be achieved by signing the diagnosis policy file.

[0263] S905: Return the diagnostic strategy file to the diagnostic platform

[0264] S906: The diagnostic platform sends the diagnostic strategy file to the vehicle-side diagnostic module.

[0265] Among them, the vehicle-side diagnostic module can be the diagnostic client module 131 in Figure 1.

[0266] S907: The vehicle-side diagnostic module verifies the authenticity and integrity of the diagnostic strategy file.

[0267] Specifically, the detailed process of the vehicle-side diagnostic module verifying the authenticity and integrity of the diagnostic strategy file is detailed in Figure 15.

[0268] S908, the vehicle-side diagnostic module stores the diagnostic strategy file in the vehicle after the verification is passed.

[0269] In an embodiment of the present application, the authorization management system can generate and send a diagnostic policy file to the vehicle side according to the policy request scope of the diagnostic platform. The vehicle-side diagnostic module can store the diagnostic policy file after authenticity and integrity verification to facilitate subsequent detection and verification of diagnostic instructions.

[0270] FIG10 is a method 1000 for issuing and executing diagnostic tasks during a remote diagnosis process provided by an embodiment of the present application. The method 1000 may be a specific process of step S807 in FIG8 . The method 1000 may include the following steps.

[0271] S1001, the diagnostic platform performs integrity protection on diagnostic tasks or commands

[0272] Specifically, the purpose of the diagnostic platform performing integrity protection on diagnostic tasks or diagnostic commands is to prevent the diagnostic tasks or commands from being illegally tampered with. The specific implementation method can be to perform integrity protection on the diagnostic tasks or commands through encryption or other means when the diagnostic platform and the vehicle establish a communication channel.

[0273] S1002: The diagnostic platform sends the diagnostic task or command to the vehicle-side diagnostic module.

[0274] Specifically, the vehicle-side diagnostic module may be the diagnostic module 130 in FIG. 1 .

[0275] S1003, the vehicle-side diagnostic module checks the diagnostic task and command integrity

[0276] S1004: The vehicle-side diagnostic module verifies the validity of the diagnostic task or command through the diagnostic strategy file.

[0277] Specifically, the process of the vehicle-side diagnostic module verifying the diagnostic task or command through the diagnostic strategy file is described in detail in FIG16 .

[0278] It should be understood that this step can also be understood as using the diagnosis policy file to verify whether the diagnosis task or the diagnosis command has access control permission.

[0279] S1005: After verification, the vehicle-side diagnostic module sends a command to the corresponding ECU for execution.

[0280] Specifically, after the diagnostic task or command is verified using the diagnostic strategy file, the vehicle-side diagnostic module can send the diagnostic command to the ECU for execution through the diagnostic agent module 133.

[0281] S1006, the ECU returns the diagnostic results to the vehicle-side diagnostic module

[0282] Specifically, after executing the diagnosis command, the ECU may return the diagnosis result to the diagnosis agent module 133 .

[0283] S1007: The vehicle-side diagnostic module returns the diagnostic results to the diagnostic platform through the diagnostic client.

[0284] Specifically, the diagnosis agent module 133 may send the diagnosis result to the diagnosis platform through the diagnosis client module 131 .

[0285] In the embodiment of the present application, a diagnostic strategy file can be used to check the diagnostic task or diagnostic command. Only after the check passes can the vehicle's ECU receive and execute the corresponding diagnostic task or command. In this way, the authenticity and integrity of the execution of the diagnostic task or diagnostic command can be guaranteed on the vehicle side.

[0286] The execution process of the proximal diagnosis is described in detail below with reference to FIG11 to FIG13.

[0287] FIG11 is a proximal diagnosis method 1100 provided in an embodiment of the present application. The method 1100 may be applied to the system architecture of FIG6 . The method 1100 may include the following steps.

[0288] S1101, diagnostic user locally unlocks the online diagnostic instrument

[0289] S1102, enter the authorized user name and password

[0290] Specifically, the user name and password may be a user name and password that the OEM has configured for the diagnostic user.

[0291] S1103, the diagnostic authorization management system performs identity authentication

[0292] Specifically, after the diagnostic user enters the user name and password, the authorization management system can verify the identity of the diagnostic user. If the verification is successful, step S1104 is executed. If the verification is unsuccessful, the user is prompted with a login failure or steps S1107 to S1109 are executed in sequence.

[0293] S1104, after successful login, select the vehicle model and parts to be diagnosed

[0294] Specifically, after successfully logging in, the diagnostician can select the vehicle model and vehicle parts that need to be diagnosed within the scope of authority.

[0295] S1105: The diagnostic authorization management system generates a diagnostic strategy file and sends it to the vehicle via the diagnostic instrument.

[0296] S1106, select diagnostic function

[0297] Specifically, the diagnostic user can select a diagnostic function on the diagnostic instrument. These functions may include one or more of: reading fault codes, clearing fault codes, scanning the entire vehicle, component diagnosis, and other diagnostic functions. Since the diagnostic user has already completed identity verification, selecting these diagnostic functions also grants them read and write permissions. After selecting a diagnostic function, the user can proceed directly to step S1108.

[0298] S1107, select diagnostic function

[0299] Specifically, when the diagnostic user fails to log in or does not log in, the authority and menu for selecting the diagnostic function are different from those when the user logs in successfully.

[0300] For example, if in step S1102, the diagnostic user operates the diagnostic instrument to select a diagnostic function when the login fails or the user is not logged in, the diagnostic user can only obtain read-only permissions. The diagnostic functions that can be selected may include: reading fault codes, scanning the entire vehicle, and performing other diagnostic functions.

[0301] S1108, the diagnostic command is sent to the vehicle and executed

[0302] Specifically, the diagnostic instrument sends a diagnostic command to the vehicle, and the ECU in the vehicle executes it.

[0303] S1109, the diagnosis result is returned to the diagnostic instrument

[0304] Specifically, after executing the diagnostic command, the vehicle returns the diagnostic result to the diagnostic instrument.

[0305] In an embodiment of the present application, before performing proximal diagnosis, it is necessary to verify the identity information of the diagnostician. If the identity information of the diagnostician complies with the regulations, the diagnostician can select more diagnostic functions and obtain greater diagnostic authority. In this way, different types of diagnostic personnel can be granted corresponding diagnostic authority, ensuring that different types of diagnostic personnel issue diagnostic commands within the corresponding authority scope.

[0306] Figure 12 is a method 1200 for generating and issuing a diagnostic strategy file during a proximal diagnosis process provided by an embodiment of the present application. The method 1200 may be a specific process of step S1105 in Figure 11 , and the method 1200 may include the following steps.

[0307] S1201, diagnostic instrument generates strategy request scope

[0308] Specifically, the diagnosis policy request scope may include: authorization type, diagnosis target, diagnosis validity period, etc.

[0309] S1202: The diagnostic instrument submits an authorization request to the authorization management system.

[0310] Specifically, the diagnostic instrument sends authorization request information to the authorization management system, which is used to request the diagnostic authorization management system to generate and return a diagnostic policy file according to the diagnostic policy request range. The authorization request information can be the first request information in method 500.

[0311] S1203: The authorization management system generates a diagnostic strategy file

[0312] Specifically, the authorization management system generates a diagnosis policy file according to the authorization request information. The specific content of the diagnosis policy file is introduced in detail in FIG. 14 .

[0313] S1204: Perform integrity protection on the diagnostic strategy file

[0314] The purpose of integrity protection for the diagnosis policy file is to prevent the diagnosis policy file from being illegally tampered with. The integrity protection of the diagnosis policy file can be achieved by setting a signature for the diagnosis policy file.

[0315] S1205, return the diagnostic strategy file to the diagnostic instrument

[0316] S1206: The diagnostic instrument forwards the diagnostic strategy file to the vehicle-side diagnostic module.

[0317] S1207: The vehicle-side diagnostic module verifies the authenticity and integrity of the diagnostic strategy file.

[0318] Specifically, the detailed process of the vehicle-side diagnostic module verifying the authenticity and integrity of the diagnostic strategy file is introduced in Figure 15.

[0319] S1208: The vehicle diagnostic module stores the diagnostic strategy file in the vehicle after the verification is passed.

[0320] In an embodiment of the present application, the authorization management system can generate and send a diagnostic policy file to the vehicle side according to the policy request range of the diagnostic instrument. The vehicle-side diagnostic module can store the diagnostic policy file after performing an integrity check to facilitate subsequent detection and verification of diagnostic commands.

[0321] FIG13 is a method 1300 for issuing and executing diagnostic tasks during a proximal diagnosis process provided by an embodiment of the present application. The method 1300 may be a specific process of step S1106 or S1107 in FIG11 , and the method 1300 may include the following steps.

[0322] S1301, the diagnostic instrument performs integrity protection on the diagnostic task or command

[0323] Specifically, the purpose of the diagnostic instrument performing integrity protection on the diagnostic task or diagnostic command is to prevent the diagnostic task or command from being illegally tampered with.

[0324] S1302: The diagnostic instrument sends the diagnostic task or command to the vehicle-side diagnostic module.

[0325] Among them, the vehicle-side diagnostic module can be the diagnostic module 130 in Figure 1.

[0326] S1303, the vehicle-side diagnostic module checks the diagnostic task and command integrity

[0327] Specifically, the detailed process of the vehicle-side diagnostic module performing integrity verification on the diagnostic strategy file is introduced in Figure 15.

[0328] S1304: The vehicle-side diagnostic module checks the diagnostic task or command through the diagnostic strategy file.

[0329] Specifically, the process of the vehicle-side diagnostic module checking the diagnostic task or command through the diagnostic strategy file is introduced in detail in Figure 16.

[0330] It should be understood that this step can also be understood as using the diagnosis policy file to verify whether the diagnosis task or the diagnosis command has access control permission.

[0331] S1305, after the inspection is passed, the vehicle-side diagnostic module sends a command to the corresponding ECU and executes

[0332] Specifically, after the diagnostic task or command is checked and passed using the diagnostic strategy file, the vehicle-side diagnostic module can send the diagnostic command to the ECU for execution through the diagnostic agent module 133.

[0333] S1306, ECU returns the diagnosis result to the vehicle-side diagnosis module

[0334] Specifically, after executing the diagnosis command, the ECU may return the diagnosis result to the diagnosis agent module 133 .

[0335] S1307, the vehicle-side diagnostic module returns the diagnostic results to the diagnostic instrument through the diagnostic client

[0336] Specifically, the diagnosis agent module 133 may send the diagnosis result to the diagnosis instrument through the diagnosis client module 131 .

[0337] In this embodiment of the present application, a diagnostic strategy file can be used to check diagnostic tasks or diagnostic commands. Only after the check passes can the vehicle's ECU receive and execute the corresponding diagnostic task or command. In this way, the validity and legality of the execution of the diagnostic task or diagnostic command can be guaranteed on the vehicle side.

[0338] FIG14 is a schematic diagram of a diagnosis strategy file format provided in an embodiment of the present application. The diagnosis strategy file shown in FIG14 may be the diagnosis strategy file in FIG8 to FIG13 .

[0339] Diagnostic strategy files are involved in both remote diagnosis and local diagnosis processes. The role of the diagnostic strategy file is that before executing the diagnostic command, the vehicle-side diagnostic module uses the diagnostic strategy file to check whether the diagnostic command is valid in time and space. That is, the diagnostic service must diagnose the authorized ECU within the authorized time and space range.

[0340] As shown in Figure 14, the format of the diagnostic file may include: authorization type, spatial domain, time domain, version, signature and certificate. Among them, the authorization type may refer to the type of diagnostic policy file, for example, the type of diagnostic policy file may refer to proximal diagnosis or remote diagnosis. The authorization type may indicate that multiple diagnostic policy files of the same type can coexist, for example, diagnostic policy files for proximal diagnosis and remote diagnosis coexist. It may also indicate that a specific diagnostic policy file type is effective, for example, when diagnostic policy files for proximal diagnosis and remote diagnosis coexist, the proximal diagnostic policy file may be effective and the remote diagnostic policy file may be invalid.

[0341] The spatial domain can check the legitimacy of the diagnostic target, and the verification of the spatial domain can include: at least one of the vehicle identification number (VIN) verification, ECU verification, CAN ID verification, diagnostic service ID verification and data ID verification. The time domain can be used to monitor the validity of the diagnostic time, and the time domain verification can include: checking whether the timestamp of the monitoring script is within the authorized time range and whether the monitoring diagnostic strategy file itself is valid. The version can refer to the format version of the diagnostic strategy file, and the version record can facilitate future updates to the format file. The signature can refer to the signature of the cloud-based authorization management system, which can be verified on the vehicle side. If the verification is passed, the authenticity and integrity of the diagnostic strategy file itself are guaranteed.

[0342] It should be understood that the authorization type, spatial domain, time domain, version, signature and certificate in the above-mentioned diagnosis policy file can also be reflected in the access control policy information in the diagnosis policy file.

[0343] In an embodiment of the present application, the format of the diagnostic strategy file can be set, so that the diagnostic strategy file can be used to check whether the diagnostic command is valid in time and space, thereby ensuring the validity and legality of the execution of the diagnostic task or diagnostic command on the vehicle side.

[0344] FIG15 is a flowchart 1500 of the authenticity and integrity verification of a diagnostic policy file according to an embodiment of the present application. The method 1500 can be applied to step S907 in FIG9 or step S1207 in FIG12.

[0345] Because the diagnostic strategy file is automatically generated and distributed by the diagnostic instrument or platform based on the diagnostic objectives and functions selected by the diagnostician, and is automatically used on the vehicle to check and control diagnostic commands, the vehicle can verify the authenticity and integrity of the diagnostic strategy file upon receipt and, upon successful verification, store the file in the vehicle. This eliminates the need for extensive human involvement throughout the process, reducing the risk of diagnosticians exceeding their authority.

[0346] The integrity verification and authenticity verification of the diagnosis strategy file may include the following steps.

[0347] S1501, Verify Certificate

[0348] Specifically, after receiving the diagnostic strategy file, the vehicle verifies whether the certificate in the diagnostic strategy file is valid. If the certificate is valid, step S1502 is performed; if the certificate is invalid, the integrity and authenticity verification process of the diagnostic strategy file is terminated.

[0349] S1502, decrypt the signature using the certificate public key to obtain a digital summary

[0350] Specifically, the vehicle uses the public key in its certificate to decrypt the signature of the diagnostic policy file, generating a digital digest. This digital digest is a ciphertext of a fixed length (128 bits) generated using a one-way hash function. The digital digest is derived from a hash algorithm and is also known as a hash value.

[0351] S1503, get new summary

[0352] Specifically, the vehicle performs hash calculations on the authorization type, spatial domain, time domain, and version in the diagnostic policy file to obtain a new summary.

[0353] S1504: Compare the two summaries to see if they are the same.

[0354] Specifically, the vehicle compares the summary and the new summary to determine whether they are the same. If they are the same, the process proceeds to step S1505 . If they are not the same, the integrity and authenticity verification process of the diagnostic strategy file ends.

[0355] It should be understood that since the digital digest is a fixed-length value corresponding to a message or a text, if the diagnostic strategy file received by the vehicle is tampered with during the transmission process, the new digest obtained after the vehicle performs the same hash calculation on the received diagnostic strategy file will be different from the original digest. Therefore, the authenticity and integrity of the diagnostic strategy file can be verified by comparing whether the two digests are the same.

[0356] S1505, determine whether the diagnostic strategy file matches the vehicle through the VIN

[0357] Specifically, whether the measurement file and the vehicle match can be determined by checking whether the VIN of the diagnostic strategy file is consistent with the VIN of the vehicle. If they match, step S1506 is performed; if they do not match, the integrity and authenticity verification process of the diagnostic strategy file is terminated.

[0358] S1506: Verify the timestamp of the diagnosis policy file and the timestamp stored locally

[0359] Specifically, the timestamp of the diagnostic policy file is compared with the locally stored timestamp, where the locally stored timestamp may refer to the timestamp of the last time the vehicle received the diagnostic policy file. If the timestamp of the diagnostic policy file is greater than or equal to the locally stored timestamp, the integrity and authenticity verification of the diagnostic policy file is passed, and the vehicle stores the diagnostic policy file in the vehicle and begins calculating the validity period of the diagnostic policy file. If the timestamp of the diagnostic policy file is less than the locally stored timestamp, the integrity and authenticity verification process of the diagnostic policy file is terminated.

[0360] It should be understood that the purpose of verifying the timestamp of the diagnosis policy file and the locally stored timestamp is to prevent the diagnosis policy file from being reused or replayed. If the timestamp of the diagnosis policy file is less than the timestamp of the locally stored timestamp, it means that the diagnosis policy file may have been modified and the diagnosis policy file is not authentic.

[0361] Alternatively, this step may be replaced by verifying whether the difference between the timestamp parameter of the diagnostic strategy file and the vehicle local time is less than or equal to a preset threshold. If so, the verification passes; if greater than the preset threshold, the verification fails.

[0362] In an embodiment of the present application, after receiving the diagnostic strategy file, the vehicle can verify the authenticity and integrity of the diagnostic strategy file itself, and store the diagnostic strategy file in the vehicle after successful verification, thereby facilitating the subsequent use of the diagnostic strategy file to check the diagnostic command.

[0363] FIG16 is a method 1600 for managing diagnostic tasks or diagnostic commands using a policy file according to an embodiment of the present application. The method 1600 can be applied to step S1004 in FIG10 or step S1304 in FIG13 , and can include the following steps.

[0364] S1601: Compare the VINs in the diagnostic task and the diagnostic strategy file to see if they are consistent.

[0365] Specifically, in this step, the diagnostic task VIN can be compared with the VIN in the diagnostic strategy file to determine whether it matches the vehicle. If they are consistent, step S1602 is performed; if not, the diagnostic task execution process is terminated.

[0366] Optionally, during the proximal diagnosis process, step S1601 may be skipped.

[0367] It should be understood that since the VIN of the diagnostic strategy file and the VIN of the vehicle have been verified to be consistent in step S1505 of Figure 15, at this time, if the diagnostic task VIN and the VIN of the diagnostic strategy file are consistent, it means that the diagnostic task matches the vehicle.

[0368] S1602: Determine whether the timestamp of the diagnosis task is greater than the timestamp of the diagnosis policy file.

[0369] Specifically, in this step, it can be determined whether the timestamp of the diagnosis task is greater than the timestamp of the diagnosis strategy file. If so, step S1603 is performed; if not, the diagnosis task execution process is terminated.

[0370] Optionally, during the proximal diagnosis process, step S1602 may be skipped.

[0371] It should be understood that the purpose of ensuring that the timestamp of the diagnostic task is greater than the timestamp of the diagnostic strategy file in this step is to prevent the diagnostic task from being reused or replayed, that is, it is necessary to ensure that the time when the vehicle receives the diagnostic command is later than the time when it receives the diagnostic strategy file.

[0372] S1603, check whether the diagnostic command matches the authorized ECU in the spatial domain

[0373] Specifically, this step can check whether the diagnostic command matches the ECU authorized in the diagnostic policy file space domain. If it matches, step S1604 is performed; if it does not match, the diagnostic task execution process is terminated.

[0374] Optionally, this step may also be replaced by checking whether the diagnostic command matches one or more of the CAN ID, diagnostic service ID, and diagnostic data ID authorized in the diagnostic policy file space domain.

[0375] S1604: Monitor the validity period of the diagnosis strategy file until the diagnosis strategy file expires.

[0376] Specifically, when the diagnosis strategy file is valid, the diagnosis task or the diagnosis command is detected using the diagnosis strategy file; if the diagnosis strategy file is invalid, the diagnosis process is terminated.

[0377] In this embodiment of the present application, a diagnostic task can be checked using a diagnostic strategy file. Only after the check passes can the vehicle's ECU receive and execute the corresponding diagnostic task or command. In this way, the authenticity and integrity of the execution of the diagnostic task or diagnostic command can be guaranteed on the vehicle side.

[0378] The entire diagnostic process is described in detail below with reference to FIG17 .

[0379] (1) Create a character

[0380] Before performing diagnostics, OEMs can create roles as shown in Table 1.

[0381] Table 1

[0382]

[0383] The diagnostic service may refer to the corresponding rights specified in the UDS protocol for remote diagnosis or proximal diagnosis.

[0384] (2) Create a user

[0385] After creating the role, you can use the method in Table 2 below to create a user. In Table 2, CDC refers to a continuous damping control system (CDC).

[0386] Table 2

[0387]

[0388] (3) Owner authorization

[0389] Car owners can send an application to the diagnostic platform by phone, requesting the OEM's remote diagnostic personnel to perform a diagnosis.

[0390] (4) Perform diagnostics

[0391] Executing the diagnosis may specifically include the following steps.

[0392] S1701: The OEM remote diagnostics personnel enters the user name and password to log in to the diagnostic platform.

[0393] S1702, the authorization management system authenticates the user name and password.

[0394] S1703, after successful login, the OEM remote diagnostic personnel enters the menu of corresponding permissions.

[0395] S1704, the diagnostician selects the vehicle model and diagnostic resources. According to the settings in Table 2, the diagnostician selects the vehicle model F4 and the diagnostic ECU selected is the vehicle ECU.

[0396] S1705: The diagnostic platform generates a policy request scope based on the F4 model and vehicle component permissions.

[0397] S1706: The diagnostic platform submits an authorization request to the authorization management system.

[0398] S1707: The authorization management system generates a diagnosis policy file according to the authorization request.

[0399] S1708, the authorization management system performs integrity protection on the diagnosis policy file.

[0400] S1709: The authorization management system returns the diagnosis policy file to the remote diagnosis platform.

[0401] S1710: The diagnostic platform sends the diagnostic strategy file to the vehicle diagnostic client.

[0402] The diagnosis client may refer to the diagnosis client module 131 in FIG. 1 .

[0403] S1711, the diagnostic client performs integrity verification on the policy file and stores it after passing the verification. The integrity verification can adopt the method shown in Figure 15.

[0404] The diagnostic task format described in the above steps S1705 to S1711 can be shown as (a) in Figure 17, the diagnostic strategy file format can be shown as (b) in Figure 17, and the specific implementation method of the diagnostic strategy file can be shown as (c) in Figure 17.

[0405] At S1712, the OEM remote diagnostics personnel select the vehicle scanning function, and the diagnostic platform generates the corresponding diagnostic task.

[0406] S1713: The diagnostic platform performs integrity protection on the diagnostic task.

[0407] S1714: The diagnostic platform sends the diagnostic task to the vehicle-side diagnostic module.

[0408] S1715: The diagnosis module checks the integrity of the diagnosis task.

[0409] Specifically, the diagnosis module may be the diagnosis module 130 in FIG. 1 .

[0410] S1716 , extracting a diagnostic command from the diagnostic task, and checking the diagnostic command through the diagnostic strategy file. The method shown in FIG16 may be used to check the diagnostic command through the diagnostic strategy file.

[0411] S1717: After the check passes, the diagnostic agent module sends a diagnostic command to the corresponding ECU for execution.

[0412] Specifically, the diagnosis agent module may be the diagnosis agent module 133 in FIG. 1 .

[0413] S1718: After completing the diagnostic task, the ECU returns the diagnostic result to the diagnostic agent module.

[0414] S1719: The diagnostic agent returns the diagnostic results to the diagnostic platform via the diagnostic client.

[0415] S1720: The execution result is successfully returned to the diagnosis platform.

[0416] FIG18 is a schematic diagram of a diagnostic device 1800 according to an embodiment of the present application. The device 1800 may be applied to the vehicle 100 shown in FIG2 .

[0417] The apparatus 1800 may include a transceiver unit 1810, an acquisition unit 1820, and a processing unit 1830. The transceiver unit 1810 may implement corresponding communication functions and may also be referred to as a communication interface or communication unit. The acquisition unit 1820 is configured to acquire corresponding instructions and / or data. The processing unit 1830 is configured to process the corresponding instructions and / or data. The processing unit 1830 may read the instructions and / or data in the storage unit to enable the apparatus to implement the aforementioned method embodiments.

[0418] Optionally, the device 1800 further includes a storage unit for storing corresponding instructions and / or data.

[0419] As a design, the device 1800 can be used to execute the actions performed by the vehicle in the above method embodiment.

[0420] The device 1800 includes: a transceiver unit 1810, used to receive a first diagnostic policy file sent by a diagnostic device, the first diagnostic policy file includes: access control policy information, and the diagnostic device includes: a remote diagnostic platform or a proximal diagnostic instrument; a processing unit 1830, used to verify the authenticity and integrity of the first diagnostic policy file; the processing unit 1830 is also used to verify whether the diagnostic command has access control authority based on the access control policy information when the authenticity and integrity verification of the first diagnostic policy file are passed.

[0421] In a possible implementation, the access control policy information includes: a validity period; and the processing unit 1830 is specifically configured to use the access control policy information to verify whether the diagnostic command has access control authority within the validity period.

[0422] In one possible implementation, the access control policy information further includes: first vehicle identity information; the processing unit 1830 is specifically used to verify whether the first vehicle identity information is consistent with the second vehicle identity information, and the diagnostic command includes the second vehicle identity information.

[0423] In a possible implementation, the first vehicle identity information and / or the second vehicle identity information is a vehicle identification number.

[0424] In one possible implementation, the access control policy information also includes: a first identification ID, the first identification ID includes: at least one of: a first electronic control unit ID, a first CAN ID, a first diagnostic service ID and a first diagnostic data ID; the processing unit 1830 is specifically used to verify whether the first identification ID is consistent with the second identification ID, the second identification ID is the identification ID in the diagnostic command, and the second identification ID includes: at least one of: a second electronic control unit ID, a second CAN ID, a second diagnostic service ID and a second diagnostic data ID.

[0425] In a possible implementation, the access control policy information further includes: a first timestamp; and the processing unit 1830 is specifically configured to verify whether a second timestamp is greater than the first timestamp, where the second timestamp is the timestamp of the diagnostic command.

[0426] In one possible implementation, the diagnostic device includes: a proximal diagnostic instrument, the first diagnostic strategy file includes: a first key; the processing unit 1830 is also used to store the first key in a vehicle, and the vehicle is the vehicle to execute the diagnostic command; the processing unit 1830 is also used to verify whether the first key is consistent with the second key, and the second key is the key stored in the proximal diagnostic instrument; the processing unit 1830 is also used to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

[0427] In one possible implementation, the diagnostic device includes: a proximal diagnostic instrument; the transceiver unit 1810 is also used to receive a first key sent by the proximal diagnostic instrument; the processing unit 1830 is also used to store the first key in a vehicle, which is a vehicle to execute the diagnostic command; the processing unit 1830 is also used to verify whether the first key is consistent with a second key, which is a key stored in the proximal diagnostic instrument; the processing unit 1830 is also used to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

[0428] In a possible implementation, the processing unit 1830 is specifically configured to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key and the first key is within a validity period.

[0429] In one possible implementation, the access control policy information also includes: a certificate and a signature; the processing unit 1830 is specifically used to decrypt the signature using the public key of the certificate to obtain a first digital summary; perform hash calculation on the access control policy information to obtain a second digital summary; and verify whether the first digital summary is consistent with the second digital summary.

[0430] In one possible implementation, the processing unit 1830 is specifically configured to verify whether the first vehicle identity information matches a vehicle on which the diagnostic command is to be executed.

[0431] In one possible implementation, the transceiver unit 1810 is further configured to receive a second diagnostic strategy file sent by the diagnostic device, where the second diagnostic file includes a third timestamp. The processing unit 1830 is specifically configured to verify whether the first timestamp is greater than the third timestamp.

[0432] In a possible implementation, the transceiver unit 1810 is specifically configured to receive the first diagnostic strategy file sent by the diagnostic device upon obtaining authorization from the vehicle owner.

[0433] As a design, the apparatus 1800 can be used to execute the actions performed by the diagnostic device in the above method embodiment.

[0434] The device 1800 includes: a transceiver unit 1810, used to send a first request message to the authorization management system, the first request message is used to request the authorization management system to generate a first diagnostic policy file, the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; the transceiver unit 1810 is also used to receive the first diagnostic policy file sent by the authorization management system; the transceiver unit 1810 is also used to send the first diagnostic policy file to a vehicle, the vehicle being the vehicle on which the diagnostic command is to be executed.

[0435] In one possible implementation, the device also includes: an acquisition unit 1820, used to obtain the identity information of the diagnostic personnel; the transceiver unit 1810, also used to send the identity information of the diagnostic personnel to the authorization management system; the transceiver unit 1810, specifically used to send the first request information to the authorization management system when receiving the first response information sent by the authorization management system, and the first response information is used to indicate that the identity authentication of the diagnostic personnel is successful.

[0436] In a possible implementation, the first diagnostic strategy file includes: a second key, and the apparatus further includes: a processing unit 1830 for storing the second key in the diagnostic device.

[0437] In one possible implementation, the transceiver unit 1810 is further used to receive a second key sent by the key management system; the processing unit 1830 is further used to store the second key in the diagnostic device, which is the proximal diagnostic instrument; and send the first key to the vehicle.

[0438] As a design, the device 1800 can be used to execute the actions performed by the authorization management system in the above method embodiment.

[0439] The device 1800 includes: a transceiver unit 1810, used to receive a first request message sent by a diagnostic device, a processing unit 1830, used to generate a first diagnostic strategy file based on the first request message, and the first diagnostic strategy file is used to verify whether the diagnostic command has access control authority; the transceiver unit 1810 is also used to send the first diagnostic strategy file to the diagnostic device.

[0440] In one possible implementation, the transceiver unit 1810 is further used to receive the identity information of the diagnostic personnel sent by the diagnostic device; the transceiver unit 1810 is further used to send a first response message to the diagnostic device when the identity information of the diagnostic personnel is consistent with the identity information preset in the authorization management system, and the first response message is used to indicate that the identity authentication of the diagnostic personnel is successful.

[0441] It should be understood that the transceiver unit provided in the embodiments of the present application can be a communication interface on a diagnostic module (diagnostic device), through which the diagnostic module can receive the first diagnostic strategy file from a T-BOX or other device. The transceiver unit can also be a communication interface on a T-BOX in a vehicle, which receives the first diagnostic strategy file and sends it to the diagnostic module for processing.

[0442] It should also be understood that the processing unit 1830 in FIG18 can be implemented by at least one processor or processor-related circuit, the acquisition unit 1820 and the transceiver unit 1810 can be implemented by a transceiver or transceiver-related circuit, and the storage unit can be implemented by at least one memory.

[0443] Optionally, if the device 1800 is located in the vehicle 200 , the processing unit 1830 may be the processor 211 shown in FIG. 2 .

[0444] Optionally, the processing unit 1830 may be the processor 1920 in FIG. 19 , the storage unit may be the memory 1910 in FIG. 19 , and the acquisition unit 1810 or the acquisition unit 1820 may be the communication interface 1930 in FIG. 19 .

[0445] FIG19 is a schematic diagram of a diagnostic device 1900 according to an embodiment of the present application. The device 1900 may be applied to the vehicle 100 shown in FIG1 .

[0446] The diagnostic device 1900 includes a memory 1910, a processor 1920, and a communication interface 1930. The memory 1910, the processor 1920, and the communication interface 1930 are connected via an internal connection path. The memory 1910 is used to store instructions, and the processor 1920 is used to execute the instructions stored in the memory 1910. Optionally, the memory 1910 can be coupled to the processor 1920 via an interface or integrated with the processor 1920.

[0447] It should be noted that the communication interface 1930 uses a transceiver device such as, but not limited to, a transceiver to implement communication between the communication device 1000 and other devices or a communication network. The communication interface 1930 may also include an input / output interface.

[0448] The processor 1920 stores one or more computer programs, which include instructions. When the instructions are executed by the processor 1920, the diagnostic device 1900 executes the diagnostic method and technical solutions in the above-mentioned embodiments.

[0449] Alternatively, the apparatus 1800 and the apparatus 1900 may be located in the vehicle 200 in FIG. 2 .

[0450] Optionally, the device 1800 and the device 1900 may be the computing platform 210 in the vehicle in FIG. 2 .

[0451] During implementation, each step of the above method can be completed by an integrated logic circuit of the hardware in the processor 1920 or by instructions in the form of software. The method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 1910, and the processor 1920 reads the information in the memory 1910 and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

[0452] An embodiment of the present application further provides a computer-readable medium storing a program code. When the computer program code is executed on a computer, the computer executes any one of the methods in FIG. 3 to FIG. 17 .

[0453] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed, the computer executes any one of the methods in Figures 3 to 17 above.

[0454] An embodiment of the present application also provides a chip, comprising: at least one processor and a memory, wherein the at least one processor is coupled to the memory and is used to read and execute instructions in the memory to execute any one of the methods in Figures 3 to 17 above.

[0455] An embodiment of the present application also provides a vehicle, comprising: at least one processor and a memory, wherein the at least one processor is coupled to the memory and is configured to read and execute instructions in the memory to execute any one of the methods in Figures 3 to 17 above.

[0456] An embodiment of the present application also provides a vehicle, comprising any one of the diagnostic devices shown in FIG18 or FIG19 .

[0457] It should be understood that in the embodiments of the present application, the processor may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0458] It should also be understood that in the embodiments of the present application, the memory may include read-only memory and random access memory, and provide instructions and data to the processor. A portion of the processor may also include non-volatile random access memory. For example, the processor may also store device type information.

[0459] It should be understood that the term "and / or" in this document simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0460] It should also be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0461] As used in this specification, the terms "component," "module," and the like are used to represent computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. By way of illustration, both applications running on a computing device and a computing device can be components. One or more components can reside in a process and / or an execution thread, and a component can be located on a computer and / or distributed between two or more computers. In addition, these components can be executed from various computer-readable media having various data structures stored thereon. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0462] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0463] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0464] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0465] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0466] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0467] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

Claims

1. A diagnostic method, characterized in that The method comprises: Receiving a first diagnostic strategy file sent by a diagnostic device, wherein the first diagnostic strategy file includes access control strategy information, and the diagnostic device includes a remote diagnostic platform or a proximal diagnostic instrument; Verifying the authenticity and integrity of the first diagnostic strategy file; If the authenticity and integrity verification of the first diagnosis policy file passes, it is verified whether the diagnosis command has the access control authority according to the access control policy information.

2. The method according to claim 1, wherein The access control policy information includes: a validity period, and the verifying whether the diagnostic command has access control authority according to the access control policy information includes: During the validity period, the access control policy information is used to verify whether the diagnostic command has the access control authority.

3. The method according to claim 1 or 2, wherein: The access control policy information further includes: first vehicle identity information, and the verifying whether the diagnostic command has access control authority according to the access control policy information includes: Verify whether the first vehicle identity information is consistent with the second vehicle identity information, the diagnostic command including the second vehicle identity information.

4. The method according to claim 3, wherein The first vehicle identity information and / or the second vehicle identity information is a vehicle identification number.

5. The method according to claims 1 to 4, characterized in that The access control policy information further includes: a first identification ID, wherein the first identification ID includes: at least one of a first electronic control unit ID, a first CAN ID, a first diagnostic service ID, and a first diagnostic data ID; The using the access control policy information to verify whether the diagnostic command has access control authority includes: Verify whether the first identification ID is consistent with the second identification ID, where the second identification ID is the identification ID in the diagnostic command, and the second identification ID includes at least one of: a second electronic control unit ID, a second CAN ID, a second diagnostic service ID, and a second diagnostic data ID.

6. The method according to claims 1 to 5, characterized in that The access control policy information further includes: a first timestamp, and the using the access control policy information to verify whether the diagnostic command has access control authority includes: Verify whether a second timestamp is greater than the first timestamp, the second timestamp being the timestamp of the diagnostic command.

7. The method according to claims 1 to 6, characterized in that The diagnostic device includes: a proximal diagnostic instrument, the first diagnostic strategy file also includes: a first key, and the method further includes: storing the first key in a vehicle, where the vehicle is to execute the diagnostic command; Verifying whether the first key is consistent with a second key, where the second key is a key stored in the proximal diagnostic instrument; When the first key is consistent with the second key, a secure access service is established with the proximal diagnostic instrument.

8. The method according to claims 1 to 6, characterized in that The diagnostic device includes: a proximal diagnostic instrument, and the method further includes: receiving a first key sent by the proximal diagnostic instrument; storing the first key in a vehicle, where the vehicle is to execute the diagnostic command; Verifying whether the first key is consistent with a second key, where the second key is a key stored in the proximal diagnostic instrument; When the first key is consistent with the second key, a secure access service is established with the proximal diagnostic instrument.

9. The method according to claim 7 or 8, wherein The step of establishing a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key includes: When the first key is consistent with the second key and the first key is within the validity period, a secure access service is established with the proximal diagnostic instrument.

10. The method according to any one of claims 1 to 9, characterized in that The access control policy information also includes: a certificate and a signature. The verification of the authenticity and integrity of the first diagnostic policy file includes: decrypting the signature using the public key of the certificate to obtain a first digital digest; Performing a hash calculation on the access control policy information to obtain a second digital digest; Verify whether the first digital digest is consistent with the second digital digest.

11. The method according to claim 3, wherein Verifying the authenticity and integrity of the first diagnostic strategy file includes: Verify whether the first vehicle identity information matches a vehicle on which the diagnostic command is to be executed.

12. The method according to claim 6, wherein Before receiving the first diagnostic strategy file sent by the diagnostic device, the method further includes: receiving a second diagnostic strategy file sent by the diagnostic device, wherein the second diagnostic strategy file includes: a third timestamp; Verifying the authenticity and integrity of the first diagnostic strategy file includes: Verify whether the first timestamp is greater than the third timestamp.

13. The method according to claims 1 to 12, characterized in that The receiving a first diagnostic strategy file sent by the diagnostic device includes: With the authorization of the vehicle owner, the first diagnostic strategy file sent by the diagnostic device is received.

14. A diagnostic method, characterized in that: The method is applied to a diagnostic device, which includes a remote diagnostic platform or a proximal diagnostic instrument. The method includes: Sending a first request message to the authorization management system, wherein the first request message is used to request the authorization management system to generate a first diagnostic policy file, wherein the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; Receiving the first diagnostic strategy file sent by the authorization management system; The first diagnostic strategy file is sent to a vehicle, where the diagnostic command is to be executed.

15. The diagnostic method according to claim 14, wherein Before sending the first request information to the authorization management system, the method further includes: Obtain the identity information of the diagnostic personnel; Sending the identity information of the diagnostic personnel to the authorization management system; The sending of the first request information to the authorization management system includes: Upon receiving the first response information sent by the authorization management system, the first request information is sent to the authorization management system, where the first response information is used to indicate that the identity authentication of the diagnostician is successful.

16. The method according to claim 14 or 15, characterized in that The first diagnostic strategy file includes a second key. Before sending the first diagnostic strategy file to the vehicle, the method further includes: The second key is stored in the diagnostic device, which is the proximal diagnostic instrument.

17. The method according to claim 14 or 15, wherein: Before sending the first diagnostic strategy file to the vehicle, the method further includes: receiving a second key sent by the key management system; storing the second key in the diagnostic device, wherein the diagnostic device is the proximal diagnostic instrument; A first key is sent to the vehicle.

18. A diagnostic method, characterized in that: The method is applied to an authorization management system, and the method includes: Receiving first request information sent by a diagnostic device, wherein the diagnostic device includes: a remote diagnostic platform or a proximal diagnostic instrument; generating a first diagnostic policy file according to the first request information, wherein the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; The first diagnostic strategy file is sent to the diagnostic device.

19. The method according to claim 18, wherein Before receiving the first request information sent by the diagnostic device, the method further includes: receiving the diagnostic personnel identity information sent by the diagnostic device; When the identity information of the diagnostician is consistent with the identity information preset in the authorization management system, a first response message is sent to the diagnostic device, where the first response message is used to indicate that the identity authentication of the diagnostician is successful.

20. A diagnostic device, characterized in that The device comprises: a transceiver unit, configured to receive a first diagnostic strategy file sent by a diagnostic device, wherein the first diagnostic strategy file includes access control strategy information, and the diagnostic device includes a remote diagnostic platform or a proximal diagnostic instrument; a processing unit, configured to verify the authenticity and integrity of the first diagnostic strategy file; The processing unit is further configured to verify whether the diagnostic command has access control authority according to the access control policy information when the authenticity and integrity verification of the first diagnostic policy file passes.

21. The device according to claim 20, characterized in that The access control policy information includes: validity period; The processing unit is specifically configured to use the access control policy information to verify, within the validity period, whether the diagnostic command has the access control authority.

22. The device according to claim 20 or 21, characterized in that The access control policy information also includes: first vehicle identity information; The processing unit is specifically used to verify whether the first vehicle identity information is consistent with the second vehicle identity information, and the diagnostic command includes the second vehicle identity information.

23. The device according to claim 22, wherein The first vehicle identity information and / or the second vehicle identity information is a vehicle identification number.

24. The device according to any one of claims 20 to 23, characterized in that The access control policy information further includes: a first identification ID, wherein the first identification ID includes: at least one of a first electronic control unit ID, a first CAN ID, a first diagnostic service ID, and a first diagnostic data ID; The processing unit is specifically used to verify whether the first identification ID is consistent with the second identification ID, the second identification ID is the identification ID in the diagnostic command, and the second identification ID includes: at least one of: a second electronic control unit ID, a second CAN ID, a second diagnostic service ID, and a second diagnostic data ID.

25. The device according to any one of claims 20 to 24, characterized in that The access control policy information further includes: a first timestamp; The processing unit is specifically configured to verify whether a second timestamp is greater than the first timestamp, where the second timestamp is the timestamp of the diagnostic command.

26. The device according to any one of claims 20 to 25, characterized in that The diagnostic device includes: a proximal diagnostic instrument, and the first diagnostic strategy file includes: a first key; The processing unit is further configured to store the first key in a vehicle, where the vehicle is to execute the diagnostic command; The processing unit is further configured to verify whether the first key is consistent with a second key, where the second key is a key stored in the proximal diagnostic instrument; The processing unit is further configured to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

27. The device according to any one of claims 20 to 25, characterized in that The diagnostic equipment includes: a proximal diagnostic instrument; The transceiver unit is further configured to receive a first key sent by the proximal diagnostic instrument; The processing unit is further configured to store the first key in a vehicle, where the vehicle is to execute the diagnostic command; The processing unit is further configured to verify whether the first key is consistent with a second key, where the second key is a key stored in the proximal diagnostic instrument; The processing unit is further configured to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key.

28. The device according to claim 26 or 27, characterized in that The processing unit is specifically configured to establish a secure access service with the proximal diagnostic instrument when the first key is consistent with the second key and the first key is within a validity period.

29. The device according to any one of claims 20 to 28, characterized in that The access control policy information also includes: a certificate and a signature; The processing unit is specifically configured to decrypt the signature using the public key of the certificate to obtain a first digital summary; Performing a hash calculation on the access control policy information to obtain a second digital digest; Verify whether the first digital digest is consistent with the second digital digest.

30. The device according to claim 22, wherein The processing unit is specifically configured to verify whether the first vehicle identity information matches a vehicle on which the diagnostic command is to be executed.

31. The device according to claim 25, wherein The transceiver unit is further configured to receive a second diagnostic strategy file sent by the diagnostic device, wherein the second diagnostic file includes: a third timestamp; The processing unit is specifically configured to verify whether the first timestamp is greater than the third timestamp.

32. The device according to any one of claims 20 to 31, characterized in that The transceiver unit is specifically configured to receive the first diagnostic strategy file sent by the diagnostic device upon obtaining authorization from the vehicle owner.

33. A diagnostic device, characterized in that The device comprises: a transceiver unit, configured to send a first request message to the authorization management system, wherein the first request message is used to request the authorization management system to generate a first diagnostic policy file, wherein the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; The transceiver unit is further configured to receive the first diagnostic strategy file sent by the authorization management system; The transceiver unit is further configured to send the first diagnostic strategy file to a vehicle on which the diagnostic command is to be executed.

34. The device according to claim 33, wherein The device further comprises: An acquisition unit, used for acquiring the identity information of the diagnosis personnel; The transceiver unit is further configured to send the identity information of the diagnostic personnel to the authorization management system; The transceiver unit is specifically configured to send the first request information to the authorization management system upon receiving the first response information sent by the authorization management system, where the first response information is used to indicate that the identity authentication of the diagnostician is successful.

35. The device according to claim 33 or 34, characterized in that The first diagnostic strategy file includes: a second key, and the device further includes: A processing unit is configured to store the second key in the diagnostic device.

36. The device according to claim 33 or 34, characterized in that The transceiver unit is further configured to receive a second key sent by the key management system; The processing unit is further configured to store the second key in the diagnostic device, wherein the diagnostic device is the proximal diagnostic instrument; A first key is sent to the vehicle.

37. A diagnostic device, characterized in that The device comprises: a transceiver unit, configured to receive a first request message sent by a diagnostic device, a processing unit, configured to generate a first diagnostic policy file according to the first request information, wherein the first diagnostic policy file is used to verify whether the diagnostic command has access control authority; The transceiver unit is further configured to send the first diagnostic strategy file to the diagnostic device.

38. The device according to claim 37, wherein The transceiver unit is further configured to receive the diagnostic personnel identity information sent by the diagnostic device; The transceiver unit is further configured to send a first response message to the diagnostic device when the identity information of the diagnostician is consistent with the identity information preset in the authorization management system, wherein the first response message is used to indicate that the identity authentication of the diagnostician is successful.

39. A diagnostic device, characterized in that include: At least one processor and a memory, wherein the at least one processor is coupled to the memory and configured to read and execute instructions in the memory to perform the method according to any one of claims 1 to 19.

40. A computer-readable medium, characterized in that The computer-readable medium stores a program code, and when the computer program code is run on a computer, the computer is caused to perform the method according to any one of claims 1 to 19.

41. A chip, characterized in that: include: At least one processor and a memory, wherein the at least one processor is coupled to the memory and configured to read and execute instructions in the memory to perform the method according to any one of claims 1 to 19.

42. A computer program product, characterized in that The computer product comprises a computer program, which enables a computer to perform the method according to any one of claims 1 to 19 when the computer program is executed.

43. A vehicle, characterized in that: include: At least one processor and a memory, wherein the at least one processor is coupled to the memory and configured to read and execute instructions in the memory to perform the method according to any one of claims 1 to 13.

Images