Driver card remote information writing system and method based on commercial vehicle network driving recorder

Abstract

The application provides a driver card remote information writing system and method based on a commercial vehicle network driving recorder. The application constructs a four-level collaborative architecture of a mobile phone applet, a cloud scheduling platform, a network recorder and a driver IC card, divides the IC card into independent storage partitions, and matches a terminal, transmits fragments, issues a timing sequence and writes a complete integrity quantitative verification model. An operation and maintenance personnel uploads driver identity data through the applet, the cloud issues the data to the vehicle recorder through encryption and fragmentation, the recorder completes IC card partition writing and automatically verifies data integrity, writes abnormally and reports faults, and after the card writing is completed, the cloud automatically synchronizes and binds data to a freight supervision platform. The application does not require external card writing hardware, supports remote batch card issuance, guarantees data reliability through full-link encryption verification, reduces operation and maintenance costs, and is suitable for operation vehicle supervision scenarios.

Description

Technical Field

[0001] This invention relates to the field of IC card information reading and writing technology, specifically to a system and method for remotely writing driver card information based on a commercial vehicle connected driving recorder. Background Technology

[0002] According to current road transport management regulations, during the operation of commercial vehicles with a total mass of 12 tons or more, the driver must insert a dedicated driver IC card into the vehicle driving recorder. The recorder will read the card's name, driver's license number, professional qualification and other identity information, and simultaneously upload the vehicle trajectory, driving time and driver identity data to the national freight supervision platform to complete the dynamic supervision of operating vehicles. The current industry standard for IC card writing is offline, stand-alone operation. Maintenance personnel need to carry a laptop and a dedicated USB card writer, along with exclusive client software, to complete the on-site input and writing of blank driver IC card information. This solution has several technical shortcomings: First, it is heavily dependent on hardware, as the two sets of supporting equipment are inconvenient to carry, and card writing operations cannot be carried out in remote logistics stations and parking lots without power supply. Second, it does not support remote batch card issuance. In scenarios involving multiple fleets and multiple drivers, maintenance personnel need to go to each vehicle to operate offline, resulting in low overall operational efficiency. Third, it lacks a cloud data interconnection link. Local card writing records are only stored on the computer and cannot be automatically synchronized to the freight supervision platform. Manual secondary entry is prone to errors and omissions in information. Fourth, it lacks a data security verification mechanism. Traditional card writing programs only provide a simple write completion status and do not set up CRC integrity verification logic for storage partitions. This can easily lead to situations where IC card data writing is interrupted or incomplete, yet the writing is deemed successful. After the vehicle is on the road, the recorder fails to read the card, triggering a regulatory violation alarm. Existing technologies have not yet formed a mature solution for remote card issuance based on the vehicle's standard connected driving recorder. There is no secure writing system that coordinates mobile app, cloud platform, and vehicle terminal. At the same time, there is a lack of standardized segmented transmission, dynamic distribution timing, and quantitative mathematical models for IC card write integrity verification adapted to vehicle-cloud transmission scenarios, resulting in significant limitations in technology implementation. Summary of the Invention

[0003] The purpose of this invention is to address the shortcomings of existing technologies by proposing a remote information writing system and method for driver cards based on a commercial vehicle connected driving recorder.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: a remote information writing system for driver cards based on a commercial vehicle connected driving recorder, the system comprising a driver IC card, a connected driving recorder, a mobile app terminal, and a cloud dispatch platform; The driver IC card has a built-in read / write storage partition and an encrypted verification partition, which are used to store the driver's name, driver's license number, and professional qualification certificate number for supervising identity data. The IC card is divided into independent storage partitions, including a read-only basic partition, a driver identity writable partition, and a verification code storage partition. The read-only basic partition stores the card's factory hardware ID and cannot be rewritten. The driver identity writable partition stores driver monitoring information. The verification code storage partition stores a cyclic redundancy check (CRC) value generated based on the driver information, used for integrity verification after the recorder writes the data. The connected driving recorder has a built-in 4G / 5G network communication module, IC card read / write recognition module, local storage unit, protocol parsing unit, and card write verification calculation unit. The recorder establishes a long connection with the cloud dispatch platform through a cellular network. The recorder is equipped with a physical IC card slot for inserting the driver's IC card. The mobile app terminal is mounted on a smartphone and includes a driver information input module, a vehicle recorder binding module, an encrypted upload module, and a writing progress feedback module. The cloud-based dispatch platform includes a user authorization module, a vehicle terminal mapping database, an instruction cache and distribution module, a protocol encapsulation and parsing module, a log writing and storage module, and a freight supervision data synchronization interface. The mobile app terminal communicates with the cloud dispatch platform via an HTTPS encrypted link. The cloud dispatch platform and the connected driving recorder transmit card writing instructions and driver identity data through a custom binary vehicle-cloud protocol. The connected driving recorder drives the IC card read / write recognition module through the internal SPI bus to complete the IC card partition writing. When the system performs remote card writing, it adopts a write integrity verification model, an instruction issuance timing control formula, and a data encryption verification formula to complete the full-process security control.

[0005] Preferably, the cloud-based dispatch platform has a built-in vehicle terminal mapping database, and establishes a binding relationship mapping formula: In the formula, A unique identification code for a vehicle; The terminal number of the connected driving recorder; This serves as an indicator of the terminal's online status. This determines the terminal's connection lifespan; the cloud uses this mapping formula to match the card writing command to be issued with the target vehicle recorder terminal.

[0006] Preferably, the custom binary vehicle-to-cloud protocol adopts a segmented and fragmented transmission mechanism, with the following formula constraining the length of a single driver information fragment: In the formula, This represents the total length in bytes of a single fragment. The protocol header has a fixed length in bytes; The length of the segmented driver identity data payload; The length of the fragment checksum in bytes; This is the maximum number of bytes that can be transmitted in a single packet for the vehicle communication module. If the threshold is exceeded, the cloud will automatically split the packet into multiple segments and send them out in fragments.

[0007] Preferably, the built-in card write verification calculation unit of the connected driving recorder adopts the write integrity verification formula: ; ; In the formula, A complete driver identity dataset uploaded by the mini-program and distributed to the cloud; The CRC32 check value is calculated and written to the verification partition simultaneously when the recorder writes to the IC card; The verification value is calculated by the recorder rereading the IC card identity partition data after the write operation is completed; This is a write result identifier; 1 indicates a complete and valid write, while 0 indicates a write failure that needs to be rewritten.

[0008] The method for remotely writing driver card information based on a commercial vehicle connected driving recorder includes the following steps: S1. Device Binding and Authentication: Vehicle registration via mobile app. With the recorder terminal The cloud-based scheduling platform uses mapping formulas Verify the terminal's online status; once authentication is successful, establish a command transmission channel between the mini-program and the target recorder. S2. Encrypted Driver Information Input: Complete regulatory data including driver's name, driver's license number, and professional qualification number is entered via the mini-program. The data is uploaded to the cloud scheduling platform after being encrypted using AES symmetric encryption. S3, Cloud-based instruction encapsulation and fragmentation: The cloud-based encrypted driver data is constrained according to the fragment length formula. Perform fragmentation and encapsulation to generate remote card writing instruction packets with serial numbers and verification codes, and store them in the instruction cache queue; S4. Remote command delivery from the cloud: The cloud sends segmented command packets sequentially to the target connected driving recorder via a long connection; S5. Recorder Parses Buffered Data: The recorder protocol parsing unit receives all fragments, reassembles the complete encrypted driver dataset according to the fragment sequence number, and decrypts it to obtain the original data. ; S6. Local IC Card Write Operation: The recorder detects a valid driver IC card in the IC card slot, calls the IC card read / write recognition module, and writes the IC card... Write the driver's identity to the writable partition on the IC card and perform synchronous calculations. Write the verification code to the storage partition; S7. Write Integrity Verification: Recorder rereads IC card identity partition data calculation Substituting into the integrity check formula, we get Identification; if Generate a successful write receipt and upload it to the cloud; if Automatically initiate local rewriting, with a maximum of 3 rewriting attempts. If the limit is exceeded, a write exception will be reported to the mini-program and the cloud. S8. Data Synchronization and Archiving: After receiving the successful write receipt in the cloud, the binding relationship between the driver, vehicle, and recorder is synchronized to the national freight supervision platform, and the complete write operation log is stored.

[0009] Preferably, in step S4, the instruction issuance adopts a dynamic timing control formula to dynamically adjust the fragmentation issuance interval to avoid data congestion in the vehicle terminal: In the formula, The interval for sending data between adjacent fragments; Based on the interval constant, the interval is issued; This represents the number of instructions currently pending in the cloud queue. This is the maximum buffer threshold for the queue; the more tasks in the queue, the longer the distribution interval will be to prevent the vehicle terminal from being overloaded at any moment.

[0010] Preferably, the local rewrite logic in step S7 includes a failure judgment threshold model, which determines the failure threshold after three consecutive verifications. When the recorder determines that the IC card is faulty, the card slot has poor contact, or the card is locked, it pushes a fault code upstream, and the mini program pops up a prompt to check the card or recorder card slot on site. Compared with existing technologies, the beneficial effects of this invention are as follows: On the one hand, the invention eliminates the dependence of traditional offline card writing on dedicated card writing hardware and on-site power supply conditions. It relies on a mobile app, a cloud-based dispatch platform, and a vehicle-equipped connected driving recorder to form a collaborative operation system. It eliminates the need for maintenance personnel to operate on-site for each vehicle and can remotely complete the writing of driver IC card identity information. It is suitable for batch card production scenarios of multiple fleets, greatly simplifying the operation process and improving card issuance and maintenance efficiency. At the same time, it establishes a data synchronization channel between the cloud and the freight supervision platform, and the card writing operation records are automatically archived and synchronized, avoiding data errors caused by manual secondary entry and meeting the data interoperability requirements of dynamic road transport supervision.

[0011] On the other hand, this invention constructs a multi-level data security and transmission protection mechanism. Through a partitioned IC card storage structure, segmented transmission control, dynamic distribution timing adjustment, and complete data verification logic, it avoids problems such as data congestion and incomplete information transmission in vehicle terminals. After writing is completed, it automatically verifies the integrity of the card storage content. In case of writing anomalies, it can automatically retry and accurately locate hardware and card-related faults. It avoids regulatory violations caused by card reader failures from the entire link of transmission, writing, and verification. The overall system data security and operational reliability are significantly better than traditional offline card writing solutions. Attached Figure Description

[0012] Figure 1 Flowchart of remote card writing service steps; Figure 2 This is a schematic diagram of the system module connections. Detailed Implementation

[0013] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0014] Please refer to the reference. Figure 1 and Figure 2 This invention provides a system and method for remotely writing driver card information based on a commercial vehicle connected driving recorder.

[0015] During the production phase, the driver's IC card is divided into three independent physical storage partitions and initialized: a read-only basic partition with a unique hardware ID for the card and a hardware lock to prevent any rewriting operations; a driver identity writable partition with standardized storage space for storing driver's name, driver's license number, road transport qualification certificate number, and other identity data required for supervision; and a verification code storage partition with a fixed-length block specifically for storing CRC checksums generated based on complete driver identity data. The partition isolation configuration is completed at the factory, ensuring that identity data and verification data are stored independently and without interference.

[0016] The hardware assembly and programming of the recorder are completed during the commercial vehicle manufacturing or on-board equipment modification stage. The device integrates a 4G / 5G cellular communication module, a dedicated IC card read / write module, a local storage unit, a protocol parsing unit, and a card write verification unit. An onboard SPI hardware bus connects to the IC card read / write module, and a standard physical IC card slot is reserved externally. Upon power-up, the device automatically establishes a permanent connection with the cloud dispatch platform. The local storage unit caches fragmentation instructions, driver identity data, and local card write logs. The card write verification unit has a built-in CRC32 calculation program, enabling real-time calculation of identity data verification codes and card reread verification comparison. The protocol parsing unit has built-in custom binary vehicle-cloud protocol parsing logic, supporting fragmented data packet reassembly and data decryption.

[0017] The front-end functional modules are developed based on WeChat / Alipay mini-programs, including driver information entry, vehicle recorder binding, encrypted upload, and write progress feedback modules. The mini-program requires no user download or installation; users can access it simply by scanning a QR code with their smartphone. The front-end supports manual entry of the driver's full monitoring identity information, incorporates AES symmetric encryption, encrypts data locally, and then uploads it to the cloud via an HTTPS encrypted channel. The binding module supports reading the vehicle identification number and recorder terminal number to complete device association. The write progress feedback module receives and visualizes real-time data from the cloud, including segmented transmission status, card write verification results, and fault prompts.

[0018] The cloud-based scheduling platform incorporates six core functional modules and has completed database configuration, including... The user permission authentication module is used to set hierarchical account permissions, distinguish the operation permissions of fleet administrators, maintenance personnel, and supervisors, and block unauthorized card writing requests; the vehicle terminal mapping database is used to build a two-way mapping library between vehicle identification codes and recorder terminal numbers, with built-in binding relationship mapping logic, real-time updates of vehicle terminal online status and connection survival time, and quick matching of card writing instructions with target vehicle terminals; the instruction cache distribution module is used to create an independent instruction cache queue, configure the maximum cache threshold of the queue, and has built-in dynamic timing control logic for segmented distribution. The protocol encapsulation and parsing module enables custom binary vehicle-to-cloud protocol encapsulation, fragmentation, and data packet verification, automatically splitting large data packets based on the single-packet transmission threshold of vehicle communication; the log storage module persistently stores the entire process log of all remote card writing operations, including operator, vehicle, driver, writing time, and verification results; the freight supervision data synchronization interface reserves a standardized interface, automatically pushing the driver, vehicle, and recorder binding data to the national freight supervision platform after successful card writing.

[0019] Example 2: Complete Implementation Process of Remote Card Writing Method: S1: Device Binding and Identity Authentication Fleet maintenance personnel open the mobile app and enter the unique identification code of the target vehicle in sequence. Vehicle-mounted connected driving recorder terminal serial number The system submits a binding authentication request to the cloud dispatch platform. The platform retrieves the vehicle terminal mapping database and executes the request through preset mapping logic. Check the online status of the corresponding recorder terminal. Connection liveness If the terminal is offline The mini-program pops up a message indicating that the vehicle's equipment is not connected to the internet, terminating the card writing process; if the terminal is online and the account permissions match... A dedicated command channel is established between the mini-program and the target recorder in the cloud to initiate the information entry process.

[0020] S2: Driver Information Entry and Local Encryption: Maintenance personnel complete the driver supervision identity dataset in the driver information entry module of the mini-program. The dataset includes required regulatory fields such as name, driver's license number, and professional qualification certificate number. After confirming the information is correct, an encrypted upload command is triggered. The mini-program locally calls the AES symmetric encryption algorithm to process the complete identity dataset. Encryption is used to prevent plaintext data from being leaked during mobile network transmission. After encryption, the encrypted data packets are uploaded to the cloud scheduling platform via an HTTPS encrypted link.

[0021] S3: Cloud Data Sharding and Command Caching The cloud protocol encapsulation and parsing module receives encrypted driver data and reads the maximum transmission byte threshold for a single packet from the vehicle communication module. Calculate the total byte length of a single fragment according to the fragment length constraint logic. The complete encrypted data is split into multiple ordered fragment data packets; each fragment is accompanied by a fragment sequence number and a fragment independent check code, and is encapsulated into a standardized remote card writing instruction packet. All instruction packets are stored in the cloud instruction cache queue to await issuance.

[0022] S4: Cloud-based dynamic time-series distribution of sharding commands: The cloud-based instruction cache delivery module reads the current number of instructions waiting to be delivered in real time. Combined with the preset basic distribution interval constant Maximum cache threshold for queue The dynamic timing control logic automatically calculates the interval between adjacent shards. : ; Queue of pending tasks The more fragments there are, the longer the interval between fragment distributions will be automatically increased. To avoid data congestion caused by the vehicle terminal receiving a large number of data packets instantaneously, the cloud relies on a long-term cellular network connection established with the recorder, and processes data in sequence according to the fragment number, at intervals. All instruction packets are sent out sequentially, and the sending time of each segment is recorded synchronously.

[0023] S5: Recorder fragment reconstruction and data decryption: The connected driving recorder's protocol parsing unit continuously receives fragmented data packets from the cloud, while the local storage unit temporarily caches all fragments. Once all fragments have been received, the complete encrypted driver dataset is reassembled based on the fragment sequence number, and the local decryption program is called to restore the original unencrypted driver identity data. It completes the initial verification of data integrity, and actively sends a request to the cloud to resubmit missing fragments.

[0024] S6: Vehicle-mounted IC card partition writing: The recorder monitors the physical IC card slot status in real time. After recognizing that a valid blank driver IC card has been inserted into the slot, it drives the IC card read / write recognition module to perform a write operation via the SPI bus: transferring the original driver identity dataset. Write the driver's identity information to the writable partition of the IC card, synchronously call the card write verification unit to calculate the CRC32 check value corresponding to the complete identity data, and generate the card verification code based on the dataset: ; Will Write the IC card verification code separately to the IC card verification code storage partition, and keep the read-only basic partition in an unchangeable state throughout the process.

[0025] S7: Card Write Integrity Verification and Abnormal Retry: After the data writing is complete, the recorder rereads all the data in the writable partition of the IC card identity and recalculates to obtain the reread verification value. The original verification value stored on the card is compared with the reread verification value to generate a write result identifier. .

[0026] If the flag is determined to be valid The recorder generates a success receipt data packet containing information about the vehicle, driver, and verification results, and uploads it to the cloud. If the identifier indicates that writing is incomplete, it will fail. The device automatically initiates a local rewrite process, repeatedly performing write verification operations; if verification fails after reaching the preset rewrite limit (i.e., after 3 consecutive verifications), the process continues. If all values ​​are 0, it is determined that the IC card is damaged, the card slot has poor contact, or the card is locked. A special fault code is pushed to the upstream cloud and mini-program. The mini-program pops up a visual prompt to guide the maintenance personnel to check the card or recorder hardware on site.

[0027] S8: Cloud-based data archiving and synchronization with the regulatory platform: After receiving the successful write receipt from the vehicle recorder, the cloud-based dispatch platform archives the entire remote card writing process in the log storage module. At the same time, it calls the freight supervision data synchronization interface to automatically push the binding relationship between the driver's identity information, vehicle identification, and recorder terminal information to the national freight supervision platform, completing the real-time synchronization of supervision data without requiring maintenance personnel to manually enter and file the data again.

[0028] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A remote information writing system for driver's cards based on a commercial vehicle connected driving recorder, characterized in that: The system includes a driver IC card, a connected driving recorder, a mobile app terminal, and a cloud dispatch platform. The driver IC card has a built-in read / write storage partition and an encrypted verification partition, which are used to store the driver's name, driver's license number, and professional qualification certificate number for supervising identity data. The connected driving recorder has a built-in 4G / 5G network communication module, IC card read / write recognition module, local storage unit, protocol parsing unit, and card write verification calculation unit. The recorder establishes a long connection with the cloud dispatch platform through a cellular network. The recorder is equipped with a physical IC card slot for inserting the driver's IC card. The mobile app terminal is mounted on a smartphone and includes a driver information input module, a vehicle recorder binding module, an encrypted upload module, and a writing progress feedback module. The cloud-based dispatch platform includes a user authorization module, a vehicle terminal mapping database, an instruction cache and distribution module, a protocol encapsulation and parsing module, a log writing and storage module, and a freight supervision data synchronization interface. The mobile app terminal communicates with the cloud dispatch platform via an HTTPS encrypted link. The cloud dispatch platform and the connected driving recorder transmit card writing instructions and driver identity data through a custom binary vehicle-cloud protocol. The connected driving recorder drives the IC card read / write recognition module through the internal SPI bus to complete the IC card partition writing. When the system performs remote card writing, it adopts a write integrity verification model, an instruction issuance timing control formula, and a data encryption verification formula to complete the full-process security control.

2. The driver card remote information writing system based on a commercial vehicle network driving recorder as described in claim 1, characterized in that: The IC card is divided into independent storage partitions, including a read-only basic partition, a driver identity writable partition, and a verification code storage partition; the read-only basic partition stores the card's factory hardware ID and cannot be rewritten; the driver identity writable partition is used to store driver monitoring information; The check code storage partition stores a cyclic redundancy check (CRC) value generated based on the driver's information, which is used for integrity verification after the recorder is written.

3. The driver card remote information writing system based on a commercial vehicle network driving recorder as described in claim 1, characterized in that: The cloud-based dispatch platform has a built-in vehicle terminal mapping database, and establishes a binding relationship mapping formula: In the formula, A unique identification code for a vehicle; The terminal number of the connected driving recorder; This serves as an indicator of the terminal's online status. For terminal connection liveness duration; The cloud uses this mapping formula to match the card writing command to be sent with the target vehicle dashcam terminal.

4. The driver card remote information writing system based on a commercial vehicle network driving recorder as described in claim 1, characterized in that: The custom binary vehicle-to-cloud protocol adopts a segmented and fragmented transmission mechanism, with the following formula constraining the length of a single driver information segment: In the formula, This represents the total length in bytes of a single fragment. The protocol header has a fixed length in bytes; The length of the segmented driver identity data payload; The length of the fragment checksum in bytes; This is the maximum number of bytes that can be transmitted in a single packet for the vehicle communication module. If the threshold is exceeded, the cloud will automatically split the packet into multiple segments and send them out in fragments.

5. The driver card remote information writing system based on a commercial vehicle network driving recorder as described in claim 1, characterized in that: The built-in card write verification calculation unit of the connected driving recorder uses the write integrity verification formula: ； ； In the formula, A complete driver identity dataset uploaded by the mini-program and distributed to the cloud; The CRC32 check value is calculated and written to the verification partition simultaneously when the recorder writes to the IC card; The verification value is calculated by the recorder rereading the IC card identity partition data after the write operation is completed; This is a write result identifier; 1 indicates a complete and valid write, while 0 indicates a write failure that needs to be rewritten.

6. A method for remotely writing driver card information based on a commercial vehicle connected driving recorder, characterized in that, It includes the following steps: S1. Device Binding and Authentication: Vehicle registration via mobile app. With the recorder terminal The cloud-based scheduling platform uses mapping formulas Verify the terminal's online status; once authentication is successful, establish a command transmission channel between the mini-program and the target recorder. S2. Encrypted Driver Information Input: Complete regulatory data including driver's name, driver's license number, and professional qualification number is entered via the mini-program. The data is uploaded to the cloud scheduling platform after being encrypted using AES symmetric encryption. S3, Cloud-based instruction encapsulation and fragmentation: The cloud-based encrypted driver data is constrained according to the fragment length formula. Perform fragmentation and encapsulation to generate remote card writing instruction packets with serial numbers and verification codes, and store them in the instruction cache queue; S4. Remote command delivery from the cloud: The cloud sends segmented command packets sequentially to the target connected driving recorder via a long connection; S5. Recorder Parses Buffered Data: The recorder protocol parsing unit receives all fragments, reassembles the complete encrypted driver dataset according to the fragment sequence number, and decrypts it to obtain the original data. ; S6. Local IC Card Write Operation: The recorder detects a valid driver IC card in the IC card slot, calls the IC card read / write recognition module, and writes the IC card... Write the driver's identity to the writable partition on the IC card and perform synchronous calculations. Write the verification code to the storage partition; S7. Write Integrity Verification: Recorder rereads IC card identity partition data calculation Substituting into the integrity check formula, we get Identification; if Generate a successful write receipt and upload it to the cloud; if Automatically initiate local rewriting, with a maximum of 3 rewriting attempts. If the limit is exceeded, a write exception will be reported to the mini-program and the cloud. S8. Data Synchronization and Archiving: After receiving the successful write receipt in the cloud, the binding relationship between the driver, vehicle, and recorder is synchronized to the national freight supervision platform, and the complete write operation log is stored.

7. The method for remotely writing driver card information based on a commercial vehicle connected driving recorder as described in claim 6, characterized in that: In step S4, the instruction issuance adopts a dynamic timing control formula to dynamically adjust the fragmentation issuance interval to avoid data congestion in the vehicle terminal: In the formula, The interval for sending data between adjacent fragments; Based on the interval constant, the interval is issued; This represents the number of instructions currently pending in the cloud queue. This is the maximum buffer threshold for the queue; the more tasks in the queue, the longer the distribution interval will be to prevent the vehicle terminal from being overloaded at any moment.

8. The method for remotely writing driver card information based on a commercial vehicle network-connected driving recorder as described in claim 6, characterized in that: Step S7, the local rewrite logic, includes a failure threshold model. When three consecutive checks occur... When the recorder determines that the IC card is faulty, the card slot has poor contact, or the card is locked, it pushes a fault code upstream, and the mini program pops up a prompt to check the card or recorder card slot on site.

Images