Automobile production line network fault processing method and device and electronic equipment

Abstract

The application relates to a network fault processing method and device for an automobile production line and electronic equipment, wherein the method comprises the following steps: obtaining a request response result of a research and development end key generation system; judging whether communication between the current production line and the research and development end key generation system is interrupted based on the request response result; in the case of communication interruption, obtaining any offline key meeting a preset availability condition from a pre-deployed backup key pool; filling any offline key into a target electronic control unit of a current vehicle, and recording the offline key binding relationship between any offline key and the current vehicle, so that the offline key binding relationship is sent to the research and development end key generation system after the communication between the current production line and the research and development end key generation system is restored. Therefore, the technical problem that, in the related art, the emergency capability is poor, the production line is stalled under the condition that the network connectivity is poor, and the production efficiency and delivery progress are affected is solved.

Description

Technical Field

[0001] This application relates to the field of production line management technology, and in particular to a network fault handling method, device and electronic equipment for an automobile production line. Background Technology

[0002] In related technologies, production line key management systems typically employ a highly dependent online interaction mode when interfacing with the key distribution system at the R&D end. This makes them extremely vulnerable to upstream failures. The production line key management system heavily relies on network connectivity with the R&D key distribution system; any network delay, jitter, or interruption will directly lead to key data transmission failure. This causes the production line key management system to stall due to the inability to receive keys in real time, forcing the interruption of key filling processes for subsequent vehicles. Consequently, the production line comes to a standstill, severely impacting production efficiency and delivery schedules. It lacks the emergency response capability to maintain core business continuity in the event of network or service anomalies, and urgently needs improvement. Summary of the Invention

[0003] This application provides a network fault handling method, apparatus, and electronic equipment for an automotive production line, in order to solve the technical problem in the related art that poor emergency response capabilities lead to production line shutdowns and affect production efficiency and delivery schedules under poor network connectivity conditions.

[0004] The first aspect of this application provides a network fault handling method for an automotive production line, comprising the following steps: obtaining a request response result from a research and development key generation system; determining, based on the request response result, whether communication between the current production line and the research and development key generation system is interrupted; in the event of a communication interruption, obtaining any offline key that meets preset availability conditions from a pre-deployed backup key pool; loading any offline key into a target electronic control unit of the current vehicle, and recording the offline key binding relationship between any offline key and the current vehicle, so that after communication between the current production line and the research and development key generation system is restored, the offline key binding relationship is sent to the research and development key generation system.

[0005] Optionally, in one embodiment of this application, the offline key binding relationship includes at least one of the current vehicle identification code, the identifier of any of the offline keys, and the filling timestamp.

[0006] Optionally, in one embodiment of this application, obtaining any offline key that meets preset availability conditions from a pre-deployed backup key pool includes: obtaining usage status tags and valid time window tags corresponding to multiple offline keys in the backup key pool; obtaining the configuration information of the current vehicle; combining the usage status tags, the valid time window tags, and the configuration information to filter at least one candidate offline key that meets the preset availability conditions from the multiple offline keys; and selecting any offline key from the at least one candidate offline key.

[0007] Optionally, in one embodiment of this application, after obtaining any offline key that meets the preset availability conditions from a pre-deployed backup key pool, the method further includes: modifying the usage status label of any offline key to obtain new usage status labels corresponding to multiple offline keys in the backup key pool; combining the new usage status labels and valid time window labels to filter out available offline keys that meet the backup conditions from the multiple offline keys; counting the number of available offline keys, and generating a key replenishment reminder if the number is less than a preset number threshold.

[0008] Optionally, in one embodiment of this application, before sending the offline key binding relationship to the R&D-end key generation system, the method further includes: sending a target number of test data packets to the R&D-end key generation system, and obtaining the received data and data transmission time difference fed back by the R&D-end key generation system; based on the received data and the data transmission time difference, determining whether the communication between the current production line and the R&D-end key generation system meets a preset stability condition; and if the preset stability condition is met, sending the offline key binding relationship to the R&D-end key generation system.

[0009] Optionally, in one embodiment of this application, sending the offline key binding relationship to the R&D-end key generation system includes: acquiring multiple offline key binding relationships during a communication interruption; extracting the identification code of the corresponding vehicle from the multiple offline key binding relationships; determining the manufacturing sequence of the corresponding vehicle based on the identification code; sorting the multiple offline key binding relationships using the manufacturing sequence to obtain a sending order table, so as to send the multiple offline key binding relationships to the R&D-end key generation system sequentially according to the sending order table.

[0010] A second aspect of this application provides a network fault handling device for an automotive production line, comprising: a first acquisition module for acquiring a request response result from a research and development end key generation system; a first judgment module for determining, based on the request response result, whether communication between the current production line and the research and development end key generation system is interrupted; a second acquisition module for acquiring, in the event of a communication interruption, any offline key satisfying a preset availability condition from a pre-deployed backup key pool; and a processing module for loading any offline key into a target electronic control unit of the current vehicle and recording the offline key binding relationship between any offline key and the current vehicle, so as to send the offline key binding relationship to the research and development end key generation system after communication between the current production line and the research and development end key generation system is restored.

[0011] Optionally, in one embodiment of this application, the offline key binding relationship includes at least one of the current vehicle identification code, the identifier of any of the offline keys, and the filling timestamp.

[0012] Optionally, in one embodiment of this application, the second acquisition module includes: a first acquisition unit, configured to acquire usage status tags and valid time window tags corresponding to multiple offline keys in the backup key pool; a second acquisition unit, configured to acquire the configuration information of the current vehicle; a filtering unit, configured to combine the usage status tags, the valid time window tags, and the configuration information to filter at least one candidate offline key that meets the preset availability condition from the multiple offline keys; and a selection unit, configured to select any one of the offline keys from the at least one candidate offline key.

[0013] Optionally, in one embodiment of this application, it further includes: a modification module, configured to modify the usage status label of any of the offline keys to obtain new usage status labels corresponding to multiple offline keys in the backup key pool; a filtering module, configured to combine the new usage status labels and valid time window labels to filter out available offline keys that meet the backup conditions from the multiple offline keys; and a reminder module, configured to count the number of available offline keys and generate a key replenishment reminder when the number is less than a preset number threshold.

[0014] Optionally, in one embodiment of this application, it further includes: a first sending module, configured to send a target number of test data packets to the R&D end key generation system, and obtain the received data and data transmission time difference fed back by the R&D end key generation system; a second judging module, configured to judge whether the communication between the current production line and the R&D end key generation system meets a preset stability condition based on the received data and the data transmission time difference; and a second sending module, configured to send the offline key binding relationship to the R&D end key generation system if the preset stability condition is met.

[0015] Optionally, in one embodiment of this application, the processing module includes: a third acquisition unit, configured to acquire multiple offline key binding relationships during a communication interruption; an extraction unit, configured to extract the identification code of the corresponding vehicle from the multiple offline key binding relationships; a determination unit, configured to determine the manufacturing sequence of the corresponding vehicle based on the identification code; and a sorting unit, configured to sort the multiple offline key binding relationships using the manufacturing sequence to obtain a sending order list, so as to send the multiple offline key binding relationships to the R&D end key generation system in sequence according to the sending order list.

[0016] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the network fault handling method for an automotive production line as described in the above embodiments.

[0017] A fourth aspect of this application provides a production line key management system, including the aforementioned electronic device.

[0018] A fifth aspect of this application provides a computer-readable storage medium storing computer instructions for causing the computer to execute the network fault handling method for an automotive production line as described in the above embodiments.

[0019] A sixth aspect of this application provides a computer program product, including a computer program, which, when executed, is used to implement the above-described network fault handling method for an automotive production line.

[0020] This application embodiment can determine whether a communication interruption has occurred between the production line key management system and the R&D key generation system based on the request and response results of the R&D key generation system. In the event of a communication interruption, a usable offline key is obtained from the backup key pool. After filling the vehicle using the offline key, the binding relationship between the offline key and the current vehicle's offline key is recorded. Once communication between the production line and the R&D key generation system is restored, the offline key binding relationship is sent to the R&D key generation system, achieving uninterrupted production, ensuring key traceability for each vehicle, eliminating the need for manual intervention, and reducing labor costs. This solves the technical problem in related technologies where poor emergency response capabilities and poor network connectivity lead to production line shutdowns, affecting production efficiency and delivery schedules.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a network fault handling method for an automobile production line according to an embodiment of this application; Figure 2 This is a flowchart of a network fault handling method for an automobile production line according to an embodiment of this application; Figure 3 This is a schematic diagram of a network fault handling device for an automobile production line according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] The following description, with reference to the accompanying drawings, outlines a network fault handling method, apparatus, and electronic equipment for an automotive production line according to embodiments of this application. Addressing the technical problem mentioned in the background art—poor emergency response capabilities leading to production line shutdowns and impacting production efficiency and delivery schedules under poor network connectivity—this application provides a network fault handling method for an automotive production line. In this method, the system determines whether a communication interruption has occurred between the production line key management system and the R&D key generation system based on the request and response results of the R&D key generation system. If a communication interruption occurs, a usable offline key is obtained from a backup key pool. After filling a vehicle with the offline key, the binding relationship between the offline key and the current vehicle's offline key is recorded. Once communication between the production line and the R&D key generation system is restored, the offline key binding relationship is sent to the R&D key generation system, achieving uninterrupted production, ensuring key traceability for each vehicle, eliminating the need for manual intervention, and reducing labor costs. This solves the technical problem in related technologies where poor emergency response capabilities lead to production line shutdowns and impacting production efficiency and delivery schedules under poor network connectivity.

[0025] Specifically, Figure 1 This is a flowchart illustrating a network fault handling method for an automobile production line provided in an embodiment of this application.

[0026] like Figure 1 As shown, the network fault handling method for this automobile production line includes the following steps: In step S101, the request response result of the R&D end key generation system is obtained.

[0027] It is understood that the embodiments of this application can be applied to a production line key management system. This system can be deployed on the factory production line and is a dedicated system for key distribution, burning, storage, verification, and lifecycle management of mass production equipment and terminal products. The R&D-side key generation system can be deployed on the enterprise's secure R&D intranet and serves as the source generation and root access control system for the entire key system.

[0028] The production line key management system and the R&D key generation system are connected through an encrypted dedicated communication channel. R&D pushes key packages, key versions, revocation lists, and authorization policies downstream; the production line sends back burning logs, equipment serial numbers, and anomaly records upstream.

[0029] If communication between the production line key management system and the R&D key generation system is interrupted, the production line will be unable to continue key filling for vehicles, resulting in a production line standstill.

[0030] To reduce the impact of communication interruptions, this application embodiment can first determine the communication status and then take corresponding actions based on the determination result. The production line key management system of this application embodiment can initiate a key request to the R&D end key generation system and receive the request response result (such as monitoring the response status of the key request interface through the TCP / IP protocol) to determine whether the communication is normal.

[0031] In step S102, based on the request response result, it is determined whether the communication between the current production line and the R&D end key generation system is interrupted.

[0032] For example, when monitoring the response status of the key request interface using the TCP / IP protocol, this embodiment of the application can set a certain timeout threshold. If no response is received after the timeout threshold is exceeded, or a connection rejection signal is received, it can be determined that the communication between the current production line and the key generation system at the R&D end is interrupted.

[0033] In step S103, in the event of a communication interruption, any offline key that meets the preset availability conditions is obtained from the pre-deployed backup key pool.

[0034] The backup key pool is a set of blank, available keys pre-deployed locally on the production line and pre-generated and distributed by the R&D-side key generation system. It is used for emergency calls in case of network interruption and does not rely on the external network.

[0035] In the event of a communication interruption, embodiments of this application can obtain a usable offline key from a backup key pool. The availability conditions may include that the key is not occupied, is compatible with the current vehicle, or is within its validity period.

[0036] Optionally, in one embodiment of this application, obtaining any offline key that meets preset availability conditions from a pre-deployed backup key pool includes: obtaining usage status tags and valid time window tags corresponding to multiple offline keys in the backup key pool; obtaining the current vehicle configuration information; combining the usage status tags, valid time window tags, and configuration information to filter at least one candidate offline key that meets preset availability conditions from multiple offline keys; and selecting any offline key from at least one candidate offline key.

[0037] Among them, status tags can be used to mark the current status of the backup key, such as idle (unoccupied) tag, occupied tag, invalid tag, revoked tag, etc.; valid time window tag can be used to mark the effective time and expiration time of the key, forming a valid time window, and keys that exceed the window are considered invalid; the current vehicle configuration information can include vehicle model, electronic control unit model, security level requirements, etc., to determine whether the key is compatible with the current vehicle.

[0038] This application embodiment can combine status tags, valid time window tags, and configuration information to filter out idle offline keys that are within the valid time window and suitable for the current vehicle from all offline keys. Then, an offline key can be randomly selected or selected in sequence from these offline keys to avoid filling failure and duplicate key allocation.

[0039] Optionally, in one embodiment of this application, after obtaining any offline key that meets the preset availability conditions from the pre-deployed backup key pool, the method further includes: modifying the usage status label of any offline key to obtain new usage status labels corresponding to multiple offline keys in the backup key pool; combining the new usage status labels and the effective time window labels to filter out available offline keys that meet the backup conditions from the multiple offline keys; counting the number of available offline keys, and generating a key replenishment reminder if the number is less than a preset number threshold.

[0040] In actual implementation, the embodiments of this application can change the usage status tag of the selected offline key from idle to occupied, ensuring that the key will not be reassigned.

[0041] In this embodiment, after the status tag is updated, the candidate key pool can be filtered in combination with the valid time window tag to obtain idle offline keys that are within the valid time window and can be used as backups. The number of offline keys that can be used as backups can be counted, and then a key replenishment reminder can be given when the number is small.

[0042] The quantity threshold can be determined comprehensively based on factors such as the production line's historical output and the minimum value required to meet emergency needs (which can be set by the user).

[0043] In step S104, any offline key is loaded into the target electronic control unit of the current vehicle, and the offline key binding relationship between any offline key and the current vehicle is recorded. This offline key binding relationship is then sent to the R&D key generation system after communication between the current production line and the R&D key generation system is restored. The offline key binding relationship includes at least one of the following: the current vehicle's identification code, the identifier of any offline key, and the loading timestamp.

[0044] Furthermore, in this embodiment of the application, an offline key can be loaded into the current vehicle, and the binding relationship between the offline key and the vehicle, i.e., the offline key binding relationship, can be recorded. After communication is restored, the offline key binding relationship can be uploaded to the key generation system at the R&D end for subsequent traceability.

[0045] The offline key binding relationship can include the vehicle identification code (vehicle identity identifier, used to distinguish different vehicles), the identifier of the offline key (which can be pre-generated by the key generation system at the R&D end, used to distinguish keys), and the filling timestamp (used to record the time when the offline key was filled).

[0046] Optionally, in one embodiment of this application, before sending the offline key binding relationship to the R&D-end key generation system, the method further includes: sending a target number of test data packets to the R&D-end key generation system, and obtaining the received data and data transmission time difference fed back by the R&D-end key generation system; based on the received data and data transmission time difference, determining whether the communication between the current production line and the R&D-end key generation system meets a preset stability condition; and if the preset stability condition is met, sending the offline key binding relationship to the R&D-end key generation system.

[0047] As one possible implementation method, this application embodiment can use test data packets (such as 3-5 packets) to detect communication stability. After the R&D end key generation system receives the test data packets, it can provide feedback on the success / failure status of reception and the number of data packets received. Then, it can obtain the total time (i.e., data transmission time difference) from when the test data packets are sent from the production line to the R&D end key generation system to when feedback is received.

[0048] By combining the success / failure status feedback, the number of received data packets, and the data transmission time difference, this application embodiment can determine whether the communication is stable. If all test data packets are successfully received and the average transmission time difference (delay) is less than a certain delay time, the communication is determined to be stable.

[0049] Optionally, in one embodiment of this application, sending offline key binding relationships to the R&D-end key generation system includes: acquiring multiple offline key binding relationships during a communication interruption; extracting the identification code of the corresponding vehicle from the multiple offline key binding relationships; determining the manufacturing sequence of the corresponding vehicle based on the identification code; sorting the multiple offline key binding relationships using the manufacturing sequence to obtain a sending order list, so as to send the multiple offline key binding relationships to the R&D-end key generation system in sequence according to the sending order list.

[0050] After communication is restored, this embodiment of the application can upload offline binding keys to the R&D end key generation system in batches. During transmission, this embodiment of the application can first obtain the planned production order of the vehicles (such as sorting by production work order or sorting by production date associated with identification code), and sort the list formed by sorting multiple offline key binding relationships according to the vehicle production time sequence, so as to clarify the sending order of the binding relationships and thus ensure the priority processing of vehicles waiting to be shipped.

[0051] Combination Figure 2As shown, the working principle of the network fault handling method for an automobile production line according to an embodiment of this application will be explained in detail with reference to one example.

[0052] like Figure 2 As shown, embodiments of this application may include the following steps: Step S201, Key Request Error Emergency Handling. This is triggered when a production line vehicle requests a key but encounters a network failure or service unavailability, and may include the following steps: S1, Fault Detection and Judgment. When the production line key management system initiates a request to the R&D-side key production system through the key application interface, it monitors the request response in real time. If a network timeout, connection refusal, or service error signal occurs, it is immediately determined to be a network or system fault.

[0053] S2, automatically switch to the backup key pool. Once a fault is confirmed, this embodiment of the application will not repeat the attempt or wait, but will automatically switch from the online application mode to the offline emergency mode, and obtain a usable offline key from the backup key pool that has been pre-deployed locally.

[0054] S3, Complete Offline Filling. The offline key obtained from the backup key pool is filled into the designated electronic control unit of the current vehicle, and a key offline key binding relationship is recorded locally. This relationship includes at least the Vehicle Identification Number (VIN), the identifier of the key used, and the filling timestamp. Through this process, uninterrupted production is achieved in a completely offline state.

[0055] Step S202: Automatic synchronization of offline keys. This ensures that offline data generated in an emergency can be automatically and completely transmitted back to the central system after the network is restored, forming a closed-loop management system.

[0056] S1, Synchronization Trigger. This embodiment of the application can continuously monitor the network connection status with the Key Management System (KMS) at the R&D end. When the connection is detected to be restored, the synchronization process can be triggered. As a preferred automated implementation, a timed triggering mechanism can be configured to proactively check for any unsynchronized offline key binding records.

[0057] S2, Data Preparation and Upload. Upon triggering, this embodiment of the application can search the local database for all records originating from the backup key pool that have been successfully loaded but whose binding relationships have not yet been written back to the R&D-side Key Production System (KMS). Subsequently, it automatically calls the offline electronic control unit key VIN write-back interface provided by the R&D side to upload these batches of key binding relationships.

[0058] S3, Result Processing and Feedback. Receives the processing results of the uploaded data from the R&D-side key production system and updates the status of local records accordingly. Simultaneously, it generates and prints clear synchronization logs on the management interface.

[0059] In summary, the embodiments of this application can automatically switch to offline mode when a network connection or service failure is detected with the key production system at the R&D end. It retrieves keys from a pre-deployed backup key pool locally and completes vehicle filling. Simultaneously, it records offline binding relationships locally, including vehicle identification codes, key identifiers, and timestamps. After the network connection is restored, a synchronization process is automatically triggered through events or timed strategies. It actively searches for all unsynchronized offline binding records and calls specific interfaces to batch-transmit them back to the central key management system. Subsequently, based on the transmission results, it automatically updates the local record status and generates synchronization logs, thereby constructing a complete data closed loop that ensures production line continuity and global data consistency. This solves the technical problems of production line shutdowns and data inconsistencies caused by reliance on online connections.

[0060] Next, with reference to the accompanying drawings, a network fault handling device for an automotive production line according to an embodiment of this application is described.

[0061] Figure 3 This is a block diagram of a network fault handling device for an automobile production line according to an embodiment of this application.

[0062] like Figure 3 As shown, the network fault handling device 10 of the automobile production line includes: Specifically, the first acquisition module 100 is used to acquire the request response result of the R&D end key generation system.

[0063] The first judgment module 200 is used to determine whether the communication between the current production line and the R&D end key generation system is interrupted based on the request response result.

[0064] The second acquisition module 300 is used to acquire any offline key that meets preset availability conditions from a pre-deployed backup key pool in the event of a communication interruption.

[0065] The processing module 400 is used to load any offline key into the target electronic control unit of the current vehicle and record the binding relationship between any offline key and the offline key of the current vehicle, so as to send the offline key binding relationship to the R&D key generation system after communication between the current production line and the R&D key generation system is restored.

[0066] Optionally, in one embodiment of this application, the offline key binding relationship includes at least one of the following: the current vehicle identification code, the identifier of any offline key, and the filling timestamp.

[0067] Optionally, in one embodiment of this application, the second acquisition module 300 includes: The first acquisition unit is used to acquire the usage status label and valid time window label corresponding to multiple offline keys in the backup key pool.

[0068] The second acquisition unit is used to acquire the configuration information of the current vehicle.

[0069] The filtering unit is used to combine usage status tags, valid time window tags, and configuration information to filter out at least one alternative offline key that meets preset availability conditions from multiple offline keys.

[0070] The selection unit is used to select any offline key from at least one alternative offline key.

[0071] Optionally, in one embodiment of this application, the network fault handling device 10 for the automotive production line further includes: The modification module is used to modify the usage status label of any offline key to obtain new usage status labels for multiple offline keys in the backup key pool.

[0072] The filtering module is used to filter available offline keys that meet the backup conditions from multiple offline keys by combining the new usage status label and the effective time window label.

[0073] The reminder module is used to count the number of available offline keys and generate a key replenishment reminder when the number is less than a preset threshold.

[0074] Optionally, in one embodiment of this application, the network fault handling device 10 for the automotive production line further includes: The first sending module is used to send a target number of test data packets to the R&D end key generation system and obtain the received data and data transmission time difference fed back by the R&D end key generation system.

[0075] The second judgment module is used to determine whether the communication between the current production line and the key generation system at the R&D end meets the preset stability conditions based on the time difference between the received data and the data transmission.

[0076] The second sending module is used to send the offline key binding relationship to the R&D end key generation system when the preset stability conditions are met.

[0077] Optionally, in one embodiment of this application, the processing module 400 includes: The third acquisition unit is used to acquire multiple offline key binding relationships during the communication interruption period.

[0078] The extraction unit is used to extract the identification code of the corresponding vehicle from multiple offline key binding relationships.

[0079] The determination unit is used to determine the manufacturing sequence of the corresponding vehicle based on the identification code.

[0080] The sorting unit is used to sort multiple offline key binding relationships according to the factory timing to obtain a sending order list, so as to send multiple offline key binding relationships to the R&D end key generation system in sequence according to the sending order list.

[0081] It should be noted that the foregoing explanation of the network fault handling method embodiment for automobile production lines also applies to the network fault handling device for automobile production lines in this embodiment, and will not be repeated here.

[0082] The network fault handling device for an automotive production line proposed in this application can determine whether a communication interruption has occurred between the production line key management system and the R&D key generation system based on the request and response results of the R&D key generation system. In the event of a communication interruption, a usable offline key is obtained from the backup key pool. After filling the vehicle using the offline key, the binding relationship between the offline key and the current vehicle's offline key is recorded. Once communication between the production line and the R&D key generation system is restored, the offline key binding relationship is sent to the R&D key generation system, achieving uninterrupted production, ensuring key traceability for each vehicle, eliminating the need for manual intervention, and reducing labor costs. This solves the technical problem in related technologies where poor emergency response capabilities lead to production line shutdowns and affect production efficiency and delivery schedules under poor network connectivity conditions.

[0083] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.

[0084] When processor 402 executes the program, it implements the network fault handling method for the automobile production line provided in the above embodiments.

[0085] Furthermore, electronic devices also include: Communication interface 403 is used for communication between memory 401 and processor 402.

[0086] The memory 401 is used to store computer programs that can run on the processor 402.

[0087] Memory 401 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0088] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0089] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0090] Processor 402 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0091] This embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described network fault handling method for an automotive production line.

[0092] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the network fault handling method for an automotive production line provided in this embodiment of the invention.

[0093] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0094] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0095] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0096] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0097] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0098] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0099] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0100] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for handling network faults in an automotive production line, characterized in that, Includes the following steps: Obtain the request and response results from the R&D-side key generation system; Based on the request response result, determine whether the communication between the current production line and the R&D end key generation system is interrupted; In the event of a communication interruption, any offline key that meets the preset availability conditions can be obtained from a pre-deployed backup key pool; Any of the offline keys is loaded into the target electronic control unit of the current vehicle, and the binding relationship between any of the offline keys and the offline keys of the current vehicle is recorded, so that after communication is restored between the current production line and the R&D end key generation system, the offline key binding relationship is sent to the R&D end key generation system.

2. The method according to claim 1, characterized in that, The offline key binding relationship includes at least one of the following: the current vehicle's identification code, the identifier of any of the offline keys, and the filling timestamp.

3. The method according to claim 1, characterized in that, The step of obtaining any offline key that meets preset availability conditions from a pre-deployed backup key pool includes: Obtain the usage status tags and valid time window tags corresponding to multiple offline keys in the backup key pool; Obtain the configuration information of the current vehicle; By combining the usage status label, the effective time window label, and the configuration information, at least one alternative offline key that meets the preset availability condition is selected from a plurality of offline keys; Choose any one of the offline keys from at least one of the candidate offline keys.

4. The method according to claim 3, characterized in that, After obtaining any offline key that meets preset availability conditions from a pre-deployed backup key pool, the process also includes: Modify the usage status label of any of the offline keys to obtain new usage status labels corresponding to multiple offline keys in the backup key pool; By combining the new usage status label and the effective time window label, available offline keys that meet the backup conditions are selected from multiple offline keys; The number of available offline keys is counted, and a key replenishment reminder is generated if the number is less than a preset threshold.

5. The method according to claim 1, characterized in that, Before sending the offline key binding relationship to the R&D-side key generation system, the following steps are also included: Send a target number of test data packets to the R&D end key generation system, and obtain the received data and data transmission time difference fed back by the R&D end key generation system; Based on the received data and the time difference of the data transmission, determine whether the communication between the current production line and the R&D end key generation system meets the preset stability conditions; If the preset stability conditions are met, the offline key binding relationship is sent to the R&D-end key generation system.

6. The method according to claim 1, characterized in that, Sending the offline key binding relationship to the R&D-end key generation system includes: Retrieve multiple offline key binding relationships during the communication interruption period; Extract the vehicle identification codes from the multiple offline key binding relationships; The manufacturing sequence of the corresponding vehicle is determined based on the identification code; The offline key binding relationships are sorted using the factory timing to obtain a sending order table, and the offline key binding relationships are sent to the R&D end key generation system in sequence according to the sending order table.

7. A network fault handling device for an automobile production line, characterized in that, include: The first acquisition module is used to acquire the request response results from the key generation system on the R&D side. The judgment module is used to determine, based on the request response result, whether the communication between the current production line and the R&D end key generation system is interrupted; The second acquisition module is used to acquire any offline key that meets preset availability conditions from a pre-deployed backup key pool in the event of a communication interruption. The processing module is used to load any of the offline keys into the target electronic control unit of the current vehicle and record the offline key binding relationship between any of the offline keys and the offline key of the current vehicle, so as to send the offline key binding relationship to the R&D key generation system after communication between the current production line and the R&D end key generation system is restored.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and capable of running on the processor, the processor executing the program to implement the network fault handling method for an automotive production line as described in any one of claims 1-6.

9. A production line key management system, characterized in that, It includes the electronic device as described in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the network fault handling method for an automotive production line as described in any one of claims 1-6.

Images