Vehicle-mounted certificate centralized management and automatic issuing system and method

Abstract

The application discloses a kind of vehicle-mounted certificate centralized management and automatic issuing system and method, system includes cloud PKI system, CMS node deployed in central computing platform and the certificate request client of each area controller, cloud PKI system is responsible for issuing vehicle-mounted certificate and managing certificate strategy, CMS node is as in-vehicle certificate issuing center;Adopt two sets of systems of vehicle-mounted certificate and self-signed root certificate, vehicle-mounted certificate is used for the TLS two-way authentication of vehicle and cloud;Self-signed root certificate, CMS is locally generated when first starting, is used to issue in-vehicle equipment certificate.The method is divided into three stages: production line is only for central computing platform to preset vehicle-mounted certificate, CMS initialization generates self-signed root certificate, and controller is powered on and automatically requests equipment certificate to CMS.The application realizes in-vehicle certificate unified management, simplifies production line operation, supports device plug and play and automation operation and maintenance, reduces vehicle-mounted certificate full life cycle management cost.

Description

Technical Field

[0001] This invention relates to the field of vehicle-mounted certificate management technology, and in particular to a centralized management and automatic issuance system and method for vehicle-mounted certificates. Background Technology

[0002] With the rapid development of automotive intelligence and connectivity, automotive electronic and electrical architecture is evolving from distributed to centralized. The new generation architecture adopts a "central computing platform + area controller" model. The central computing platform has powerful computing power, security chips, and networking capabilities, while the area controllers are distributed throughout the vehicle and are responsible for controlling the nearest devices. All nodes are connected via an in-vehicle Ethernet network. To meet the two-way certification requirements of automotive cybersecurity regulations such as ISO / SAE 21434 and UN R155, the onboard controllers need to deploy digital certificates.

[0003] Existing vehicle certificate deployment solutions have the following drawbacks: high production line complexity, traditional solutions require separate certificate loading for each controller on the production line, and the production line needs to be connected to the cloud PKI system; when retrofitting or replacing parts, it is necessary to return to the factory or use special equipment for certificate loading, resulting in long maintenance cycles and high costs; lack of unified in-vehicle certificate management, with certificates for each controller being managed separately, increasing the complexity of operation and maintenance. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the present invention aims to provide a centralized management and automatic issuance system and method for vehicle-mounted certificates.

[0005] To achieve the objectives of this invention, the technical solution adopted is as follows:

[0006] A centralized management and automatic issuance system for vehicle-mounted certificates includes a cloud-based PKI system, a CMS node, and a certificate request client. The cloud-based PKI system is responsible for issuing vehicle-mounted certificates and managing certificate policies. The CMS node is deployed on a central computing platform and serves as the in-vehicle certificate issuance center. The certificate request client is deployed on each regional controller.

[0007] The cloud-based PKI system includes an on-board certificate issuance module and a certificate policy management module. The on-board certificate issuance module issues a unique on-board certificate for each vehicle based on the VIN code. The certificate policy management module configures the certificate validity period, purpose, and rotation cycle policy.

[0008] The CMS node includes a secure storage module, a certificate issuance module, and a communication module. The secure storage module stores the vehicle certificate, the self-signed root certificate, and their private keys. The certificate issuance module uses the self-signed root certificate and private keys to process certificate requests and calls the secure chip to issue device certificates. The communication module uses the vehicle certificate to communicate with the cloud and communicates with the controller through the in-vehicle network.

[0009] The certificate request client includes a key generation module, a request sending module, and a certificate management module. The key generation module generates key pairs locally, and the private key is stored in the controller's local security zone. The request sending module sends certificate requests to the CMS. The certificate management module stores and manages local certificates.

[0010] Furthermore, the system employs two certificate systems: an in-vehicle certificate, which is packaged on the production line and used for TLS two-way authentication between the vehicle and the cloud; and a self-signed root certificate, which is generated locally when the CMS is first started and used to issue certificates for in-vehicle devices.

[0011] A method for centralized management and automatic issuance of vehicle-mounted certificates includes three stages: the first stage is the pre-installation of vehicle-mounted certificates on the production line. During the vehicle production stage, only the central computing platform carrying CMS services needs to be pre-installed with vehicle-mounted certificates; the second stage is the initialization of CMS services and the generation of self-signed root certificates; the third stage is that after the domain controller is powered on, it automatically requests certificates from CMS.

[0012] Furthermore, the first stage specifically includes the following steps:

[0013] (1) The cloud-based PKI system generates vehicle-mounted certificates, vehicle-mounted certificate private keys, and certificate chains;

[0014] (2) The cloud-based PKI system distributes the encrypted certificate package to the production line filling tools;

[0015] (3) The production line filling tool fills the vehicle certificate and private key into the security chip of the central computing platform.

[0016] Furthermore, the second stage specifically includes the following steps:

[0017] (1) CMS checks whether a self-signed root certificate exists in the security chip;

[0018] (2) If it is the first time to start, a root certificate public and private key pair is generated in the security chip, and the private key is stored in the security chip; a self-signed root certificate is generated, which contains the vehicle VIN code information, and the root certificate is stored in the security chip.

[0019] (3) Initialize the CMS service and start the certificate request service;

[0020] (4) Use the pre-installed vehicle certificate to establish a TLS connection with the cloud via the network module;

[0021] (5) Synchronize certificate management policies from the cloud;

[0022] (6) Report the CMS readiness status to the cloud.

[0023] Furthermore, the third stage specifically includes the following steps:

[0024] (1) The controller performs a power-on self-test to check if there is a valid certificate locally; if there is no valid certificate, the controller generates a key pair in the local security zone;

[0025] (2) Based on the key pair and device information, generate a standard format Certificate Signing Request (CSR) and then send the CSR message to the CMS;

[0026] (3) After receiving the CSR, the CMS uses the public key in the CSR to verify the legality of the CSR signature, check the compliance of the request format, extract the device ID and check whether there are duplicate issuance records;

[0027] (4) CMS constructs certificate content based on the public key and device information in CSR, and calls the security chip to complete the signing using the private key of the self-signed root certificate;

[0028] (5) The security chip returns the issued device certificate;

[0029] (6) The CMS will issue the issued device certificate and root certificate to the controller;

[0030] (7) The controller verifies the validity of the certificate, checks the matching between the certificate public key and the local private key, and stores the certificate in the local secure area after the check is passed;

[0031] (8) The controller confirms to the CMS that the certificate installation was successful;

[0032] (9) The CMS records complete issuance logs for auditing and tracing, and reports the device type, device ID, and issuance time to the cloud.

[0033] Furthermore, certificate management strategies include: automatic lifecycle updates and cloud-triggered batch rotation.

[0034] Furthermore, the certificate management strategy also includes: automatically triggering the certificate issuance process when a new controller is connected to the in-vehicle network; and requiring the pre-configuration of the identity through the production line and the reconstruction of the in-vehicle certificate trust system when the CMS node is replaced.

[0035] Furthermore, when a new device connects to the in-vehicle network, it sends a certificate request to the CMS; after verifying that the device ID is not registered, the CMS directly issues and distributes the certificate; the CMS then reports the new device information to the cloud.

[0036] When CMS detects a device of the same type but with a different ID accessing the network, it triggers a replacement process. CMS verifies the legitimacy of the new device and revokes the original device's certificate. CMS issues a new certificate for the new device, and the new device is activated. CMS reports the replacement event to the cloud, including the old device ID and the new device ID.

[0037] The beneficial effects of this invention are that, compared with the prior art, this invention deploys a Certificate Management Service (CMS) on a central computing platform, utilizing the computing power and networking capabilities of the central computing platform to achieve unified issuance and management of in-vehicle certificates; it simplifies production line operations to the greatest extent and reduces certificate deployment costs; it supports plug-and-play controllers and enables automated certificate acquisition for aftermarket installations and replacement parts.

[0038] This invention constructs a highly centralized vehicle certificate management system, unifying the certificate issuance, storage, and update functions, originally scattered across various controllers, into a unified CMS service on a central computing platform. This centralized management fundamentally transforms traditional production line processes. Production lines only need to pre-configure a single-node CMS certificate, using the CMS as the in-vehicle CA to automatically issue certificates to all vehicle controllers in batches after the vehicle is powered on. This reduces the pre-configured objects from "all controllers in the vehicle" to "only the central computing platform," lowering the configuration complexity of production line equipment interfaces. During the operation and maintenance phase, the CMS uniformly coordinates the lifecycle of all vehicle certificates, supporting batch rotation and automatic updates triggered by cloud commands, ensuring consistent policy execution. For aftermarket and replacement scenarios, the CMS automatically identifies the device and completes certificate re-signing, achieving true plug-and-play and automated operation and maintenance.

[0039] This invention adopts a "vehicle-cloud dual certificate" architecture, ensuring that the private key does not leave the security chip throughout the entire process. Combined with centralized audit logs, it achieves full-chain security control from production to scrapping. It fully leverages the computing power and security advantages of centralized electronic architecture, significantly improves compliance efficiency, and effectively reduces the management cost of the entire life cycle of a vehicle. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the vehicle-mounted certificate centralized management and automatic issuance system described in this invention;

[0041] Figure 2 This is a flowchart of the centralized management and automatic issuance method for vehicle-mounted certificates described in this invention. Detailed Implementation

[0042] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of this application.

[0043] like Figure 1 As shown, the vehicle-mounted certificate centralized management and automatic issuance system of the present invention is based on a centralized electronic and electrical architecture, which includes at least one central computing platform and multiple regional controllers, with each node connected via an in-vehicle Ethernet network.

[0044] The vehicle-mounted certificate centralized management and automatic issuance system of the present invention includes a cloud-based PKI system, a CMS node, and a certificate request client; the cloud-based PKI system is responsible for issuing vehicle-mounted certificates and managing certificate policies; the CMS node is deployed on a central computing platform as an in-vehicle certificate issuance center; and the certificate request client is deployed on each regional controller.

[0045] The cloud-based PKI system includes an on-board certificate issuance module and a certificate policy management module. The on-board certificate issuance module issues a unique on-board certificate for each vehicle based on the VIN code. The certificate policy management module configures policies such as certificate validity period, purpose, and rotation cycle.

[0046] The CMS (Certificate Manager Service) node includes a secure storage module, a certificate issuance module, and a communication module. The secure storage module stores the vehicle certificate, the self-signed root certificate, and their private keys; the private keys do not leave the secure chip. The certificate issuance module uses the self-signed root certificate and the private key to process certificate requests and calls the secure chip to issue device certificates. The communication module uses the vehicle certificate to communicate with the cloud and communicates with the controller through the in-vehicle network.

[0047] The certificate request client includes a key generation module, a request sending module, and a certificate management module. The key generation module generates key pairs locally, and the private key is stored in the controller's local security zone. The request sending module sends certificate requests to the CMS. The certificate management module stores and manages local certificates.

[0048] This invention employs two certificate systems: an in-vehicle certificate (installed on the production line) for TLS two-way authentication between the vehicle and the cloud; and a self-signed root certificate (generated locally upon first startup of the CMS) for issuing certificates for in-vehicle devices. This design separates the responsibilities of vehicle-to-cloud communication from those of in-vehicle certificate management, simplifying the certificate deployment process.

[0049] like Figure 2 As shown, the centralized management and automatic issuance method for vehicle-mounted certificates described in this invention includes three stages: the first stage is the pre-installation of vehicle-mounted certificates on the production line. During the vehicle production stage, only the central computing platform carrying the CMS service needs to be pre-installed with vehicle-mounted certificates; the second stage is the initialization of the CMS service and the generation of self-signed root certificates; the third stage is that after the domain controller is powered on, it automatically requests a certificate from the CMS.

[0050] In the first phase, the production line pre-installs the vehicle certificate. During the vehicle production phase, only the central computing platform that carries the CMS service needs to be pre-installed with the vehicle certificate.

[0051] (1) The cloud-based PKI system generates vehicle certificates, vehicle certificate private keys, and certificate chains; the vehicle certificate contains information such as subject (VIN code), issuer (automobile enterprise intermediate CA), validity period (covering the entire life cycle of the vehicle), and purpose (digital signature, key negotiation);

[0052] (2) The cloud-based PKI system distributes the encrypted certificate package to the production line filling tools;

[0053] (3) The production line filling tool fills the vehicle certificate and private key into the security chip of the central computing platform.

[0054] The second phase involves CMS service initialization and self-signed root certificate generation.

[0055] A Certificate Management Service (CMS) is deployed on the central computing platform, employing a self-signed root certificate to achieve unified issuance and management of in-vehicle certificates. Leveraging the computing power and security chip of the central computing platform to support certificate issuance, the CMS generates a self-signed root certificate upon its first startup, serving as the trust anchor for the in-vehicle certificate system. The CMS acts as the sole certificate issuance center within the vehicle, uniformly managing all controller certificates.

[0056] (1) CMS checks whether a self-signed root certificate exists in the security chip;

[0057] (2) If it is the first startup (without root certificate), a root certificate public and private key pair is generated in the security chip; the private key is stored in the security chip; a self-signed root certificate is generated, which contains the vehicle VIN code information; the root certificate is stored in the security chip.

[0058] (3) Initialize the CMS service and start the certificate request service;

[0059] (4) Use the pre-installed vehicle certificate to establish a TLS connection with the cloud via the network module;

[0060] (5) Synchronize certificate policies (certificate lifecycle management and security usage rules) from the cloud;

[0061] (6) Report the CMS readiness status to the cloud.

[0062] In the third stage, after the domain controller is powered on, it automatically requests a certificate from the CMS;

[0063] (1) The controller performs a power-on self-test to check if there is a valid certificate locally; if there is no valid certificate, the controller generates a key pair in the local security zone;

[0064] (2) Based on the key pair and device information, generate a Certificate Signing Request (CSR) in standard PKCS#10 format. The CSR includes the device type, device ID, public key, and timestamp. Then send the CSR message to the CMS.

[0065] (3) After receiving the CSR, the CMS uses the public key in the CSR to verify the legality of the CSR signature, check the compliance of the request format, extract the device ID and check whether there are duplicate issuance records;

[0066] (4) CMS constructs certificate content based on the public key and device information in CSR, and calls the security chip to complete the signing using the private key of the self-signed root certificate;

[0067] (5) The security chip returns the issued device certificate, the certificate content includes: subject, device type + device ID; issuer, self-signed root certificate; validity period, set according to the certificate policy (e.g., 5 years); public key, taken from CSR; purpose, digital signature, key negotiation; extension, device type, vehicle VIN code, etc.

[0068] (6) The CMS will issue the issued device certificate and root certificate to the controller;

[0069] (7) The controller verifies the validity of the certificate, checks the matching between the certificate public key and the local private key, and stores the certificate in the local secure area after the check is passed;

[0070] (8) The controller confirms to the CMS that the certificate installation was successful;

[0071] (9) The CMS records complete issuance logs for auditing and tracing, and reports the device type, device ID, and issuance time to the cloud.

[0072] The certificate management strategy of this invention includes: automatic lifecycle renewal and cloud-triggered batch rotation.

[0073] The certificate will be automatically renewed upon expiration.

[0074] (1) The controller periodically checks the certificate validity period and actively initiates a Renew request with the old certificate when it is about to expire;

[0075] (2) After CMS verifies the identity, it reuses the public key and subject information of the old certificate, only updates the validity period, and issues a new certificate;

[0076] (3) The CMS issues a new certificate, and the controller installs and retains the old certificate to support a smooth transition.

[0077] Cloud-triggered batch rotation;

[0078] (1) The cloud sends a rotation command, and the CMS notifies the vehicle controller to perform key rotation;

[0079] (2) Each controller generates a new key pair and initiates an update request;

[0080] (3) The CMS issues and distributes the new certificate, and the controller completes the switch between the old and new keys and certificates;

[0081] (4) The CMS reports the status of the complete load rotation of the entire vehicle to the cloud.

[0082] The certificate management strategy of the present invention also includes: when a new controller is connected to the in-vehicle network, the certificate issuance process is automatically triggered; when the CMS node is replaced, the identity needs to be pre-configured through the production line and the in-vehicle certificate trust system needs to be rebuilt.

[0083] When a new controller is connected to the in-vehicle network, the certificate issuance process is automatically triggered.

[0084] New outfit scene:

[0085] (1) The new device connects to the in-vehicle network and sends a certificate request to the CMS;

[0086] (2) If the CMS verifies that the device ID is not registered, the certificate will be issued and distributed directly;

[0087] (3) CMS reports new device information to the cloud.

[0088] Replacement scenario:

[0089] When the CMS detects a device of the same type but a different ID connecting to the network, it triggers the replacement process:

[0090] (1) CMS verifies the legality of the new equipment and revokes the original equipment certificate;

[0091] (2) CMS issues a new certificate for the new device and activates the new device;

[0092] (3) The CMS reports the replacement event to the cloud, including the old device ID and the new device ID.

[0093] When the CMS node is changed, the identity needs to be pre-configured on the production line and the in-vehicle certificate trust system needs to be rebuilt.

[0094] (1) The new CMS performs a power-on self-test. After detecting that there is no self-signed root certificate, it generates a new root certificate and installs the vehicle certificate corresponding to the original VIN code using maintenance tools.

[0095] (2) The new CMS uses a pre-installed certificate to establish a TLS connection with the cloud and reports the replacement event;

[0096] (3) The new CMS proactively broadcasts a root certificate change notification to the whole vehicle controller, triggering the certificate re-signing process;

[0097] (4) After receiving the notification, each controller initiates a certificate request, reuses the original private key, and the new CMS issues and distributes the new certificate;

[0098] (5) The new CMS reports the updated device list to the cloud.

[0099] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

Claims

1. A centralized management and automatic issuance system for vehicle-mounted certificates, characterized in that, This includes cloud-based PKI systems, CMS nodes, and certificate request clients; The cloud-based PKI system is responsible for issuing vehicle-mounted certificates and managing certificate policies. This includes an on-board certificate issuance module and a certificate policy management module; The vehicle certificate issuance module issues a unique vehicle certificate for each vehicle based on the VIN code. The certificate policy management module allows you to configure certificate validity periods, uses, and rotation cycle policies. The CMS node, deployed on the central computing platform, serves as the in-vehicle certificate issuance center; it includes a secure storage module, a certificate issuance module, and a communication module. The secure storage module stores the vehicle certificate, the self-signed root certificate, and their private keys. The certificate issuance module uses a self-signed root certificate and a private key to process certificate requests and calls the security chip to issue device certificates. The generation, storage and signing operations of the private key of the self-signed root certificate are all completed inside the security chip, and the private key is stored in the security chip. The communication module uses the vehicle certificate to communicate with the cloud and communicates with the controller through the in-vehicle network; the CMS node also undertakes the full lifecycle management function of the in-vehicle certificate, including certificate policy synchronization, certificate status reporting, automatic certificate update, batch rotation, and automatic replacement processing. Certificate request clients are deployed on various region controllers; It includes a key generation module, a request sending module, and a certificate management module; The key generation module generates key pairs locally, and the private key is stored in the local secure area of ​​the controller. The request sending module sends a certificate request to the CMS; The certificate management module stores and manages local certificates; The system employs two certificate systems: vehicle-mounted certificates, issued by the cloud-based PKI system and packaged into the central computing platform via the production line, for TLS two-way authentication between the vehicle and the cloud; The self-signed root certificate is generated locally within the security chip when the CMS node is first started. It contains the vehicle VIN code information and is used to issue in-vehicle device certificates.

2. The vehicle-mounted certificate centralized management and automatic issuance system according to claim 1, characterized in that, After issuing the device certificate, the certificate issuance module of the CMS node sends the device certificate and the self-signed root certificate to the requesting controller.

3. A method for centralized management and automatic issuance of vehicle-mounted certificates, based on the centralized management and automatic issuance system for vehicle-mounted certificates as described in any one of claims 1-2, characterized in that, It includes three stages: In the first phase, vehicle certificates are pre-installed on the production line. During the vehicle production phase, only the central computing platform that carries CMS services needs to be pre-installed with vehicle certificates. The second phase involves CMS service initialization and self-signed root certificate generation. In the third stage, after the domain controller is powered on, it automatically requests a certificate from the CMS.

4. The method for centralized management and automatic issuance of vehicle-mounted certificates according to claim 3, characterized in that, The first stage specifically includes the following steps: (1) The cloud-based PKI system generates vehicle-mounted certificates, vehicle-mounted certificate private keys, and certificate chains; (2) The cloud-based PKI system distributes the encrypted certificate package to the production line filling tools; (3) The production line filling tool fills the vehicle certificate and private key into the security chip of the central computing platform.

5. The method for centralized management and automatic issuance of vehicle-mounted certificates according to claim 3, characterized in that, The second stage specifically includes the following steps: (1) CMS checks whether a self-signed root certificate exists in the security chip; (2) If it is the first time to start, a root certificate public and private key pair will be generated in the security chip, and the private key will be stored in the security chip; Generate a self-signed root certificate containing the vehicle VIN code information; the root certificate is stored in a secure chip. (3) Initialize the CMS service and start the certificate request service; (4) Use the pre-installed vehicle certificate to establish a TLS connection with the cloud via the network module; (5) Synchronize certificate management policies from the cloud; (6) Report the CMS readiness status to the cloud.

6. The method for centralized management and automatic issuance of vehicle-mounted certificates according to claim 3, characterized in that, The third stage specifically includes the following steps: (1) The controller performs a power-on self-test to check if there is a valid certificate locally; If no valid certificate is available, the controller generates a key pair in the local security zone; (2) Based on the key pair and device information, generate a standard format Certificate Signing Request (CSR) and then send the CSR message to the CMS; (3) After receiving the CSR, the CMS uses the public key in the CSR to verify the legality of the CSR signature, check the compliance of the request format, and extract the device ID to check whether there are duplicate issuance records. (4) CMS constructs certificate content based on the public key and device information in CSR, and calls the security chip to complete the signing using the private key of the self-signed root certificate; (5) The security chip returns the issued device certificate; (6) The CMS will issue the issued device certificate and the self-signed root certificate to the controller in a linked manner; (7) The controller verifies the validity of the certificate, checks the matching between the certificate public key and the local private key, and stores the certificate in the local secure area after the check is passed; (8) The controller confirms to the CMS that the certificate installation was successful; (9) The CMS records complete issuance logs for auditing and tracing, and reports the device type, device ID, and issuance time to the cloud.

7. The method for centralized management and automatic issuance of vehicle-mounted certificates according to claim 3, characterized in that, The management strategies implemented by the CMS node for in-vehicle certificates include: automatic lifecycle updates and cloud-triggered batch rotation.

8. The method for centralized management and automatic issuance of vehicle-mounted certificates according to claim 7, characterized in that, The automatic update of the lifecycle specifically includes the following steps: (1) The controller periodically checks the certificate validity period and actively initiates a Renew request with the old certificate when it is about to expire; (2) After CMS verifies the identity, it reuses the public key and subject information of the old certificate, only updates the validity period, and issues a new certificate; (3) The CMS issues a new certificate, and the controller installs and retains the old certificate to support a smooth transition.

9. The method for centralized management and automatic issuance of vehicle-mounted certificates according to claim 7, characterized in that, The cloud-triggered batch rotation specifically includes the following steps: (1) The cloud sends a rotation instruction, and the CMS notifies the vehicle controller to perform key rotation; (2) Each controller generates a new key pair and initiates an update request; (3) The CMS issues and distributes the new certificate, and the controller completes the switch between the old and new keys and certificates; (4) The CMS reports the status of the complete vehicle load rotation to the cloud.

10. The method for centralized management and automatic issuance of vehicle-mounted certificates according to claim 7, characterized in that, The management strategy for in-vehicle certificates implemented by the CMS node also includes: automatically triggering the certificate issuance process when a new controller connects to the in-vehicle network; and requiring the pre-configuration of the identity through the production line and the reconstruction of the in-vehicle certificate trust system when the CMS node is replaced. The CMS node is configured to: monitor the device type and device ID of devices accessing the in-vehicle network; when a device with the same type but a different ID as a registered device is detected, it is automatically identified as a replacement scenario; in response to the replacement scenario identification result, it automatically executes the processing flow of revoking the original device certificate, verifying the legality of the new device identity, issuing the new device certificate, distributing the new device certificate, and reporting the replacement event to the cloud, without any manual intervention or external dedicated equipment intervention; the replacement event report includes the old device ID and the new device ID.

Images