Platform door control unit application upgrade system, method, equipment and media

By using network communication between PMH and PMM and redundant communication via CAN bus, combined with the application area and boot area settings of Flash memory, the application program of the platform door control unit is upgraded efficiently and reliably. This solves the problem of low efficiency in traditional upgrade methods, reduces maintenance costs, and ensures system stability.

CN122173118APending Publication Date: 2026-06-09CASCO SIGNAL LTD
View PDF 1 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
CASCO SIGNAL LTD
Filing Date
2026-01-29
Publication Date
2026-06-09

AI Technical Summary

Technical Problem

In the existing technology, upgrading the application of the platform door control unit requires a lot of manpower and time, and the traditional upgrade method is inefficient and cannot meet the high-efficiency and convenient needs of large stations.

Method used

The device status monitoring and management unit (PMH) and the maintenance diagnostic terminal (PMM) communicate via a network, using a CAN bus to achieve redundant communication. New applications are sent in segments, and the locations of the application area and boot area are set in the Flash memory, which increases the reliability and efficiency of the upgrade. Verification and upgrade failures are handled through a forgiveness operation.

Benefits of technology

It improves the stability and efficiency of platform door control unit application upgrades, reduces operation and maintenance costs, simplifies the maintenance process, ensures normal operation even in the event of upgrade failure, and reduces the need for manpower.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122173118A_ABST
    Figure CN122173118A_ABST
Patent Text Reader

Abstract

This invention relates to a platform door gate control unit application upgrade system, method, device, and medium. The system includes: a gate control unit (KDCU) for receiving a new program and upgrading the application; an equipment status monitoring and management unit (PMH) connected to the KDCU via a CAN bus and interacting with it during the upgrade process; and a maintenance and diagnostic terminal (PMM) connected to the PMH via network communication and used to initiate KDCU program upgrade commands. After receiving the upgrade command through the PMH, the KDCU's execution pointer jumps from the application area to the boot area, waiting to receive the new application. The application area is the KDCU application execution area, and the boot area is the KDCU upgrade software execution area. In terms of storage location, the application area is placed before the boot area, i.e., the application area starts at a low address, and the boot area starts at a high address. Compared with existing technologies, this invention has advantages such as improved stability and efficiency.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to rail transit signaling systems, and more particularly to a platform door control unit application upgrade system, method, device, and medium. Background Technology

[0002] With the development of rail transit technology, platform screen door systems are widely used in subway and high-speed rail stations, ensuring efficient train operation and passenger safety. Platform screen door systems can be divided into full-height platform screen doors and half-height safety doors. The door control unit for full-height platform screen doors is a one-control, one-drive door control unit (KDCU-S), installed in the top box of the door body; the door control unit for half-height safety doors is a one-control, two-drive door control unit (KDCU-D), installed in the side box of the door body. The door control unit is an important component of the platform screen door control system, mainly with the following functions: It can receive PSC-CD and LCB control commands, control the electromagnetic lock, drive the motor to rotate, drive the belt to control the door movement, and complete the sliding door opening and closing action. It can detect and collect the status of motor voltage and current, limit switches, and other equipment in real time, and automatically stop the motor in case of serious faults. It can upload its own status and alarm information to the host computer via the CAN bus; at the same time, the host computer can query and modify configuration parameters and read door opening and closing data. It can drive audible and visual alarms according to specific scenarios, such as flashing door lights and sounding buzzers, to alert passengers and platform staff.

[0003] Each existing platform has one door control unit for each pair of sliding doors, including both up and down platforms, with dozens of door control units per station. As the platform screen door system operates for extended periods, when problems arise with the door control units or when additional functions are needed, the door control unit application must be upgraded. Traditional upgrade methods require staff to operate each door control unit on-site, which is extremely time-consuming and labor-intensive for large stations with numerous units.

[0004] A search of Chinese Patent Publication No. CN103347048A reveals an automatic upgrade method for an urban rail transit signaling system, comprising the following steps: 1) Initialization; 2) The DSU and the signaling system terminal equipment to be upgraded synchronize their clocks via a clock unit; 3) The DSU determines whether the signaling system terminal equipment is in a maintainable state; 4) The DSU executes the upgrade command; 5) The DSU requests the version of existing application software or data from the signaling system terminal equipment; 6) The DSU compares the version of existing application software or data with the upgrade information uploaded by the user; 7) The signaling system terminal equipment starts the download program; 8) Determine if the upgrade is successful; 9) The signaling system terminal equipment updates the version number in its local configuration file and then executes step 6) again; 10) After the DSU locates and troubleshoots the upgrade failure information reported by the equipment, it sends the upgrade command again. This existing patent saves a significant amount of personnel and workload, but it does not address platform door control units.

[0005] Therefore, developing an efficient, convenient, and reliable platform door control unit application upgrade technology is of great practical significance. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art and provide a platform door control unit application upgrade system, method, device and medium that improves stability and efficiency.

[0007] The objective of this invention can be achieved through the following technical solutions: According to a first aspect of the present invention, a platform door control unit application upgrade system is provided, the system comprising: The gate control unit (KDCU) is used to upgrade the application after receiving new programs. The Equipment Status Monitoring and Management Unit (PMH) is connected to the Gating Unit (KDCU) via a CAN bus and interacts with it during the upgrade process. The maintenance diagnostic terminal (PMM) is connected to the equipment status monitoring and management unit (PMH) via network communication and is used to initiate the KDCU program upgrade command. After receiving the upgrade command through the PMH, the KDCU gating unit jumps its running pointer from the application area to the boot area, waiting to receive the new application. The application area is the application running area of ​​the KDCU gating unit, and the boot area is the upgrade software running area of ​​the KDCU gating unit. In terms of storage location, the application area is placed before the boot area, that is, the starting address of the application area is a low address, and the starting address of the boot area is a high address.

[0008] As a preferred technical solution, the gate control unit KDCU includes a Flash memory, the application area and the boot area are located in the Flash memory, the starting address of the application area is 0x08000000, and the starting address of the boot area is 0x08040000.

[0009] As a preferred technical solution, the Flash memory further includes backup area 1 and backup area 2, wherein the starting address of backup area 1 is 0x08080000 and the starting address of backup area 2 is 0x080C0000.

[0010] As a preferred technical solution, the maintenance and diagnostic terminal PMM obtains the binary Bin file of the new KDCU application to be updated from the local industrial control computer. After receiving the user's update instruction, it sends the Bin file to the PMH through the agreed protocol, and the PMH then sends an upgrade command to the KDCU.

[0011] As a preferred technical solution, the PMH sends the new application in segments along with CAN messages to the KDCU. Each CAN message contains 8 bytes of new application information and is sent to the KDCU via CAN communication. After the program information is sent, a CRC check frame of the new application is sent.

[0012] As a preferred technical solution, after receiving several CAN messages containing new application information, the KDCU writes the 8 bytes of the data field into the backup area 1 in sequence. After receiving the CRC check frame, it calculates the CRC of the data in the backup area 1 and compares whether the two are equal. If the two are equal, the data transmission verification passes; if the two are not equal, the verification fails and subsequent forgiveness operations are performed. If the data transmission verification passes, the KDCU writes the original program from the application area to backup area 2, then erases the application area, writes the new program from backup area 1 that has passed the verification to the application area, and performs CRC verification again. If the verification passes, the upgrade is successful, and the running pointer jumps to the application area to run the new gating unit application. If the upgrade fails, subsequent forgiveness operations are performed.

[0013] As a preferred technical solution, if the KDCU verification fails no more than twice, the PMH will resend the program frame and verification frame; if the KDCU upgrade fails no more than twice, the PMH will resend the program frame and verification frame.

[0014] As a preferred technical solution, if the KDCU verification fails more than twice, the running pointer jumps to the application area and runs the original program; if the KDCU upgrade fails more than twice, the KDCU writes the original program from backup area 2 into the application area, the running pointer jumps to the application area, and runs the original program.

[0015] As a preferred technical solution, the CAN message format for communication between the PMH and KDCU includes 29-bit frame header information and 64-bit data field; In the frame header, bit 28 is the communication direction identifier, where 1 indicates a message sent from PMH to KDCU, and 0 indicates a message sent from KDCU to PMH; bits 27-22 are the KDCU address; bits 21-14 are the message type, where 0xE0 is the upgrade start frame, 0xE1 is the upgrade procedure frame, 0xE2 is the verification frame, and 0xE5 is the KDCU reply frame; bits 13-0 are the data field checksum, calculated as the remainder of the sum of the 8 bytes of the data field divided by 256. When the message type is 0xE1, bits 13-0 represent the frame sequence number. The data field is filled with different content according to different message types. When the message type is 0xE0, the data field is the number of bytes L of the new upgrade program; when the message type is 0xE1, the data field is the data packet of the new program; when the message type is 0xE2, the data field is the CRC check value of the new program; when the message type is 0xE5, the data field is the KDCU status reply, 0x1 indicates that the upgrade start frame has been received and the upgrade is pending, 0x2 indicates that the CRC check was successful, 0x3 indicates that the CRC check failed, 0x4 indicates that the CRC upgrade was successful, and 0x5 indicates that the CRC upgrade failed.

[0016] According to a second aspect of the present invention, an upgrade method for an application upgrade system using the aforementioned platform door control unit is provided, the method comprising the following steps: Step S1: After receiving the user's update instruction, PMM sends an upgrade command to PMH and simultaneously distributes the KDCU-APP.bin file of the new KDCU application to PMH through the agreed protocol. In step S2, the PMH forwards the upgrade command to the KDCU and simultaneously processes and sends the KDCU-APP.bin file of the new application to the KDCU. Step S3: KDCU undergoes an upgrade process.

[0017] As a preferred technical solution, step S2 specifically includes the following steps: Step S2.1: PMH stores KDCU-APP.bin in memory and calculates the new program length L and checksum CRC_1. If the number of bytes in the new program is not a multiple of 8 bytes, it is padded with 0s at the end of the new program. Step S2.2, PMH sends an upgrade command 0xE0 to KDCU1 with the data field set to L, and waits for a response from KDCU1; In step S2.3, if KDCU1 replies with a confirmation message in step S2.2, PMH sends several frame upgrade program packets to KDCU1. The message type is 0xE1, and the message contains a frame sequence number that increments from 0. The data field contains 8 bytes of new program content. KDCU1 does not need to reply with this message until the new program is sent. Step S2.4: After the program upgrade frame is sent, PMH continues to send a CRC check frame to KDCU1. The message type is 0xE2 and the data field is the CRC check value. Then, it waits for KDCU1 to reply.

[0018] As a preferred technical solution, step S3 specifically includes the following steps: In step S3.1, when KDCU1 receives the PMH upgrade message 0xE0, the running pointer jumps from the application area to the boot area and replies with an acknowledgment message 0xE5, with the data field being 0x01. In step S3.2, the Boot area program of KDCU1 receives several frame upgrade program packets sent by PMH and writes them sequentially to Flash backup area 1 according to the frame sequence number. When two frames with the same sequence number appear, the data of the later frame is overwritten and written to backup area 1. If a certain frame sequence number is not received, the backup area will lack 8 bytes of content of that frame message and will fail the subsequent CRC check. In step S3.3, KDCU1 receives the PMH verification message 0xE2, with the data field being the verification value CRC_1. KDCU1 calculates the CRC_2 value of the L-byte program in backup area 1 and compares it with CRC_1. If they are equal, it replies with a 0xE5 message, with the data field being 0x02; if they are not equal, it replies with a 0xE5 message, with the data field being 0x03. If the CRC verification fails and the number of failures does not exceed 2, it will re-enter steps S2.3, S3.2, S2.4, and S3.3. Step S3.4: After successful CRC verification, the original program in the application area is written to backup area 2, the application area is erased, and then the new program in backup area 1 is written to the application area. If the writing process is error-free, the new program in the application area is verified again. If the verification passes, KDCU1 replies with a 0xE5 message and the data field is 0x04. If the writing process fails or the verification of the new program in the application area fails, KDCU1 replies with a 0xE5 message and the data field is 0x05. If the writing fails and the number of failures does not exceed 2, the process will proceed to steps S2.3, S3.2, S2.4, and S3.3 again. Step S3.5: After the application area program is updated, the program pointer jumps from the Boot area to the application area and runs the new KDCU-APP program; PMH continues to upgrade the application for KDCU2, and upgrades all KDCUs in sequence; Step S3.6: After a CRC check fails, the application area is not erased. If the number of failed checks exceeds 2, the program pointer jumps from the Boot area to the application area and runs the original APP program. Step S3.7: If the new program fails to be written to the application area in step S3.4 and the number of failures exceeds 2, the original program in backup area 2 is written to the application area, the program pointer jumps from the Boot area to the application area, and the original APP program is run.

[0019] According to a third aspect of the present invention, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described thereon.

[0020] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described thereon.

[0021] Compared with the prior art, the present invention has the following advantages: 1) Improved stability: Traditional microcontroller upgrade solutions typically place the Boot area before the application area, i.e., the Boot area starts at address 0x08000000. When the program restarts after a power outage, it first enters the Boot area and then determines whether to enter the application area based on conditions in the Boot program. In contrast, this invention places the application area before the Boot area, i.e., the application area starts at address 0x08000000. When the program restarts after a power outage, it directly starts running from address 0x08000000, without needing to enter the Boot area for judgment. This avoids the problem of being unable to jump to the application area due to unmet conditions in the Boot program. Furthermore, this invention uses CAN redundant communication to improve reliability.

[0022] 2) Improved efficiency: The Boot area is set before the application area. After upgrading the application area program, it is often necessary to restart the program, run the Boot program first, and then jump to the application area to run. If the Boot area program logic is complex, it will take a long time. However, after the application area program is upgraded or restarted after a power outage, the program starts running directly from the application area, which can improve efficiency.

[0023] 3) Improved availability: This invention has a forgiveness operation for verification failures and upgrade failures during the upgrade process. After CRC verification or upgrade failure, PMH can send upgrade frames and verification frames again. After successful verification in the backup area, data verification is performed again when the new program is written to the application area. If the program still fails to upgrade after the forgiveness operation, the application area will run the original program without affecting the original functions.

[0024] 4) Reduced operation and maintenance costs: This invention can quickly upgrade the application of the gate control unit of the entire station through PMM-PMH-KDCU, and can record whether the upgrade of each gate control unit is successful, without the need for additional upgrade equipment, thereby reducing the number of maintenance personnel per station.

[0025] 5) Easy maintenance: Users can perform upgrade operations on the gate control unit through the PMM interface. The upgrade process is displayed with dynamic icons, and the success or failure of the upgrade is displayed on the interface. The operation indicators, process and results are clearly prompted, making maintenance easier. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the structure of the upgrade system of the present invention; Figure 2 This is a schematic diagram of the Flash partitioning of the KDCU microcontroller of the present invention.

[0027] Figure 3 This is a flowchart illustrating the upgrade method of the present invention. Detailed Implementation

[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] Example 1 like Figure 1 As shown, the present invention provides a platform door control unit application upgrade system, the system comprising: The gate control unit (KDCU) is used to upgrade the application after receiving new programs. The Equipment Status Monitoring and Management Unit (PMH) is connected to the Gating Unit (KDCU) via a CAN bus and interacts with it during upgrade processes. The maintenance diagnostic terminal (PMM) is connected to the equipment status monitoring and management unit (PMH) via network communication and is used to initiate the KDCU program upgrade command. After receiving the upgrade command through the PMH, the KDCU gating unit jumps its running pointer from the application area to the boot area, waiting to receive the new application. The application area is the application running area of ​​the KDCU gating unit, and the boot area is the upgrade software running area of ​​the KDCU gating unit. In terms of storage location, the application area is placed before the boot area, that is, the starting address of the application area is a low address, and the starting address of the boot area is a high address.

[0030] In this invention, the application area is placed before the boot area, with the application area starting at address 0x08000000. When the program is powered off and restarted, it starts running directly from 0x08000000 without needing to enter the boot area for judgment. This avoids the problem of being unable to jump to the application area program due to conditions not being met in the boot program.

[0031] The PMM and PMH employ redundant network communication. The PMH is primarily responsible for monitoring and managing the status of each device, enabling insecure communication with other systems via network, CAN port, and serial port, and connecting to other devices via hardwired connections for insecure data acquisition, etc. The PMM is responsible for the maintenance and diagnostics of the platform screen door control system, enabling maintenance communication with other systems via network, and serves as a user-facing maintenance and diagnostic terminal.

[0032] The PMH and KDCU are connected via redundant CAN connections, with each KDCU connected to both CAN_A and CAN_B. The PMH sends the same messages to the KDCUs via CAN_A and CAN_B. The KDCUs transmit the same status and alarm information back to the PMH via CAN_A and CAN_B. After successfully upgrading KDCU1, the PMH continues upgrading KDCU2 until all KDCUs have been upgraded.

[0033] The PMH and each KDCU are connected to a redundant CAN bus. The CAN bus uses twisted-pair shielded cable for connection, with a communication rate set to 125Kbps to ensure stable and reliable data transmission in the subway environment. The PMH mainly connects the operation and maintenance system, vehicle system, platform screen door control unit, etc., and is responsible for message transmission between various systems and equipment.

[0034] The KDCU and PMH boards are based on microcontrollers for control and communication. Microcontrollers are commonly used in embedded systems, integrating functions such as CPU, memory (RAM and ROM), timers, and input / output ports onto a single chip, thereby reducing the need for external components. The KDCU uses an STM32F429ZG microcontroller processor, while the PMH uses an AT43F403ARCT7 microcontroller processor.

[0035] The upgrade system in this invention relates to embedded systems. There are three main methods for upgrading embedded system applications: ICP (In-Circuit Programming), ISP (In-System Programming), and IAP (In-Application Programming). ICP and ISP have low universality and high hardware dependency. Therefore, IAP upgrades are more commonly used in many fields such as industrial control and automotive applications. IAP refers to the system's ability to obtain the latest software through peripheral interfaces within the application and upgrade the application. The specific implementation details and communication protocols of the IAP method vary across different systems; therefore, this invention is original.

[0036] The KDCU, based on the STM32F429ZG, divides the Flash memory into a Boot area, an Application area, and a Backup area. Specifically, the Application area starts at address 0x08000000, the Boot area starts at address 0x08040000, Backup Area 1 starts at address 0x08080000, and Backup Area 2 starts at address 0x080C0000. The gate unit application program (KDCU-APP) runs in the Application area, while the upgrade software (KDCU-BOOT) runs in the Boot area.

[0037] The CAN message format for communication between the PMH and KDCU includes a 29-bit frame header and a 64-bit data field. In the frame header, bit 28 is the communication direction identifier: 1 indicates a message sent from the PMH to the KDCU, and 0 indicates a message sent from the KDCU to the PMH. Bits 27-22 are the KDCU address (identified by hardware DIP switches, with addresses 1-62). Bits 21-14 are the message type: 0xE0 for upgrade start frame, 0xE1 for upgrade procedure frame, 0xE2 for check frame, and 0xE5 for KDCU reply frame. Bits 13-0 are the data field checksum, calculated as the remainder of the sum of the 8 data bytes divided by 256. When the message type is 0xE1, bits 13-0 represent the frame sequence number.

[0038] The data field is filled with different content depending on the message type. When the message type is 0xE0, the data field contains the number of bytes L of the new upgrade program. When the message type is 0xE1, the data field contains the data packets of the new program. When the message type is 0xE2, the data field contains the CRC checksum of the new program. When the message type is 0xE5, the data field contains the KDCU status response: 0x1 indicates confirmation of receiving the upgrade start frame and waiting for the upgrade; 0x2 indicates successful CRC checksum; 0x3 indicates failed CRC checksum; 0x4 indicates successful CRC upgrade; 0x5 indicates failed CRC upgrade. The system referred to in this invention is not a complete platform screen door system. It refers to the equipment involved in the upgrade process of the door control unit program as the upgrade system, and the implementation method focuses on describing the upgrade process.

[0039] like Figure 2 The image shows the Flash partition of the KDCU. The gate control unit application area starts at address 0x08000000 and runs the gate control unit application program (KDCU-APP). After the KDCU is powered off and restarted, the program starts running from address 0x08000000. Its main functions include receiving PSC-CD and LCB control commands, controlling the electromagnetic lock, driving the motor to rotate, and completing the sliding door opening and closing action; real-time detection and acquisition of equipment status such as motor voltage and current, and limit switch status, and automatically stopping the motor in case of a serious fault; uploading its own status and alarm information to the host computer, and allowing users to query and modify parameters through the host computer; and providing audible and visual alarms for abnormal scenarios. The Boot area starts at address 0x08040000 and runs the upgrade software (KDCU-BOOT), responsible for communicating with the PMH during the upgrade process and updating or restoring the application program in the application area based on the results. Backup area 1 starts at address 0x08080000 and is used to store the new application program to be upgraded. Backup area 2 starts at address 0x080C0000 and is used to store the original application.

[0040] Example 2 like Figure 3 The diagram shows the specific process for upgrading the gate control unit of the PMM-PMH-KDCU system.

[0041] Step S1 is the specific operation of PMM, which includes the following execution steps: Step S1.1: The user clicks the "Upgrade KDCU" control on the PMM interface.

[0042] In step S1.2, PMM sends the new KDCU-APP.bin to PMH via the agreed protocol.

[0043] Step S2 is the specific operation of PMH, which includes the following execution steps: In step S2.1, PMH stores KDCU-APP.bin in memory and calculates the new program length L (bytes) and checksum CRC_1. If the number of bytes in the new program is not a multiple of 8 bytes, zeros are added to the end of the new program.

[0044] Step S2.2, PMH sends an upgrade command 0xE0 with the data field L to KDCU1 (KDCU address is identified as 1 via hardware DIP switch), and waits for KDCU1 to reply.

[0045] In step S2.3, if KDCU1 replies with an acknowledgment message in step S2.2, PMH sends several upgrade program packets to KDCU1. The message type is 0xE1, and the message contains a frame sequence number, incrementing from 0. The data field contains 8 bytes of new program content. KDCU1 does not need to reply to this message until the new program is sent.

[0046] Step S2.4: After the program upgrade frame is sent, PMH continues to send a CRC check frame to KDCU1. The message type is 0xE2 and the data field is the CRC check value. Then, it waits for KDCU1 to reply.

[0047] Step S3 is the specific operation of KDCU, which includes the following execution steps: In step S3.1, when KDCU1 receives the PMH upgrade message 0xE0, the running pointer jumps from the application area to the boot area and replies with an acknowledgment message 0xE5, with the data field being 0x01.

[0048] In step S3.2, the Boot area program of KDCU1 receives several upgrade program packets sent by PMH and writes them sequentially to Flash backup area 1 according to the frame sequence number (starting from 0). When two frames have the same sequence number, the data of the later frame is overwritten into backup area 1. If a frame sequence number is not received, the backup area will lack 8 bytes of that frame message content and will fail subsequent CRC checks.

[0049] In step S3.3, KDCU1 receives the PMH check message 0xE2, with the data field being the check value CRC_1. KDCU1 calculates the CRC_2 value of the L-byte program in backup area 1 and compares it with CRC_1. If they are equal, it replies with a 0xE5 message, with the data field being 0x02; if they are not equal, it replies with a 0xE5 message, with the data field being 0x03. If the CRC check fails, and the number of failures does not exceed two, it will re-enter steps S2.3, S3.2, S2.4, and S3.3.

[0050] In step S3.4, after successful CRC verification, the original program in the application area is written to backup area 2, the application area is erased, and then the new program in backup area 1 is written to the application area. If the writing process is error-free, the new program in the application area is verified again and if the verification passes, KDCU1 replies with a 0xE5 message with a data field of 0x04; if the writing process encounters an error or the verification of the new program in the application area fails, KDCU1 replies with a 0xE5 message with a data field of 0x05. If the writing fails, and the number of failures does not exceed 2, steps S2.3, S3.2, S2.4, and S3.3 will be repeated.

[0051] In step S3.5, after the application area program is updated, the program pointer jumps from the Boot area to the application area and runs the new KDCU-APP program. PMH continues to upgrade the application for KDCU2, and upgrades all KDCUs in sequence.

[0052] Step S3.6: After a CRC check fails, the application area is not erased. If the number of failed checks exceeds two, the program pointer jumps from the Boot area to the application area and runs the original APP program.

[0053] Step S3.7: If the new program fails to be written to the application area in step S3.4 and the number of failures exceeds 2, the original program in backup area 2 is written to the application area, the program pointer jumps from the Boot area to the application area, and the original APP program is run.

[0054] Steps S3.6 and S3.7 will result in "Upgrade Failed" displayed on the PMM interface. Manual troubleshooting or flashing using a programmer is required.

[0055] Example 3 This invention also 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 loaded from a storage unit into a random access memory (RAM). The RAM may also store various programs and data required for device operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0056] Multiple components in the device are connected to the I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0057] The processing unit executes the various methods and processes described above, such as the method of Embodiment 2. For example, in some embodiments, the method of Embodiment 2 may be implemented as a computer software program tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via 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 method of Embodiment 2 described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute the method of Embodiment 2 by any other suitable means (e.g., by means of firmware).

[0058] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0059] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

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

[0061] 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 these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A platform door control unit application upgrade system, characterized in that, The system includes: The gate control unit (KDCU) is used to upgrade the application after receiving new programs. The Equipment Status Monitoring and Management Unit (PMH) is connected to the Gating Unit (KDCU) via a CAN bus and interacts with it during the upgrade process. The maintenance diagnostic terminal (PMM) is connected to the equipment status monitoring and management unit (PMH) via network communication and is used to initiate the KDCU program upgrade command. After receiving the upgrade command through the PMH, the KDCU gating unit jumps its running pointer from the application area to the boot area, waiting to receive the new application. The application area is the application running area of ​​the KDCU gating unit, and the boot area is the upgrade software running area of ​​the KDCU gating unit. In terms of storage location, the application area is placed before the boot area, that is, the starting address of the application area is a low address, and the starting address of the boot area is a high address.

2. The platform door control unit application upgrade system according to claim 1, characterized in that, The gate control unit (KDCU) includes a Flash memory, with the application area and the boot area located in the Flash memory. The starting address of the application area is 0x08000000, and the starting address of the boot area is 0x08040000.

3. The platform door control unit application upgrade system according to claim 2, characterized in that, The Flash memory also includes backup area 1 and backup area 2, wherein the starting address of backup area 1 is 0x08080000 and the starting address of backup area 2 is 0x080C0000.

4. The platform door control unit application upgrade system according to claim 3, characterized in that, The maintenance and diagnostic terminal PMM obtains the binary Bin file of the new KDCU application to be updated from the local industrial control computer. After receiving the user's update instruction, it sends the Bin file to the PMH through the agreed protocol. The PMH then sends an upgrade command to the KDCU.

5. The platform door control unit application upgrade system according to claim 3, characterized in that, The PMH sends the new application in segments along with CAN messages to the KDCU. Each CAN message contains 8 bytes of new application information and is sent to the KDCU via CAN communication. After the program information is sent, a CRC check frame of the new application is sent.

6. The platform door control unit application upgrade system according to claim 5, characterized in that, After receiving several CAN messages containing new application information, the KDCU writes the 8 bytes of the data field into backup area 1 in sequence. After receiving the CRC check frame, it calculates the CRC of the data in backup area 1 and compares whether the two are equal. If the two are equal, the data transmission verification passes; if the two are not equal, the verification fails and subsequent forgiveness operations are performed. If the data transmission verification passes, the KDCU writes the original program in the application area to the backup area 2, then erases the application area, writes the new program that passed the verification in the backup area 1 to the application area, and performs CRC verification again. If the verification passes, it means that the upgrade is successful, and the running pointer jumps to the application area to run the new gating unit application. If the upgrade fails, proceed with the subsequent forgiveness process.

7. The platform door control unit application upgrade system according to claim 6, characterized in that, If the KDCU verification fails no more than twice, the PMH will resend the program frame and verification frame; if the KDCU upgrade fails no more than twice, the PMH will resend the program frame and verification frame.

8. The platform door control unit application upgrade system according to claim 6, characterized in that, If the KDCU verification fails more than twice, the running pointer jumps to the application area and runs the original program; if the KDCU upgrade fails more than twice, the KDCU writes the original program from backup area 2 into the application area, the running pointer jumps to the application area, and runs the original program.

9. The platform door control unit application upgrade system according to claim 5, characterized in that, The CAN message format for communication between the PMH and KDCU includes 29-bit frame header information and 64-bit data field. In the frame header, bit 28 is the communication direction identifier, where 1 indicates a message sent from PMH to KDCU, and 0 indicates a message sent from KDCU to PMH; bits 27-22 are the KDCU address; bits 21-14 are the message type, where 0xE0 is the upgrade start frame, 0xE1 is the upgrade procedure frame, 0xE2 is the verification frame, and 0xE5 is the KDCU reply frame; bits 13-0 are the data field checksum, calculated as the remainder of the sum of the 8 bytes of the data field divided by 256. When the message type is 0xE1, bits 13-0 represent the frame sequence number. The data field is filled with different content according to different message types. When the message type is 0xE0, the data field is the number of bytes L of the new upgrade program; when the message type is 0xE1, the data field is the data packet of the new program; when the message type is 0xE2, the data field is the CRC check value of the new program; when the message type is 0xE5, the data field is the KDCU status reply, 0x1 indicates that the upgrade start frame has been received and the upgrade is pending, 0x2 indicates that the CRC check was successful, 0x3 indicates that the CRC check failed, 0x4 indicates that the CRC upgrade was successful, and 0x5 indicates that the CRC upgrade failed.

10. An upgrade method for a platform door control unit application upgrade system using any one of claims 1-9, characterized in that, The method includes the following steps: Step S1: After receiving the user's update instruction, PMM sends an upgrade command to PMH and simultaneously distributes the KDCU-APP.bin file of the new KDCU application to PMH through the agreed protocol. In step S2, the PMH forwards the upgrade command to the KDCU and simultaneously processes and sends the KDCU-APP.bin file of the new application to the KDCU. Step S3: KDCU undergoes an upgrade process.

11. The upgrade method according to claim 10, characterized in that, Step S2 specifically includes the following steps: Step S2.1: PMH stores KDCU-APP.bin in memory and calculates the new program length L and checksum CRC_1. If the number of bytes in the new program is not a multiple of 8 bytes, it is padded with 0s at the end of the new program. Step S2.2, PMH sends an upgrade command 0xE0 to KDCU1 with the data field set to L, and waits for a response from KDCU1; In step S2.3, if KDCU1 replies with a confirmation message in step S2.2, PMH sends several frame upgrade program packets to KDCU1. The message type is 0xE1, and the message contains a frame sequence number that increments from 0. The data field contains 8 bytes of new program content. KDCU1 does not need to reply with this message until the new program is sent. Step S2.4: After the program upgrade frame is sent, PMH continues to send a CRC check frame to KDCU1. The message type is 0xE2 and the data field is the CRC check value. Then, it waits for KDCU1 to reply.

12. The upgrade method according to claim 11, characterized in that, Step S3 specifically includes the following steps: In step S3.1, when KDCU1 receives the PMH upgrade message 0xE0, the running pointer jumps from the application area to the boot area and replies with an acknowledgment message 0xE5, with the data field being 0x01. In step S3.2, the Boot area program of KDCU1 receives several frame upgrade program packets sent by PMH and writes them sequentially to Flash backup area 1 according to the frame sequence number. When two frames with the same sequence number appear, the data of the later frame is overwritten and written to backup area 1. If a certain frame sequence number is not received, the backup area will lack 8 bytes of content of that frame message and will fail the subsequent CRC check. In step S3.3, KDCU1 receives the PMH verification message 0xE2, with the data field being the verification value CRC_1. KDCU1 calculates the CRC_2 value of the L-byte program in backup area 1 and compares it with CRC_1. If they are equal, it replies with a 0xE5 message, with the data field being 0x02; if they are not equal, it replies with a 0xE5 message, with the data field being 0x03. If the CRC verification fails and the number of failures does not exceed 2, it will re-enter steps S2.3, S3.2, S2.4, and S3.

3. Step S3.4: After successful CRC verification, the original program in the application area is written to backup area 2, the application area is erased, and then the new program in backup area 1 is written to the application area. If the writing process is error-free, the new program in the application area is verified again. If the verification passes, KDCU1 replies with a 0xE5 message and the data field is 0x04. If the writing process fails or the verification of the new program in the application area fails, KDCU1 replies with a 0xE5 message and the data field is 0x05. If the writing fails and the number of failures does not exceed 2, the process will proceed to steps S2.3, S3.2, S2.4, and S3.3 again. Step S3.5: After the application area program is updated, the program pointer jumps from the Boot area to the application area and runs the new KDCU-APP program; PMH continues to upgrade the application for KDCU2, and upgrades all KDCUs in sequence; Step S3.6: After a CRC check fails, the application area is not erased. If the number of failed checks exceeds 2, the program pointer jumps from the Boot area to the application area and runs the original APP program. Step S3.7: If the new program fails to be written to the application area in step S3.4 and the number of failures exceeds 2, the original program in backup area 2 is written to the application area, the program pointer jumps from the Boot area to the application area, and the original APP program is run.

13. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 10 to 12.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 10 to 12.

Citation Information

Patent Citations

  • Automatic updating method of urban railway traffic signal system

    CN103347048A