Vehicle-mounted computer security platform automatic updating method, device and medium

Abstract

The invention relates to an automatic updating method and device for a vehicle-mounted computer security platform and a medium, and the method comprises the steps: updating a configuration file and a mirror image file of each business board card of the vehicle-mounted computer security platform through a DWU (Data Maintenance Unit) and a U disk of the vehicle-mounted computer security platform; and reading the updating result file of each to-be-updated board card from the USB flash disk for re-confirmation. Compared with the prior art, under the condition that functions of an original vehicle-mounted safety computer are not affected, mirror image files or configuration files of the whole vehicle-mounted system are updated by using the maintenance module DWU of an original vehicle-mounted safety computer platform and the BMC of each service board card and externally inserting updating equipment, and maintainability of the vehicle-mounted system is enhanced.

Description

Technical Field

[0001] The present invention relates to a rail transit train control system, and in particular to a method, device and medium for automatically updating an on-board computer security platform of a rail transit train control system. Background Art

[0002] In rail transit train control systems, train control systems such as ATP (Automotic Train Protection) and ATO (Automatic Train Operation) run on an onboard computer security platform. Upgrading or updating the security platform or upper-layer application software requires manual programming of each service board on the platform, one by one. This is time-consuming, labor-intensive, and error-prone, placing high demands on on-site operators. Furthermore, remote network updates of the onboard security computer platform are not universally applicable and are inconvenient to carry external devices such as PCs, making board configuration and image updates extremely inconvenient.

[0003] A search of Chinese patent publication number CN115248698A revealed a two-by-two-out-of-two architecture in-vehicle security platform and its automatic update method. Specifically, the in-vehicle security platform includes a main MPU1 logic processing board, a main MPU2 logic processing board, a backup MPU1 logic processing board, a backup MPU2 logic processing board, and an MCU communication board. The automatic update method includes a two-out-of-two comparison of files to be updated, automatic update processing of the logic processing board and the communication board, and version rollback processing. System configuration files and image files are updated using dual USB flash drives, and the updated versions are read from the USB flash drives and then verified to ensure the security and correctness of the updated files. This existing patent employs the method of inserting dual USB flash drives into the main logic processing board and sending update data to each board in the cage via the M-LVDS bus. This results in low update efficiency, which not only affects the original in-vehicle platform functionality but also does not support multi-cage expansion, limiting its applicability. Summary of the Invention

[0004] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and provide a method, device and medium for automatically updating the vehicle-mounted computer security platform.

[0005] The purpose of the present invention can be achieved by the following technical solutions:

[0006] According to a first aspect of the present invention, a method for automatically updating an on-board computer security platform is provided. The method updates the configuration files and mirror files of each business board of the on-board computer security platform through the data maintenance unit DWU and USB flash drive of the on-board computer security platform, and reads the update result files of each board to be updated from the USB flash drive for reconfirmation.

[0007] As a preferred technical solution, the method specifically includes the following steps:

[0008] Step S1, update file checking process;

[0009] Step S2, updating the board confirmation process;

[0010] Step S3, update file transfer process;

[0011] Step S4, update result output process.

[0012] As a preferred technical solution, the update file checking process in step S1 specifically includes:

[0013] Step S101: If the DWU detects the presence of a USB flash drive and an update configuration file during the initialization phase, it enters the update mode and executes step S102; otherwise, it exits the update mode.

[0014] Step S102: The DWU reads the update configuration file in the USB flash drive and checks the correctness of the image file or configuration file to be updated in the USB flash drive according to the update file verification code of each board to be updated in the update configuration file.

[0015] Step S103: If the updated configuration files are consistent, the update board confirmation process is entered; otherwise, the update is exited.

[0016] As an optimal technical solution, the configuration file updated in step S102 includes the number of updated board types, the board type corresponding to each updated board, the number of flash types to be updated, the name of the file to be updated and the verification code of the file, as well as the number of boards to be updated and the board cage slot number under each updated board type.

[0017] As a preferred technical solution, the step S2, updating the board confirmation process specifically includes:

[0018] Step S201: DWU sends card scanning information to all CAN channels of the SWB card;

[0019] Step S202: After sending the scanned card information, the DWU receives the card scan information replied by the card to be updated from the SWB card.

[0020] Step S203: If all the boards to be updated in the configuration file have replied to the board scan information within the set time, step S3 is executed; otherwise, the update is exited.

[0021] As a preferred technical solution, in step S201, the message is sent every N seconds, and is sent M times in total.

[0022] As a preferred technical solution, the step S3, updating the file transmission process specifically includes:

[0023] Step S301: The DWU sends a write request WQ for a file to be updated to the board to be updated.

[0024] Step S302: After receiving the file write request, the board to be updated replies a SOF of the file write request to the DWU;

[0025] Step S303: After receiving the SOF, the DWU sends the unpacked update file data packet to the board to be updated.

[0026] As an optimal technical solution, when DWU receives the termination packet IOF sent by the board to be updated, DWU stops sending the current update file data packet; when DWU receives the resume packet COF sent by the board to be updated, DWU continues to send the update file data packet according to the packet sequence of the resume packet.

[0027] As a preferred technical solution, after the DWU finishes sending the data packet of the current update file, it sends the end packet EOF of the update file. After the update board receives the EOF, it packages the currently received data and calculates the file check code, and then packages the check code and board file information into a file download completion message DL and sends it to the DWU;

[0028] After receiving the file download completion message DL for all boards to be updated, the DWU enters step S4;

[0029] If not, check whether there is a file that has not received the correct DL message for more than X times. If not, resend the file write request. If so, exit the update.

[0030] As a preferred technical solution, the step S4, the update result output process specifically includes:

[0031] Step S401: After receiving the file download completion information from all boards to be updated, the DWU performs a byte XOR operation on the checksum of each file to be updated on each board to be updated and the checksum in the update configuration file. If they are consistent, the DWU outputs the update result as 0x5A; if they are inconsistent, the DWU outputs the result as all 0s.

[0032] Step S402 , performing an AND operation on the update result of each file to be updated of each board to be updated, and outputting the final update result.

[0033] According to a second aspect of the present invention, an electronic device is provided, comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the method when executing the program.

[0034] According to a third aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method described above is implemented.

[0035] Compared with the prior art, the present invention has the following advantages:

[0036] 1) Without affecting the original vehicle safety computer functions, the present invention utilizes the maintenance module DWU of the original vehicle safety computer platform and the BMC of each service board to update the image file or configuration file of the entire vehicle system through an external update device, thereby enhancing the maintainability of the vehicle system;

[0037] 2) The present invention achieves the coexistence of two different communication media in serial and parallel mode under asymmetric bandwidth, greatly improving the efficiency of simultaneous file updates for multiple cages and multiple boards on-board the vehicle.

[0038] 3) The present invention can not only solve the problem that the on-board train control system can only be manually burned by single-board operation during on-site burning, but also realize the updating of configuration or image files during train operation, providing an effective reference for the functional optimization design of on-board systems of trains running across lines with different standards of train control systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 This is a schematic diagram of the structure of the vehicle-mounted safety platform system of the present invention.

[0040] Figure 2 The figure is a schematic diagram of the communication structure between the BMC and DWU of each board on each cage of the vehicle-mounted safety platform of the present invention.

[0041] Figure 3 This is a schematic diagram of the automatic update process of the present invention.

[0042] Figure 4 This is a schematic diagram of the BmcInfo structure for network communication between DWU and SWB and the CanInfo structure for communication between SWB and other BMCs in the present invention.

[0043] Figure 5 This is a schematic diagram of the format of the update file data packet unpacking, packing and sending according to the present invention.

[0044] Figure 6 This is a schematic diagram of multi-task and multi-board processing when the SWB sends a file write request according to the present invention.

[0045] Figure 7 This is a specific flow chart of multi-task and multi-board processing when the SWB sends a file write request according to the present invention. DETAILED DESCRIPTION

[0046] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0047] The present invention provides an automatic updating method for an on-board computer security platform, which updates the configuration files and mirror files of each business board of the on-board computer security platform through a data maintenance unit DWU and a USB flash drive of the on-board computer security platform, and can read the update result files of each board to be updated from the USB flash drive for reconfirmation, thereby ensuring the security and correctness of the update files of each board.

[0048] like Figure 1 Figure 1 shows the schematic diagram of the vehicle-mounted safety platform system structure of the present invention. The DWU is a data logging and maintenance module with USB read / write capabilities; the MPB is a logic processing board, the GWB is a communication board, the VOB is a safety output board, the VIB is a safety acquisition board, the AIOB is an analog input / output board, and the VVB is a sensor acquisition unit. The SWB is a switch board that communicates with the DWU and other SWB boards over the network, as well as with the BMCs (Baseboard Management Controllers) of other boards in the cage via the CAN bus.

[0049] like Figure 2 Figure 1 shows the communication structure between the BMCs and DWUs of each board in each cage of the vehicle-mounted safety platform of the present invention. Each SWB's BMC has a unique IP address for communicating with the DWU, and each SWB has two CAN channels for communicating with the BMCs of each board in the cage.

[0050] like Figure 3 As shown, the specific implementation steps of the present invention are as follows.

[0051] Step 1, update file checking process:

[0052] 1.1) During the initialization phase, DWU detects the presence of a USB drive and an update configuration file and enters update mode.

[0053] 1.2) The DWU reads the update configuration file from the USB drive and obtains the number of update board types, the board type corresponding to each update board, the number of flash memory types to be updated, the file name to be updated and the file's checksum, as well as the number of boards to be updated for each update board type and the board cage slot number. The board cage slot number is determined by the board's location and is unique to each board.

[0054] 1.3) DWU reads each file to be updated from the USB drive and calculates the checksum of the file.

[0055] 1.4) DWU compares the calculated checksum of each file to be updated with the checksum of the corresponding file in the update configuration file. If they are consistent, it goes to step 2; if they are inconsistent, it exits the update.

[0056] Step 2, update the board confirmation process:

[0057] 2.1) DWU sends card scan information to all CAN channels of all SWB cards, once every 30 seconds, for a total of 3 times.

[0058] 2.2) After sending the scanned card information, the DWU receives the card scan information replied by the updated card from the SWB card. Set the following priorities for the CAN channels of the SWB cards in each cage: Assume that SWB1 in each cage is the SWB card with the smaller slot number, and SWB2 is the SWB card with the larger slot number. Then the CAN0 channel priority of SWB1 is 1 (0x1), the CAN0 channel priority of SWB2 is 2 (0x1<<1), the CAN1 channel priority of SWB2 is 4 (0x1<<2), and the CAN1 channel priority of SWB1 is 8 (0x1<<3). Figure 6 and Figure 7 As shown. The DWU compares the SWB board and CAN channel priority used in the scan information replied by each board to be updated, and then records the UsedLink value of each board to be updated. If all boards to be updated in the update configuration file have replied to the board scan information, proceed to step 3.

[0059] 2.3) If the card scan information of all the cards to be updated in the update configuration file is not received within the timeout period, the update is exited.

[0060] Step 3, update file transfer process:

[0061] Due to processor performance limitations, the DWU can handle up to six session tasks simultaneously, and the BMC of each service card can only handle one session at a time.

[0062] 3.1) DWU sends an update write request:

[0063] 3.1.a) Finding Idle Session Tasks and Update Files to be Sent: Traverse all session task index values. If the session task corresponding to the current session task index value is idle and the current update file to be sent has not been successfully updated, then record the session task index value in the session task index value used by the current update file.

[0064] 3.1.b) Find the available communication link for the current session: Traverse the UsedLink values ​​of all boards to be updated under the update board type where the current file to be updated is located, find a CAN channel that can be used by all boards to be updated under the current update board type, and record it as the available communication link for the current session.

[0065] 3.1.c) The file size, board type, session number, and communication link to be updated are packaged into a BmcInfo structure and sent to the corresponding SWB board. The link value and session number are filled in according to the following rules: If the link value is 1, the write request is sent to the CAN0 channel of the SWB1 board; if the link value is 2, the write request is sent to the CAN0 channel of the SWB2 board, and the session number is increased by 8; if the link value is 4, the write request is sent to the CAN1 channel of the SWB2 board, and the session number is increased by 8; if the link value is 8, the write request is sent to the CAN1 channel of the SWB1 board, as shown in the following example: Figure 4 shown.

[0066] 3.1.d) If no idle session task or available communication link is found, continue waiting without sending a write request.

[0067] 3.2) After receiving the write request, the board to be updated sends the board slot number and board type to the SWB board via a SOF message, packaged in the CanInfo structure. The DWU receives the SOF information forwarded by each SWB board and records the board type and board slot number in the SOF message according to the session number.

[0068] 3.3) If all the cards of the same card type as the one to be updated in the current session task have responded to the SOF, the update file data packet is broadcast to all the cards to be updated. Otherwise, after waiting for 20 update cycles, the file write request for the session is sent again.

[0069] 3.4) Package the files to be updated according to the following rules:

[0070] 3.4.a) Calculate the size of the file to be updated and the package number (PackageNumber) after unpacking it into 1024-byte packets.

[0071] 3.4.b) Allocate a BmcDatabuffer for the current file to the current session, with a size no less than PackageNumber*1024+7 bytes.

[0072] 3.4.c) Place the first 1018 bytes of the file to be updated, the checksum of the updated file, and the packet number 1 into the first 1056 bytes of memory in BmcDatabuffer. The 1024 bytes are unpacked in 64-byte increments. The CanId value of each CanData packet starts at 1 and increases by 16 for each additional CanData packet. If the number is less than 1024 bytes, fill it with 0s. For an unpacking example, see Figure 5 .

[0073] 3.5) Update file data packets are sent according to the following rules:

[0074] 3.5.a) The current session task of the DWU broadcasts the file data packet to the board to be updated according to the packet sequence number;

[0075] 3.5.b) After receiving the file data packet, the board to be updated temporarily stores the data packet in a temporary storage area. The data packets in the temporary storage area are then grouped according to the CanId and stored in the local memory area. If the file data packet received in the temporary storage area reaches the upper threshold (which can be set by the business board BMC by default or configured in the update configuration file and sent to the business board BMC via a write request), an abort packet (IOF) for the current session is sent. If the DWU receives an abort packet (IOF) for the current session task, it stops sending data packets.

[0076] 3.5.c) If the number of packets in the temporary storage area of ​​the current card to be updated reaches the lower threshold (this can be set by the business card BMC by default or configured in the update configuration file and sent to the business card BMC via a write request), a resume packet (COF) for the current session is sent. If the DWU receives a resume packet (COF) for the current session task, it will continue sending packets according to the packet sequence in the resume packet.

[0077] 3.5.d) When all update file data packets have been sent, the DWU sends an End of Session (EOF) packet to the card to be updated. Upon receiving the EOF packet, the card to be updated calculates a checksum value based on the update file data for the current update session stored in its local memory. This checksum value, along with the card type, card slot number, and session number, forms a file download completion message (DL) and sends it to the SWB.

[0078] 3.5.e) The DWU receives the download completion message (DL) of the current session file sent by the board to be updated, forwarded by the SWB. It records the XOR value of the file checksum in the DL message and 0x5A, as well as the slot number and board type.

[0079] 3.6) If the DWU has received the download completion message (DL) for all files to be updated for all boards to be updated in the update configuration file, it proceeds to step 4. Otherwise, it checks whether there are any files to be updated that have not received the DL message for more than three times. If not, it returns to step 3.1) and resends the file write request. If so, it exits the update.

[0080] Step 4: Update the result output process:

[0081] 4.1) After receiving the file download completion message from all cards to be updated, the DWU performs an XOR operation on the locally recorded checksum value in the DL file of each card to be updated with the checksum value of the corresponding file in the update configuration file. The XOR result of each file to be updated is output in the order of card type and cage slot number. If the results match, the update result is output as 0x5A; if they do not match, the result is output as 0.

[0082] 4.2) DWU performs an AND operation on the update results of each file to be updated on each board to be updated, and outputs the final update result in the first line of the update result output file. If all files to be updated on all boards to be updated are updated successfully, the result is 0x5A, otherwise it is all 0s.

[0083] The above is an introduction to a method embodiment. The following further illustrates the solution of the present invention through an electronic device and a storage medium embodiment.

[0084] An embodiment of the present invention further provides an electronic device including a central processing unit (CPU), which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) or computer program instructions loaded from a storage unit into a random access memory (RAM). In the RAM, various programs and data required for device operation can also be stored. The CPU, ROM, and RAM are connected to each other via a bus. An input / output (I / O) interface is also connected to the bus.

[0085] Many components in a device are connected to the I / O interface, including: input units, such as a keyboard and mouse; output units, such as various types of displays and speakers; storage units, such as magnetic disks and optical disks; and communication units, such as network cards, modems, and wireless communication transceivers. The communication unit allows the device to exchange information / data with other devices via computer networks such as the Internet and / or various telecommunication networks.

[0086] The processing unit performs the various methods and processes described above, such as the inventive method. For example, in some embodiments, the inventive method can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program can be loaded and / or installed on the device via a ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of the inventive method described above can be performed. Alternatively, in other embodiments, the CPU can be configured to perform the inventive method by any other appropriate means (e.g., by means of firmware).

[0087] The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0088] The program code for implementing the method of the present invention can be written in any combination of one or more programming languages. Such program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0089] In the context of the present invention, machine-readable medium can be a tangible medium that can contain or store a program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0090] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A method for automatically updating a vehicle-mounted computer security platform, characterized in that: The method updates the configuration files and image files of each business board of the vehicle-mounted computer security platform through the data maintenance unit DWU and USB flash drive of the vehicle-mounted computer security platform, and reads the update result files of each board to be updated from the USB flash drive for reconfirmation.

2. The method for automatically updating a vehicle-mounted computer security platform according to claim 1, characterized in that: The method specifically comprises the following steps: Step S1, update file checking process; Step S2, updating the board confirmation process; Step S3, update file transfer process; Step S4, update result output process.

3. The method for automatically updating a vehicle-mounted computer security platform according to claim 2, characterized in that: The update file checking process in step S1 specifically includes: Step S101: If the DWU detects the presence of a USB flash drive and an update configuration file during the initialization phase, it enters the update mode and executes step S102; otherwise, it exits the update mode. Step S102: The DWU reads the update configuration file in the USB flash drive and checks the correctness of the image file or configuration file to be updated in the USB flash drive according to the update file verification code of each board to be updated in the update configuration file. Step S103: If the updated configuration files are consistent, the update board confirmation process is entered; otherwise, the update is exited.

4. The method for automatically updating a vehicle-mounted computer security platform according to claim 3, characterized in that: The configuration file updated in step S102 includes the number of updated board types, the board type corresponding to each updated board, the number of flash types to be updated, the file name to be updated and the checksum of the file, and the number of boards to be updated under each updated board type and the board cage slot number.

5. The method for automatically updating a vehicle-mounted computer security platform according to claim 2, characterized in that: The step S2, updating the board confirmation process specifically includes: Step S201: DWU sends card scanning information to all CAN channels of the SWB card; Step S202: After sending the scanned card information, the DWU receives the card scan information replied by the card to be updated from the SWB card. Step S203: If all the boards to be updated in the configuration file have replied to the board scan information within the set time, step S3 is executed; otherwise, the update is exited.

6. The method for automatically updating a vehicle-mounted computer security platform according to claim 5, characterized in that: In step S201, the message is sent every N seconds, and is sent M times in total.

7. The method for automatically updating a vehicle-mounted computer security platform according to claim 2, characterized in that: The step S3, updating the file transmission process specifically includes: Step S301: The DWU sends a write request WQ for a file to be updated to the board to be updated. Step S302: After receiving the file write request, the board to be updated replies a SOF of the file write request to the DWU; Step S303: After receiving the SOF, the DWU sends the unpacked update file data packet to the board to be updated.

8. The method for automatically updating a vehicle-mounted computer security platform according to claim 7, characterized in that: When DWU receives the termination packet IOF sent by the board to be updated, DWU stops sending the current update file data packet; when DWU receives the resume packet COF sent by the board to be updated, DWU continues to send the update file data packet according to the packet sequence of the resume packet.

9. The method for automatically updating a vehicle-mounted computer security platform according to claim 7, characterized in that: When DWU finishes sending the data packet of the current update file, it sends the end packet EOF of the update file. After the update board receives EOF, it packages the currently received data and calculates the file check code. It then packages the check code and board file information into a file download completion message DL and sends it to DWU. After receiving the file download completion message DL for all boards to be updated, the DWU enters step S4; If not, check whether there is a file that has not received the correct DL message for more than X times. If not, resend the file write request. If so, exit the update.

10. The method for automatically updating a vehicle-mounted computer security platform according to claim 2, characterized in that: The step S4, the update result output process specifically includes: Step S401: After receiving the file download completion information from all boards to be updated, the DWU performs a byte XOR operation on the checksum of each file to be updated on each board to be updated and the checksum in the update configuration file. If they are consistent, the DWU outputs the update result as 0x5A; if they are inconsistent, the DWU outputs the result as all 0s. Step S402 , performing an AND operation on the update result of each file to be updated of each board to be updated, and outputting the final update result.

11. An electronic device comprising a memory and a processor, wherein a computer program is stored in the memory, wherein: When the processor executes the program, the method according to any one of claims 1 to 10 is implemented.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images