WO2024000402A1 - 诊断方法和装置 - Google Patents

诊断方法和装置 Download PDF

Info

Publication number
WO2024000402A1
WO2024000402A1 PCT/CN2022/102811 CN2022102811W WO2024000402A1 WO 2024000402 A1 WO2024000402 A1 WO 2024000402A1 CN 2022102811 W CN2022102811 W CN 2022102811W WO 2024000402 A1 WO2024000402 A1 WO 2024000402A1
Authority
WO
WIPO (PCT)
Prior art keywords
diagnostic
vehicle
key
access control
information
Prior art date
Application number
PCT/CN2022/102811
Other languages
English (en)
French (fr)
Inventor
钟胤
谢玉娟
张作强
魏卓
付天福
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2022/102811 priority Critical patent/WO2024000402A1/zh
Publication of WO2024000402A1 publication Critical patent/WO2024000402A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring

Definitions

  • Embodiments of the present application relate to the field of security, and more specifically, to a diagnostic method and device.
  • Vehicle diagnosis refers to determining the cause of vehicle failure, that is, determining the technical condition of the vehicle and identifying the fault location and cause without dismantling the vehicle.
  • the scope of diagnosis can include not only power, chassis, body and accessories, but also vehicle exhaust emissions, noise and safety testing.
  • Embodiments of the present application provide a diagnostic method and device, which can prevent the vehicle from executing wrong or illegal diagnostic commands during diagnosis and protect the property and privacy of the vehicle owner.
  • a diagnostic method 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 Proximal diagnostic instrument; verify the authenticity and integrity of the first diagnosis policy file; if the authenticity and integrity of the first diagnosis policy file pass the verification, verify the diagnosis command according to the access control policy information Whether it has access control permissions.
  • the diagnostic command may be a diagnostic command to be executed by the vehicle, and the diagnostic command may be sent by the diagnostic device. Diagnostic commands may include, but are not limited to: reading fault codes, clearing fault codes, vehicle scan and component diagnosis.
  • the access control policy information may include: one or more of authorization type, validity period, vehicle identity information, identification ID, timestamp, version, signature and certificate. If a diagnostic command has access control permission, it can be understood that the diagnostic command is legal and valid, and the diagnostic command can be executed by the vehicle.
  • the access control policy information in the first diagnostic policy file can be used to verify whether the diagnostic command has access control permissions. Diagnostic commands can only be executed if they have access control permissions. In this way, the vehicle can be prevented from executing incorrect or illegal diagnostic commands, and the user's property and privacy can be protected.
  • the access control policy information includes: a validity period, and verifying whether the diagnostic command has access control permissions according to the access control policy information includes: within the validity period Within, use the access control policy information to verify whether the diagnostic command has access control permissions.
  • the access control policy information in the diagnostic policy file is used to verify whether the diagnostic command has access control permissions. In this way, it is possible to prevent the diagnostic policy file from being used even after it expires, thereby improving the security of the use of the diagnostic policy file.
  • the access control policy information further includes: first vehicle identity information, and verifying whether the diagnostic command has access control permissions according to the access control policy information includes: : Verify whether the first vehicle identity information is consistent with the second vehicle identity information, and the diagnosis command includes the second vehicle identity information.
  • the first vehicle identity information may be information used to represent the vehicle identity, which may include but is not limited to a vehicle identification number.
  • the diagnosis may be determined. Commands have access control permissions.
  • the first vehicle identity information and/or the second vehicle identity information is a vehicle identification number.
  • the access control policy information further includes: a first identification ID
  • the first identification ID includes: a first electronic control unit ID, a first CAN ID, at least one of the first diagnostic service ID and the first diagnostic data ID
  • the use of the access control policy information to verify whether the diagnostic command has access control permissions includes: verifying the first identification ID and the second identification Whether the IDs are consistent, the second identification ID is the identification ID in the diagnosis command.
  • the second identification ID includes: a second electronic control unit ID, a second CAN ID, a second diagnostic service ID and a second diagnostic data. At least one of the IDs.
  • the diagnostic command take effect on the corresponding electronic control unit or the vehicle can use the corresponding diagnostic service or diagnostic data.
  • the second electronic control unit ID may be the ID of the electronic control unit targeted by the diagnostic command
  • the second CAN ID may represent the address or name of the CAN node that sends and receives the diagnostic command
  • the second diagnostic service ID may be the diagnostic command.
  • the required service ID and the second diagnostic data ID may be the data ID required to perform diagnostic services or diagnostic commands.
  • the diagnostic command take effect on the corresponding electronic control unit or the vehicle can use the corresponding diagnostic service or diagnostic data. In this way, it not only provides a diagnostic access control mechanism for vehicles and components, but also provides an access mechanism for diagnostic services, ensuring the safety and effectiveness of diagnostic commands.
  • 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 permissions, including: verifying whether the second timestamp is greater than the first timestamp, and the second timestamp is the timestamp of the diagnostic command
  • the diagnosis command if the second timestamp is greater than the first timestamp, the diagnosis command has access control authority; if the second timestamp is less than the first timestamp, the diagnosis command does not have access control authority.
  • the diagnostic command has access control permissions.
  • the purpose of ensuring whether 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 vehicle receives the diagnostic command later than the time it receives the diagnostic policy file. time.
  • the diagnosis task is prevented from being reused or replayed, and the user's property security and privacy security can be further ensured.
  • the diagnostic device includes: a proximal diagnostic instrument
  • the first diagnosis policy file includes: a first key
  • the method further includes: converting the The first key is stored in the vehicle, and the vehicle is the vehicle where the diagnostic command is to be executed; verify whether the first key and the second key are consistent, and the second key is stored in the near-end A key in the diagnostic instrument; when the first key and the second key are consistent, establish a secure access service with the near-end diagnostic instrument.
  • a secure access service can be established between the vehicle and the near-end diagnostic instrument. After the secure access service is established, the near-end diagnostic instrument can use the key in the diagnostic policy file. Access control policy information to verify whether the diagnostic command has diagnostic control permissions.
  • both the first key and the second key may be temporary keys, and the application process of the first key and the second key may be: first, the key management system generates the second key and The key is sent to the authorization management system. After generating the first diagnosis strategy file, the authorization management system sends the second key along with the first diagnosis strategy file to the near-end diagnostic instrument, and the near-end diagnostic instrument obtains the second key. The second key can then be saved to the local diagnostic instrument. Then, the near-end diagnostic instrument delivers the first key along with the first diagnosis policy file to the vehicle, and the vehicle saves the first key.
  • the second 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 near-end 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 unsafe.
  • the near-end diagnostic instrument can send a ciphertext to the vehicle, and the vehicle verifies the ciphertext to determine whether the first key and the second key are consistent.
  • the near-end diagnostic instrument can directly send the saved second key to the vehicle, and the vehicle verifies the first key and Whether the second key is consistent.
  • the reason for verifying whether the first key and the second key are consistent is to be compatible with the old version of the near-end diagnostic instrument. If the diagnostic user uses the old version of the near-end diagnostic instrument to diagnose the vehicle, the key will not be used. Verification may cause the execution of diagnostic commands to fail.
  • the diagnostic device includes: a proximal diagnostic instrument, and the method further includes: receiving a first key sent by the proximal diagnostic instrument; The first key is stored in the vehicle, and the vehicle is the vehicle where the diagnostic command is to be executed; verify whether the first key and the second key are consistent, and the second key is stored in the near-end A key in the diagnostic instrument; when the first key and the second key are consistent, establish a secure access service with the near-end diagnostic instrument.
  • both the first key and the second key may be temporary keys, and the application process of the first key and the second key may be: first, the key management system generates the second key and transfers the second key to the temporary key. After being sent to the local diagnostic instrument, the local diagnostic instrument saves it. Then, the near-end diagnostic instrument directly delivers the first key to the vehicle, and the vehicle saves the first key.
  • 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 near-end 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 unsafe.
  • establishing a secure access service with the proximal diagnostic instrument includes: : When the first key is consistent with the second key and the first key is within the validity period, establish a secure access service with the near-end diagnostic instrument.
  • the above validity period may be the validity period in the access control policy information, or may be the validity period of the first key. If the above validity period is exceeded, the first key will become invalid.
  • the vehicle only when the first key and the second key are consistent and the first key is within the validity period can the vehicle establish a secure access service with the near-end diagnostic instrument. In this way, it is possible to avoid using The invalid first key is verified for consistency to further improve the security of key use.
  • the access control policy information includes: a certificate and a signature
  • the verifying the authenticity and integrity of the first diagnostic policy file includes: using the certificate Decrypt the signature with the public key to obtain a first digital digest; perform 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.
  • the method also includes verifying the authenticity and validity of the certificate before using the certificate to decrypt the signature.
  • a symmetric key may also be used to verify the authenticity and integrity of the first diagnosis policy file.
  • Use the symmetric key to perform encryption calculations 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.
  • the access control policy information may include the first digital digest without having to use the public key to decrypt the signature to obtain the first digital digest.
  • the access control policy information can be hashed to obtain the second digital summary, and the second digital summary can be compared with the first digital summary to verify the authenticity and integrity of the first diagnostic policy file.
  • the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, which can further protect the user's property. and privacy security.
  • the verifying the authenticity and integrity of the first diagnostic policy file includes: verifying whether the first vehicle identity information matches the vehicle, and the The vehicle is the vehicle on which the diagnostic command is to be executed.
  • the first vehicle identity information is a vehicle identification number.
  • the first vehicle identification number can be compared with the vehicle's identification code to determine whether the first vehicle identification number matches the vehicle. If the two are consistent, the verification is passed. If If the two are inconsistent, the verification fails.
  • the vehicle identification code can be viewed on the front partition of the vehicle engine compartment or on the vehicle dashboard.
  • the authenticity and integrity of the first diagnosis policy file can be verified by determining whether the first vehicle identity information matches the vehicle. In this way, the authenticity and integrity of the first diagnosis policy file pass the verification In this case, the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, which can further protect the user's property and privacy security.
  • the method before receiving the first diagnosis policy file sent by the diagnosis device, the method further includes: receiving a second diagnosis policy file sent by the diagnosis device, The second diagnostic file includes: a third timestamp; and verifying the authenticity and integrity of the first diagnostic policy file includes: verifying whether the first timestamp is greater than the third timestamp.
  • the time at which the vehicle receives the second diagnosis strategy file is earlier than the time at which the first diagnosis strategy file is received.
  • the second diagnostic strategy file may be the diagnostic strategy file used when the diagnostic command was executed last time, or it may 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 policy file has been reused or replayed. If the first timestamp is less than the third timestamp, it means that the first diagnostic policy file may be reused or replayed in a replay attack, and the policy file is not authentic. If the first timestamp is greater than the third timestamp, the authenticity and integrity verification of the first diagnostic policy file is passed.
  • the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, which can further protect the user's property and privacy security.
  • the verifying the authenticity and integrity of the first diagnostic policy file includes: determining whether the difference between the first timestamp and the vehicle local time is less than or equal to the preset threshold.
  • the difference between the first timestamp and the vehicle's local time is less than or equal to the preset threshold, the authenticity and integrity verification of the first diagnostic policy file is passed. If the difference between the first timestamp and the vehicle's local time is greater than the preset threshold, it indicates that the first diagnostic policy file may be reused or replayed.
  • the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, which can further protect the user's property and privacy security.
  • receiving the first diagnostic policy file sent by the diagnostic device includes: receiving the first diagnostic policy file sent by the diagnostic device with the authorization of the vehicle owner. Diagnostic policy file.
  • car owner authorization can be authorized with a certain time limit through online/offline service agreements or phone calls to meet privacy compliance requirements.
  • the vehicle owner needs to sign or check the diagnostic service agreement before the diagnosis can begin.
  • the vehicle can only perform diagnostic tasks after the vehicle detects that the owner has signed or checked the diagnostic service agreement.
  • the diagnostic service agreement may include but is not limited to: diagnostic objects, diagnostic permissions, resources that the vehicle needs to call to perform diagnostic tasks, etc.
  • the car owner before the diagnosis is started, the car owner can request vehicle diagnosis by phone. In this case, the car owner can be deemed to have agreed to the diagnostic service agreement.
  • car owners can trigger the diagnostic process through an app on the vehicle.
  • the vehicle can receive the first diagnostic policy file only with the authorization of the vehicle owner, so that the first diagnostic policy file can be used to subsequently verify whether the diagnostic command has access control permissions.
  • a diagnostic method is provided.
  • the method is applied to diagnostic equipment.
  • the diagnostic equipment includes: a remote diagnostic platform or a proximal diagnostic instrument.
  • the method includes: sending first request information to an authorization management system, and the third request information is sent to an authorization management system.
  • a request message is used to request the authorization management system to generate a first diagnosis policy file, and the first diagnosis policy file is used to verify whether the diagnosis command has access control permissions; receiving the first diagnosis policy sent by the authorization management system file; sending the first diagnosis strategy file to a vehicle, where the vehicle is the vehicle to be executed with the diagnosis command.
  • the diagnostic device receives the first diagnostic policy file from the authorization management system and forwards it to the vehicle, so that subsequent vehicles can use the first diagnostic policy file to verify whether the diagnostic command has access rights.
  • the method before sending the first request information to the authorization management system, further includes: obtaining the identity information of the diagnostician; and sending the first request information to the authorization management system.
  • the identity information of the diagnostician; and 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. Request information, and the first response information is used to indicate that the identity verification of the diagnostician is successful.
  • the identity information of the diagnostician can be expressed in various forms.
  • the identity information of the diagnostician can be account information.
  • the account information can be created by the original equipment manufacturer (original equipment manufacturer, OEM), and the account number and password can be assigned To the diagnostician, who will enter the account number and password on the diagnostic platform or diagnostic instrument.
  • the identity information can be the facial feature information of the diagnostician.
  • the OEM can enter the facial feature information of the qualified diagnostician into the diagnostic device or diagnostic platform in advance.
  • the diagnostician needs to verify the facial feature information on the diagnostic platform or diagnostic device. Log in.
  • the identity information may also be the diagnostician's iris feature information or voiceprint feature information, etc., which will not be described again here.
  • the diagnostician needs to log in on the diagnostic platform before performing diagnosis.
  • the diagnostic equipment needs to send the diagnostician's identity information to the authorization management system, and the authorization management system will verify it. After receiving the verification from the authorization management system, After receiving the success message, the diagnostic device can request the authorization management to send the first diagnostic policy file.
  • an identity verification mechanism for diagnostic personnel is provided, which can prevent the diagnostic platform or diagnostic instrument from being abused or maliciously diagnosed by illegal personnel, causing the user's privacy, property and life safety to be violated.
  • the first diagnostic strategy file includes: a second key
  • the method before sending the first diagnostic strategy file to the vehicle, the method further includes : Save the second key in the diagnostic device, and the diagnostic device is the proximal diagnostic instrument.
  • the diagnostic device can obtain the second key from the first diagnostic policy file and save the second key to the diagnostic device to facilitate subsequent vehicle verification of the first key and the second key. consistency.
  • the method further includes: receiving a second key sent by the key management system, saving the second key in the diagnostic device, and The first key is sent by the vehicle, which is the vehicle for which the diagnostic command is to be executed.
  • a diagnostic method is provided, which method is applied in an authorization management system.
  • the method includes: receiving first request information sent by a diagnostic device, and generating a first diagnostic policy file according to the first request information.
  • the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions; and the first diagnostic policy file is sent to the diagnostic device.
  • the method before receiving the first request information sent by the diagnostic device, the method further includes: receiving diagnostic personnel identity information sent by the diagnostic device; When the identity information of the diagnostic personnel is consistent with the identity information preset in the authorization management system, the first response information is sent to the diagnostic equipment, and the first response information is used to indicate the identity verification of the diagnostic personnel. success.
  • various methods can be used to verify the diagnostician's identity information. 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. After successful verification, it will send a third message to the diagnostic device. A response message used to inform the diagnostician that the authentication is successful. For another example, if the identity information of the diagnostician is facial feature information, the authorization management system can compare the facial feature information with the facial feature information preset in the system, and then send the first response information to the diagnostic device after the verification is successful, using Yu notifies the diagnostician that the identity verification is successful.
  • the authorization management system can verify the identity information, and then identify the legitimacy of the diagnosis user. Only when the identity of the diagnosis user is legal, can the authorization management system verify the identity information of the diagnostic personnel.
  • the diagnostic device sends the first diagnostic policy file. In this way, the identity verification mechanism of the diagnostic personnel is provided before diagnosis, which can prevent the diagnostic platform or diagnostic instrument from being abused or maliciously diagnosed by illegal persons, resulting in the user's privacy, property and life. Security violated.
  • a diagnostic device in a fourth aspect, includes: a transceiver unit configured to receive a first diagnostic policy file sent by a diagnostic device.
  • the first diagnostic policy file includes: access control policy information.
  • the diagnostic device includes: : a remote diagnosis platform or a near-end diagnostic instrument; a processing unit, used to verify the authenticity and integrity of the first diagnosis strategy file; the processing unit, also used to verify the authenticity and integrity of the first diagnosis strategy file If the verification is passed, verify whether the diagnostic command has access control permissions based on the access control policy information.
  • the transceiver unit may be a communication interface on a diagnostic module (diagnostic device), and the diagnostic module may receive the third message from a smart vehicle terminal (telematics-box, T-BOX) or other device through this interface.
  • a diagnostic strategy file may also be a communication interface on the T-BOX in the vehicle.
  • the T-BOX receives the first diagnosis strategy file and sends the first diagnosis strategy file to the diagnosis module for processing.
  • the access control policy information includes: a validity period; and the processing unit is specifically configured to use the access control policy information to verify the Check whether the diagnostic command has access control permissions.
  • the access control policy information further includes: first vehicle identity information; the processing unit is specifically used to verify that the first vehicle identity information and the second Whether the vehicle identity information is consistent, the diagnostic command includes the second vehicle identity information.
  • the first vehicle identity information and/or the second vehicle identity information is a vehicle identification number.
  • the access control policy information further includes: a first identification ID
  • the first identification ID includes: a first electronic control unit ID, a first CAN ID, At least one of the first diagnostic service ID and the first diagnostic data ID
  • the processing unit is specifically used to verify whether the first identification ID and the second identification ID are consistent, and the second identification ID is the diagnosis
  • the identification ID in the command, the second identification ID includes: at least one of the second electronic control unit ID, the second CAN ID, the second diagnostic service ID and the second diagnostic data ID.
  • the access control policy information further includes: a first timestamp; the processing unit is specifically configured to verify whether the second timestamp is greater than the first time stamp, and the second timestamp is the timestamp of the diagnostic command.
  • the diagnostic device includes: a proximal diagnostic instrument
  • the first diagnosis policy file includes: a first key
  • the processing unit is also configured to The first key is stored in the vehicle, and the vehicle is the vehicle to be executed.
  • the processing unit is also used to verify whether the first key and the second key are consistent.
  • the second key is a key stored in the near-end diagnostic instrument; the processing unit is also used to communicate with the near-end diagnosis instrument when the first key and the second key are consistent. Instrument to establish secure access services.
  • the diagnostic device includes: a proximal diagnostic instrument; the transceiver unit is further configured to receive the first key sent by the proximal diagnostic instrument; The processing unit is also configured to save the first key in a vehicle, and the vehicle is the vehicle to execute the diagnostic command; the processing unit is also configured to verify that the first key and the second key are stored in the vehicle. Whether the keys are consistent, the second key is the key stored in the near-end diagnostic instrument; the processing unit is also used to determine whether the first key and the second key are consistent Next, establish a secure access service with the near-end diagnostic instrument.
  • the processing unit is specifically configured to operate when the first key and the second key are consistent and the first key is within the validity period. In this case, establish a secure access service with the near-end diagnostic instrument.
  • the access control policy information further includes: a certificate and a signature; the processing unit is specifically configured to use the public key of the certificate to decrypt the signature, to obtain a first digital digest; performing a hash calculation on the access control policy information to obtain a second digital digest; verifying whether the first digital digest is consistent with the second digital digest.
  • the processing unit is specifically configured to verify whether the first vehicle identity information matches a vehicle, and the vehicle is the vehicle for which the diagnosis command is to be executed.
  • the transceiver unit is further configured to receive a second diagnostic policy file sent by the diagnostic device, where 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.
  • the transceiver unit is specifically configured to receive the first diagnostic policy file sent by the diagnostic device upon obtaining authorization from the vehicle owner.
  • a diagnostic device which device includes: a transceiver unit configured to send first request information to an authorization management system, where the first request information 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 is also used to receive the first diagnostic policy file sent by the authorization management system; the transceiver unit is also used The first diagnostic strategy file is sent to a vehicle, where the vehicle is the vehicle on which the diagnostic command is to be executed.
  • the device further includes: an acquisition unit, configured to acquire the identity information of the diagnostician; and the transceiver unit, further configured to send the information to the authorization management system.
  • the identity information of the diagnostician; 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.
  • the response information is used to indicate that the diagnostician's identity authentication is successful.
  • the first diagnosis policy file includes: a second key
  • the device further includes: a processing unit configured to save the second key in in the diagnostic equipment
  • the transceiver unit is further configured to receive the second key sent by the key management system; the processing unit is further configured to convert the second key to The key is stored in the diagnostic device, and the diagnostic device is the near-end diagnostic instrument; and the first key is sent to the vehicle.
  • a diagnostic device which device includes: a transceiver unit configured to receive first request information sent by a diagnostic device, and a processing unit configured to generate a first diagnostic policy file according to the first request information, so The first diagnostic policy file is used to verify whether the diagnostic command has access control permission; the transceiver unit is also used to send the first diagnostic policy file to the diagnostic device.
  • the transceiver unit is also used to receive the identity information of the diagnostician sent by the diagnostic equipment; the transceiver unit is also used to determine the identity information of the diagnostician. If the information is consistent with the identity information preset in the authorization management system, first response information is sent to the diagnostic device, and the first response information is used to indicate that the identity verification of the diagnostic personnel is successful.
  • a diagnostic device in a seventh aspect, includes: at least one processor and a memory.
  • the at least one processor is coupled to the memory and is used to read and execute instructions in the memory.
  • the device is configured to Implement the methods in each of the above aspects.
  • a computer-readable medium stores program code.
  • the computer program code When the computer program code is run on a computer, it causes the computer to perform the methods in the above aspects.
  • a chip in a ninth aspect, includes: at least one processor and a memory.
  • the at least one processor is coupled to the memory and is used to read and execute instructions in the memory.
  • the device is used to execute methods in each of the above aspects.
  • a computer program product includes: a computer program, which when the computer program is run, causes the computer to perform the methods in the above aspects.
  • a vehicle comprising: at least one processor and a memory, the at least one processor being coupled to the memory and configured to read and execute instructions in the memory, the vehicle being configured to Execute the method in the first aspect above.
  • Figure 1 is a diagnostic system 100 provided by an embodiment of the present application.
  • FIG. 2 is a functional schematic diagram of a vehicle provided by an embodiment of the present application.
  • Figure 3 is a diagnostic solution provided by an embodiment of the present application.
  • Figure 4 is another diagnostic solution provided by the embodiment of the present application.
  • Figure 5 is a diagnostic method 500 provided by an embodiment of the present application.
  • Figure 6 is a system architecture 600 suitable for a diagnostic method provided by an embodiment of the present application.
  • Figure 7 is a schematic diagram of character creation provided by an embodiment of the present application.
  • Figure 8 is a remote diagnosis method 800 provided by an embodiment of the present application.
  • Figure 9 is a method 900 for generating and delivering a diagnostic policy file during remote diagnosis provided by an embodiment of the present application.
  • Figure 10 is a method 1000 for issuing and executing diagnostic tasks during remote diagnosis provided by an embodiment of the present application.
  • Figure 11 is a proximal diagnosis method 1100 provided by an embodiment of the present application.
  • Figure 12 is a method 1200 for generating and delivering a diagnostic policy file during a near-end diagnosis process provided by an embodiment of the present application.
  • Figure 13 is a method 1300 for issuing and executing diagnostic tasks during a near-end diagnosis process provided by an embodiment of the present application.
  • Figure 14 is a schematic diagram of a policy file format provided by an embodiment of the present application.
  • Figure 15 is a flow chart 1500 of policy file authenticity and integrity verification provided by the embodiment of this application.
  • Figure 16 is a method 1600 for using a policy file to control diagnostic tasks or diagnostic commands provided by an embodiment of the present application.
  • Figure 17 is a specific implementation manner of a policy file provided by the embodiment of this application.
  • Figure 18 is a diagnostic device 1800 provided by an embodiment of the present application.
  • Figure 19 is another diagnostic device 1900 provided by an embodiment of the present application.
  • Figure 1 is a diagnostic system 100 provided by an embodiment of the present application.
  • 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 can be a physical server or a virtual server. When the cloud server 110 is a virtual server, it can be located around the world to provide services for vehicles in different countries and regions.
  • the diagnostic platform 111 can connect to the vehicle 140 through the 4G/5G network and directly issue diagnostic commands to the vehicle 140 for vehicle diagnosis. This diagnostic method can also be called remote diagnosis.
  • Other services 112 may include: collecting and analyzing vehicle component operation data or providing data value-added services such as software upgrade services to vehicles.
  • the diagnostic instrument 120 can synchronize information with the cloud server 110 through the 4G/5G network, and can send diagnostic commands to diagnose the vehicle by connecting to the vehicle's on-board diagnostic system (OBD) interface. This diagnostic method Also called proximal diagnosis.
  • OBD on-board diagnostic system
  • the diagnostic module 130 is located in the vehicle 140 , and 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 can receive diagnostic commands from the cloud server 110 or the diagnostic device 120 and use the diagnostic policy file to verify the diagnostic commands.
  • the diagnostic strategy module 132 can check the diagnostic strategy file and perform vehicle status monitoring. When the status of the vehicle meets preset conditions, the diagnostic strategy module 132 can send diagnostic commands to the electronic control unit (ECU) via the diagnostic agent module 133. . For example, it may be set that when the vehicle's driving speed is less than 3 km/h, the diagnosis strategy module 132 may send a diagnosis command to the diagnosis agent module 133 .
  • the diagnostic agent module 133 may forward the diagnostic command sent by the diagnostic policy module 132 to the ECU through controller area network (CAN) processing or Ethernet processing.
  • CAN controller area network
  • the diagnosis strategy module 132 sends the diagnosis command to the diagnosis agent module 133 for the safety of the vehicle, because the vehicle needs to call when performing the diagnosis task. Certain resources, therefore, performing diagnostic tasks while the vehicle is traveling at high speed may have an impact on other functions of the vehicle.
  • FIG. 2 is a functional schematic diagram of a vehicle provided by an embodiment of the present application.
  • the vehicle 200 in FIG. 2 may be the vehicle 140 in FIG. 1 . It should be understood that FIG. 2 and related descriptions are only an example and do not limit the vehicle in the embodiment of the present application.
  • the vehicle 200 may be configured in a fully or partially autonomous driving mode, or may be manually driven by a user.
  • Vehicle 200 may include various subsystems, such as computing platform 210 and display device 220 .
  • vehicle 200 may include more or fewer subsystems, and each subsystem may include one or more components.
  • each subsystem and component of the vehicle 200 can be interconnected through wired or wireless means.
  • the computing platform 210 may include processors 211 to 21n (n is a positive integer).
  • a processor is a circuit with signal processing capabilities.
  • the processor may be a circuit with instruction reading and execution capabilities.
  • CPU central processing unit
  • microprocessor graphics processing unit
  • GPU graphics processing unit
  • DSP digital signal processor
  • the processor can realize certain functions through the logical relationship of the hardware circuit. The logical relationship of the hardware circuit is fixed or can be reconstructed.
  • the processor is an application-specific integrated circuit (application-specific integrated circuit). ASIC) or programmable logic device (PLD) implemented hardware circuit, such as FPGA.
  • ASIC application-specific integrated circuit
  • PLD programmable logic device
  • the process of the processor loading the configuration file and realizing the hardware circuit configuration can be understood as the process of the processor loading instructions to realize the functions of some or all of the above units.
  • 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), tensor processing unit (TPU), deep learning processing Unit (deep learning processing unit, DPU), etc.
  • the computing platform 210 may also include a memory, which is used to store instructions. Some or all of the processors 211 to 21n may call instructions in the memory to execute the quality to implement corresponding functions.
  • Computing platform 210 may control functionality of vehicle 200 based on input received from various subsystems. In some embodiments, computing platform 210 is operable to provide control of many aspects of vehicle 200 and its subsystems.
  • vehicle 200 or a sensing and computing device associated with vehicle 200 may perform motion detection based on characteristics of the identified objects and the state of the surrounding environment (eg, traffic, rain, ice on the road, etc. etc.) to predict the behavior of the identified object.
  • each recognized object depends on the behavior of each other, so it is also possible to predict the behavior of a single recognized object by considering all recognized objects together.
  • the vehicle 200 is able to adjust its speed based on the predicted behavior of the identified objects.
  • the autonomous vehicle is able to determine what stable state the vehicle will need to adjust to (eg, accelerate, decelerate, or stop) based on the predicted behavior of the object.
  • other factors may also be considered to determine the speed of the vehicle 200, such as the lateral position of the vehicle 200 in the road on which it is traveling, the curvature of the road, the proximity of static and dynamic objects, and so on.
  • the computing device may also provide instructions to modify the steering angle of the vehicle 200 so that the autonomous vehicle follows a given trajectory and/or maintains contact with objects in the vicinity of the autonomous vehicle (e.g., , the safe lateral and longitudinal distance between cars in adjacent lanes on the road).
  • objects in the vicinity of the autonomous vehicle e.g., , the safe lateral and longitudinal distance between cars in adjacent lanes on the road.
  • the above-mentioned vehicle 200 may be a car, a truck, a motorcycle, a public vehicle, a boat, an airplane, a helicopter, a lawnmower, an entertainment vehicle, a playground vehicle, construction equipment, a tram, a golf cart, a train, etc., in the embodiment of the present application No special restrictions are made.
  • Figure 3 is a diagnostic solution provided by an embodiment of the present application.
  • the diagnostic solution shown in Figure 3 can be applied to the diagnostic system 100 of Figure 1.
  • the diagnostic solution shown in Figure 3 can include the following steps.
  • the client sends a "client hello" message to the server, which contains password information and the string "client random”.
  • the client may refer to the diagnostic platform 111 or the diagnostic instrument 120 in Figure 1
  • the server may refer to the diagnostic module 130 in Figure 1 .
  • the server responds with the "server hello” message, which contains the password combination and digital certificate, as well as the random string "server random”, etc.
  • the digital certificate can include: public key, issuing authority information, company name, domain name, validity period, etc.
  • the client verifies the digital certificate and obtains the public key from the certificate, generates the next random string premaster secret and encrypts it with the public key.
  • the server uses the private key to decrypt and obtain the "premaster secret”.
  • the client sends a "finished" message to the server.
  • steps S301 to S309 are the specific process of authenticating communication equipment outside the vehicle through the transport layer security protocol (transport layer security, TLS).
  • transport layer security transport layer security
  • the diagnostic platform or diagnostic instrument may be attacked by hackers, and hackers may steal or tamper with diagnostic instructions after invading the client. Since the user's identity cannot be verified through the above method, once the vehicle executes diagnostic instructions tampered with by hackers, the user's property may be damaged.
  • the equipment operation and maintenance personnel of the diagnostic platform or diagnostic instrument may perform operations beyond the scope of their duties, causing the diagnostic instructions to be inconsistent with the user's intentions. Since this situation cannot be identified through the above method, once the vehicle performs operations that are not in line with the user's intentions, Diagnostic instructions for operating purposes may cause the user's privacy and property security to be unprotected.
  • Figure 4 is another diagnostic solution provided by an embodiment of the present application.
  • the diagnostic solution shown in Figure 4 can be applied to the diagnostic system 100 of Figure 1.
  • the diagnostic solution shown in Figure 4 can include the following steps.
  • the client requests a seed from the server
  • the server sends a random seed to the client
  • the client sends the calculated KEY to the server
  • the server can compare its own stored KEY 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 they are different, it can send an unlocking failure instruction in step S404. instructions.
  • steps S401 to S404 are specific processes executed using unified diagnostic services 27 (unified diagnostic services 27, UDS 27).
  • USD 27 mainly uses seeds and keys to provide a protection mechanism for the ECU.
  • the target ECU controls access to sensitive diagnostic services (for example, writing data to the ECU) through the secure access service. Only after passing the secure access service can the ECU perform sensitive diagnostic services.
  • the UDS 27 security access service is a service-oriented access control, that is, this method can only protect the preset sensitive diagnostic services. Therefore, when using this method to perform other services other than sensitive diagnostic services, the diagnostic commands are easily accessible to diagnostic personnel or Malicious diagnosis and illegal manipulation by hackers. Moreover, since this method lacks a diagnostic access control mechanism for vehicles and components, specific components of the vehicle are easily maliciously diagnosed by diagnosticians or hackers.
  • Embodiments of this application provide a diagnostic method that can prevent the vehicle from executing incorrect or illegal diagnostic commands and protect the user's property and privacy.
  • Figure 5 is a diagnostic method 500 provided by an embodiment of the present application.
  • the method 500 may include the following steps:
  • the first diagnosis policy file includes: access control policy information.
  • the diagnostic equipment may include: a remote diagnostic platform or a local diagnostic instrument.
  • the 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 authorization type may refer to the type of the diagnostic policy file, for example, the remote diagnosis type or the local diagnosis type.
  • the vehicle identity information and identification ID can be used to check the legitimacy of the diagnosis target, and the validity period can be used to monitor the validity of the diagnosis time.
  • the version may refer to the format version of the first diagnostic strategy file, and the record of the version may facilitate future updates to the format file.
  • the signature can refer to the signature of the cloud authorization management system, which can be verified on the vehicle. If the signature is passed, the authenticity and integrity of the diagnostic policy file itself are guaranteed.
  • receiving the first diagnostic strategy file sent by the diagnostic device includes: receiving the first diagnostic strategy file sent by the diagnostic device with the authorization of the vehicle owner.
  • car owner authorization can be authorized with a certain time limit through online/offline service agreements or phone calls to meet privacy compliance requirements.
  • the vehicle owner needs to sign or check the diagnostic service agreement before the diagnosis can begin.
  • the vehicle can only perform diagnostic tasks after the vehicle detects that the owner has signed or checked the diagnostic service agreement.
  • the diagnostic service agreement may include but is not limited to: diagnostic objects, diagnostic permissions, resources that the vehicle needs to call to perform diagnostic tasks, etc.
  • the car owner before the diagnosis is started, the car owner can request vehicle diagnosis by phone. In this case, the car owner can be deemed to have agreed to the diagnostic service agreement.
  • car owners can trigger the diagnostic process through an app on the vehicle.
  • the vehicle can receive the first diagnostic policy file only with the authorization of the vehicle owner, so that the access control policy information in the first diagnostic policy file can be used to subsequently verify whether the diagnostic command has access control permissions.
  • the diagnostic device includes: a proximal diagnostic instrument
  • the first diagnostic policy file includes: a first key
  • the method further includes: saving the first key in the vehicle.
  • the vehicle is the vehicle on which the diagnostic command is to be executed; verify whether the first key and the second key are consistent, and the second key is the key stored in the near-end diagnostic instrument; in When the first key and the second key are consistent, a secure access service is established with the near-end diagnostic instrument.
  • a secure access service can be established between the vehicle and the near-end diagnostic instrument. After the secure access service is established, the near-end diagnostic instrument can use the key in the diagnostic policy file. Access control policy information to verify whether the diagnostic command has diagnostic control permissions.
  • both the first key and the second key may be temporary keys, and the application process of the first key and the second key may be: first, the key management system generates the second key and The key is sent to the authorization management system. After generating the first diagnosis strategy file, the authorization management system sends the second key along with the first diagnosis strategy file to the near-end diagnostic instrument, and the near-end diagnostic instrument obtains the second key. The second key can then be saved to the local diagnostic instrument. Then, the near-end diagnostic instrument delivers the first key along with the first diagnosis policy file to the vehicle, and the vehicle saves the first key.
  • the second 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 near-end 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 unsafe.
  • the near-end diagnostic instrument can send a ciphertext to the vehicle, and the vehicle verifies the ciphertext to determine whether the first key and the second key are consistent.
  • the near-end diagnostic instrument can directly send the saved second key to the vehicle, and the vehicle verifies the first key and Whether the second key is consistent.
  • the reason for verifying whether the first key and the second key are consistent is to be compatible with the old version of the near-end diagnostic instrument. If the diagnostic user uses the old version of the near-end diagnostic instrument to diagnose the vehicle, the key will not be used. Verification may cause the execution of diagnostic commands to fail.
  • the diagnostic device includes: a proximal diagnostic instrument, and the method further includes: receiving a first key sent by the proximal diagnostic instrument; and storing the first key in the vehicle.
  • the vehicle is the vehicle on which the diagnostic command is to be executed; verify whether the first key and the second key are consistent, and the second key is the key stored in the near-end diagnostic instrument; in When the first key and the second key are consistent, a secure access service is established with the near-end diagnostic instrument.
  • both the first key and the second key may be temporary keys, and the application process of the first key and the second key may be: first, the key management system generates the second key and transfers the second key to the temporary key. After being sent to the local diagnostic instrument, the local diagnostic instrument saves it. Then, the near-end diagnostic instrument directly delivers the first key to the vehicle, and the vehicle saves the first key.
  • 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 near-end 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 unsafe.
  • Various methods may be used to verify the authenticity and integrity of the first diagnostic policy file.
  • the access control policy information includes: a certificate and a signature
  • verifying the authenticity and integrity of the first diagnostic policy file includes: decrypting the signature using the public key of the certificate, Obtain a first digital digest; perform hash calculation on the access control policy information to obtain a second digital digest; verify whether the first digital digest and the second digital digest are consistent.
  • the method also includes verifying the authenticity and validity of the certificate before using the certificate to decrypt the signature.
  • a symmetric key may also be used to verify the authenticity and integrity of the first diagnosis policy file.
  • Use the symmetric key to perform encryption calculations 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.
  • the access control policy information may include the first digital digest without having to use the public key to decrypt the signature to obtain the first digital digest.
  • the access control policy information can be hashed to obtain the second digital summary, and the second digital summary can be compared with the first digital summary to verify the authenticity and integrity of the first diagnostic policy file.
  • the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, which can further protect the user's property. and privacy security.
  • the verifying the authenticity and integrity of the first diagnostic policy file includes: verifying whether the first vehicle identity information matches the vehicle, and the The vehicle is the vehicle on which the diagnostic command is to be executed.
  • the first vehicle identity information is a vehicle identification number.
  • the first vehicle identification number can be compared with the vehicle's identification code to determine whether the first vehicle identification number matches the vehicle. If the two are consistent, the verification is passed. If If the two are inconsistent, the verification fails.
  • the vehicle identification code can be viewed on the front partition of the vehicle engine compartment or on the vehicle dashboard.
  • the authenticity and integrity of the first diagnosis policy file can be verified by determining whether the first vehicle identity information matches the vehicle. In this way, the authenticity and integrity of the first diagnosis policy file pass the verification In this case, the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, which can further protect the user's property and privacy security.
  • the method before receiving the first diagnosis policy file sent by the diagnosis device, the method further includes: receiving a second diagnosis policy file sent by the diagnosis device, The second diagnostic file includes: a third timestamp; and verifying the authenticity and integrity of the first diagnostic policy file includes: verifying whether the first timestamp is greater than the third timestamp.
  • the time at which the vehicle receives the second diagnosis strategy file is earlier than the time at which the first diagnosis strategy file is received.
  • the second diagnostic strategy file may be the diagnostic strategy file used when the diagnostic command was last executed, or may 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 policy file has been reused or replayed. If the first timestamp is less than the third timestamp, it means that the first diagnostic policy file may be reused or replayed in a replay attack, and the policy file is not authentic. If the first timestamp is greater than the third timestamp, the authenticity and integrity verification of the first diagnostic policy file is passed.
  • the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, which can further protect the user's property and privacy security.
  • the verifying the authenticity and integrity of the first diagnostic policy file includes: determining whether the difference between the first timestamp and the vehicle local time is less than or equal to the preset threshold.
  • the difference between the first timestamp and the vehicle's local time is less than or equal to the preset threshold, the authenticity and integrity verification of the first diagnostic policy file is passed. If the difference between the first timestamp and the vehicle's local time is greater than the preset threshold, it indicates that the first diagnostic policy file may be reused or replayed.
  • the access control policy information in the first diagnostic policy file is used to verify whether the diagnostic command has access control permissions, which can further protect the user's property and privacy security.
  • each of the above methods of verifying the authenticity and integrity of the first diagnostic policy file can be used individually or in combination.
  • the method of verifying whether the first vehicle identity information matches the vehicle can be used alone. When used alone, it is determined that the first vehicle identity information matches the vehicle, and the authenticity and integrity of the first diagnostic policy file are verified.
  • the consistency verification of the first digital abstract and the second digital abstract can be performed first, and then the verification of whether the first vehicle identification number matches the vehicle. When both verifications pass, the authenticity of the first diagnostic policy file and integrity verification is passed.
  • the access control policy information in the first diagnostic policy file can be used to verify whether the diagnostic command has access control permissions. Diagnostic commands can only be executed if they have access control permissions. In this way, the vehicle can be prevented from executing incorrect or illegal diagnostic commands, and the user's property and privacy can be protected.
  • using the access control policy information to verify whether the diagnostic command has access control permissions can be implemented in various ways.
  • the access control policy information includes: a validity period, and verifying whether the diagnostic command has access control permissions according to the access control policy information includes: using the access control policy within the validity period The information verifies that the diagnostic command has access control permissions.
  • the access control policy information in the diagnostic policy file is used to verify whether the diagnostic command has access control permissions. In this way, it is possible to prevent the diagnostic policy file from being used even after it expires, thereby improving the security of the use of the diagnostic policy file.
  • the access control policy information also includes: first vehicle identity information, and verifying whether the diagnostic command has access control permissions according to the access control policy information includes: verifying the first vehicle identity. Whether the information is consistent with the second vehicle identity information, the diagnostic command includes the second vehicle identity information.
  • the first vehicle identity information may be information used to represent the vehicle identity, which may include but is not limited to a vehicle identification number.
  • the diagnosis may be determined. Commands have access control permissions.
  • the first vehicle identity information and/or the second vehicle identity information is a vehicle identification number.
  • the access control policy information also includes: a first identification ID, and the first identification ID includes: a first electronic control unit ID, a first CAN ID, a first diagnostic service ID, and a first identification ID. at least one of the diagnostic data IDs; the use of the access control policy information to verify whether the diagnostic command has access control permissions includes: verifying whether the first identification ID and the second identification ID are consistent, and the second The identification ID is the identification ID in the diagnosis 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.
  • the diagnostic command take effect on the corresponding electronic control unit or the vehicle can use the corresponding diagnostic service or diagnostic data.
  • the second electronic control unit ID may be the ID of the electronic control unit targeted by the diagnostic command
  • the second CAN ID may represent the address or name of the CAN node that sends and receives the diagnostic command
  • the second diagnostic service ID may be the diagnostic command.
  • the required service ID and the second diagnostic data ID may be the data ID required to perform diagnostic services or diagnostic commands.
  • the diagnostic command take effect on the corresponding electronic control unit or the vehicle can use the corresponding diagnostic service or diagnostic data. In this way, it not only provides a diagnostic access control mechanism for vehicles and components, but also provides an access mechanism for diagnostic services, ensuring the safety and effectiveness of diagnostic commands.
  • the access control policy information further includes: a first timestamp
  • using the access control policy information to verify whether the diagnostic command has access control permission includes: verifying whether the second timestamp is greater than the first timestamp, and the second timestamp is the timestamp of the diagnostic command
  • the diagnosis command if the second timestamp is greater than the first timestamp, the diagnosis command has access control authority; if the second timestamp is less than the first timestamp, the diagnosis command does not have access control authority.
  • the diagnostic command has access control permissions.
  • the purpose of ensuring whether 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 vehicle receives the diagnostic command later than the time it receives the diagnostic policy file. time.
  • the diagnosis task is prevented from being reused or replayed, and the user's property security and privacy security can be further ensured.
  • method 500 introduces the process of using the first diagnostic policy file to verify the validity of the diagnostic command with the vehicle as the subject.
  • the vehicle can be a shared taxi or a private car, or the vehicle in method 500 can also be replaced with a home or private car. Commercial smart car charging pile.
  • the following uses the diagnostic platform or authorization management system as the main body to introduce the generation and delivery process of the first diagnostic policy file.
  • Embodiments of the present application provide another diagnostic method, which method is applied to diagnostic equipment.
  • the diagnostic equipment includes: a remote diagnostic platform or a proximal diagnostic instrument.
  • the method includes: sending a first request information to an authorization management system, and the first request information is sent to an authorization management system.
  • a request message is used to request the authorization management system to generate a first diagnosis policy file, and the first diagnosis policy file is used to verify whether the diagnosis command has access control permissions; receiving the first diagnosis policy sent by the authorization management system file; sending the first diagnosis strategy file to a vehicle, where the vehicle is the vehicle to be executed with the diagnosis command.
  • the diagnostic device receives the first diagnostic policy file from the authorization management system and forwards it to the vehicle, so that subsequent vehicles can use the first diagnostic policy file to verify whether the diagnostic command has access rights.
  • the method before sending the first request information to the authorization management system, the method further includes: obtaining the identity information of the diagnostician; sending the identity information of the diagnostician to the authorization management system;
  • the 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 The message is used to indicate that the diagnostician's authentication was successful.
  • the identity information of the diagnostician can be expressed in various forms.
  • the identity information of the diagnostician can be account information.
  • the account information can be created by the OEM, and the account and password are assigned to the diagnostician.
  • the diagnostician can log in to the diagnostic platform on the diagnostic platform. Or enter the account number and password on the diagnostic tool.
  • the identity information can be the facial feature information of the diagnostician.
  • the OEM can enter the facial feature information of the qualified diagnostician into the diagnostic device or diagnostic platform in advance.
  • the diagnostician needs to verify the facial feature information on the diagnostic platform or diagnostic device. Log in.
  • the identity information may also be the diagnostician's iris feature information or voiceprint feature information, etc., which will not be described again here.
  • the diagnostician needs to log in on the diagnostic platform before performing diagnosis.
  • the diagnostic equipment needs to send the diagnostician's identity information to the authorization management system, and the authorization management system will verify it. After receiving the verification from the authorization management system, After receiving the success message, the diagnostic device can request the authorization management to send the first diagnostic policy file.
  • an identity verification mechanism for diagnostic personnel is provided, which can prevent the diagnostic platform or diagnostic instrument from being abused or maliciously diagnosed by illegal personnel, causing the user's privacy, property and life safety to be violated.
  • the first diagnosis strategy file includes: a second key
  • the method further includes: converting the second key stored in the diagnostic device, which is the proximal diagnostic instrument.
  • the diagnostic device can obtain the second key from the first diagnostic policy file and save the second key to the diagnostic device to facilitate subsequent vehicle verification of the first key and the second key. consistency.
  • the method further includes: receiving a second key sent by the key management system, saving the second key in the diagnostic device, and sending the first key to the vehicle.
  • the vehicle mentioned above is the vehicle for which the diagnostic command is to be executed.
  • the embodiment of the present application provides another diagnostic method, which method is applied in an authorization management system.
  • the method includes: receiving the first request information sent by the diagnostic device, and generating the first request information according to the first request information. Diagnostic policy file, the first diagnostic policy file is used to verify whether the diagnostic command has access control permission; send the first diagnostic policy file to the diagnostic device.
  • the method before receiving the first request information sent by the diagnostic device, the method further includes: receiving diagnostic personnel identity information sent by the diagnostic device; If the identity information preset in the authorization management system is consistent, first response information is sent to the diagnostic device, and the first response information is used to indicate that the identity verification of the diagnostic personnel is successful.
  • various methods can be used to verify the diagnostician's identity information. 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. After successful verification, it will send a third message to the diagnostic device. A response message used to inform the diagnostician that the authentication is successful. For another example, if the identity information of the diagnostician is facial feature information, the authorization management system can compare the facial feature information with the facial feature information preset in the system, and then send the first response information to the diagnostic device after the verification is successful, using Yu notifies the diagnostician that the identity verification is successful.
  • the authorization management system can verify the identity information, and then identify the legitimacy of the diagnosis user. Only when the identity of the diagnosis user is legal, can the authorization management system verify the identity information of the diagnostic personnel.
  • the diagnostic device sends the first diagnostic policy file. In this way, the identity verification mechanism of the diagnostic personnel is provided before diagnosis, which can prevent the diagnostic platform or diagnostic instrument from being abused or maliciously diagnosed by illegal persons, resulting in the user's privacy, property and life. Security violated.
  • FIG. 6 is a system architecture 600 applicable to a diagnostic method provided by an embodiment of the present application.
  • the system architecture 600 may be a system architecture applicable to the method 500 .
  • the system architecture 600 may include: a cloud server 610 , a remote diagnostician 620 , a diagnostic instrument 630 , a local diagnostician 640 , a vehicle authorization module 650 and a vehicle 660 .
  • the cloud server 610 may also include: a remote diagnosis platform 611 and an authorization management system 612.
  • the remote diagnosis platform 611 includes a user login module 613
  • 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 and control module 661.
  • the vehicle 600 may be the vehicle 200 in FIG. 2 .
  • OEMs can create roles using the role creation method shown in Figure 7. As shown in Figure 7, the OEM can create roles based on the authorization control system 700 (role-based access control, RBAC).
  • the RBAC system may include: system administrator 701, security administrator 702, and audit administrator 703. Among them, the system administrator 701 can be responsible for creating roles, the security administrator 702 can be responsible for authorizing the created roles, and the audit administrator 703 can be responsible for checking the creation and authorization of roles. That is, the authorization of the above three roles in the RBAC system can be based on separation of powers.
  • the system management administrator 701 can create a role type.
  • the security administrator 702 gives corresponding permissions to different types of roles, and then the audit administrator 703 checks.
  • the remote diagnostic role grants diagnostic service permissions with only read capabilities (for example, with read-only security identifier (SID) permissions).
  • the role grants the diagnostic service permissions that can read and write (for example, have read and write SID permissions).
  • RBAC is a type of authorization management system 612 in Figure 6.
  • RBAC is only an exemplary illustration, and other authorization management systems can also be used to create roles here.
  • OEM can create user accounts for diagnosticians. When creating accounts, diagnosticians can be assigned corresponding roles. Diagnostics with corresponding roles will have corresponding diagnostic service permissions. At the same time, the OEM can also configure corresponding vehicle resource permissions for the account, that is, which models and parts the user can diagnose.
  • an OEM-type diagnostician can be configured to diagnose the entire vehicle component of the first model, while a supplier-type diagnostician can diagnose specific components of the first model.
  • car owners Before diagnosis begins, car owners can authorize a certain time limit through online/offline service agreements or phone calls to meet privacy compliance requirements.
  • the vehicle owner needs to sign or check the diagnostic service agreement before the diagnosis can begin.
  • the vehicle can only perform diagnostic tasks after the vehicle detects that the owner has signed or checked the diagnostic service agreement.
  • the diagnostic service agreement may include but is not limited to: diagnostic objects, diagnostic permissions, resources that the vehicle needs to call to perform diagnostic tasks, etc.
  • the car owner can request vehicle diagnosis by phone.
  • the car owner can be deemed to have agreed to the diagnostic service agreement.
  • the remote diagnostic personnel 620 need to log in through the user login module 631 and have the user identity verified by the user management module 614.
  • the policy generation module 615 can generate a diagnostic policy file , and deliver the diagnosis policy file to the vehicle 600 through the remote diagnosis platform 611.
  • the local diagnostic personnel 640 need to log in through the user login module 631, and the user identity is verified by the user management module 614.
  • the policy generation module 615 generates a diagnosis policy file and then downloads the diagnosis policy file through the diagnostic instrument 630. Sent to vehicle 600.
  • the diagnostic policy file can be checked through the policy management and control module 661 .
  • the car owner can manage the diagnosis policy file from the perspective of privacy compliance through the car owner authorization module 650.
  • a diagnostician when a diagnostician makes a diagnosis, he or she needs to log in to a corresponding account on the diagnostic platform or diagnostic instrument, and the authorized platform verifies the identity of the diagnostician. Only after the identity verification is successful can the diagnostic platform or diagnostic instrument download the vehicle to the vehicle. Issuing a diagnostic policy file can reduce the risk of the diagnostic platform or diagnostic instrument being abused or maliciously diagnosed by illegal persons, thus protecting the user's privacy, property and life safety.
  • Figure 8 is a remote diagnosis method 800 provided by an embodiment of the present application.
  • the method 800 can be applied to the system architecture of Figure 6.
  • vehicle information synchronization may include: the vehicle sends vehicle model data, bicycle data and component data to a cloud server, and the cloud server completes vehicle information synchronization.
  • the process of configuring diagnostic data may include: the diagnostic platform determines the corresponding vehicle model based on the above data, and generates a diagnostic script and generates diagnostic data.
  • the diagnostic script may include a diagnostic script for vehicle components and/or a diagnostic script for a vehicle model, and the diagnostic data may include at least one of component diagnostic data ID, diagnostic trouble code, and component diagnostic parameter.
  • Method 800 can include the following steps:
  • the diagnostic user enters the user name and password to log in.
  • the diagnostic user enters the account username and password created by the OEM on the diagnostic platform to log in.
  • the authorization management system authenticates the user name and password.
  • the authorization management system 612 can perform identity verification on the user name and password input by the diagnostician in step S801. If the verification is successful, proceed to step S803. If the verification fails, the diagnostic user will be prompted with a login failure and the diagnosis process will be ended.
  • the diagnostic user enters the menu with corresponding permissions.
  • the diagnostic user can view the diagnostic permissions in the permission menu.
  • the diagnostic user can only issue diagnostic policies within this permission. Diagnostic policies issued beyond this permission are invalid.
  • the diagnostic user selects the vehicle model and components that need to be diagnosed.
  • the authorization management system generates a diagnosis policy file based on the diagnosis user's selection and delivers it to the vehicle end.
  • the diagnostic policy file can be used to check the authenticity and completeness of the diagnostic instructions.
  • the diagnostic function may be generated by a diagnostic script, and the diagnostic function may include one or more of: reading fault codes, clearing fault codes, vehicle scanning, component judgment, and other diagnoses.
  • the diagnostic task is sent to the vehicle end and executed.
  • 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 terminal for execution.
  • the vehicle after the vehicle completes the diagnosis task, it can report the execution results and execution data to the diagnosis platform, and the diagnosis platform compares the execution results and diagnosis data to analyze the vehicle's execution of the diagnosis task.
  • the identity information of the diagnostician needs to be verified. Only when the identity information of the diagnostician meets the regulations can the diagnostician issue diagnostic instructions to the vehicle within the scope of authority through the diagnostic platform or Diagnostic policy file. In this way, people outside the scope of diagnostic authority can be prevented from illegally manipulating vehicle and component resources, and the security of remote diagnosis can be improved.
  • Figure 9 is a method 900 for generating and delivering a diagnostic policy file during remote diagnosis provided by an embodiment of the present application.
  • the method 900 may be the specific process of step S805 in Figure 8.
  • the method 900 may include the following steps.
  • the diagnostic platform generates a diagnostic policy request range
  • the diagnostic policy request scope may include: authorization type, diagnostic target, diagnostic validity period, etc.
  • the diagnostic platform submits an authorization request to the authorization management system
  • the diagnosis platform sends authorization request information to the authorization management system, and the information is used to request the diagnosis authorization management system to generate and return a diagnosis policy file according to the diagnosis policy request range.
  • the authorization request information may be the first request information in method 500.
  • the authorization management system generates a diagnostic policy file
  • the authorization management system generates a diagnostic policy file based on the authorization request information.
  • the specific content of the diagnostic policy file is introduced in detail in Figure 14.
  • the purpose of integrity protection for the diagnostic policy file is to prevent the diagnostic policy file from being illegally tampered with.
  • the integrity protection of the diagnostic policy file can be achieved by signing the diagnostic policy file.
  • the diagnostic platform issues the diagnostic policy file to the vehicle-side diagnostic module.
  • the vehicle-side diagnostic module may be the diagnostic client module 131 in Figure 1 .
  • the vehicle-side diagnostic module verifies the authenticity and integrity of the diagnostic policy file.
  • the vehicle-side diagnostic module stores the diagnostic policy file in the vehicle after it passes the verification.
  • the authorization management system can generate and deliver a diagnostic policy file to the vehicle terminal according to the policy request range of the diagnostic platform.
  • the vehicle terminal diagnostic module can store the diagnostic policy file after verifying its authenticity and integrity. Facilitates subsequent detection and verification of diagnostic instructions.
  • Figure 10 is a method 1000 for issuing and executing diagnostic tasks during remote diagnosis provided by an embodiment of the present application.
  • the method 1000 may be the specific process of step S807 in Figure 8.
  • the method 1000 may include the following steps.
  • the diagnostic platform performs integrity protection on diagnostic tasks or commands.
  • the purpose of integrity protection of diagnostic tasks or commands by the diagnostic platform is to prevent the diagnostic tasks or commands from being illegally tampered with.
  • the specific implementation method may be to encrypt the diagnostic tasks or commands when the diagnostic platform and the vehicle establish a communication channel. method for integrity protection.
  • the diagnostic platform issues diagnostic tasks or commands to the vehicle-side diagnostic module.
  • the vehicle-side diagnostic module may be the diagnostic module 130 in FIG. 1 .
  • the vehicle-side diagnostic module checks the diagnostic task and command integrity
  • the vehicle-side diagnostic module verifies the validity of the diagnostic task or command through the diagnostic policy file.
  • this step can also be understood as using the diagnostic policy file to verify whether the diagnostic task or diagnostic command has access control permissions.
  • the vehicle-side diagnostic module sends commands to the corresponding ECU for execution.
  • the vehicle-side diagnostic module may send the diagnostic command to the ECU for execution through the diagnostic agent module 133 .
  • the ECU may return the diagnosis result to the diagnosis agent module 133 .
  • the vehicle-side diagnosis module returns the diagnosis results to the diagnosis platform through the diagnosis client.
  • the diagnosis agent module 133 can send the diagnosis results to the diagnosis platform through the diagnosis client module 131 .
  • the 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 diagnostic tasks or diagnostic commands can be ensured on the vehicle side.
  • Figure 11 is a proximal diagnosis method 1100 provided by an embodiment of the present application.
  • the method 1100 can be applied to the system architecture of Figure 6.
  • the method 1100 can include the following steps.
  • the username and password may be the username and password configured by the OEM for the diagnostic user.
  • the authorization management system can verify the identity of the diagnostic user. After successful verification, step S1104 is executed. If the verification is unsuccessful, the user is prompted to log in failed or steps S1107 to S1109 are executed in sequence.
  • the diagnostician can select the models and vehicle components that need to be diagnosed within the scope of authority.
  • the diagnostic authorization management system generates a diagnostic policy file and sends it to the vehicle terminal through the diagnostic instrument.
  • the diagnostic user can select a diagnostic function on the diagnostic instrument, and the diagnostic function may include one or more of: reading fault codes, clearing fault codes, vehicle scanning, component diagnosis, and other diagnoses. Since the diagnostic user has completed the authentication, when selecting the above diagnostic function, the diagnostic user also obtains read and write permissions. After the diagnostic user selects the diagnostic function, step S1108 can be directly performed.
  • the permissions and the menu for selecting the diagnostic function are different from those in the case of successful login.
  • step S1102 the diagnostic user operates the diagnostic instrument to select a diagnostic function without logging in or failing to log in, the diagnostic user can only obtain read-only permissions at this time, and the diagnostic functions that can be selected may include: reading fault codes , vehicle scanning and other diagnostic functions.
  • the diagnosis command is sent to the vehicle by the diagnostic instrument and executed by the ECU in the vehicle.
  • the vehicle After executing the diagnostic command, the vehicle returns the diagnostic result to the diagnostic instrument.
  • the identity information of the diagnostician needs to be verified.
  • the diagnostician can choose more diagnostic functions and obtain more diagnostic permissions. Large, in this way, different types of diagnostic personnel can be given corresponding diagnostic authority, ensuring that different types of diagnostic personnel can issue diagnostic commands within the corresponding authority range.
  • Figure 12 is a method 1200 for generating and delivering a diagnostic policy file during a near-end diagnosis process provided by an embodiment of the present application.
  • the method 1200 may be the specific process of step S1105 in Figure 11, and the method 1200 may include the following steps.
  • the diagnostic policy request scope may include: authorization type, diagnostic target, diagnostic validity period, etc.
  • the diagnostic instrument submits an authorization request to the authorization management system
  • the diagnostic instrument sends authorization request information to the authorization management system, and the information is used to request the diagnosis authorization management system to generate and return a diagnosis policy file according to the diagnosis policy request range.
  • the authorization request information may be the first request information in method 500.
  • the authorization management system generates a diagnostic policy file
  • the authorization management system generates a diagnostic policy file based on the authorization request information.
  • the specific content of the diagnostic policy file is introduced in detail in Figure 14.
  • the purpose of integrity protection for the diagnostic policy file is to prevent the diagnostic policy file from being illegally tampered with.
  • the integrity protection of the diagnostic policy file can be achieved by setting a signature on the diagnostic policy file.
  • the diagnostic instrument forwards the diagnostic policy file to the vehicle-side diagnostic module
  • the vehicle-side diagnostic module verifies the authenticity and integrity of the diagnostic policy file.
  • the vehicle diagnostic module stores the diagnostic policy file in the vehicle after it passes the verification.
  • the authorization management system can generate and deliver a diagnostic policy file to the vehicle based on the policy request range of the diagnostic instrument.
  • the vehicle diagnostic module can store the diagnostic policy file after integrity verification to facilitate subsequent detection. and verify diagnostic commands.
  • Figure 13 is a method 1300 for issuing and executing diagnostic tasks during a near-end diagnosis process provided by an embodiment of the present application.
  • Method 1300 may be the specific process of step S1106 or S1107 in Figure 11, and method 1300 may include the following steps.
  • the diagnostic instrument performs integrity protection on diagnostic tasks or commands.
  • the purpose of integrity protection of diagnostic tasks or diagnostic commands by the diagnostic instrument is to prevent the diagnostic tasks or commands from being illegally tampered with.
  • the diagnostic instrument sends the diagnostic task or command to the vehicle-side diagnostic module.
  • the vehicle-side diagnostic module may be the diagnostic module 130 in Figure 1 .
  • the vehicle-side diagnostic module checks the diagnostic task and command integrity
  • the vehicle terminal diagnostic module checks the diagnostic task or command through the diagnostic policy file.
  • this step can also be understood as using the diagnostic policy file to verify whether the diagnostic task or diagnostic command has access control permissions.
  • the vehicle-side diagnostic module after passing the check, sends a command to the corresponding ECU and executes it.
  • the vehicle-side diagnostic module may send the diagnostic command to the ECU for execution through the diagnostic agent module 133 .
  • the ECU may return the diagnosis result to the diagnosis agent module 133 .
  • the vehicle-side diagnostic module returns the diagnostic results to the diagnostic instrument through the diagnostic client.
  • the diagnostic agent module 133 may send the diagnostic result to the diagnostic instrument through the diagnostic client module 131 .
  • the 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 validity and legality of the execution of diagnostic tasks or diagnostic commands can be ensured on the vehicle side.
  • FIG. 14 is a schematic diagram of a diagnostic strategy file format provided by an embodiment of the present application.
  • the diagnostic strategy file shown in FIG. 14 may be the diagnostic strategy files in FIGS. 8 to 13 .
  • Diagnostic strategy files are involved in both remote diagnosis and local diagnosis processes.
  • the function 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, diagnostic service The authorized ECU must be diagnosed within the authorized time and space.
  • the format of the diagnostic file may include: authorization type, space domain, time domain, version, signature and certificate.
  • the authorization type may refer to the type of the diagnostic policy file.
  • the type of the diagnostic policy file may refer to local diagnosis or remote diagnosis.
  • the authorization type can indicate that multiple diagnostic policy files can coexist under the same type. For example, diagnostic policy files for local diagnosis and remote diagnosis coexist. It can also indicate that a specific diagnosis policy file type is effective. For example, when the diagnosis policy files for local diagnosis and remote diagnosis coexist, the local diagnosis policy file can be made effective and the remote diagnosis policy file is invalid.
  • the spatial domain can check the legitimacy of the diagnostic target. Verification in the spatial domain can include: vehicle identification number (VIN) verification, ECU verification, CAN ID verification, diagnostic service ID verification and data ID verification. at least one of them.
  • the time domain can be used to monitor the validity of the diagnostic time. Time domain verification can include: checking whether the timestamp of the monitoring script is within the authorized time range and whether the monitoring and diagnosis policy file itself is valid.
  • the version may refer to the format version of the 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 authorization management system. The signature can be verified on the vehicle side. If the verification passes, the authenticity and integrity of the diagnostic policy file itself are guaranteed.
  • the authorization type, space domain, time domain, version, signature and certificate in the diagnostic policy file can also be reflected in the access control policy information in the diagnostic policy file.
  • the format of the diagnostic policy file can be set, so that the diagnostic policy file can be used to check whether the diagnostic command is valid in time and space, thereby ensuring the validity and legality of the diagnostic task or the execution of the diagnostic command on the vehicle end.
  • Figure 15 is a flow chart 1500 for verifying the authenticity and integrity of the diagnostic policy file provided by the embodiment of the present application.
  • the method 1500 may be applied to step S907 in FIG. 9 or step S1207 in FIG. 12 .
  • the diagnostic strategy file is automatically generated and issued by the diagnostic instrument or diagnostic platform based on the diagnostic targets and diagnostic functions selected by the diagnostician, and is automatically used in vehicle-side inspection and control diagnostic commands.
  • the vehicle end can verify the authenticity and integrity of the diagnostic strategy file itself, and store the diagnostic strategy file in the vehicle after successful verification. Therefore, the entire process does not require too much involvement of diagnosticians, thereby reducing the risk of diagnosticians exceeding their authority.
  • the integrity verification and authenticity verification of the diagnostic policy file may include the following steps.
  • 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 ends.
  • S1502 use the certificate public key to decrypt the signature and obtain the digital digest.
  • the vehicle uses the certificate's public key to decrypt the signature of the diagnostic policy file to obtain a digital digest.
  • digital digest can refer to using a one-way Hash function to "digest" the plaintext that needs to be encrypted into a string of fixed-length (128-bit) ciphertext.
  • the digital digest is obtained based on the hash algorithm and can also be called a hash value.
  • the vehicle performs hash calculation on the authorization type, space domain, time domain and version in the diagnostic policy file to obtain a new summary.
  • step S1505 check whether the vehicle comparison summary and the new summary are the same. If they are the same, step S1505 is performed. If they are not the same, the integrity and authenticity verification process of the diagnostic policy file ends.
  • the digital digest is a fixed-length value corresponding to a message or a text
  • the diagnostic policy file received by the vehicle is tampered with during the delivery process, after the vehicle performs the same hash calculation on the received diagnostic policy file, The new summary obtained will be different from the original summary, so the authenticity and completeness of the diagnostic policy file can be verified by comparing whether the two summaries are the same.
  • step S1506 it can be determined whether the measurement file and the vehicle match by whether the VIN of the diagnostic policy 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 policy file ends.
  • the time stamp of the diagnostic policy file is compared with the locally stored timestamp, where the locally stored timestamp may refer to the time stamp 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 of the diagnostic policy file is verified and the vehicle stores the diagnostic policy file in the vehicle and starts calculating the validity period of the diagnostic policy file. If the timestamp of the diagnostic policy file is smaller than the locally stored timestamp, the integrity and authenticity verification process of the diagnostic policy file ends.
  • the purpose of verifying the timestamp of the diagnostic policy file and the time stamp of the local storage is to prevent the diagnostic policy file from being reused or replayed. If the timestamp of the diagnostic policy file is smaller than the time stamp of the local storage, it means that the diagnostic policy file may have been changed and the diagnostic policy file is not authentic.
  • this step can also be replaced by verifying whether the difference between the timestamp parameter of the diagnostic policy file and the vehicle's local time is less than or equal to the preset threshold. If it is less than or equal to the preset threshold, the verification passes; if it is greater than the preset threshold, the verification fails.
  • the vehicle after receiving the diagnostic strategy file, the vehicle can verify the authenticity and integrity of the diagnostic strategy file itself. After the verification is successful, the diagnostic strategy file will be stored in the vehicle, thereby facilitating subsequent use of the diagnostic strategy file for inspection. Diagnostic commands.
  • Figure 16 is a method 1600 for using a policy file to control diagnostic tasks or diagnostic commands provided by an embodiment of the present application.
  • the method 1600 may be applied to step S1004 in FIG. 10 or step S1304 in FIG. 13, and the method 1600 may include the following steps.
  • this step it can be determined whether the diagnostic task matches the vehicle by comparing whether the VIN of the diagnostic task and the VIN of the diagnostic policy file are consistent. If they are consistent, proceed to step S1602; if they are inconsistent, the diagnostic task execution process ends.
  • step S1601 can also be skipped.
  • step S1603 it can be determined whether the timestamp of the diagnosis task is greater than the timestamp of the diagnosis policy file. If it is greater, step S1603 is performed. If it is not greater, the diagnosis task execution process ends.
  • step S1602 can also be skipped.
  • the purpose of ensuring in this step whether the timestamp of the diagnostic task is greater than the timestamp of the diagnostic policy file is to prevent the diagnostic task from being reused or replayed. That is, it is necessary to ensure that the vehicle receives the diagnostic command later than the time it receives the diagnostic policy file. time.
  • this step can check whether the diagnostic command matches the authorized ECU in the diagnostic policy file space domain. If it matches, proceed to step S1604. If it does not match, end the diagnostic task execution process.
  • this step can also be replaced by checking whether the diagnostic command matches one or more of the authorized CAN ID, diagnostic service ID, and diagnostic data ID in the diagnostic policy file space domain.
  • S1604 monitor the validity period of the diagnostic policy file until the diagnostic policy file expires.
  • the diagnostic policy file when the diagnostic policy file is valid, the diagnostic policy file is used to detect the diagnostic task or diagnostic command. If the diagnostic policy file is invalid, the diagnostic process is ended.
  • the diagnostic task can be checked through the diagnostic policy 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 diagnostic tasks or diagnostic commands can be ensured on the vehicle side.
  • the diagnostic service may refer to the corresponding permissions specified in the UDS protocol for remote diagnosis or near-end diagnosis.
  • CDC can refer to the continuous damping control system (continuous damping control, CDC).
  • Car owners can send an application to the diagnostic platform by phone and request the OEM's remote diagnostic personnel to perform diagnosis.
  • Performing diagnosis may specifically include the following steps.
  • OEM remote diagnostic personnel enter their username and password to log in on the diagnostic platform.
  • the authorization management system authenticates the user name and password.
  • the diagnostician selects the car model and diagnostic resources. According to the settings in Table 2, the car model selected by the diagnostician is F4, and the selected diagnostic ECU is the vehicle ECU.
  • the diagnostic platform generates a policy request range based on the F4 model and vehicle component permissions.
  • S1706 The diagnostic platform submits an authorization request to the authorization management system.
  • the authorization management system generates a diagnostic policy file based on the authorization request.
  • S1708 The authorization management system performs integrity protection on the diagnostic policy file.
  • the authorization management system returns the diagnosis policy file to the remote diagnosis platform.
  • the diagnosis platform delivers the diagnosis policy file to the vehicle diagnosis client.
  • the diagnostic client may refer to the diagnostic client module 131 in Figure 1 .
  • the diagnostic client performs integrity verification on the policy file, and stores it after passing the verification.
  • the integrity verification can use the method shown in Figure 15.
  • diagnosis task format described in the above steps S1705 to S1711 can be as shown in (a) in Figure 17, the diagnosis strategy file format can be as shown in Figure 17(b), and the specific implementation method of the diagnosis strategy file can be as shown in Figure 17 (c) is shown.
  • the OEM remote diagnostic personnel selects the vehicle scanning function, and the diagnostic platform generates the corresponding diagnostic task.
  • the diagnostic platform performs integrity protection on the diagnostic task.
  • the diagnosis platform sends the diagnosis task to the vehicle-end diagnosis module.
  • the diagnostic module checks the integrity of the diagnostic task.
  • the diagnostic module may be the diagnostic module 130 in FIG. 1 .
  • S1716 Extract the diagnostic command from the diagnostic task, and check the diagnostic command through the diagnostic policy file.
  • the method shown in Figure 16 can be used to check the diagnostic command through the diagnostic policy file.
  • the diagnostic agent module after passing the check, the diagnostic agent module sends the diagnostic command to the corresponding ECU and executes it.
  • the diagnostic agent module may be the diagnostic agent module 133 in FIG. 1 .
  • the diagnostic agent returns the diagnostic results to the diagnostic platform through the diagnostic client;
  • Figure 18 is a schematic diagram of a diagnostic device 1800 provided by an embodiment of the present application.
  • the device 1800 may be implemented in the vehicle 100 of FIG. 2 .
  • the device 1800 may include a transceiver unit 1810, an acquisition unit 1820, and a processing unit 1830.
  • the transceiver unit 1810 can implement corresponding communication functions, and the transceiver unit 1810 can also be called a communication interface or a communication unit.
  • the acquisition unit 1820 is used to acquire corresponding instructions and/or data.
  • the processing unit 1830 is used to process corresponding instructions and/or data.
  • the processing unit 1830 can read the instructions and/or data in the storage unit, so that the device implements the foregoing method embodiments.
  • the device 1800 also includes a storage unit for storing corresponding instructions and/or data,
  • the device 1800 can be used to perform the actions performed by the vehicle in the above method embodiment.
  • the device 1800 includes: a transceiver unit 1810, configured to receive a first diagnostic policy file sent by a diagnostic device, where the first diagnostic policy file includes: access control policy information, and the diagnostic device includes: a remote diagnostic platform or a near-end diagnostic instrument ;
  • the processing unit 1830 is used to verify the authenticity and integrity of the first diagnosis policy file; the processing unit 1830 is also used to verify the authenticity and integrity of the first diagnosis policy file if the verification is passed. , verify whether the diagnostic command has access control permissions according to the access control policy information.
  • the access control policy information includes: a validity period; the processing unit 1830 is specifically configured to use the access control policy information to verify whether the diagnostic command has access control permissions within the validity period. .
  • the access control policy information also 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, so The diagnostic command includes the second vehicle identity information.
  • the first vehicle identity information and/or the second vehicle identity information is a vehicle identification number.
  • the access control policy information also includes: a first identification ID
  • the first identification ID includes: a first electronic control unit ID, a first CAN ID, a first diagnostic service ID, and a first identification ID.
  • At least one of the diagnostic data IDs; the processing unit 1830 is specifically configured to verify whether the first identification ID and the second identification ID are consistent, and the second identification ID is the identification ID in the diagnosis command, so
  • 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.
  • the access control policy information also includes: a first timestamp; the processing unit 1830 is specifically configured to verify whether the second timestamp is greater than the first timestamp, and the second time Stamp is the timestamp of the diagnostic command.
  • the diagnostic device includes: a proximal diagnostic instrument
  • the first diagnostic policy file includes: a first key
  • the processing unit 1830 is also configured to save the first key In the vehicle, the vehicle is the vehicle on which the diagnostic command is to be executed; the processing unit 1830 is also used to verify whether the first key and the second key are consistent, and the second key is stored in The key in the near-end diagnostic instrument; the processing unit 1830 is also configured to establish a secure access service with the near-end diagnostic instrument when the first key and the second key are consistent.
  • the diagnostic device includes: a proximal diagnostic instrument; the transceiver unit 1810 is also configured to receive the first key sent by the proximal diagnostic instrument; and the processing unit 1830 is also configured to In order to save the first key in the vehicle, the vehicle is the vehicle on which the diagnosis command is to be executed; the processing unit 1830 is also used to verify whether the first key and the second key are consistent, The second key is a key stored in the near-end diagnostic instrument; the processing unit 1830 is also configured to, when the first key and the second key are consistent, The near-end diagnostic instrument establishes a secure access service.
  • the processing unit 1830 is specifically configured to, when the first key is consistent with the second key, and the first key is within the validity period, and the The local diagnostic instrument establishes a secure access service.
  • the access control policy information also includes: a certificate and a signature; the processing unit 1830 is specifically configured to use the public key of the certificate to decrypt the signature to obtain the first digital digest; Perform hash calculation on the access control policy information to obtain a second digital digest; verify whether the first digital digest and the second digital digest are consistent.
  • the processing unit 1830 is specifically configured to verify whether the first vehicle identity information matches a vehicle, and the vehicle is the vehicle for which the diagnosis command is to be executed.
  • the transceiver unit 1810 is also configured to receive a second diagnostic policy file sent by the diagnostic device, where the second diagnostic file includes: a third timestamp; the processing unit 1830, specifically Used to verify whether the first timestamp is greater than the third timestamp.
  • the transceiver unit 1810 is specifically configured to receive the first diagnostic policy file sent by the diagnostic device upon obtaining authorization from the vehicle owner.
  • the device 1800 can be used to perform the actions performed by the diagnostic equipment in the above method embodiment.
  • the device 1800 includes: a transceiver unit 1810, configured to send first request information to the authorization management system.
  • the first request information is used to request the authorization management system to generate a first diagnosis policy file.
  • the first diagnosis policy file is 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 third diagnostic policy file to the vehicle.
  • a diagnostic strategy file the vehicle is the vehicle for which the diagnostic command is to be executed.
  • the device further includes: an acquisition unit 1820, used to obtain the identity information of the diagnostician; and the transceiver unit 1810, also used to send the identity information of the diagnostician to the authorization management system. ;
  • the transceiver unit 1810 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, and the first response information is used to indicate The diagnostician's identity was successfully authenticated.
  • the first diagnosis policy file includes: a second key
  • the device further includes: a processing unit 1830, configured to save the second key in the diagnosis device.
  • the transceiver unit 1810 is also configured to receive the second key sent by the key management system; the processing unit 1830 is also configured to save the second key in the diagnosis In the device, the diagnostic device is the near-end diagnostic instrument; sending the first key to the vehicle.
  • the device 1800 can be used to perform the actions performed by the authorization management system in the above method embodiment.
  • the device 1800 includes: a transceiver unit 1810, configured to receive the first request information sent by the diagnostic device, and a processing unit 1830, configured to generate a first diagnostic strategy file according to the first request information, and the first diagnostic strategy file is used to Verify whether the diagnostic command has access control permission; the transceiver unit 1810 is also configured to send the first diagnostic policy file to the diagnostic device.
  • the transceiver unit 1810 is also used to receive the identity information of the diagnostician sent by the diagnostic device; the transceiver unit 1810 is also used to compare the identity information of the diagnostician with the authorization. If the identity information preset in the management system is consistent, first response information is sent to the diagnostic device, and the first response information is used to indicate that the identity verification of the diagnostic personnel is successful.
  • the transceiver unit provided by the embodiment of the present application can be a communication interface on the diagnostic module (diagnostic device), and the diagnostic module can receive the first diagnostic policy file from the T-BOX or other devices through this interface.
  • the transceiver unit may also be a communication interface on the T-BOX in the vehicle. The T-BOX receives the first diagnosis strategy file and sends the first diagnosis strategy file to the diagnosis module for processing.
  • processing unit 1830 in Figure 18 can be implemented by at least one processor or processor-related circuit
  • acquisition unit 1820 and the transceiver unit 1810 can be implemented by a transceiver or transceiver-related circuit
  • storage unit can be implemented by at least one memory.
  • the processing unit 1830 may be the processor 211 shown in FIG. 2 .
  • the above-mentioned processing unit 1830 may be the processor 1920 in FIG. 19
  • the above-mentioned storage unit may be the memory 1910 in FIG. 19
  • the above-mentioned acquisition unit 1810 or 1820 may be the communication interface 1930 in FIG. 19 .
  • Figure 19 is a schematic diagram of a diagnostic device 1900 provided by an embodiment of the present application.
  • the device 1900 may be implemented in the vehicle 100 of FIG. 1 .
  • 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 through an internal connection path.
  • the memory 1910 is used to store instructions
  • the processor 1920 is used to execute the instructions stored in the memory 1910.
  • the memory 1910 can both
  • the processor 1920 is coupled through an interface and can also be integrated with the processor 1920.
  • the above-mentioned 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 communication networks.
  • the above-mentioned communication interface 1930 may also include an input/output interface.
  • Processor 1920 stores one or more computer programs including instructions. When the instruction is executed by the processor 1920, the diagnostic device 1900 is caused to execute the technical solutions of the diagnostic methods in the above embodiments.
  • the device 1800 and the device 1900 may be located in the vehicle 200 in FIG. 2 .
  • the device 1800 and the device 1900 may be the computing platform 210 in the vehicle in FIG. 2 .
  • each step of the above method can be completed by instructions in the form of hardware integrated logic circuits or software in the processor 1920 .
  • the method disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware processor for execution, or can be executed by a combination of hardware and software modules in the processor.
  • the software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field.
  • the storage medium is located in the memory 1910.
  • 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.
  • Embodiments of the present application also provide a computer-readable medium.
  • the computer-readable medium stores program code.
  • the computer program code When the computer program code is run on a computer, it causes the computer to execute any of the above-mentioned Figures 3 to 17. a way.
  • An embodiment of the present application also provides a computer program product.
  • the computer program product includes a computer program, which when the computer program is run, causes the computer to execute any one of the methods in FIG. 3 to FIG. 17 .
  • An embodiment of the present application also provides a chip, including: at least one processor and a memory.
  • the at least one processor is coupled to the memory and is used to read and execute instructions in the memory to execute the above-mentioned Figures 3 to 3. Either method in Figure 17.
  • Embodiments of the present application also provide a vehicle, including: at least one processor and a memory, the at least one processor being coupled to the memory and configured to read and execute instructions in the memory to execute the above-mentioned Figures 3 to 3. Either method in Figure 17.
  • An embodiment of the present application also provides a vehicle, including any diagnostic device shown in Figure 18 or Figure 19 .
  • the above-mentioned processor may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), or dedicated integrated processors.
  • Circuit application specific integrated circuit, ASIC
  • off-the-shelf programmable gate array field programmable gate array, FPGA
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.
  • the memory may include read-only memory and random access memory, and provide instructions and data to the processor.
  • Part of the processor may also include non-volatile random access memory.
  • the processor may also store information about the device type.
  • the size of the sequence numbers of the above-mentioned processes does not mean the order of execution.
  • the execution order of each process should be determined by its functions and internal logic, and should not be implemented in this application.
  • the implementation of the examples does not constitute any limitations.
  • a component may be, but is not limited to, a process, a processor, an object, an executable file, a thread of execution, a program and/or a computer running on a processor.
  • applications running on the computing device and the computing device may be components.
  • One or more components can reside in a process and/or thread of execution and a component can be localized on one computer and/or distributed between 2 or more computers. Additionally, these components can execute from various computer-readable media having various data structures stored thereon.
  • a component may, for example, be based on a signal having one or more data packets (eg, data from two components interacting with another component, a local system, a distributed system, and/or a network, such as the Internet, which interacts with other systems via signals) Communicate through local and/or remote processes.
  • data packets eg, data from two components interacting with another component, a local system, a distributed system, and/or a network, such as the Internet, which interacts with other systems via signals
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.
  • 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.
  • the technical solution of the present application is essentially or the part that contributes to the existing technology 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, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code. .

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Selective Calling Equipment (AREA)
  • Storage Device Security (AREA)

Abstract

本申请实施例提供了一种诊断方法和装置，该方法包括：接收诊断设备发送的第一诊断策略文件,所述诊断策略文件包括：访问控制策略信息，所述诊断设备包括：远程诊断平台或近端诊断仪；验证所述第一诊断策略文件的真实性和完整性；在所述第一诊断策略文件的真实性和完整性验证通过的情况下，根据所述访问控制策略信息验证诊断命令是否具有访问控制权限。通过上述方法，能够避免在诊断时车辆执行错误的或非法的诊断命令，保障车主的财产和隐私安全。

Description

诊断方法和装置 技术领域
本申请实施例涉及安全领域，并且更具体地，涉及一种诊断方法和装置。
背景技术
随着网络技术的演进和车辆的普及，车辆诊断能够给车辆的使用者带来诸多便利。车辆诊断是指确定车辆故障的起因，即在不解体车辆的条件下，确定汽车技术状况，查明故障部位及原因。诊断范围既可以包括动力，底盘，车身及附件，还可以包括车辆的尾气排放、噪声与安全的检测等内容。
然而，在车辆诊断的过程中，由于诊断平台或诊断仪需要向车辆发送诊断命令，一旦诊断平台或诊断仪被非法人员滥用或恶意诊断下发了错误或恶意诊断命令，车辆执行了该错误或者非法的诊断命令后，可能致使用户的隐私、财产和生命安全受到侵犯。
发明内容
本申请实施例提供一种诊断方法和装置，能够避免在诊断时车辆执行错误的或非法的诊断命令，保障车主的财产和隐私安全。
第一方面，提供了一种诊断方法,该方法包括:接收诊断设备发送的第一诊断策略文件,所述第一诊断策略文件包括：访问控制策略信息，所述诊断设备包括：远程诊断平台或近端诊断仪；验证所述第一诊断策略文件的真实性和完整性；在所述第一诊断策略文件的真实性和完整性验证通过的情况下，根据所述访问控制策略信息验证诊断命令是否具有访问控制权限。
其中，该诊断命令可以是车辆待执行的诊断命令，诊断命令可以由诊断设备发送。诊断命令可以包括但不限于：读取故障码、清除故障码、整车扫描和部件诊断。访问控制策略信息可以包括：授权类型、有效期、车辆身份信息、标识ID、时间戳、版本、签名和证书中的一种或多种。诊断命令具有访问控制权限可以理解为该诊断命令是合法的、有效的，该诊断命令可以被车辆执行。
本申请实施例中,在车辆执行诊断命令前，能够使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具有访问控制权限。只有诊断命令具备访问控制权限的情况下，才执行诊断命令。通过这样的方式，能够避免车辆执行错误或非法的诊断命令，保障用户的财产和隐私安全。
结合第一方面，在第一方面的某些实现方式中，所述访问控制策略信息包括：有效期，所述根据所述访问控制策略信息验证诊断命令是否具有访问控制权限，包括：在所述有效期内，使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限。
本申请实施例中，只有在诊断策略文件在有效期内，才使用诊断策略文件中的访问控制策略信息验证诊断命令是否具有访问控制权限。通过这样的方式，能够避免诊断策略文 件失效后仍然被使用，提高诊断策略文件使用的安全性。
结合第一方面，在第一方面的某些实现方式中，所述访问控制策略信息还包括：第一车辆身份信息，所述根据所述访问控制策略信息验证诊断命令是否具有访问控制权限，包括：验证所述第一车辆身份信息与第二车辆身份信息是否一致，所述诊断命令包括所述第二车辆身份信息。
其中，第一车辆身份信息可以是用于表示车辆身份的信息，其可以包括但不限于车辆识别号码，在访问控制策略信息中的第一车辆身份信息与诊断命令一致的情况下，可以确定诊断命令具有访问控制权限。
本申请实施例中，通过验证第一车辆身份信息与第二车辆身份信息是否一致，来验证诊断命令是否具有访问控制权限，能够进一步保证用户的财产安全和隐私安全。
结合第一方面，在第一方面的某些实现方式中，所述第一车辆身份信息和/或所述第二车辆身份信息为车辆识别号码。
结合第一方面，在第一方面的某些实现方式中，所述访问控制策略信息还包括：第一标识ID，所述第一标识ID包括：第一电子控制单元ID、第一CAN ID、第一诊断服务ID和第一诊断数据ID中的至少一项；所述使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限，包括：验证所述第一标识ID与第二标识ID是否一致，所述第二标识ID为所述诊断命令中的标识ID，所述第二标识ID包括：第二电子控制单元ID、第二CAN ID、第二诊断服务ID和第二诊断数据ID中的至少一项。
在第一标识ID和第二标识ID一致的情况下，诊断命令才能对相应的电子控制单元生效或者车辆才能使用相应的诊断服务或诊断数据。
其中，第二电子控制单元ID可以是诊断命令所针对的电子控制单元的ID，第二CAN ID可以表示发送和接收诊断命令的CAN节点的地址或名称，第二诊断服务ID可以是进行诊断命令所需要服务ID，第二诊断数据ID可以是进行诊断服务或诊断命令所需要的数据ID。
本申请实施例中，在诊断命令中第一标识ID和访问控制策略信息第二标识ID一致的情况下，诊断命令才能对相应的电子控制单元生效或者车辆才能使用相应的诊断服务或诊断数据，通过这样的方式，既提供了面向车辆和部件的诊断访问控制机制，又提供了面向诊断服务的访问机制，保证了诊断命令的安全有效。
结合第一方面，在第一方面的某些实现方式中，所述访问控制策略信息还包括：第一时间戳，所述使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限，包括：验证第二时间戳是否大于所述第一时间戳，所述第二时间戳为所述诊断命令的时间戳
其中，在第二时间戳大于第一时间戳的情况下，该诊断命令具备访问控制权限，在第二时间戳小于第一时间戳的情况下，该诊断命令不具备访问控制权限。
可选地，在此种实现方式中，可以设定在第二时间戳大于第一时间戳，且诊断任务的执行时间在访问控制策略信息的有效期的范围内时，诊断命令具备访问控制权限。
应理解，该步骤中保证诊断任务的时间戳是否大于访问控制策略信息的时间戳的目的是防止诊断任务被重用或重放攻击，即需要保证车辆接收诊断命令的时间晚于接收诊断策略文件的时间。
本申请实施例中，通过验证第二时间戳是否大于第一时间戳，来防止诊断任务被重用 或重放攻击，能够进一步保证用户的财产安全和隐私安全。
结合第一方面，在第一方面的某些实现方式中，所述诊断设备包括：近端诊断仪，所述第一诊断策略文件包括：第一密钥，所述方法还包括：将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
只有在第一密钥与所述第二密钥一致的情况下，车辆和近端诊断仪之间才能建立安全访问服务，在建立安全访问服务后，近端诊断仪才能使用诊断策略文件中的访问控制策略信息来验证诊断命令是否具备诊断控制权限。
其中，第一密钥和第二密钥均可以是临时密钥，第一密钥和第二密钥的应用过程可以是：首先由密钥管理系统生成第二密钥并将该第二密钥发送到授权管理系统中，授权管理系统在生成第一诊断策略文件后，将该第二密钥随着第一诊断策略文件发送至近端诊断仪，近端诊断仪得到该第二密钥后可以将第二密钥保存至近端诊断仪中。然后近端诊断仪将第一密钥随着第一诊断策略文件下发至车辆，由车辆保存该第一密钥。在验证密钥时，如果第一密钥和第二密钥一致，也就是第一密钥就是第二密钥，则说明第二密钥在传递的过程中没有被近端诊断仪篡改。如果第一密钥和第二密钥不一致，则说明第二密钥可能被窜改，诊断过程不安全。
其中，验证第一密钥和第二密钥是否一致也可以具有多种方式。
一种可能的实现方式中，可以由近端诊断仪向车辆发送密文，由车辆验证该密文确定第一密钥和第二密钥是否一致。
一种可能的实现方式中，在通过第一诊断策略文件将第一密钥保存在车辆后，近端诊断仪可以将保存的第二密钥直接发送给车辆，由车辆验证第一密钥和第二密钥是否一致。
应理解，上述验证第一密钥和第二密钥是否一致的原因是兼容旧版本的近端诊断仪，如果诊断用户使用的是旧版本的近端诊断仪对车辆进行诊断，不进行密钥验证的可能导致诊断命令的执行失败。
结合第一方面，在第一方面的某些实现方式中，所述诊断设备包括：近端诊断仪，所述方法还包括：接收所述近端诊断仪发送的第一密钥；将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
其中，第一密钥和第二密钥均可以是临时密钥，第一密钥和第二密钥的应用过程可以是：首先由密钥管理系统生成第二密钥并将第二密钥发送给近端诊断仪后，由近端诊断仪进行保存。然后，近端诊断仪将第一密钥直接下发至车辆，由车辆保存该第一密钥。在验证密钥时，如果第一密钥和第二密钥一致，也就是第一密钥就是第二密钥，则说明第二密钥在传递的过程中没有被近端诊断仪篡改。如果第一密钥和第二密钥不一致，则说明第二密钥可能被窜改，诊断过程不安全。
本申请实施例中，通过验证第一密钥和第二密钥是否一致的方式，来判断车辆和诊断平台间是否建立安全访问服务，只有建立了安全访问服务后，车辆才能使用访问控制策略信息验证诊断命令是否具备访问控制权限，通过这样的方式，能够进一步保障诊断命令执 行的安全性和合法性。
结合第一方面，在第一方面的某些实现方式中，所述在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务，包括：在所述第一密钥与所述第二密钥一致，且所述第一密钥在有效期内的情况下，与所述近端诊断仪建立安全访问服务。
其中，上述有效期可以是访问控制策略信息中的有效期，也可以是第一密钥的有效期。如果超过上述有效期，第一密钥将失效。
本申请实施例中，在第一密钥和第二密钥一致，且第一密钥在有效期内的情况下，车辆才能与近端诊断仪建立安全访问服务，通过这样的方式，能够避免使用失效的第一密钥进行一致性验证，进一步提高密钥使用的安全性。
结合第一方面，在第一方面的某些实现方式中，该访问控制策略信息包括：证书和签名，所述验证所述第一诊断策略文件的真实性和完整性，包括：使用所述证书的公钥解密所述签名，得到第一数字摘要；对所述访问控制策略信息进行哈希计算，得到第二数字摘要；验证所述第一数字摘要与所述第二数字摘要是否一致。
可选地，在使用证书解密签名之前，该方法还包括对证书的真实性和有效性进行验证。
可选地，还可以采用对称密钥对第一诊断策略文件的真实性和完整性进行验证。使用所述对称密钥对所述访问控制策略信息进行加密计算，得到第二数字摘要；验证所述第一数字摘要与所述第二数字摘要是否一致。其中，使用这种方式进行验证的过程中，访问控制策略信息可以包括第一数字摘要，而不必使用公钥解密签名得到第一数字摘要。
本申请实施例中，可以对访问控制策略信息进行哈希计算得到第二数字摘要，并将第二数字摘要与第一数字摘要进行比较，来验证第一诊断策略文件的真实性和完整性，通过这样的方式，在第一诊断策略文件真实性和完整性验证通过的情况下，才使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问控制权限，能够进一步保障用户的财产和隐私安全。
结合第一方面，在第一方面的某些实现方式中，所述验证所述第一诊断策略文件的真实性和完整性，包括：验证所述第一车辆身份信息是否与车辆匹配，所述车辆为待执行所述诊断命令的车辆。
示例性地，该第一车辆身份信息是车辆识别号码，可以将第一车辆识别号码与车辆的识别码进行比较来判断第一车辆识别号码是否与车辆匹配，如果两者一致则验证通过，如果两者不一致则验证失败。其中，车辆的识别码可以在车辆发动机舱前隔板上或车辆仪表台上查看。
本申请实施例中，可以通过判断第一车辆身份信息是否匹配车辆，来验证第一诊断策略文件的真实性和完整性，通过这样的方式，在第一诊断策略文件真实性和完整性验证通过的情况下，才使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问控制权限，能够进一步保障用户的财产和隐私安全。
结合第一方面，在第一方面的某些实现方式中，在所述接收诊断设备发送的第一诊断策略文件之前，所述方法还包括：接收所述诊断设备发送的第二诊断策略文件，所述第二诊断文件包括：第三时间戳；所述验证所述第一诊断策略文件的真实性和完整性，包括：验证所述第一时间戳是否大于所述第三时间戳。
其中，车辆接收第二诊断策略文件的时间早于第一诊断策略文件的时间。第二诊断策 略文件可以是上一次执行诊断命令时所使用的诊断策略文件，也可以是尚未使用过的诊断策略文件。验证第一时间戳是否大于第三时间戳的目的是判断第一诊断策略文件是否被重用或重放攻击。如果第一时间戳小于第三时间戳说明第一诊断策略文件可能被重用或重放攻击，该策略文件不真实。如果第一时间戳大于第三时间戳则第一诊断策略文件的真实性和完整性验证通过。
本申请实施例中，通过验证第一时间戳和第三时间戳的大小关系，来判断第一诊断策略文件是否被重用或重放攻击。在验证通过的情况下，才使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问控制权限，能够进一步保障用户的财产和隐私安全。
结合第一方面，在第一方面的某些实现方式中，所述验证所述第一诊断策略文件的真实性和完整性，包括：判断第一时间戳与车辆本地时间的差值是否小于或等于预设阈值。
其中，如果第一时间戳与车辆本地时间的差值小于或等于预设阈值，则第一诊断策略文件的真实性和完整性验证通过。如果第一时间戳与车辆本地时间的差值大于预设阈值则说明第一诊断策略文件可能被重用或重放攻击。
本申请实施例中，通过验证第一时间戳和车辆本地时间的大小关系，来判断第一诊断策略文件是否被重用或重放攻击。在验证通过的情况下，才使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问控制权限，能够进一步保障用户的财产和隐私安全。
结合第一方面，在第一方面的某些实现方式中，所述接收诊断设备发送的第一诊断策略文件，包括：在取得车主授权的情况下，接收所述诊断设备发送的所述第一诊断策略文件。
其中，车主授权可以通过线上/线下服务协议或者通话方式进行一定时效的授权，以满足隐私合规的要求。例如，在诊断开始前需要车主签订或勾选诊断服务协议，在车辆检测到车主签订或勾选诊断服务协议后，车辆才能够执行诊断任务。其中，诊断服务协议可以包括但不限于：诊断的对象、诊断的权限和车辆执行诊断任务需要调用的资源等等。再例如，在诊断开始前，可以由车主通过电话的方式请求进行车辆诊断，在此种情况下可以默认车主同意诊断服务协议。再例如，车主可以通过车辆上的应用程序触发诊断流程。
本申请实施例中，在得到车主授权的情况下，车辆才能够接收第一诊断策略文件，以便于后续通过第一诊断策略文件验证诊断命令是否具有访问控制权限。
第二方面，提供了一种诊断方法，该方法应用于诊断设备中，该诊断设备包括：远程诊断平台或近端诊断仪，该方法包括：向授权管理系统发送第一请求信息，所述第一请求信息用于请求所述授权管理系统生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；接收所述授权管理系统发送的所述第一诊断策略文件；向车辆发送所述第一诊断策略文件，所述车辆为待执行所述诊断命令的车辆。
本申请实施例中，诊断设备从授权管理系统接收第一诊断策略文件并转发给车辆，便于后续车辆使用第一诊断策略文件验证诊断命令是否具有访问权限。
结合第二方面，在第二方面的某些实现方式中，在所述向授权管理系统发送第一请求信息之前，所述方法还包括：获取诊断人员的身份信息；向所述授权管理系统发送所述诊断人员的身份信息；所述向授权管理系统发送第一请求信息，包括：在接收到所述授权管 理系统发送的第一响应信息情况下，向所述授权管理系统发送所述第一请求信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
其中，诊断人员的身份信息可以有多种表现形式，例如，诊断人员的身份信息可以是账号信息，该账号信息可以由原始设备制造商(original equipment manufacturer，OEM)创建，并将账号和密码分配给诊断人员，由诊断人员在诊断平台或诊断仪上输入账号和密码。又例如，该身份信息可以是诊断人员的面部特征信息，OEM可以预先将符合资质的诊断人员的面部特征信息录入诊断仪或诊断平台，诊断人员需要在诊断平台或诊断仪上通过验证面部特征信息登录。此外，该身份信息还可以是诊断人员的虹膜特征信息或声纹特征信息等等，此处不再赘述。
本申请实施例中，诊断人员在进行诊断前需要在诊断平台上登录，诊断设备需要将诊断人员的身份信息发送给授权管理系统，并由授权管理系统进行验证，在接收到授权管理系统的验证成功信息后，诊断设备才能请求授权管理发送第一诊断策略文件。通过这样的方式，提供了诊断人员的身份验证机制，能够避免诊断平台或诊断仪被非法人员滥用或恶意诊断，致使用户的隐私、财产和生命安全受到侵犯。
结合第二方面，在第二方面的某些实现方式中，所述第一诊断策略文件包括：第二密钥，在所述向车辆发送所述第一诊断策略文件之前，所述方法还包括：将所述第二密钥保存在所述诊断设备中，所述诊断设备为所述近端诊断仪。
本申请实施例中，诊断设备可以从第一诊断策略文件中得到第二密钥，并将第二密钥保存至该诊断设备中，以便于后续车辆验证第一密钥和第二密钥的一致性。
结合第二方面，在第二方面的某些实现方式中，所述方法还包括：接收密钥管理系统发送的第二密钥，将所述第二密钥保存在所述诊断设备中，向车辆发送第一密钥，所述车辆为待执行诊断命令的车辆。
第三方面，提供了一种诊断方法，该方法应用于授权管理系统中，所述方法包括：接收诊断设备发送的第一请求信息，根据所述第一请求信息生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；向所述诊断设备发送所述第一诊断策略文件。
结合第三方面，在第三方面的某些实现方式中，在所述接收诊断设备发送的第一请求信息之前，所述方法还包括：接收所述诊断设备发送的诊断人员身份信息；在所述诊断人员的身份信息与所述授权管理系统中预设的身份信息一致的情况下，向所述诊断设备发送第一响应信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
其中，验证诊断人员的身份信息也可以采用多种方式，例如，如果诊断人员的身份信息是账号信息，授权管理系统需要对诊断人员输入的账号和密码进行验证，验证成功后向诊断设备发送第一响应信息，用于告知诊断人员身份验证成功。又例如，如果诊断人员的身份信息是面部特征信息，授权管理系统可以将该面部特征信息与系统中预设的面部特征信息进行比对，验证成功后再向诊断设备发送第一响应信息，用于告知诊断人员身份验证成功。
本申请实施例中，授权管理系统在接收到诊断平台发送的诊断人员的身份信息后，能够对该身份信息进行验证，进而识别诊断用户的合法性，在诊断用户身份合法的情况下，才向诊断设备发送第一诊断策略文件，通过这样的方式，在进行诊断之前提供了诊断人员 的身份验证机制，能够避免诊断平台或诊断仪被非法人员滥用或恶意诊断，致使用户的隐私、财产和生命安全受到侵犯。
第四方面，提供了一种诊断装置，该装置包括：收发单元，用于接收诊断设备发送的第一诊断策略文件,所述第一诊断策略文件包括：访问控制策略信息，所述诊断设备包括：远程诊断平台或近端诊断仪；处理单元，用于验证所述第一诊断策略文件的真实性和完整性；所述处理单元，还用于所述第一诊断策略文件的真实性和完整性验证通过的情况下，根据所述访问控制策略信息验证诊断命令是否具有访问控制权限。
应理解，本申请实施例提供的收发单元可以是诊断模块(诊断装置)的上的通信接口，诊断模块可以通过该接口从智能车载终端(telematics-box，T-BOX)或其他设备中接收第一诊断策略文件。收发单元还可以是车辆中T-BOX上的通信接口，由该T-BOX接收第一诊断策略文件，并将第一诊断策略文件发送给诊断模块处理。
结合第四方面，在第四方面的某些实现方式中，所述访问控制策略信息包括：有效期；所述处理单元，具体用于在所述有效期内，使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限。
结合第四方面，在第四方面的某些实现方式中，所述访问控制策略信息还包括：第一车辆身份信息；所述处理单元，具体用于验证所述第一车辆身份信息与第二车辆身份信息是否一致，所述诊断命令包括所述第二车辆身份信息。
结合第四方面，在第四方面的某些实现方式中，所述第一车辆身份信息和/或所述第二车辆身份信息为车辆识别号码。
结合第四方面，在第四方面的某些实现方式中，所述访问控制策略信息还包括：第一标识ID，所述第一标识ID包括：第一电子控制单元ID、第一CAN ID、第一诊断服务ID和第一诊断数据ID中的至少一项；所述处理单元，具体用于验证所述第一标识ID与第二标识ID是否一致，所述第二标识ID为所述诊断命令中的标识ID，所述第二标识ID包括：第二电子控制单元ID、第二CAN ID、第二诊断服务ID和第二诊断数据ID中的至少一项。
结合第四方面，在第四方面的某些实现方式中，所述访问控制策略信息还包括：第一时间戳；所述处理单元，具体用于验证第二时间戳是否大于所述第一时间戳，所述第二时间戳为所述诊断命令的时间戳。
结合第四方面，在第四方面的某些实现方式中，所述诊断设备包括：近端诊断仪，所述第一诊断策略文件包括：第一密钥；所述处理单元，还用于将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；所述处理单元，还用于验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；所述处理单元，还用于在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
结合第四方面，在第四方面的某些实现方式中，所述诊断设备包括：近端诊断仪；所述收发单元，还用于接收所述近端诊断仪发送的第一密钥；所述处理单元，还用于将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；所述处理单元，还用于验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；所述处理单元，还用于在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
结合第四方面，在第四方面的某些实现方式中，所述处理单元，具体用于在所述第一 密钥与所述第二密钥一致，且所述第一密钥在有效期内的情况下，与所述近端诊断仪建立安全访问服务。
结合第四方面，在第四方面的某些实现方式中，所述访问控制策略信息还包括：证书和签名；所述处理单元，具体用于使用所述证书的公钥解密所述签名，得到第一数字摘要；对所述访问控制策略信息进行哈希计算，得到第二数字摘要；验证所述第一数字摘要与所述第二数字摘要是否一致。
结合第四方面，在第四方面的某些实现方式中，所述处理单元，具体用于验证所述第一车辆身份信息是否与车辆匹配，所述车辆为待执行所述诊断命令的车辆。
结合第四方面，在第四方面的某些实现方式中，所述收发单元，还用于接收所述诊断设备发送的第二诊断策略文件，所述第二诊断文件包括：第三时间戳；所述处理单元，具体用于验证所述第一时间戳是否大于所述第三时间戳。
结合第四方面，在第四方面的某些实现方式中，所述收发单元，具体用于在取得车主授权的情况下，接收所述诊断设备发送的所述第一诊断策略文件。
第五方面，提供了一种诊断装置，该装置包括：收发单元，用于向授权管理系统发送第一请求信息，所述第一请求信息用于请求所述授权管理系统生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；所述收发单元，还用于接收所述授权管理系统发送的所述第一诊断策略文件；所述收发单元，还用于向车辆发送所述第一诊断策略文件，所述车辆为待执行所述诊断命令的车辆。结合第五方面，在第五方面的某些实现方式中，所述装置还包括：获取单元，用于获取诊断人员的身份信息；所述收发单元，还用于向所述授权管理系统发送所述诊断人员的身份信息；所述收发单元，具体用于在接收到所述授权管理系统发送的第一响应信息情况下，向所述授权管理系统发送所述第一请求信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
结合第五方面，在第五方面的某些实现方式中，所述第一诊断策略文件包括：第二密钥，所述装置还包括：处理单元，用于将所述第二密钥保存在所述诊断设备中
结合第五方面，在第五方面的某些实现方式中，所述收发单元，还用于接收密钥管理系统发送的第二密钥；所述处理单元，还用于将所述第二密钥保存在所述诊断设备中，所述诊断设备为所述近端诊断仪；向所述车辆发送第一密钥。
第六方面，提供了一种诊断装置，该装置包括：收发单元，用于接收诊断设备发送的第一请求信息，处理单元，用于根据所述第一请求信息生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；所述收发单元，还用于向所述诊断设备发送所述第一诊断策略文件。
第六方面，在第六方面的某些实现方式中，所述收发单元，还用于接收所述诊断设备发送的诊断人员身份信息；所述收发单元，还用于在所述诊断人员的身份信息与所述授权管理系统中预设的身份信息一致的情况下，向所述诊断设备发送第一响应信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
第七方面，提供一种诊断装置，该装置包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，该装置用于执行上述各个方面中的方法。
第八方面，提供一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述 计算机程序代码在计算机上运行时，使得计算机执行上述各个方面中的方法。
第九方面，提供一种芯片，该芯片包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，该装置用于执行上述各个方面中的方法。
第十方面，提供一种计算机程序产品，所述计算机产品包括：计算机程序，当所述计算机程序被运行时，使得计算机执行上述各个方面中的方法。
第十一方面，提供一种车辆，该车辆包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，该车辆用于执行上述第一方面中的方法。
附图说明
图1是本申请实施例提供的一种诊断系统100。
图2是本申请实施例提供的车辆功能性示意图。
图3是本申请实施例提供的一种诊断方案。
图4是本申请实施例提供的另一种诊断方案。
图5是本申请实施例提供的一种诊断方法500。
图6是本申请实施例提供的一种诊断方法所适用的系统架构600。
图7是本申请实施例提供的一种角色创建示意图。
图8是本申请实施例提供的一种远程诊断方法800。
图9是本申请实施例提供的一种远程诊断过程中诊断策略文件生成和下发的方法900。
图10是本申请实施例提供的一种远程诊断过程中下发和执行诊断任务的方法1000。
图11是本申请实施例提供的一种近端诊断方法1100。
图12是本申请实施例提供的一种近端诊断过程中诊断策略文件生成和下发的方法1200。
图13是本申请实施例提供的一种近端诊断过程中下发和执行诊断任务的方法1300。
图14是本申请实施例提供的一种策略文件格式示意图。
图15是本申请实施例提供的策略文件真实性和完整性验证流程图1500。
图16是本申请实施例提供的一种使用策略文件管控诊断任务或诊断命令的方法1600。
图17是本申请实施例提供的一种策略文件的具体实现方式。
图18是本申请实施例提供的一种诊断装置1800。
图19是本申请实施例提供的另一种诊断装置1900。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
图1是本申请实施例提供的一种诊断系统100。
如图1中的(a)所示，系统100可以包括云端服务器110、诊断仪120、诊断模块130和车辆140。其中，云端服务器110可以包括诊断平台111和其他服务112。云端服务器110可以是实体服务器也可以是虚拟服务器，当云端服务器110是虚拟服务器时，其可以位于世界各地，为不同国家和地区的车辆提供服务。诊断平台111可以通过4G/5G网络连 接车辆140，并直接向车辆140下发诊断命令进行车辆诊断。这种诊断方式也可以称作远程诊断。其他服务112可以包括：收集并分析车辆的部件运行数据或者给车辆提供软件升级服务等数据增值服务。诊断仪120可以和云端服务器110通过4G/5G网络实现信息同步，并且可以通过连接车辆的车上诊断系统(on-board diagnostics,OBD)接口，从而发送诊断命令对车辆进行诊断，这种诊断方式也称作近端诊断。
如图1中的(b)所述，诊断模块130位于车辆140中，诊断模块130可以包括：诊断客户模块131、诊断策略模块132和诊断代理模块133。其中，诊断客户模块131能够从云端服务器110或诊断仪120接收诊断命令并使用诊断策略文件对诊断命令进行校验。诊断策略模块132能够检查诊断策略文件和进行车辆状态监控，在车辆的状态满足预设的条件时诊断策略模块132能够将诊断命令经由诊断代理模块133发送到电子控制单元(electronic control unit，ECU)。例如，可以设定当在车辆的行驶速度小于3km/h时，诊断策略模块132可以将诊断命令发送给诊断代理模块133。诊断代理模块133可以通过控制器域网(controller area network,CAN)处理或以太处理将诊断策略模块132发送的诊断命令转发至ECU。
应理解，将车辆设定在较低的速度(例如，3km/h)时，诊断策略模块132将诊断命令发送给诊断代理模块133是出于车辆的安全考虑，由于车辆执行诊断任务时需要调用一定的资源，因此，在车辆高速行驶时执行诊断任务可能会对车辆的其他功能造成影响。
图2是本申请实施例提供的车辆功能性示意图，图2中的车辆200可以是图1中的车辆140。应理解，图2及相关描述仅为一种举例，并不对本申请实施例中的车辆进行限定。
在实施过程中，车辆200可以被配置为完全或部分自动驾驶模式，也可以由用户进行人工驾驶。
车辆200可包括多种子系统，例如计算平台210和显示装置220。可选地，车辆200可包括更多或更少的子系统，并且每个子系统都可包括一个或多个部件。另外，车辆200的每个子系统和部件可以通过有线或者无线的方式实现互连。
车辆200的部分或所有功能可以由计算平台210控制。计算平台210可包括处理器211至21n(n为正整数)，处理器是一种具有信号的处理能力的电路，在一种实现中，处理器可以是具有指令读取与运行能力的电路，例如中央处理单元(central processing unit，CPU)、微处理器、图形处理器(graphics processing unit，GPU)(可以理解为一种微处理器)、或数字信号处理器(digital signal processor，DSP)等；在另一种实现中，处理器可以通过硬件电路的逻辑关系实现一定功能，该硬件电路的逻辑关系是固定的或可以重构的，例如处理器为专用集成电路(application-specific integrated circuit，ASIC)或可编程逻辑器件(programmable logic device，PLD)实现的硬件电路，例如FPGA。在可重构的硬件电路中，处理器加载配置文档，实现硬件电路配置的过程，可以理解为处理器加载指令，以实现以上部分或全部单元的功能的过程。此外，还可以是针对人工智能设计的硬件电路，其可以理解为一种ASIC，例如神经网络处理单元(neural network processing unit，NPU)、张量处理单元(tensor processing unit，TPU)、深度学习处理单元(deep learning processing unit，DPU)等。此外，计算平台210还可以包括存储器，存储器用于存储指令，处理器211至21n中的部分或全部处理器可以调用存储器中的指令，执行质量，以实现相应的功能。
计算平台210可基于从各种子系统接收的输入来控制车辆200的功能。在一些实施例中，计算平台210可操作来对车辆200及其子系统的许多方面提供控制。
可选地，上述组件只是一个示例，实际应用中，上述各个模块中的组件有可能根据实际需要增添或者删除，图2不应理解为对本申请实施例的限制。
可选地，车辆200或者与车辆200相关联的感知和计算设备(例如，计算平台210)可以基于所识别的物体的特性和周围环境的状态(例如，交通、雨、道路上的冰、等等)来预测所述识别的物体的行为。可选地，每一个所识别的物体都依赖于彼此的行为，因此还可以将所识别的所有物体全部一起考虑来预测单个识别的物体的行为。车辆200能够基于预测的所述识别的物体的行为来调整它的速度。换句话说，自动驾驶车辆能够基于所预测的物体的行为来确定车辆将需要调整到(例如，加速、减速、或者停止)什么稳定状态。在这个过程中，也可以考虑其它因素来确定车辆200的速度，诸如，车辆200在行驶的道路中的横向位置、道路的曲率、静态和动态物体的接近度等等。
除了提供调整自动驾驶车辆的速度的指令之外，计算设备还可以提供修改车辆200的转向角的指令，以使得自动驾驶车辆遵循给定的轨迹和/或维持与自动驾驶车辆附近的物体(例如，道路上的相邻车道中的轿车)的安全横向和纵向距离。
上述车辆200可以为轿车、卡车、摩托车、公共车辆、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车等，本申请实施例不做特别的限定。
图3是本申请实施例提供的一种诊断方案，图3所示的诊断方案可应用于图1的诊断系统100中，图3所示的诊断方案可以包括以下步骤。
S301，客户端向服务器发送“client hello(客户你好)”消息，该消息中包含密码信息和字符串“client random(客户随机)”等。
其中，客户端可以指图1中的诊断平台111或诊断仪120，服务器可以指图1中的诊断模块130。
S302，服务器响应“server hello(服务器你好)”消息，该消息中包含密码组合和数字证书以及随机字符串“server random(服务器随机)”等。
其中，数字证书可以包括：公钥、颁发机构信息、公司名称、域名和有效期等。
S303，客户端验证数字证书并从证书中获取公钥，生成下一个随机字符串premaster secret(主前秘密)并用公钥将其加密。
S304，客户端向服务器发送加密后的“premaster secret(主前秘密)”给服务器。
S305，服务器使用私钥解密获取“premaster secret(主前秘密)”。
S306，客户端和服务器双方使用相同的算法，并使用“client random(客户随机)”、“server random(服务器随机)”和“premaster secret(主前秘密)”生成相同的密钥KEY，用于后面的流程对称加密。
S307，客户端向服务器发送“finished(结束)”消息。
S308，服务器向客户端发送“finished(结束)”消息。
S309，成功建立安全连接，客户端和服务器双方使用共同的密钥KEY对称加密进行安全通信。
其中，步骤S301至S309是通过传输层安全协议(transport layer security，TLS)对车 外的通信设备进行认证的具体流程，通过此种方法虽然能够对诊断平台和诊断仪的真实性进行验证，但是无法对诊断用户的真实性进行认证，一旦诊断平台或诊断仪被非法人员滥用或恶意诊断，可能致使用户的隐私、财产和生命安全受到侵犯。
例如，诊断平台或诊断仪可能受到黑客的攻击，黑客入侵客户端后可能窃取或篡改诊断指令。由于通过上述方法无法验证用户的身份，一旦车辆执行经黑客篡改后的诊断指令，可能会使用户的财产遭受损失。
又例如，诊断平台或诊断仪的设备运维人员可能因超出其职责范围的操作，导致诊断指令不符合用户的意图，由于通过上述方法无法对此种情况进行识别，一旦车辆执行了不符合用户操作意图的诊断指令，可能会使用户的隐私、财产安全得不到保障。
图4是本申请实施例提供的另一种诊断方案，图4所示的诊断方案可应用于图1的诊断系统100中，图4所示的诊断方案可以包括以下步骤。
S401，客户端向服务器请求种子(seed)
S402，服务器向客户端发送随机种子(seed)
S403，客户端向服务器发送计算出来的KEY
具体地，服务器可以利用自身存储的KEY与客户端发送的KEY进行比较，如果二者相同，可以在步骤S404中向客户端发送解锁成功的指令，如果二者不同可以在步骤S404中发送解锁失败的指令。
S404，服务器向客户端回复解锁是否成功
其中，步骤S401至S404是使用统一诊断服务27(unified diagnostic services 27,UDS 27)执行的具体流程。USD 27主要采用种子和密钥的方式为ECU提供了一种保护机制。目标ECU通过安全访问服务对敏感诊断服务(例如，将数据写入ECU)进行访问控制，只有通过安全访问服务后，ECU才可以执行敏感的诊断服务。
然而，UDS 27安全访问服务是面向服务的访问控制，即该方法仅仅可以保护预设的敏感诊断服务，所以使用该方法执行除敏感的诊断服务以外的其他服务时，诊断命令容易被诊断人员或黑客恶意诊断和非法操纵。并且，由于该方法缺乏面向车辆和部件的诊断访问控制机制，所以对于车辆的特定部件容易被诊断人员或黑客恶意进行恶意诊断。
可见，图3或图4的诊断方案在实际的应用中，诊断平台和诊断仪容易被非法人员滥用或恶意诊断，从而致使用户的隐私、财产和生命安全受到侵犯。
本申请实施例提供一种诊断方法，能够避免车辆执行错误或非法的诊断命令，保障用户的财产和隐私安全。
图5是本申请实施例提供的一种诊断方法500，方法500可以包括如下步骤：
S501，接收诊断设备发送的第一诊断策略文件，该第一诊断策略文件包括：访问控制策略信息。
其中，诊断设备可以包括：远程诊断平台或近端诊断仪。
访问控制策略信息可以包括：授权类型、有效期、车辆身份信息、标识ID、时间戳、版本、签名和证书中的一项或多项。其中，授权类型可以指诊断策略文件的类型，例如，远程诊断类型或者近端诊断类型。车辆身份信息和标识ID可以用于检查诊断目标的合法性，有效期可以用于监控诊断时间的有效性。版本可以指第一诊断策略文件的格式版本，版本的记录可以便于未来对格式文件进行更新。签名可以指云端授权管理系统的签名，该 签名可以在车辆进行验签，在验签通过的情况下，保证诊断策略文件本身的真实性和完整性。
一种可能的实现方式，所述接收诊断设备发送的第一诊断策略文件，包括：在取得车主授权的情况下，接收所述诊断设备发送的所述第一诊断策略文件。
其中，车主授权可以通过线上/线下服务协议或者通话方式进行一定时效的授权，以满足隐私合规的要求。例如，在诊断开始前需要车主签订或勾选诊断服务协议，在车辆检测到车主签订或勾选诊断服务协议后，车辆才能够执行诊断任务。其中，诊断服务协议可以包括但不限于：诊断的对象、诊断的权限和车辆执行诊断任务需要调用的资源等等。再例如，在诊断开始前，可以由车主通过电话的方式请求进行车辆诊断，在此种情况下可以默认车主同意诊断服务协议。再例如，车主可以通过车辆上的应用程序触发诊断流程。
本申请实施例中，在得到车主授权的情况下，车辆才能够接收第一诊断策略文件，以便于后续通过第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问控制权限。
一种可能的实现方式中，所述诊断设备包括：近端诊断仪，所述第一诊断策略文件包括：第一密钥，所述方法还包括：将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
只有在第一密钥与所述第二密钥一致的情况下，车辆和近端诊断仪之间才能建立安全访问服务，在建立安全访问服务后，近端诊断仪才能使用诊断策略文件中的访问控制策略信息来验证诊断命令是否具备诊断控制权限。
其中，第一密钥和第二密钥均可以是临时密钥，第一密钥和第二密钥的应用过程可以是：首先由密钥管理系统生成第二密钥并将该第二密钥发送到授权管理系统中，授权管理系统在生成第一诊断策略文件后，将该第二密钥随着第一诊断策略文件发送至近端诊断仪，近端诊断仪得到该第二密钥后可以将第二密钥保存至近端诊断仪中。然后近端诊断仪将第一密钥随着第一诊断策略文件下发至车辆，由车辆保存该第一密钥。在验证密钥时，如果第一密钥和第二密钥一致，也就是第一密钥就是第二密钥，则说明第二密钥在传递的过程中没有被近端诊断仪篡改。如果第一密钥和第二密钥不一致，则说明第二密钥可能被窜改，诊断过程不安全。
其中，验证第一密钥和第二密钥是否一致也可以具有多种方式。
一种可能的实现方式中，可以由近端诊断仪向车辆发送密文，由车辆验证该密文确定第一密钥和第二密钥是否一致。
一种可能的实现方式中，在通过第一诊断策略文件将第一密钥保存在车辆后，近端诊断仪可以将保存的第二密钥直接发送给车辆，由车辆验证第一密钥和第二密钥是否一致。
应理解，上述验证第一密钥和第二密钥是否一致的原因是兼容旧版本的近端诊断仪，如果诊断用户使用的是旧版本的近端诊断仪对车辆进行诊断，不进行密钥验证的可能导致诊断命令的执行失败。
一种可能的实现方式中，所述诊断设备包括：近端诊断仪，所述方法还包括：接收所述近端诊断仪发送的第一密钥；将所述第一密钥保存在车辆中，所述车辆为待执行所述诊 断命令的车辆；验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
其中，第一密钥和第二密钥均可以是临时密钥，第一密钥和第二密钥的应用过程可以是：首先由密钥管理系统生成第二密钥并将第二密钥发送给近端诊断仪后，由近端诊断仪进行保存。然后，近端诊断仪将第一密钥直接下发至车辆，由车辆保存该第一密钥。在验证密钥时，如果第一密钥和第二密钥一致，也就是第一密钥就是第二密钥，则说明第二密钥在传递的过程中没有被近端诊断仪篡改。如果第一密钥和第二密钥不一致，则说明第二密钥可能被窜改，诊断过程不安全。
本申请实施例中，通过验证第一密钥和第二密钥是否一致的方式，来判断车辆和诊断平台间是否建立安全访问服务，只有建立了安全访问服务后，车辆才能使用访问控制策略信息验证诊断命令是否具备访问控制权限，通过这样的方式，能够进一步保障诊断命令执行的安全性和合法性。
S502，验证第一诊断策略文件的真实性和完整性
其中，验证第一诊断策略文件的真实性和完整性可以采用多种方式。
一种可能的实现方式中，该访问控制策略信息包括：证书和签名，所述验证所述第一诊断策略文件的真实性和完整性，包括：使用所述证书的公钥解密所述签名，得到第一数字摘要；对所述访问控制策略信息进行哈希计算，得到第二数字摘要；验证所述第一数字摘要与所述第二数字摘要是否一致。
可选地，在使用证书解密签名之前，该方法还包括对证书的真实性和有效性进行验证。
可选地，还可以采用对称密钥对第一诊断策略文件的真实性和完整性进行验证。使用所述对称密钥对所述访问控制策略信息进行加密计算，得到第二数字摘要；验证所述第一数字摘要与所述第二数字摘要是否一致。其中，使用这种方式进行验证的过程中，访问控制策略信息可以包括第一数字摘要，而不必使用公钥解密签名得到第一数字摘要。
本申请实施例中，可以对访问控制策略信息进行哈希计算得到第二数字摘要，并将第二数字摘要与第一数字摘要进行比较，来验证第一诊断策略文件的真实性和完整性，通过这样的方式，在第一诊断策略文件真实性和完整性验证通过的情况下，才使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问控制权限，能够进一步保障用户的财产和隐私安全。
结合第一方面，在第一方面的某些实现方式中，所述验证所述第一诊断策略文件的真实性和完整性，包括：验证所述第一车辆身份信息是否与车辆匹配，所述车辆为待执行所述诊断命令的车辆。
示例性地，该第一车辆身份信息是车辆识别号码，可以将第一车辆识别号码与车辆的识别码进行比较来判断第一车辆识别号码是否与车辆匹配，如果两者一致则验证通过，如果两者不一致则验证失败。其中，车辆的识别码可以在车辆发动机舱前隔板上或车辆仪表台上查看。
本申请实施例中，可以通过判断第一车辆身份信息是否匹配车辆，来验证第一诊断策略文件的真实性和完整性，通过这样的方式，在第一诊断策略文件真实性和完整性验证通过的情况下，才使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问 控制权限，能够进一步保障用户的财产和隐私安全。
结合第一方面，在第一方面的某些实现方式中，在所述接收诊断设备发送的第一诊断策略文件之前，所述方法还包括：接收所述诊断设备发送的第二诊断策略文件，所述第二诊断文件包括：第三时间戳；所述验证所述第一诊断策略文件的真实性和完整性，包括：验证所述第一时间戳是否大于所述第三时间戳。
其中，车辆接收第二诊断策略文件的时间早于第一诊断策略文件的时间。第二诊断策略文件可以是上一次执行诊断命令时所使用的诊断策略文件，也可以是尚未使用过的诊断策略文件。验证第一时间戳是否大于第三时间戳的目的是判断第一诊断策略文件是否被重用或重放攻击。如果第一时间戳小于第三时间戳说明第一诊断策略文件可能被重用或重放攻击，该策略文件不真实。如果第一时间戳大于第三时间戳则第一诊断策略文件的真实性和完整性验证通过。
本申请实施例中，通过验证第一时间戳和第三时间戳的大小关系，来判断第一诊断策略文件是否被重用或重放攻击。在验证通过的情况下，才使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问控制权限，能够进一步保障用户的财产和隐私安全。
结合第一方面，在第一方面的某些实现方式中，所述验证所述第一诊断策略文件的真实性和完整性，包括：判断第一时间戳与车辆本地时间的差值是否小于或等于预设阈值。
其中，如果第一时间戳与车辆本地时间的差值小于或等于预设阈值，则第一诊断策略文件的真实性和完整性验证通过。如果第一时间戳与车辆本地时间的差值大于预设阈值则说明第一诊断策略文件可能被重用或重放攻击。
本申请实施例中，通过验证第一时间戳和车辆本地时间的大小关系，来判断第一诊断策略文件是否被重用或重放攻击。在验证通过的情况下，才使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具备访问控制权限，能够进一步保障用户的财产和隐私安全。
应理解，上述各个验证第一诊断策略文件真实性和完整性的方式可以单独使用，也可以结合使用。例如，验证第一车辆身份信息是否匹配车辆的方法可以单独使用，在单独使用时，确定了第一车辆身份信息匹配车辆，第一诊断策略文件的真实性和完整性验证通过。又例如，可以先进行第一数字摘要与第二数字摘要一致性验证，再进行第一车辆识别号码是否匹配车辆的验证，在两项验证均通过的情况下，第一诊断策略文件的真实性和完整性验证才通过。
还应理解，在不同的验证方法结合使用时，各个验证方法的执行顺序可以有先后关系，也可以同时执行。
S503，在所述第一诊断策略文件的真实性和完整性验证通过的情况下，根据所述访问控制策略信息验证诊断命令是否具有访问控制权限
本申请实施例中,在车辆执行诊断命令前，能够使用第一诊断策略文件中的访问控制策略信息验证诊断命令是否具有访问控制权限。只有诊断命令具备访问控制权限的情况下，才执行诊断命令。通过这样的方式，能够避免车辆执行错误或非法的诊断命令，保障用户的财产和隐私安全。
其中，使用访问控制策略信息验证诊断命令是否具有访问控制权限可以具有多种实现 方式。
一种可能的实现方式中，所述访问控制策略信息包括：有效期，所述根据所述访问控制策略信息验证诊断命令是否具有访问控制权限，包括：在所述有效期内，使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限。
本申请实施例中，只有在诊断策略文件在有效期内，才使用诊断策略文件中的访问控制策略信息验证诊断命令是否具有访问控制权限。通过这样的方式，能够避免诊断策略文件失效后仍然被使用，提高诊断策略文件使用的安全性。
一种可能的实现方式中，所述访问控制策略信息还包括：第一车辆身份信息，所述根据所述访问控制策略信息验证诊断命令是否具有访问控制权限，包括：验证所述第一车辆身份信息与第二车辆身份信息是否一致，所述诊断命令包括所述第二车辆身份信息。
其中，第一车辆身份信息可以是用于表示车辆身份的信息，其可以包括但不限于车辆识别号码，在访问控制策略信息中的第一车辆身份信息与诊断命令一致的情况下，可以确定诊断命令具有访问控制权限。
本申请实施例中，通过验证第一车辆身份信息与第二车辆身份信息是否一致，来验证诊断命令是否具有访问控制权限，能够进一步保证用户的财产安全和隐私安全。
一种可能的实现方式中，所述第一车辆身份信息和/或所述第二车辆身份信息为车辆识别号码。
一种可能的实现方式中，所述访问控制策略信息还包括：第一标识ID，所述第一标识ID包括：第一电子控制单元ID、第一CAN ID、第一诊断服务ID和第一诊断数据ID中的至少一项；所述使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限，包括：验证所述第一标识ID与第二标识ID是否一致，所述第二标识ID为所述诊断命令中的标识ID，所述第二标识ID包括：第二电子控制单元ID、第二CAN ID、第二诊断服务ID和第二诊断数据ID中的至少一项。
在第一标识ID和第二标识ID一致的情况下，诊断命令才能对相应的电子控制单元生效或者车辆才能使用相应的诊断服务或诊断数据。
其中，第二电子控制单元ID可以是诊断命令所针对的电子控制单元的ID，第二CAN ID可以表示发送和接收诊断命令的CAN节点的地址或名称，第二诊断服务ID可以是进行诊断命令所需要服务ID，第二诊断数据ID可以是进行诊断服务或诊断命令所需要的数据ID。
本申请实施例中，在诊断命令中第一标识ID和访问控制策略信息第二标识ID一致的情况下，诊断命令才能对相应的电子控制单元生效或者车辆才能使用相应的诊断服务或诊断数据，通过这样的方式，既提供了面向车辆和部件的诊断访问控制机制，又提供了面向诊断服务的访问机制，保证了诊断命令的安全有效。
一种可能的实现方式中，所述访问控制策略信息还包括：第一时间戳，所述使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限，包括：验证第二时间戳是否大于所述第一时间戳，所述第二时间戳为所述诊断命令的时间戳
其中，在第二时间戳大于第一时间戳的情况下，该诊断命令具备访问控制权限，在第二时间戳小于第一时间戳的情况下，该诊断命令不具备访问控制权限。
可选地，在此种实现方式中，可以设定在第二时间戳大于第一时间戳，且诊断任务的 执行时间在访问控制策略信息的有效期的范围内时，诊断命令具备访问控制权限。
应理解，该步骤中保证诊断任务的时间戳是否大于访问控制策略信息的时间戳的目的是防止诊断任务被重用或重放攻击，即需要保证车辆接收诊断命令的时间晚于接收诊断策略文件的时间。
本申请实施例中，通过验证第二时间戳是否大于第一时间戳，来防止诊断任务被重用或重放攻击，能够进一步保证用户的财产安全和隐私安全。
应理解，方法500以车辆为主体介绍了使用第一诊断策略文件验证诊断命令的有效性的过程，该车辆可以是共享出租车或者私家车，或者，方法500中的车辆也可以替换成家用或者商用的智能车的充电桩。
下面以诊断平台或授权管理系统为主体介绍第一诊断策略文件的生成和下发过程。
本申请实施例提供另一种诊断方法，该方法应用于诊断设备中，该诊断设备包括：远程诊断平台或近端诊断仪，该方法包括：向授权管理系统发送第一请求信息，所述第一请求信息用于请求所述授权管理系统生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；接收所述授权管理系统发送的所述第一诊断策略文件；向车辆发送所述第一诊断策略文件，所述车辆为待执行所述诊断命令的车辆。
本申请实施例中，诊断设备从授权管理系统接收第一诊断策略文件并转发给车辆，便于后续车辆使用第一诊断策略文件验证诊断命令是否具有访问权限。
一种可能的实现方式中，在所述向授权管理系统发送第一请求信息之前，所述方法还包括：获取诊断人员的身份信息；向所述授权管理系统发送所述诊断人员的身份信息；所述向授权管理系统发送第一请求信息，包括：在接收到所述授权管理系统发送的第一响应信息情况下，向所述授权管理系统发送所述第一请求信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
其中，诊断人员的身份信息可以有多种表现形式，例如，诊断人员的身份信息可以是账号信息，该账号信息可以由OEM创建，并将账号和密码分配给诊断人员，由诊断人员在诊断平台或诊断仪上输入账号和密码。又例如，该身份信息可以是诊断人员的面部特征信息，OEM可以预先将符合资质的诊断人员的面部特征信息录入诊断仪或诊断平台，诊断人员需要在诊断平台或诊断仪上通过验证面部特征信息登录。此外，该身份信息还可以是诊断人员的虹膜特征信息或声纹特征信息等等，此处不再赘述。
本申请实施例中，诊断人员在进行诊断前需要在诊断平台上登录，诊断设备需要将诊断人员的身份信息发送给授权管理系统，并由授权管理系统进行验证，在接收到授权管理系统的验证成功信息后，诊断设备才能请求授权管理发送第一诊断策略文件。通过这样的方式，提供了诊断人员的身份验证机制，能够避免诊断平台或诊断仪被非法人员滥用或恶意诊断，致使用户的隐私、财产和生命安全受到侵犯。
一种可能的实现方式中，所述第一诊断策略文件包括：第二密钥，在所述向车辆发送所述第一诊断策略文件之前，所述方法还包括：将所述第二密钥保存在所述诊断设备中，所述诊断设备为所述近端诊断仪。
本申请实施例中，诊断设备可以从第一诊断策略文件中得到第二密钥，并将第二密钥保存至该诊断设备中，以便于后续车辆验证第一密钥和第二密钥的一致性。
一种可能的实现方式中，所述方法还包括：接收密钥管理系统发送的第二密钥，将所 述第二密钥保存在所述诊断设备中，向车辆发送第一密钥，所述车辆为待执行诊断命令的车辆。
本申请实施例提供另一种诊断方法，该方法应用于授权管理系统中，所述方法包括：所述方法包括：接收诊断设备发送的第一请求信息，根据所述第一请求信息生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；向所述诊断设备发送所述第一诊断策略文件。
一种可能的实现方式中，在所述接收诊断设备发送的第一请求信息之前，所述方法还包括：接收所述诊断设备发送的诊断人员身份信息；在所述诊断人员的身份信息与所述授权管理系统中预设的身份信息一致的情况下，向所述诊断设备发送第一响应信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
其中，验证诊断人员的身份信息也可以采用多种方式，例如，如果诊断人员的身份信息是账号信息，授权管理系统需要对诊断人员输入的账号和密码进行验证，验证成功后向诊断设备发送第一响应信息，用于告知诊断人员身份验证成功。又例如，如果诊断人员的身份信息是面部特征信息，授权管理系统可以将该面部特征信息与系统中预设的面部特征信息进行比对，验证成功后再向诊断设备发送第一响应信息，用于告知诊断人员身份验证成功。
本申请实施例中，授权管理系统在接收到诊断平台发送的诊断人员的身份信息后，能够对该身份信息进行验证，进而识别诊断用户的合法性，在诊断用户身份合法的情况下，才向诊断设备发送第一诊断策略文件，通过这样的方式，在进行诊断之前提供了诊断人员的身份验证机制，能够避免诊断平台或诊断仪被非法人员滥用或恶意诊断，致使用户的隐私、财产和生命安全受到侵犯。
图6是本申请实施例提供的一种诊断方法所适用的系统架构600，系统架构600可以是方法500所适用的系统架构。
如图6所示，系统架构600中可以包括：云端服务器610、远程诊断人员620、诊断仪630、近端诊断人员640、车端授权模块650和车辆660。
其中，云端服务器610中还可以包括：远程诊断平台611和授权管理系统612。远程诊断平台611中包括用户登录模块613，授权管理系统612中包括：用户管理模块614和策略生成模块615。诊断仪630中包括用户登录模块631。车辆660中包括：策略管控模块661。其中，车辆600可以是图2中的车辆200。
该通过该系统架构600实现诊断方法之前需要进行如下设置：
(1)创建角色
OEM可以使用图7所示的角色创建方法创建角色。如图7所示，OEM可以基于授权控制系统700(role-based access control,RBAC)创建角色。在RBAC系统中可以包括：系统管理员701、安全管理员702和审计管理员703。其中，系统管理员701可以负责创建角色的工作，安全管理员702可以负责对创建的角色进行授权，审计管理员703可以负责检查角色的创建与授权。即以上三种角色在RBAC系统中的授权可以是三权分立。
在进行使用RBAC系统创建角色过程中，可以由系统管理管理员701创建角色的类型，安全管理员702赋予不同类型角色相对应的权限，再由审计管理员703进行检查。
例如，可以通过RBAC系统创建一个远程诊断角色和近端诊断角色，远程诊断角色授 予只具备读功能的诊断服务权限(例如，具备只读安全标识符(security identifier,SID)权限)，近端诊断角色授予即可以读也可以写的诊断服务权限(例如，具备读写SID权限)。
应理解，RBAC是图6中的授权管理系统612的一种，RBAC仅仅是示例性的说明，此处也可以使用其他的授权管理系统来创建角色。
(2)创建用户
OEM可以为诊断人员创建用户的账号，在账号创建时，可以为诊断人员分配相应的角色，具备对应角色的诊断人员将具备对应的诊断服务权限。同时，OEM还可为账号配置相应的车辆资源权限，即用户可以诊断哪些车型和部件。
例如，可以设定一个OEM类型的诊断人员可以诊断第一车型的整车部件，而一个供应商类型的诊断人员可以诊断第一车型的特定部件。
(3)车主授权
在诊断开始前，车主可以通过线上/线下服务协议或者通话方式进行一定时效的授权，以满足隐私合规的要求。
例如，在诊断开始前需要车主签订或勾选诊断服务协议，在车辆检测到车主签订或勾选诊断服务协议后，车辆才能够执行诊断任务。其中，诊断服务协议可以包括但不限于：诊断的对象、诊断的权限和车辆执行诊断任务需要调用的资源等等。
再例如，在诊断开始前，可以由车主通过电话的方式请求进行车辆诊断，在此种情况下可以默认车主同意诊断服务协议。
诊断方法500在该系统架构的实际应用中，远程诊断人员620需要在通过用户登录模块631登录，并由用户管理模块614验证用户身份，在身份验证成功后，策略生成模块615能够生成诊断策略文件，并通过远程诊断平台611将诊断策略文件下发到车辆600。同样的，近端诊断人员640需要通过用户登录模块631登录，并由用户管理模块614验证用户身份，在身份验证成功后，策略生成模块615生成诊断策略文件然后通过诊断仪630将诊断策略文件下发到车辆600。
在车辆600接收到诊断策略文件后，可以通过策略管控模块661对诊断策略文件进行检查。同时，在执行诊断之前，车主可以通过车主授权模块650从隐私是否合规的角度对诊断策略文件进行管理。
本申请实施例中，诊断人员进行诊断时，需要在诊断平台或诊断仪上登录相应的账号，并且由授权平台对诊断人员的身份进行验证，身份验证成功后诊断平台或诊断仪才能向车辆下发诊断策略文件，通过这样的方式，能够减少诊断平台或诊断仪被非法人员滥用或恶意诊断的风险，从而保护用户的隐私、财产和生命安全。
下面结合图8至图10详细的介绍远程诊断的执行流程。
图8是本申请实施例提供的一种远程诊断方法800，方法800可应用于图6的系统架构中。
在执行方法800之前，需要进行车辆的信息同步和诊断数据的配置。其中，车辆的信息同步可以包括：车辆将车型数据、单车数据和部件数据发送给云端服务器，由云端服务器完成车辆的信息同步。诊断数据的配置的过程可以包括：诊断平台根据上述数据确定相对应的车型，并生成诊断脚本和生成诊断数据。
其中，诊断脚本可以包括车辆部件的诊断脚本和/或车型的诊断脚本，诊断数据可以 包括部件诊断数据ID、诊断故障码和部件诊断参数至少一种。
在完成上述准备工作后，可以执行方法800，方法800可以包括如下步骤：
S801，诊断用户输入用户名及密码进行登录
具体地，诊断用户在诊断平台上输入OEM创建的账户用户名和密码进行登录。
S802，授权管理系统对用户名与密码进行身份验证
具体地，授权管理系统612可以对步骤S801中诊断人员输入的用户名和密码进行身份验证。验证成功则进行步骤S803，如果验证失败则向诊断用户提示登录失败，并结束诊断流程。
S803，登录成功后，诊断用户进入相应权限的菜单
具体地，诊断用户可以在权限菜单中查看诊断权限，诊断用户只有在该权限内才能下发诊断策略，超过该权限下发的诊断策略无效。
S804，选择诊断的车型和部件
具体地，由诊断用户选择需要诊断的车型和部件。
S805，授权管理系统根据诊断用户的选择生成诊断策略文件，并下发到车端。
其中，诊断策略文件中可以用于检查诊断指令的真实性和完整性。
S806，诊断用户选择诊断功能，系统生成对应的诊断任务
其中，诊断功能可以是由诊断脚本生成的，诊断功能可以包括：读取故障码、清除故障码、整车扫描、部件判断和其他诊断中的一种或多种。
S807，诊断任务下发到车端并执行
具体地，在步骤S806中，在诊断用户选择诊断功能后，诊断平台生成诊断任务并将诊断任务发送给车端执行。
S808，执行结果返回到诊断平台。
具体地，车辆在执行完毕诊断任务后，可以将执行结果和执行的数据上报给诊断平台，由诊断平台根据执行的结果和诊断数据进行对比，从而对车辆的执行诊断任务的情况进行分析。
本申请实施例中，在进行远程诊断之前，需要验证诊断人员的身份信息，在诊断人员的身份信息符合规定的情况下，诊断人员才能通过诊断平台向车端在权限范围内下发诊断指令或诊断策略文件。通过这样的方式，能够防止诊断权限范围之外的人员对车辆和部件资源进行非法操纵，提高远程诊断的安全性。
图9是本申请实施例提供的一种远程诊断过程中诊断策略文件生成和下发的方法900，方法900可以是图8中步骤S805的具体过程，方法900可以包括如下步骤。
S901，诊断平台生成诊断策略请求范围
具体地，诊断策略请求范围可以包括：授权类型、诊断目标和诊断有效期等。
S902，诊断平台向授权管理系统提出授权请求
具体地，诊断平台向授权管理系统发送授权请求信息，该信息用于请求诊断授权管理系统根据诊断策略请求范围生成并返回诊断策略文件。该授权请求信息可以是方法500中的第一请求信息。
S903，授权管理系统生成诊断策略文件
具体地，授权管理系统根据授权请求信息生成诊断策略文件，诊断策略文件的具体内 容在图14中进行详细的介绍。
S904，对诊断策略文件进行完整性保护
其中，对诊断策略文件进行完整性保护的目的是防止诊断策略文件被非法篡改，可以通过对诊断策略文件进行签名的方式实现对诊断策略文件的完整性保护。
S905，返回诊断策略文件至诊断平台
S906，诊断平台下发诊断策略文件至车端诊断模块
其中，车端诊断模块可以是图1中的诊断客户模块131。
S907，车端诊断模块对诊断策略文件进行真实性和完整性校验
具体地，车端诊断模块对诊断策略文件进行真实性和完整性校验的详细过程在图15中详细介绍。
S908，车端诊断模块在诊断策略文件的校验通过后将其存储在车辆中。
本申请实施例中，授权管理系统能够根据诊断平台的策略请求范围，生成并向车端下发诊断策略文件，车端诊断模块能够在进行真实性和完整性校验后存储该诊断策略文件，便于后续检测和验证诊断指令。
图10是本申请实施例提供的一种远程诊断过程中下发和执行诊断任务的方法1000，方法1000可以是图8中步骤S807的具体过程，方法1000可以包括如下步骤。
S1001，诊断平台对诊断任务或命令进行完整性保护
具体地，诊断平台对诊断任务或诊断命令进行完整性保护的目的是防止诊断任务或命令被非法篡改，具体的实现方式可以是在诊断平台和车辆建立通信通道时对诊断任务或命令通过加密等方式进行完整性保护。
S1002，诊断平台将诊断任务或命令下发至车端诊断模块
具体地，车端诊断模块可以是图1中的诊断模块130。
S1003，车端诊断模块检查诊断任务和命令完整性
S1004，车端诊断模块通过诊断策略文件对诊断任务或命令进行有效性验证
具体地，车端诊断模块通过诊断策略文件对诊断任务或命令进行验证的过程在图16中进行详细的介绍。
应理解，该步骤也可以理解为使用诊断策略文件验证诊断任务或诊断命令是否具有访问控制权限。
S1005，验证通过后，车端诊断模块发送命令至相应的ECU执行
具体地，在使用诊断策略文件对诊断任务或命令验证通过后，车端诊断模块可以通过诊断代理模块133将诊断命令发送至ECU执行。
S1006，ECU将诊断结果返回到车端诊断模块
具体地，ECU在执行诊断命令后，可以将诊断结果返回到诊断代理模块133。
S1007，车端诊断模块通过诊断客户端把诊断结果返回到诊断平台
具体地，诊断代理模块133可以通过诊断客户模块131将诊断结果发送至诊断平台。
本申请实施例中，能够使用诊断策略文件对诊断任务或诊断命令进行检查，在检查通过后车辆的ECU才能接收并执行相应的诊断任务或命令。通过这样的方式，能够在车端保证诊断任务或诊断命令执行的真实性和完整性。
下面结合图11至图13详细的介绍近端诊断的执行流程。
图11是本申请实施例提供的一种近端诊断方法1100，方法1100可应用于图6的系统架构中，方法1100可以包括如下步骤。
S1101，诊断用户本地解锁在线诊断仪
S1102，输入具有权限的用户名及密码
具体地，用户名及密码可以是OEM为诊断用户已经配置好的用户名及密码。
S1103，诊断授权管理系统进行身份验证
具体地，诊断用户在输入用户名和密码后，授权管理系统能够对诊断用户的身份进行验证，验证成功后执行步骤S1104，验证不成功则向用户提示登录失败或者依次执行步骤S1107至S1109。
S1104，登录成功后，选择需要诊断的车型和部件
具体地，诊断人员在登录成功后可以在权限范围内选择需要诊断的车型和车辆部件。
S1105，诊断授权管理系统生成诊断策略文件并通过诊断仪下发给车端
S1106，选择诊断功能
具体地，诊断用户在诊断仪上可以选择诊断功能，诊断功能可以包括：读取故障码、清除故障码、整车扫描、部件诊断和其他诊断中的一种或多种。由于诊断用户已经完成了身份验证，在选择上述诊断功能时，诊断用户也获得了读写权限。在诊断用户选择诊断功能后可以直接进行步骤S1108。
S1107，选择诊断功能
具体地，诊断用户在登录失败或不进行登录的情况下，权限和选择诊断功能的菜单与登录的成功的情况有所不同。
例如，如果在步骤S1102中，诊断用户在登录失败或不登录的情况下操作诊断仪选择诊断功能，此时诊断用户仅仅能够获取只读的权限，能够选择的诊断功能可以包括：读取故障码、整车扫描和进行其的他读诊断功能。
S1108，诊断命令发送给车辆并执行
具体地，由诊断仪将诊断命令发送给车辆，并由车辆中的ECU执行。
S1109，诊断结果返回到诊断仪
具体地，车辆在执行诊断命令后，将诊断的结果返回给诊断仪。
本申请实施例中，在进行近端诊断之前，需要验证诊断人员的身份信息，在诊断人员的身份信息符合规定的情况下，诊断人员能够选择的诊断功能更多，并且能够获得的诊断权限更大，通过这样的方式，能够为不同类型的诊断人员赋予相对应的诊断权限，保证了不同类型诊断人员在相应权限范围内下发诊断命令。
图12是本申请实施例提供的一种近端诊断过程中诊断策略文件生成和下发的方法1200。方法1200可以是图11中步骤S1105的具体过程，方法1200可以包括如下步骤。
S1201，诊断仪生成策略请求范围
具体地，诊断策略请求范围可以包括：授权类型、诊断目标和诊断有效期等。
S1202，诊断仪向授权管理系统提出授权请求
具体地，诊断仪向授权管理系统发送授权请求信息，该信息用于请求诊断授权管理系统根据诊断策略请求范围生成并返回诊断策略文件。该授权请求信息可以是方法500中的第一请求信息。
S1203，授权管理系统生成诊断策略文件
具体地，授权管理系统根据授权请求信息生成诊断策略文件，诊断策略文件的具体内容在图14中进行详细的介绍。
S1204，对诊断策略文件进行完整性保护
其中，对诊断策略文件进行完整性保护的目的是防止诊断策略文件被非法篡改，可以通过设置诊断策略文件签名的方式实现诊断策略文件的完整性保护。
S1205，返回诊断策略文件至诊断仪
S1206，诊断仪转发诊断策略文件至车端诊断模块
S1207，车端诊断模块对诊断策略文件进行真实性和完整性校验
具体地，车端诊断模块对诊断策略文件进行真实性和完整性校验的详细过程在图15中介绍。
S1208，车辆诊断模块在诊断策略文件的校验通过后将其存储在车辆中
本申请实施例中，授权管理系统能够根据诊断仪的策略请求范围，生成并向车端下发诊断策略文件，车端诊断模块能够在进行完整性校验后存储该诊断策略文件，便于后续检测和验证诊断命令。
图13是本申请实施例提供的一种近端诊断过程中下发和执行诊断任务的方法1300。方法1300可以是图11中步骤S1106或S1107的具体过程，方法1300可以包括如下步骤。
S1301，诊断仪对诊断任务或命令进行完整性保护
具体地，诊断仪对诊断任务或诊断命令进行完整性保护的目的是防止诊断任务或命令被非法篡改。
S1302，诊断仪将诊断任务或命令下发至车端诊断模块
其中，车端诊断模块可以是图1中的诊断模块130。
S1303，车端诊断模块检查诊断任务和命令完整性
具体地，车端诊断模块对诊断策略文件进行完整性校验的详细过程在图15中介绍。
S1304，车端诊断模块通过诊断策略文件对诊断任务或命令进行检查
具体地，车端诊断模块通过诊断策略文件对诊断任务或命令进行检查的过程在图16中进行详细的介绍。
应理解，该步骤也可以理解为使用诊断策略文件验证诊断任务或诊断命令是否具有访问控制权限。
S1305，检查通过后，车端诊断模块发送命令至相应ECU并执行
具体地，在使用诊断策略文件对诊断任务或命令检查通过后，车端诊断模块可以通过诊断代理模块133将诊断命令发送至ECU执行。
S1306，ECU将诊断结果返回到车端诊断模块
具体地，ECU在执行诊断命令后，可以将诊断结果返回到诊断代理模块133。
S1307，车端诊断模块通过诊断客户端把诊断结果返回到诊断仪
具体地，诊断代理模块133可以通过诊断客户模块131将诊断结果发送至诊断仪。
本申请实施例中，能够使用诊断策略文件对诊断任务或诊断命令进行检查，在检查通过后车辆的ECU才能接收并执行相应的诊断任务或命令。通过这样的方式，能够在车端保证诊断任务或诊断命令执行的有效性和合法性。
图14是本申请实施例提供的一种诊断策略文件格式示意图，图14中所示的诊断策略文件可以是图8至图13中诊断诊断策略文件。
在远程诊断与近端诊断的流程中均涉及诊断策略文件，诊断策略文件的作用是在执行诊断命令之前，车端诊断模块利用诊断策略文件检查诊断命令在时间和空间上是否有效，即诊断服务必须在授权的时间和空间范围内对授权的ECU进行诊断。
如图14所示，诊断文件的格式可以包括：授权类型、空间域、时间域、版本、签名和证书。其中，授权类型可以指诊断策略文件的类型，例如，诊断策略文件的类型可以指近端诊断或者远程诊断。授权类型既可以表示在同一类型下多个诊断策略文件可以共存，例如，近端诊断和远程诊断的诊断策略文件共存。也可以表示某一特定的诊断策略文件类型生效，例如，在近端诊断和远程诊断的诊断策略文件共存情况下，可以使近端诊断策略文件生效，远程诊断策略文件失效。
空间域可以检查诊断目标的合法性，空间域的校验可以包括：车辆识别代码(vehicle identification number，VIN)校验、ECU校验、CAN ID校检、诊断服务ID校检和数据ID校检中的至少一项。时间域可以用于监控诊断时间的有效性，时间域校验可以包括：检查监控脚本的时间戳是否在授权的时间范围内和监控诊断策略文件自身是否有效。版本可以指诊断策略文件的格式版本，版本的记录可以便于未来对格式文件进行更新。签名可以指云端授权管理系统的签名，该签名可以在车端进行验签，在验签通过的情况下，保证诊断策略文件本身的真实性和完整性。
应理解，上述诊断策略文件中的授权类型、空间域、时间域、版本、签名和证书也可以在诊断策略文件中的访问控制策略信息体现。
本申请实施例中，可以通过设置诊断策略文件的格式，从而利用诊断策略文件检查诊断命令在时间和空间上是否有效，从而能够在车端保证诊断任务或诊断命令执行的有效性和合法性。
图15是本申请实施例提供的诊断策略文件真实性和完整性验证流程图1500。方法1500可应用于图9中的步骤S907或图12中的步骤S1207。
由于诊断策略文件是由诊断仪或诊断平台根据诊断人员选择的诊断目标和诊断功能自动生成和下发，并自动用在车端检查和管控诊断命令。车端在收到诊断策略文件后可以对诊断策略文件本身的真实性和完整性进行验证，在验证成功后将诊断策略文件存储在车辆中。因此，整个过程无需诊断人员过多的参与，从而减少诊断人员超越职权诊断的风险。
其中，诊断策略文件的完整性验证和真实性验证可以包括如下步骤。
S1501，验证证书
具体地，车辆在收到诊断策略文件后验证诊断策略文件中的证书是否有效，如果证书有效则进行步骤S1502，如果证书无效，则结束诊断策略文件的完整性和真实性验证流程。
S1502，用证书公钥解密签名得到数字摘要
具体地，车辆使用证书的公钥解密诊断策略文件的签名，得到数字摘要。其中，数字摘要可以指采用单向Hash函数将需要加密的明文“摘要”成一串固定长度(128位)的密文，数字摘要是根据哈希算法得到的，也可以称作哈希值。
S1503，得到新摘要
具体地，车辆对诊断策略文件中的授权类型、空间域、时间域和版本做哈希计算，得 到新摘要。
S1504，比较两个摘要是否相同
具体地，车辆比较摘要和新摘要是否相同，如果相同则进行步骤S1505，如果不相同则结束诊断策略文件的完整性和真实性验证流程。
应理解，由于数字摘要是对应于一个消息或一个文本的固定长度的值，如果车辆接收的诊断策略文件在传递的过程中被篡改，车辆对接收的诊断策略文件进行相同的哈希计算后，得到的新摘要和原来的摘要会有所不同，因此可以通过比较两个摘要是否相同来验证诊断策略文件的真实性和完整性。
S1505，通过VIN确定诊断策略文件与车辆是否匹配
具体地，可以通过诊断策略文件VIN与和车辆的VIN是否一致，来判断测量文件和车辆是否匹配，如果匹配则进行步骤S1506，如果不匹配则结束诊断策略文件的完整性和真实性验证流程。
S1506，验证诊断策略文件的时间戳和本地存储的时间戳
具体地，通过诊断策略文件的时间戳和本地存储的时间戳进行比较，其中，本地存储的时间戳可以指车辆上一次接收到诊断策略文件的时间戳。如果诊断策略文件的时间戳大于或等于本地存储的时间戳，则诊断策略文件的完整性和真实性验证通过，车辆将诊断策略文件存储在车辆中，同时开始计算诊断策略文件的有效期。如果诊断策略文件的时间戳小于本地存储的时间戳，则结束诊断策略文件的完整性和真实性验证流程。
应理解，验证诊断策略文件的时间戳和本地存储的时间戳的目的是防止诊断策略文件被重用或重放攻击。如果诊断策略文件的时间戳小于本地存储的时间戳，说明诊断策略文件可能被更改，该诊断策略文件不真实。
可选地，该步骤也可以替换为验证诊断策略文件的时间戳参数和车辆本地时间的差值是否小于或等于预设阈值。如果小于或等于预设阈值，则验证通过，如果大于预设阈值则验证失败。
本申请实施例中，车辆在收到诊断策略文件后可以对诊断策略文件本身的真实性和完整性进行验证，在验证成功后将诊断策略文件存储在车辆中，从而便于后续使用诊断策略文件检查诊断命令。
图16是本申请实施例提供的一种使用策略文件管控诊断任务或诊断命令的方法1600。方法1600可应用于图10中的步骤S1004或图13中的步骤S1304，方法1600可以包括如下步骤。
S1601，比较诊断任务和诊断策略文件中的VIN是否一致
具体地，该步骤中可以通过比较诊断任务VIN和诊断策略文件的VIN是否一致，来判断诊断任务是否匹配车辆。如果一致则进行步骤S1602，如果不一致则结束诊断任务执行流程。
可选地，在近端诊断的过程中，也可以跳过步骤S1601。
应理解，由于在图15的步骤S1505已经验证了诊断策略文件的VIN和车辆的VIN一致，此时，如果诊断任务VIN和诊断策略文件的VIN一致，则说明该诊断任务匹配该车。
S1602，确定诊断任务的时间戳是否大于诊断策略文件的时间戳
具体地，该步骤中可以确定诊断任务的时间戳是否大于诊断策略文件的时间戳，如果 大于则进行步骤S1603，如果不大于则结束诊断任务执行流程。
可选地，在近端诊断的过程中，也可以跳过步骤S1602。
应理解，该步骤中保证诊断任务的时间戳是否大于诊断策略文件的时间戳的目的是防止诊断任务的被重用或重放攻击，即需要保证车辆接收诊断命令的时间晚于接收诊断策略文件的时间。
S1603，检查诊断命令是否匹配空间域中授权的ECU
具体地，该步骤可以检查诊断命令是否匹配诊断策略文件空间域中授权的ECU，如果匹配则任性步骤S1604，如果不匹配则结束诊断任务执行流程。
可选地，该步骤也可以替换为检查诊断命令是否匹配诊断策略文件空间域中授权的CAN ID、诊断服务ID和诊断数据ID中的一种或多种。
S1604，监控诊断策略文件的有效期直到诊断策略文件失效
具体地，在诊断策略文件有效时的情况下使用诊断策略文件对诊断任务或诊断命令检测，如果诊断策略文件失效，则结束诊断流程。
本申请实施例中，可以通过诊断策略文件实现对诊断任务的检查，在检查通过后车辆的ECU才能接收并执行相应的诊断任务或命令。通过这样的方式，能够在车端保证诊断任务或诊断命令执行的真实性和完整性。
下面结合图17对整个诊断的过程进行详细的介绍。
(1)创建角色
在进行诊断之前，OEM可以按下表1的方式创建角色。
表1
Figure PCTCN2022102811-appb-000001
其中，诊断服务可以指远程诊断或近端诊断所具备的在UDS协议中规定的对应权限。
(2)创建用户
在创建完角色后可以使用下表2的方式创建用户，表2中CDC可以指连续减震控制系统(continuous damping control,CDC)。
表2
Figure PCTCN2022102811-appb-000002
(3)车主授权
车主可以通过电话的方式向诊断平台发送申请，请求OEM的远程诊断人员进行诊断。
(4)执行诊断
执行诊断具体可以包括如下步骤。
S1701，OEM远程诊断人员在诊断平台上输入用户名及密码进行登录。
S1702，授权管理系统对用户名与密码进行身份验证。
S1703，登录成功后，OEM远程诊断人员进入相应权限的菜单。
S1704，诊断人员选择车型和诊断资源，根据表2中的设定，诊断人员选择的车型为F4，选择的诊断ECU为整车ECU。
S1705，诊断平台根据F4车型和整车部件权限生成策略请求范围。
S1706，诊断平台向授权管理系统提出授权请求。
S1707，授权管理系统根据授权请求生成诊断策略文件。
S1708，授权管理系统对诊断策略文件进行完整性保护。
S1709，授权管理系统将诊断策略文件返回至远程诊断平台。
S1710，诊断平台下发诊断策略文件至车辆诊断客户端。
其中，诊断客户端可以指图1中的诊断客户模块131。
S1711，诊断客户端对策略文件进行完整性校验，校验通过后存储，其中完整性的校验可以采用如图15所示的方法。
上述步骤S1705至S1711中所述的诊断任务格式可以如图17中的(a)所示，诊断策略文件格式可以如图17(b)所示，诊断策略文件具体实现方式可以如图17中的(c)所示。
S1712，OEM远程诊断人员选择整车扫描功能，诊断平台生成对应的诊断任务。
S1713，诊断平台对诊断任务进行完整性保护。
S1714，诊断平台将诊断任务下发至车端诊断模块。
S1715，诊断模块检查诊断任务的完整性。
具体地，诊断模块可以是图1中的诊断模块130。
S1716，从诊断任务中提取诊断命令，并通过诊断策略文件对诊断命令进行检查，其中，通过诊断策略文件对诊断命令进行检查可以使用如图16所示的方法。
S1717，检查通过后，诊断代理模块发送诊断命令至相应ECU并执行。
具体地，诊断代理模块可以是图1中的诊断代理模块133。
S1718，ECU执行完毕诊断任务后将诊断结果返回到诊断代理模块。
S1719，诊断代理通过诊断客户端把诊断结果返回到诊断平台；
S1720，执行结果成功返回到诊断平台。
图18是本申请实施例提供的诊断装置1800示意图。该装置1800可应用于图2的车辆100中。
该装置1800可以包括收发单元1810、获取单元1820和处理单元1830。收发单元1810可以实现相应的通信功能，收发单元1810还可以称为通信接口或通信单元。获取单元1820用于，获取相应的指令和/或数据。处理单元1830用于对相应的指令和/或数据进行处理，处理单元1830可以读取存储单元中的指令和/或数据，以使得装置实现前述方法实施例。
可选地，该装置1800还包括存储单元，用于存储相应的指令和/或数据，
作为一种设计，该装置1800可以用于执行上文方法实施例中车辆所执行的动作。
该装置1800包括：收发单元1810，用于接收诊断设备发送的第一诊断策略文件,所述第一诊断策略文件包括：访问控制策略信息，所述诊断设备包括：远程诊断平台或近端诊断仪；处理单元1830，用于验证所述第一诊断策略文件的真实性和完整性；所述处理单元1830，还用于在所述第一诊断策略文件的真实性和完整性验证通过的情况下，根据所述访问控制策略信息验证诊断命令是否具有访问控制权限。
一种可能的实现方式中，所述访问控制策略信息包括：有效期；所述处理单元1830，具体用于在所述有效期内，使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限。
一种可能的实现方式中，所述访问控制策略信息还包括：第一车辆身份信息；所述处理单元1830，具体用于验证所述第一车辆身份信息与第二车辆身份信息是否一致，所述诊断命令包括所述第二车辆身份信息。
一种可能的实现方式中，所述第一车辆身份信息和/或所述第二车辆身份信息为车辆识别号码。
一种可能的实现方式中，所述访问控制策略信息还包括：第一标识ID，所述第一标识ID包括：第一电子控制单元ID、第一CAN ID、第一诊断服务ID和第一诊断数据ID中的至少一项；所述处理单元1830，具体用于验证所述第一标识ID与第二标识ID是否一致，所述第二标识ID为所述诊断命令中的标识ID，所述第二标识ID包括：第二电子控制单元ID、第二CAN ID、第二诊断服务ID和第二诊断数据ID中的至少一项。
一种可能的实现方式中，所述访问控制策略信息还包括：第一时间戳；所述处理单元1830，具体用于验证第二时间戳是否大于所述第一时间戳，所述第二时间戳为所述诊断命令的时间戳。
一种可能的实现方式中，所述诊断设备包括：近端诊断仪，所述第一诊断策略文件包括：第一密钥；所述处理单元1830，还用于将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；所述处理单元1830，还用于验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；所述处理单元1830，还用于在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
一种可能的实现方式中，所述诊断设备包括：近端诊断仪；所述收发单元1810，还用于接收所述近端诊断仪发送的第一密钥；所述处理单元1830，还用于将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；所述处理单元1830，还用于验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；所述处理单元1830，还用于在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
一种可能的实现方式中，所述处理单元1830，具体用于在所述第一密钥与所述第二密钥一致，且所述第一密钥在有效期内的情况下，与所述近端诊断仪建立安全访问服务。
一种可能的实现方式中，所述访问控制策略信息还包括：证书和签名；所述处理单元1830，具体用于使用所述证书的公钥解密所述签名，得到第一数字摘要；对所述访问控制策略信息进行哈希计算，得到第二数字摘要；验证所述第一数字摘要与所述第二数字摘要是否一致。
一种可能的实现方式中，所述处理单元1830，具体用于验证所述第一车辆身份信息 是否与车辆匹配，所述车辆为待执行所述诊断命令的车辆。
一种可能的实现方式中，所述收发单元1810，还用于接收所述诊断设备发送的第二诊断策略文件，所述第二诊断文件包括：第三时间戳；所述处理单元1830，具体用于验证所述第一时间戳是否大于所述第三时间戳。
一种可能的实现方式中，所述收发单元1810，具体用于在取得车主授权的情况下，接收所述诊断设备发送的所述第一诊断策略文件。
作为一种设计，该装置1800可以用于执行上文方法实施例中诊断设备所执行的动作。
该装置1800包括：收发单元1810，用于向授权管理系统发送第一请求信息，所述第一请求信息用于请求所述授权管理系统生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；所述收发单元1810，还用于接收所述授权管理系统发送的所述第一诊断策略文件；所述收发单元1810，还用于向车辆发送所述第一诊断策略文件，所述车辆为待执行所述诊断命令的车辆。
一种可能的实现方式中，所述装置还包括：获取单元1820，用于获取诊断人员的身份信息；所述收发单元1810，还用于向所述授权管理系统发送所述诊断人员的身份信息；所述收发单元1810，具体用于在接收到所述授权管理系统发送的第一响应信息情况下，向所述授权管理系统发送所述第一请求信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
一种可能的实现方式中，所述第一诊断策略文件包括：第二密钥，所述装置还包括：处理单元1830，用于将所述第二密钥保存在所述诊断设备中
一种可能的实现方式中，所述收发单元1810，还用于接收密钥管理系统发送的第二密钥；所述处理单元1830，还用于将所述第二密钥保存在所述诊断设备中，所述诊断设备为所述近端诊断仪；向所述车辆发送第一密钥。
作为一种设计，该装置1800可以用于执行上文方法实施例中授权管理系统所执行的动作。
该装置1800包括：收发单元1810，用于接收诊断设备发送的第一请求信息，处理单元1830，用于根据所述第一请求信息生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；所述收发单元1810，还用于向所述诊断设备发送所述第一诊断策略文件。
一种可能的实现方式中，所述收发单元1810，还用于接收所述诊断设备发送的诊断人员身份信息；所述收发单元1810，还用于在所述诊断人员的身份信息与所述授权管理系统中预设的身份信息一致的情况下，向所述诊断设备发送第一响应信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
应理解，本申请实施例提供的收发单元可以是诊断模块(诊断装置)的上的通信接口，诊断模块可以通过该接口从T-BOX或其他设备中接收第一诊断策略文件。收发单元还可以是车辆中T-BOX上的通信接口，由该T-BOX接收第一诊断策略文件，并将第一诊断策略文件发送给诊断模块处理。
还应理解，图18中的处理单元1830可以由至少一个处理器或处理器相关电路实现，获取单元1820和收发单元1810可以由收发器或收发器相关电路实现，存储单元可以通过至少一个存储器实现。
可选地，若该装置1800位于车辆200中，上述处理单元1830可以是图2所示的处理器211。
可选地，上述处理单元1830可以是图19中的处理器1920，上述存储单元可以是图19中的存储器1910，上述获取单元1810或获取单元1820可以是图19中的通信接口1930。
图19是本申请实施例提供的诊断装置1900示意图。该装置1900可应用于图1的车辆100中。
该诊断装置1900包括：存储器1910、处理器1920、以及通信接口1930。其中，存储器1910、处理器1920，通信接口1930通过内部连接通路相连，该存储器1910用于存储指令，该处理器1920用于执行该存储器1910存储的指令，可选地，存储器1910既可以和处理器1920通过接口耦合，也可以和处理器1920集成在一起。
需要说明的是，上述通信接口1930使用例如但不限于收发器一类的收发装置，来实现通信设备1000与其他设备或通信网络之间的通信。上述通信接口1930还可以包括输入/输出接口(input/output interface)。
处理器1920存储有一个或多个计算机程序，该一个或多个计算机程序包括指令。当该指令被所述处理器1920运行时，使得该诊断装置1900执行上述各实施例中诊断方法技术方案。
可选地，该装置1800和装置1900可以位于图2中的车辆200中。
可选地，该装置1800和装置1900可以为图2中车辆中的计算平台210。
在实现过程中，上述方法的各步骤可以通过处理器1920中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1910，处理器1920读取存储器1910中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
本申请实施例还提供一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得所述计算机执行上述图3至图17中的任一种方法。
本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，当所述计算机程序被运行时，使得计算机执行上述图3至图17中的任一种方法。
本申请实施例还提供一种芯片，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行上述图3至图17中的任一种方法。
本申请实施例还提供一种车辆，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行上述图3至图17中的任一种方法。
本申请实施例还提供一种车辆，包括图18或图19任一种诊断装置。
应理解，本申请实施例中，上述处理器可以为中央控制单元(central processing unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列 (field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解，本申请实施例中，该存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。处理器的一部分还可以包括非易失性随机存取存储器。例如，处理器还可以存储设备类型的信息。
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
还应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
在本说明书中使用的术语“部件”、“模块”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (43)

  1. 一种诊断方法，其特征在于，所述方法包括：
    接收诊断设备发送的第一诊断策略文件,所述第一诊断策略文件包括：访问控制策略信息，所述诊断设备包括：远程诊断平台或近端诊断仪；
    验证所述第一诊断策略文件的真实性和完整性；
    在所述第一诊断策略文件的真实性和完整性验证通过的情况下，根据所述访问控制策略信息验证诊断命令是否具有访问控制权限。
  2. 如权利要求1所述的方法，其特征在于，所述访问控制策略信息包括：有效期，所述根据所述访问控制策略信息验证诊断命令是否具有访问控制权限，包括：
    在所述有效期内，使用所述访问控制策略信息验证所述诊断命令是否具有所述访问控制权限。
  3. 如权利要求1或2所述的方法，其特征在于，所述访问控制策略信息还包括：第一车辆身份信息，所述根据所述访问控制策略信息验证诊断命令是否具有访问控制权限，包括：
    验证所述第一车辆身份信息与第二车辆身份信息是否一致，所述诊断命令包括所述第二车辆身份信息。
  4. 如权利要求3所述的方法，其特征在于，所述第一车辆身份信息和/或所述第二车辆身份信息为车辆识别号码。
  5. 如权利要求1至4所述的方法，其特征在于，所述访问控制策略信息还包括：第一标识ID，所述第一标识ID包括：第一电子控制单元ID、第一CAN ID、第一诊断服务ID和第一诊断数据ID中的至少一项；
    所述使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限，包括：
    验证所述第一标识ID与第二标识ID是否一致，所述第二标识ID为所述诊断命令中的标识ID，所述第二标识ID包括：第二电子控制单元ID、第二CAN ID、第二诊断服务ID和第二诊断数据ID中的至少一项。
  6. 如权利要求1至5所述的方法，其特征在于，所述访问控制策略信息还包括：第一时间戳，所述使用所述访问控制策略信息验证所述诊断命令是否具有访问控制权限，包括：
    验证第二时间戳是否大于所述第一时间戳，所述第二时间戳为所述诊断命令的时间戳。
  7. 如权利要求1至6所述的方法，其特征在于，所述诊断设备包括：近端诊断仪，所述第一诊断策略文件还包括：第一密钥，所述方法还包括：
    将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；
    验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；
    在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
  8. 如权利要求1至6所述的方法，其特征在于，所述诊断设备包括：近端诊断仪，所述方法还包括：
    接收所述近端诊断仪发送的第一密钥；
    将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；
    验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；
    在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
  9. 如权利要求7或8所述的方法，其特征在于，所述在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务，包括：
    在所述第一密钥与所述第二密钥一致，且所述第一密钥在有效期内的情况下，与所述近端诊断仪建立安全访问服务。
  10. 如权利要求1至9任一项所述的方法，其特征在于，所述访问控制策略信息还包括：证书和签名，所述验证所述第一诊断策略文件的真实性和完整性，包括：
    使用所述证书的公钥解密所述签名，得到第一数字摘要；
    对所述访问控制策略信息进行哈希计算，得到第二数字摘要；
    验证所述第一数字摘要与所述第二数字摘要是否一致。
  11. 如权利要求3所述的方法，其特征在于，所述验证所述第一诊断策略文件的真实性和完整性，包括：
    验证所述第一车辆身份信息是否与车辆匹配，所述车辆为待执行所述诊断命令的车辆。
  12. 如权利要求6所述的方法，其特征在于，在所述接收诊断设备发送的第一诊断策略文件之前，所述方法还包括：
    接收所述诊断设备发送的第二诊断策略文件，所述第二诊断文件包括：第三时间戳；
    所述验证所述第一诊断策略文件的真实性和完整性，包括：
    验证所述第一时间戳是否大于所述第三时间戳。
  13. 如权利要求1至12所述的方法，其特征在于，所述接收诊断设备发送的第一诊断策略文件，包括：
    在取得车主授权的情况下，接收所述诊断设备发送的所述第一诊断策略文件。
  14. 一种诊断方法，其特征在于，所述方法应用于诊断设备中，所述诊断设备包括：远程诊断平台或近端诊断仪，所述方法包括：
    向授权管理系统发送第一请求信息，所述第一请求信息用于请求所述授权管理系统生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；
    接收所述授权管理系统发送的所述第一诊断策略文件；
    向车辆发送所述第一诊断策略文件，所述车辆为待执行所述诊断命令的车辆。
  15. 如权利要求14所述的诊断方法，其特征在于，在所述向授权管理系统发送第一请求信息之前，所述方法还包括：
    获取诊断人员的身份信息；
    向所述授权管理系统发送所述诊断人员的身份信息；
    所述向授权管理系统发送第一请求信息，包括：
    在接收到所述授权管理系统发送的第一响应信息情况下，向所述授权管理系统发送所述第一请求信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
  16. 如权利要求14或15所述的方法，其特征在于，所述第一诊断策略文件包括：第 二密钥，在所述向车辆发送所述第一诊断策略文件之前，所述方法还包括：
    将所述第二密钥保存在所述诊断设备中，所述诊断设备为所述近端诊断仪。
  17. 如权利要求14或15所述的方法，其特征在于，在所述向车辆发送所述第一诊断策略文件之前，所述方法还包括：
    接收密钥管理系统发送的第二密钥；
    将所述第二密钥保存在所述诊断设备中，所述诊断设备为所述近端诊断仪；
    向所述车辆发送第一密钥。
  18. 一种诊断方法，其特征在于，所述方法应用于授权管理系统中，所述方法包括：
    接收诊断设备发送的第一请求信息，所述诊断设备包括：远程诊断平台或近端诊断仪；
    根据所述第一请求信息生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；
    向所述诊断设备发送所述第一诊断策略文件。
  19. 如权利要求18所述的方法，其特征在于，在所述接收诊断设备发送的第一请求信息之前，所述方法还包括：
    接收所述诊断设备发送的诊断人员身份信息；
    在所述诊断人员的身份信息与所述授权管理系统中预设的身份信息一致的情况下，向所述诊断设备发送第一响应信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
  20. 一种诊断装置，其特征在于，所述装置包括：
    收发单元，用于接收诊断设备发送的第一诊断策略文件,所述第一诊断策略文件包括：访问控制策略信息，所述诊断设备包括：远程诊断平台或近端诊断仪；
    处理单元，用于验证所述第一诊断策略文件的真实性和完整性；
    所述处理单元，还用于在所述第一诊断策略文件的真实性和完整性验证通过的情况下，根据所述访问控制策略信息验证诊断命令是否具有访问控制权限。
  21. 如权利要求20所述的装置，其特征在于，所述访问控制策略信息包括：有效期；
    所述处理单元，具体用于在所述有效期内，使用所述访问控制策略信息验证所述诊断命令是否具有所述访问控制权限。
  22. 如权利要求20或21所述的装置，其特征在于，所述访问控制策略信息还包括：第一车辆身份信息；
    所述处理单元，具体用于验证所述第一车辆身份信息与第二车辆身份信息是否一致，所述诊断命令包括所述第二车辆身份信息。
  23. 如权利要求22所述的装置，其特征在于，所述第一车辆身份信息和/或所述第二车辆身份信息为车辆识别号码。
  24. 如权利要求20至23任一项所述的装置，其特征在于，所述访问控制策略信息还包括：第一标识ID，所述第一标识ID包括：第一电子控制单元ID、第一CAN ID、第一诊断服务ID和第一诊断数据ID中的至少一项；
    所述处理单元，具体用于验证所述第一标识ID与第二标识ID是否一致，所述第二标识ID为所述诊断命令中的标识ID，所述第二标识ID包括：第二电子控制单元ID、第二CAN ID、第二诊断服务ID和第二诊断数据ID中的至少一项。
  25. 如权利要求20至24任一项所述的装置，其特征在于，所述访问控制策略信息还包括：第一时间戳；
    所述处理单元，具体用于验证第二时间戳是否大于所述第一时间戳，所述第二时间戳为所述诊断命令的时间戳。
  26. 如权利要求20至25任一项所述的装置，其特征在于，所述诊断设备包括：近端诊断仪，所述第一诊断策略文件包括：第一密钥；
    所述处理单元，还用于将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；
    所述处理单元，还用于验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；
    所述处理单元，还用于在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
  27. 如权利要求20至25任一项所述的装置，其特征在于，所述诊断设备包括：近端诊断仪；
    所述收发单元，还用于接收所述近端诊断仪发送的第一密钥；
    所述处理单元，还用于将所述第一密钥保存在车辆中，所述车辆为待执行所述诊断命令的车辆；
    所述处理单元，还用于验证所述第一密钥与第二密钥是否一致，所述第二密钥为保存在所述近端诊断仪中的密钥；
    所述处理单元，还用于在所述第一密钥与所述第二密钥一致的情况下，与所述近端诊断仪建立安全访问服务。
  28. 如权利要求26或27所述的装置，其特征在于，
    所述处理单元，具体用于在所述第一密钥与所述第二密钥一致，且所述第一密钥在有效期内的情况下，与所述近端诊断仪建立安全访问服务。
  29. 如权利要求20至28任一项所述的装置，其特征在于，所述访问控制策略信息还包括：证书和签名；
    所述处理单元，具体用于使用所述证书的公钥解密所述签名，得到第一数字摘要；
    对所述访问控制策略信息进行哈希计算，得到第二数字摘要；
    验证所述第一数字摘要与所述第二数字摘要是否一致。
  30. 如权利要求22所述的装置，其特征在于，
    所述处理单元，具体用于验证所述第一车辆身份信息是否与车辆匹配，所述车辆为待执行所述诊断命令的车辆。
  31. 如权利要求25所述的装置，其特征在于，
    所述收发单元，还用于接收所述诊断设备发送的第二诊断策略文件，所述第二诊断文件包括：第三时间戳；
    所述处理单元，具体用于验证所述第一时间戳是否大于所述第三时间戳。
  32. 如权利要求20至31任一项所述的装置，其特征在于，
    所述收发单元，具体用于在取得车主授权的情况下，接收所述诊断设备发送的所述第一诊断策略文件。
  33. 一种诊断装置，其特征在于，所述装置包括：
    收发单元，用于向授权管理系统发送第一请求信息，所述第一请求信息用于请求所述授权管理系统生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；
    所述收发单元，还用于接收所述授权管理系统发送的所述第一诊断策略文件；
    所述收发单元，还用于向车辆发送所述第一诊断策略文件，所述车辆为待执行所述诊断命令的车辆。
  34. 如权利要求33所述的装置，其特征在于，所述装置还包括：
    获取单元，用于获取诊断人员的身份信息；
    所述收发单元，还用于向所述授权管理系统发送所述诊断人员的身份信息；
    所述收发单元，具体用于在接收到所述授权管理系统发送的第一响应信息情况下，向所述授权管理系统发送所述第一请求信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
  35. 如权利要求33或34所述的装置，其特征在于，所述第一诊断策略文件包括：第二密钥，所述装置还包括：
    处理单元，用于将所述第二密钥保存在所述诊断设备中。
  36. 如权利要求33或34所述的装置，其特征在于，
    所述收发单元，还用于接收密钥管理系统发送的第二密钥；
    所述处理单元，还用于将所述第二密钥保存在所述诊断设备中，所述诊断设备为所述近端诊断仪；
    向所述车辆发送第一密钥。
  37. 一种诊断装置，其特征在于，所述装置包括：
    收发单元，用于接收诊断设备发送的第一请求信息，
    处理单元，用于根据所述第一请求信息生成第一诊断策略文件，所述第一诊断策略文件用于验证诊断命令是否具有访问控制权限；
    所述收发单元，还用于向所述诊断设备发送所述第一诊断策略文件。
  38. 如权利要求37所述的装置，其特征在于，
    所述收发单元，还用于接收所述诊断设备发送的诊断人员身份信息；
    所述收发单元，还用于在所述诊断人员的身份信息与所述授权管理系统中预设的身份信息一致的情况下，向所述诊断设备发送第一响应信息，所述第一响应信息用于指示所述诊断人员的身份验证成功。
  39. 一种诊断装置，其特征在于，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行如权利要求1至19中任一项所述的方法。
  40. 一种计算机可读介质，其特征在于，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得所述计算机执行如权利要求1至19中任一项所述的方法。
  41. 一种芯片，其特征在于，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行如权利要求1至19中 任一项所述的方法。
  42. 一种计算机程序产品，其特征在于，所述计算机产品包括：计算机程序，当所述计算机程序被运行时，使得计算机执行如权利要求1至19中任一项所述的方法。
  43. 一种车辆，其特征在于，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行如权利要求1至13中任一项所述的方法。
PCT/CN2022/102811 2022-06-30 2022-06-30 诊断方法和装置 WO2024000402A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/102811 WO2024000402A1 (zh) 2022-06-30 2022-06-30 诊断方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/102811 WO2024000402A1 (zh) 2022-06-30 2022-06-30 诊断方法和装置

Publications (1)

Publication Number Publication Date
WO2024000402A1 true WO2024000402A1 (zh) 2024-01-04

Family

ID=89383526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/102811 WO2024000402A1 (zh) 2022-06-30 2022-06-30 诊断方法和装置

Country Status (1)

Country Link
WO (1) WO2024000402A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070288134A1 (en) * 2006-06-12 2007-12-13 Ford Global Technologies, Llc System and method for demonstrating functionality of on-board diagnostics for vehicles
CN102455700A (zh) * 2010-10-21 2012-05-16 斯必克机电产品(苏州)有限公司 汽车故障诊断信息实时互动的方法及其系统
CN104765357A (zh) * 2015-03-11 2015-07-08 西安电子科技大学 一种车辆远程诊断授权系统及方法
CN112346441A (zh) * 2020-12-09 2021-02-09 深圳市超越科技开发有限公司 一种汽车在线诊断方法、系统和汽车诊断设备
CN113759883A (zh) * 2021-10-26 2021-12-07 深圳市元征科技股份有限公司 车辆诊断方法、车辆网关设备、服务器及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070288134A1 (en) * 2006-06-12 2007-12-13 Ford Global Technologies, Llc System and method for demonstrating functionality of on-board diagnostics for vehicles
CN102455700A (zh) * 2010-10-21 2012-05-16 斯必克机电产品(苏州)有限公司 汽车故障诊断信息实时互动的方法及其系统
CN104765357A (zh) * 2015-03-11 2015-07-08 西安电子科技大学 一种车辆远程诊断授权系统及方法
CN112346441A (zh) * 2020-12-09 2021-02-09 深圳市超越科技开发有限公司 一种汽车在线诊断方法、系统和汽车诊断设备
CN113759883A (zh) * 2021-10-26 2021-12-07 深圳市元征科技股份有限公司 车辆诊断方法、车辆网关设备、服务器及存储介质

Similar Documents

Publication Publication Date Title
US11888833B2 (en) Trusted platform protection in an autonomous vehicle
US11755713B2 (en) System and method for controlling access to an in-vehicle communication network
US10991175B2 (en) Repair management system for autonomous vehicle in a trusted platform
KR20190083336A (ko) 디바이스의 보안 프로비저닝 및 관리
US20130212659A1 (en) Trusted connected vehicle systems and methods
CN110708388B (zh) 用于提供安全服务的车身安全锚节点设备、方法以及网络系统
CN112543927A (zh) 一种设备升级方法及相关设备
CN113347133B (zh) 车载设备的认证方法及装置
US9286485B2 (en) Using trust points to provide services
US20240073037A1 (en) Internal certificate authority for electronic control unit
CN113766450B (zh) 车辆虚拟钥匙共享方法及移动终端、服务器、车辆
JP5927815B2 (ja) トラストポイントを用いてサービスを提供するシステム及び方法
US11870557B2 (en) Process for generating transport keys for data communication based on actions performed by a transport
CN109714171A (zh) 安全防护方法、装置、设备和介质
CN112153646A (zh) 认证方法、设备及系统
KR20230010483A (ko) 차량 내 obd를 이용한 탄소배출 감축량 산정 시스템 및 그 방법
WO2024032438A1 (zh) 车辆安全访问方法、系统及相关装置
WO2023232045A1 (zh) 车辆校验方法、相关装置及系统
WO2024000402A1 (zh) 诊断方法和装置
US11935093B1 (en) Dynamic vehicle tags
US20230393833A1 (en) Real-time modifications for vehicles
CN117475533A (zh) 数据传输方法及装置、设备、计算机可读存储介质
Nasser Automotive Cybersecurity Engineering Handbook: The automotive engineer's roadmap to cyber-resilient vehicles
US20240272892A1 (en) Vehicle ota security validation
US20240326597A1 (en) Battery management system communication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22948507

Country of ref document: EP

Kind code of ref document: A1