Firmware Upgrade Methods for Medical Devices

Abstract

The present invention relates to the technical field of medical equipment, and specifically discloses a firmware upgrade method for medical equipment, wherein the method comprises the steps of: shaking hands with a target device based on a first CAN extended frame ID structure, a device code of the target device and firmware size information, wherein the target device is a single-chip microcomputer that currently needs to perform a firmware upgrade; dividing a firmware data packet into a plurality of data packets based on data frames; constructing a CAN extended frame about each data frame based on the first CAN extended frame ID structure, and sending the CAN extended frame to the target device that has already shaken hands; the firmware upgrade method for medical equipment realizes reliable firmware upgrade of medical equipment in a multi-single-chip microcomputer system through a structured communication protocol and a data transmission mechanism, improves the efficiency and reliability of the upgrade process through packet transmission, and can ensure the stability and accuracy of the firmware upgrade process.

Description

Technical Field

[0001] The present application relates to the technical field of medical equipment, and in particular to a firmware upgrade method for medical equipment. Background Art

[0002] In the medical and industrial fields, the increasing complexity of equipment has made the integration of multiple microcontrollers the norm. However, this architecture presents numerous challenges in terms of upgrades and maintenance. Traditional methods, such as directly upgrading the microcontroller's firmware through JTAG or UART interfaces, require disassembly of the device casing, are cumbersome and rely on specialized personnel, increasing maintenance costs and uncertainty in field operations. Furthermore, while the master control MPU's method of connecting to the MCU individually via multiple serial ports can achieve control, it is inefficient and limits system scalability.

[0003] Serial communication is widely used between chips in medical devices. While stable, it lacks flexibility and is difficult to adapt to rapidly changing upgrade requirements. Direct firmware distribution is vulnerable to security threats, such as file tampering, which can cause device performance degradation or even paralysis, seriously affecting system stability and security.

[0004] There is currently no effective technical solution to the above problems. Summary of the Invention

[0005] The purpose of this application is to provide a firmware upgrade method for medical devices to reduce operational complexity and risks, thereby achieving the advantages of high efficiency, safety, and ease of operation.

[0006] The present application provides a method for upgrading the firmware of a medical device, wherein the firmware of the medical device is upgraded through an upgrade terminal, wherein the upgrade terminal is electrically connected to multiple single-chip microcomputers of the medical device through a CAN bus;

[0007] The firmware upgrade method of the medical device is executed based on the upgrade end, and includes the following steps:

[0008] S1. Shake hands with a target device based on a first CAN extended frame ID structure, a device code, and firmware size information of the target device. The target device is a single-chip microcomputer that currently needs to perform a firmware upgrade. The first CAN extended frame ID structure includes, arranged in sequence, a priority code, a command code page number, a command code, an extended data packet tag code, a source device code, and a target device code. The extended data packet tag code is used to mark the frame number of the data packet. The source device code is used to indicate the device code of the data sending device. The target device code is used to indicate the device code of the data receiving device.

[0009] S2. Divide the firmware data packet into multiple data packets composed of data frames;

[0010] S3. Construct a CAN extended frame for each data frame based on the first CAN extended frame ID structure, and send the frame to the target device that has completed the handshake.

[0011] The firmware upgrade method for medical devices of the present application realizes reliable firmware upgrade of medical devices in multi-MCU systems through structured communication protocols and data transmission mechanisms. It can accurately identify target devices, effectively transmit firmware data, and improve the efficiency and reliability of the upgrade process through packet transmission. It is particularly suitable for scenarios such as medical devices that have high requirements for security and reliability, and can ensure the stability and accuracy of the firmware upgrade process.

[0012] The firmware upgrade method for medical equipment, wherein step S1 comprises:

[0013] S11. Establishing a first frame ID conforming to the first CAN extended frame ID structure based on a first command representing the start of a handshake, a device code of the upgrade end, and a device code of the target device; establishing a first CAN frame based on the first frame ID and sending the first CAN frame via a CAN bus; wherein data of the first CAN frame includes the firmware size information;

[0014] S12. After receiving the third CAN frame sent by the target device, shake hands with the target device, the third CAN frame is established by the target device based on the third frame ID, and after the target device receives the firmware size information according to the target device code in the first frame ID, the target device establishes a third frame ID that conforms to the first CAN extended frame ID structure based on the third command representing upgrade readiness, the device code of the upgrade end, and the device code of the target device.

[0015] The firmware upgrade method for medical equipment of the present application realizes reliable handshake communication between the upgrade end and the target device by using technical features such as the frame ID structure of the CAN extended frame, the sending of the first CAN frame, the receiving of the third CAN frame, the use of command coding and the application of device coding.

[0016] The firmware upgrade method for medical equipment, wherein the steps between step S11 and step S12 further include:

[0017] S1A. Based on the second command representing data verification, the device code of the upgrade end, and the device code of the target device, a second frame ID that conforms to the first CAN extended frame ID structure is established. Based on the second frame ID, two second CAN frames are established and the second CAN frames are sent through the CAN bus. The data of the two second CAN frames are split based on the first MD5 code, and the first MD5 code is obtained by performing MD5 calculation based on the firmware data packet.

[0018] The firmware upgrade method for medical equipment, wherein step S12 includes:

[0019] S121. After receiving the third CAN frame sent by the target device, a fourth frame ID that conforms to the first CAN extended frame ID structure is established based on the fourth command representing a successful handshake, the device code of the upgrade end, and the device code of the target device. A fourth CAN frame is established based on the fourth frame ID and the fourth CAN frame is sent through the CAN bus.

[0020] The firmware upgrade method for medical equipment, wherein step S2 comprises:

[0021] S21 . Divide the firmware data packet into multiple data frames based on 8 bytes, and reorganize the data frames into multiple data packets according to the tag capacity of the extended data packet tag code.

[0022] The firmware upgrade method for medical equipment, wherein step S3 includes:

[0023] S31. Based on the fifth command representing data transmission, the device code of the upgrade end, and the device code of the target device, a fifth frame ID that conforms to the first CAN extended frame ID structure is established; based on the fifth frame ID, a fifth CAN frame is established and the fifth CAN frame is sent through the CAN bus; the data of each of the fifth CAN frames includes a data frame in the data packet, and the frame number of the data frame in the data packet is recorded in the extended data packet tag code in the fifth frame ID.

[0024] The firmware upgrade method for medical equipment, wherein step S3 further includes:

[0025] S32. After each data packet is sent, a sixth frame ID that conforms to the first CAN extended frame ID structure is established based on the sixth command representing the data packet verification, the device code of the upgrade end, and the device code of the target device. A sixth CAN frame is established based on the sixth frame ID and the sixth CAN frame is sent through the CAN bus. The data of the sixth CAN frame includes a verification code corresponding to the data packet that has been sent.

[0026] The firmware upgrade method for medical equipment, wherein the priority code length is 3 bits, the command code page length is 1 bit, the command code length is 8 bits, the extended data packet mark code length is 5 bits, the source device code length is 6 bits, and the target device code length is 6 bits.

[0027] In the firmware upgrade method for medical equipment, the extended data packet mark code is 0, indicating that the corresponding data packet is sent without subpacketization.

[0028] From the above, it can be seen that the present application provides a firmware upgrade method for medical devices. The firmware upgrade method for medical devices realizes reliable firmware upgrade of medical devices in multi-microcontroller systems through structured communication protocols and data transmission mechanisms. It can accurately identify target devices, effectively transmit firmware data, and improve the efficiency and reliability of the upgrade process through subpacket transmission. It is particularly suitable for scenarios such as medical devices that have high requirements for security and reliability, and can ensure the stability and accuracy of the firmware upgrade process. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 This is a structural diagram of the first CAN extended frame ID structure.

[0030] Figure 2 Flowchart of a firmware upgrade method for a medical device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work fall within the scope of protection of the present application.

[0032] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0033] Please refer to Figure 1 The firmware upgrade method for medical devices provided in this application establishes relevant frame data based on a first CAN extended frame ID structure to implement firmware upgrade of multiple microcontrollers, wherein the first CAN extended frame ID structure includes: a priority code, a command code page number, a command code, an extended data packet tag code, a source device code, and a target device code, which are arranged in sequence;

[0034] The extended data packet mark code is used to mark the frame number of the data packet, the source device code is used to indicate the device code of the data sending device, and the destination device code is used to indicate the device code of the data receiving device.

[0035] Specifically, the CAN extended frame is a frame type in the CAN protocol used to transmit data with a longer identifier (29-bit binary ID) and data field. In order to be suitable for firmware upgrades of medical devices, this application redesigns the frame ID structure in the CAN extended frame (corresponding to the identifier in the extended frame) to make the CAN extended frame suitable for firmware upgrades of medical devices.

[0036] More specifically, if Figure 1 As shown, the priority code is recorded as p, the command code page number is recorded as pg, the command code is recorded as cmd, the extended data packet mark code is recorded as DID, the source device code is recorded as DST, and the target device code is recorded as SRC.

[0037] More specifically, the first CAN extended frame ID structure fully utilizes the characteristics of the CAN bus while overcoming its limitations in long data transmission and command types. Among them, priority coding can ensure the timely transmission of important information, and different priorities can be set according to different types of data or commands. Command coding can configure different commands in each data transmission link to distinguish the operation stages according to usage requirements. The command coding page number can further expand the command types that can be filled in the command coding. Its combination with the command coding allows the system to perform more operations sufficient to cover the firmware upgrade process, greatly increasing the flexibility of the upgrade process. The expanded data packet marking coding is used to mark the frame number of the data packet, realizing effective support for long data, making the transmission of large firmware files possible. The source device coding and target device coding clarify the sending and receiving devices of the data, improve the accuracy and security of communication, and reserve sufficient space for system expansion.

[0038] In practical applications, this CAN extended frame ID structure can be used to update the firmware of a multifunctional vital signs monitor. For example, a monitor containing an electrocardiogram (ECG) module, a blood oxygen saturation (SpO2) module, and a non-invasive blood pressure (NIBP) module, each with its own device ID, can be used to update the firmware of multiple modules simultaneously via the CAN bus.

[0039] More specifically, based on the above-mentioned first CAN extended frame ID structure, the master control system of the medical device can accurately control the data flow to ensure that the correct module receives the corresponding firmware update. At the same time, priority coding allows regular data transmission to be interrupted when necessary to execute emergency commands or transmit critical data. Extended data packet tag coding allows large firmware files to be divided into multiple data packets for orderly transmission, greatly improving transmission efficiency. Compared with traditional methods, the first CAN extended frame ID structure of the embodiment of the present application utilizes the characteristics of the CAN bus while overcoming its limitations in long data transmission and command types, greatly increasing the types and flexibility of executable operations, so that the firmware upgrade process can be more finely controlled and adapt to complex upgrade scenarios.

[0040] The first CAN extended frame ID structure is used in the firmware upgrade of medical equipment, so that the medical equipment can establish a CAN extended frame according to the frame ID structure through the CAN bus to transmit the firmware data packet, so that the firmware upgrade process of multiple microcontrollers in the medical equipment does not require the removal of the device casing, which greatly reduces the operation complexity and risk, has the advantages of high efficiency, safety, and easy operation, and provides better system scalability.

[0041] Please refer to Figure 2 After determining the format of the first CAN extended frame ID structure, some embodiments of the present application provide a method for upgrading firmware of a medical device, wherein the firmware of the medical device is upgraded through an upgrade terminal, and the upgrade terminal is electrically connected to multiple microcontrollers of the medical device through a CAN bus;

[0042] The firmware upgrade method of the medical device is executed based on the upgrade end and includes the following steps:

[0043] S1. Shake hands with the target device based on the first CAN extended frame ID structure, the device code and firmware size information of the target device. The target device is a single-chip microcomputer that currently needs to upgrade its firmware. The first CAN extended frame ID structure includes the following elements, which are arranged in sequence: a priority code, a command code page number, a command code, an extended data packet tag code, a source device code, and a target device code. The extended data packet tag code is used to mark the frame number of the data packet. The source device code is used to indicate the device code of the data sending device. The target device code is used to indicate the device code of the data receiving device.

[0044] S2. Divide the firmware data packet into multiple data packets composed of data frames;

[0045] S3. Construct a CAN extended frame for each data frame based on the first CAN extended frame ID structure, and send the frame to the target device that has completed the handshake.

[0046] Specifically, the upgrade end is used to transmit the firmware data packet to the corresponding single-chip microcomputer for firmware upgrade, which can be a firmware upgrader or a main controller in the medical device.

[0047] More specifically, the firmware upgrade method for medical equipment in an embodiment of the present application adopts a specific frame ID structure of a CAN extended frame, ensures that the target device is ready through a handshake mechanism, divides the firmware data packet into multiple data frames, and uses the frame ID structure of the CAN extended frame to construct and send data frames, thereby realizing reliable firmware upgrades for medical equipment in a multi-microcontroller system. This method can accurately identify the target device, effectively transmit firmware data, and improve the efficiency and reliability of the upgrade process through packet transmission.

[0048] More specifically, the firmware data packets can be divided based on the data field size of the CAN frame (usually 8 bytes) to obtain multiple data frames that meet the data field size, and these data frames can be reassembled into multiple data packets according to the capacity encoded by the extended data packet marker.

[0049] More specifically, during data transmission, each CAN frame contains specific command codes, such as data transmission commands and checksum commands. Extended packet marker codes identify the position of each data frame within the data packet, enabling the receiver to correctly reassemble the data. The source and destination device codes ensure accurate data transmission and prevent data from being received by the wrong device.

[0050] The firmware upgrade method for medical devices in the embodiment of the present application realizes reliable firmware upgrade of medical devices in a multi-microcontroller system through a structured communication protocol and data transmission mechanism. It can accurately identify the target device, effectively transmit firmware data, and improve the efficiency and reliability of the upgrade process through packet transmission. It is particularly suitable for scenarios such as medical devices that have high requirements for security and reliability, and can ensure the stability and accuracy of the firmware upgrade process; the method establishes a CAN extended frame based on the frame ID structure provided in the first aspect, so that the medical device can establish a CAN extended frame according to the frame ID structure through the CAN bus to transmit the firmware data packet, so that the firmware upgrade process of multiple microcontrollers in the medical device does not require the removal of the device casing, which greatly reduces the operation complexity and risk, has the advantages of high efficiency, safety, and ease of operation, and provides better system scalability.

[0051] In some preferred embodiments, step S1 includes:

[0052] S11. Based on the first command representing the start of handshake, the device code of the upgrade end, and the device code of the target device, a first frame ID conforming to a first CAN extended frame ID structure is established. Based on the first frame ID, a first CAN frame is established and sent via the CAN bus. The data of the first CAN frame includes firmware size information.

[0053] S12. After receiving the third CAN frame sent by the target device, shake hands with the target device. The third CAN frame is established by the target device based on the third frame ID. After the target device receives the firmware size information according to the target device code in the first frame ID, the target device establishes a third frame ID that conforms to the first CAN extended frame ID structure based on the third command representing upgrade readiness, the device code of the upgrade end, and the device code of the target device.

[0054] Specifically, the firmware upgrade method for medical devices in the embodiments of the present application achieves reliable handshake communication between the upgrade end and the target device by using technical features such as the frame ID structure of the CAN extended frame, the transmission of the first CAN frame, the reception of the third CAN frame, the use of command codes, and the application of device codes. This handshake mechanism achieves reliable communication between the upgrade end and the target device via the CAN bus, ensuring the reliability and security of the upgrade process and effectively preventing misoperation and unauthorized access. The use of command codes can not only distinguish the different stages of the handshake process, but can also be extended to the entire upgrade process, making the entire upgrade process more structured and controllable.

[0055] More specifically, during the reception of the third CAN frame, the upgrade end can set a timeout mechanism. For example, if the third CAN frame from the target device is not received within 5 seconds, the handshake is considered failed and the upgrade process can be either re-initiated or terminated. This mechanism effectively prevents the upgrade process from waiting indefinitely due to communication problems.

[0056] More specifically, in some other implementations, the application of device codes can be further refined. For example, a 6-digit device code can be divided into a 2-digit device type code and a 4-digit device serial number. This not only distinguishes different devices but also identifies the device type, providing more information for subsequent upgrade strategies.

[0057] More specifically, in an embodiment of the present application, the sending of the first CAN frame initiates the handshake process, and the firmware size information carried provides the target device with the necessary upgrade preparation information. The target device responds to the third CAN frame, allowing the upgrade end to confirm that the target device is in an upgrade-ready state, and also verifies the availability of the communication link. The use of command coding and device coding runs through the entire process to ensure the accuracy and security of communication; this handshake mechanism has significant advantages over traditional firmware upgrade methods: first, it makes full use of the characteristics of the CAN bus to achieve efficient and reliable communication; second, by using the frame ID structure of the CAN extended frame, it can transmit more information within a limited data length, thereby improving communication efficiency; third, the use of command coding and device coding enhances the security of the system and effectively prevents misoperation and unauthorized access.

[0058] More specifically, in an embodiment of the present application, the first command of the first frame ID in the first CAN frame represents that the upgrade end initiates a handshake operation on the target device, and the third command of the third frame ID in the third CAN frame represents that the target device can normally receive the first CAN frame and is in an upgrade-ready state. The data in the third CAN frame can contain any value, and in an embodiment of the present application, it is preferably 1.

[0059] In some preferred embodiments, the following steps are further included between step S11 and step S12:

[0060] S1A. Based on the second command representing data verification, the device code of the upgrade end, and the device code of the target device, a second frame ID that conforms to the first CAN extended frame ID structure is established. Based on the second frame ID, two second CAN frames are established and sent through the CAN bus. The data of the two second CAN frames are split based on the first MD5 code, and the first MD5 code is obtained by performing MD5 calculation based on the firmware data packet.

[0061] Specifically, the first MD5 code is verification data for verifying the data integrity of the firmware data packet, which may be pre-stored in the encapsulation structure corresponding to the firmware data packet, or may be generated by the upgrade end based on the decrypted firmware data packet.

[0062] More specifically, generally speaking, the length of the MD5 code is 16 bytes, and the length of the data field of the CAN frame is 8 bytes. Therefore, the firmware upgrade method of the medical device in the embodiment of the present application uses two second CAN frames to transmit the first MD5 code to the target device, which adapts to the data length limit of the CAN bus and ensures the complete transmission of the verification data.

[0063] More specifically, the firmware size information and the first MD5 code are both characteristic data of the firmware data packet. Transmitting these data based on the handshake establishment process can enable the target device to obtain the corresponding data characteristics of the target device in advance, so that the target device can immediately verify whether the firmware data packet is successfully transmitted based on these characteristic data at the end of data transmission.

[0064] More specifically, step S1A is closely integrated with the handshake process, and a data verification step is inserted after sending the firmware size information and before receiving the target device ready information, which not only ensures the integrity of the firmware data but also optimizes the entire upgrade process.

[0065] It should be noted that the data fields of the two second CAN frames contain the first 8 bytes and the last 8 bytes of the first MD5 code, respectively. After receiving these two frames, the target device can reconstruct the complete first MD5 code and verify it when receiving firmware data later.

[0066] More specifically, in this embodiment, the third command with the third frame ID in the third CAN frame represents that the target device can normally receive the first CAN frame and the second CAN frame and is in an upgrade-ready state.

[0067] In some preferred embodiments, step S12 includes:

[0068] S121. After receiving the third CAN frame sent by the target device, a fourth frame ID that conforms to the first CAN extended frame ID structure is established based on the fourth command representing a successful handshake, the device code of the upgrade end, and the device code of the target device. A fourth CAN frame is established based on the fourth frame ID and the fourth CAN frame is sent through the CAN bus.

[0069] Specifically, the firmware upgrade method for medical devices in this embodiment of the application ensures the successful handshake between the upgrade end and the target device by adding an additional confirmation step during the handshake process. Specifically, after the upgrade end receives the third CAN frame from the target device (indicating that the target device is ready for upgrade), it sends a fourth CAN frame to confirm the successful handshake. This two-way confirmation mechanism significantly improves the reliability and stability of the firmware upgrade process and is particularly suitable for medical devices in the field where security and reliability are paramount.

[0070] More specifically, by introducing this additional handshake confirmation step, the technical solution of this application significantly improves the reliability and security of the medical device firmware upgrade process. Compared to the traditional one-way handshake method, this two-way confirmation mechanism can effectively prevent upgrade failures caused by communication errors or misunderstandings, thereby reducing device downtime and maintenance costs.

[0071] More specifically, in an embodiment of the present application, the fourth command of the fourth frame ID in the fourth CAN frame represents that the upgrade end and the target device have successfully shaken hands and can perform CAN communication normally. The data in the fourth CAN frame can contain any value. In an embodiment of the present application, it is preferably 1.

[0072] In some preferred embodiments, step S2 includes:

[0073] S21 . Divide the firmware data packet into multiple data frames based on 8 bytes, and reorganize the data frames into multiple data packets according to the tag capacity of the extended data packet tag code.

[0074] Specifically, because the CAN protocol stipulates that each frame can transmit a maximum of 8 bytes of data, in the embodiments of the present application, the firmware data packet is split based on 8 bytes to obtain multiple data frames, which can fully utilize the transmission capacity of CAN communication. At the same time, the solution also takes into account the tag capacity of the extended data packet tag code and reassembles the divided data frames into multiple data packets. The purpose of this is to fully utilize the capacity of the extended data packet tag code in the frame ID structure of the CAN extended frame, so that the number of data frames contained in each data packet matches the tag code capacity. This design can improve the efficiency of data transmission and reduce the overhead during the transmission process.

[0075] More specifically, this partitioning and reassembly method not only solves firmware data transmission issues but also optimizes transmission efficiency. By matching the number of data frames with the tag encoding capacity, the system can transmit the maximum number of data frames in each packet, reducing the total number of packets and lowering transmission overhead. Furthermore, this approach improves data traceability and error resilience. Each data frame is uniquely identified within the packet (extended packet tag encoding). If an error occurs during transmission, the system can pinpoint the specific data frame without retransmitting the entire packet.

[0076] More specifically, in an embodiment of the present application, the maximum number of data frames of each data packet is the maximum capacity of the extended data packet marker code minus one. For example, in an implementation where the extended data packet marker code length is 5 bits, the value of the extended data packet marker code is 0-31, so the maximum number of data frames of each data packet is 30; wherein, the case where the extended data packet marker code is 31 is used to indicate that the corresponding data packet has been sent, to trigger the next stage of data packet to be sent or to trigger the target device to verify the integrity of the data packet just received, to ensure that data transmission is carried out in an orderly manner.

[0077] In some preferred embodiments, step S3 includes:

[0078] S31. Based on the fifth command representing data transmission, the device code of the upgrade end, and the device code of the target device, a fifth frame ID that conforms to the first CAN extended frame ID structure is established. Based on the fifth frame ID, a fifth CAN frame is established and the fifth CAN frame is sent through the CAN bus. The data of each fifth CAN frame includes a data frame in the data packet, and the frame number of the data frame in the data packet is recorded in the extended data packet tag code in the fifth frame ID.

[0079] Specifically, in this embodiment, the target device receives and stores the contents of the data field of the fifth CAN frame (i.e., the data frame) in accordance with the fifth command, enabling segmented reception and reassembly of data packets. Each CAN frame contains a single data frame, making data transmission more flexible and controllable. The data frame's frame number within the data packet is recorded in the extended packet tag encoding of the frame ID, which helps the receiving end correctly assemble and sort received data.

[0080] More specifically, the solution of this application, together with the previous handshake process and data packet segmentation steps, forms a complete firmware upgrade process. The handshake process ensures the correct connection between the upgrade end and the target device, the data packet segmentation step divides the large firmware file into small units suitable for CAN bus transmission, and this step achieves the efficient transmission of these data units.

[0081] In some preferred embodiments, step S3 further includes:

[0082] S32. After each data packet is sent, a sixth frame ID that conforms to the first CAN extended frame ID structure is established based on the sixth command representing the data packet verification, the device code of the upgrade end, and the device code of the target device. A sixth CAN frame is established based on the sixth frame ID and sent through the CAN bus. The data of the sixth CAN frame includes a verification code corresponding to the data packet that has been sent.

[0083] Specifically, this method introduces a packet verification mechanism, implemented by sending a CAN frame containing a checksum after each packet is sent. Specifically, a sixth command is used to indicate the packet verification operation. Encoding between the upgrade end and the target device is used to ensure that the verification information is accurately transmitted to the correct device. A sixth frame ID conforming to a specific structure is constructed to ensure the correct identification and processing of the checksum frame. The sixth CAN frame carries the checksum corresponding to the completed packet, which is used by the receiving end to verify data integrity.

[0084] More specifically, the checksum can be generated using a variety of algorithms, such as CRC32, MD5, or SHA256, etc. The selection of an appropriate checksum algorithm requires a balance between computational complexity and security.

[0085] More specifically, this verification mechanism, combined with the previously mentioned data transmission method, forms a complete data transmission and verification system. During data transmission, each data packet is sent in the fifth CAN frame, followed by the corresponding verification code in the sixth CAN frame. This tightly integrated transmission and verification method ensures efficient transmission while promptly detecting and correcting transmission errors.

[0086] In some preferred embodiments, after executing step S32, the target device obtains the verification code and uses the verification code to verify the previously received data packet to generate a verification result, and then establishes a seventh frame ID that conforms to the first CAN extended frame ID structure based on the seventh command representing the verification feedback, the device code of the upgrade end, and the device code of the target device, establishes a seventh CAN frame based on the seventh frame ID and sends the seventh CAN frame to the upgrade end via the CAN bus, and the data of the seventh CAN frame contains the verification result.

[0087] Specifically, after receiving the data packet, the target device will use the checksum to verify the received data packet and generate a checksum result. This checksum result is fed back to the upgrade end via the CAN bus and transmitted using a specific CAN extended frame structure.

[0088] More specifically, in actual applications, the verification process is a segmented verification process, which is used to verify the integrity of each data packet split from the firmware data packet.

[0089] More specifically, this solution is tightly integrated with the aforementioned data transmission and checksum sending process, forming a complete data transmission-check-feedback loop. This loop not only enables timely detection and location of transmission errors, but also provides a foundation for subsequent error handling.

[0090] In practice, after receiving the data packet and checksum, the target device first performs a checksum calculation on the received data packet using the same checksum algorithm. The calculated checksum result is then compared with the received checksum. If the two match, the data packet was transmitted correctly; if they do not, an error may have occurred during transmission.

[0091] It should be noted that the verification result can be a verification pass or a verification fail, which can be marked by a specific data field, such as data 1 indicates a verification pass.

[0092] More specifically, in this way, the system can quickly discover and locate transmission errors during the firmware upgrade process, providing a basis for subsequent error handling, thereby improving the reliability and efficiency of the firmware upgrade.

[0093] In some preferred embodiments, step S3 further includes:

[0094] S33, receiving the seventh CAN frame and extracting the verification result. When the verification result is passed, sending the next data packet based on step S31; when the verification result is failed, resending the corresponding data packet that failed the verification based on step S31.

[0095] Specifically, this technical solution ensures the accuracy and integrity of data packet transmission by introducing a verification mechanism during data packet transmission and taking appropriate action based on the verification results. Specifically, after each data packet is transmitted, this solution sends a CAN frame containing a verification code. Upon receiving the data packet and the verification code, the target device verifies the data packet and returns the verification result. The upgrade end then determines the next step based on the verification result. If the verification result passes, the data packet has been received correctly, and the upgrade end proceeds to send the next data packet. If the verification result fails, it indicates that an error may have occurred during transmission, and the upgrade end resends the data packet. This mechanism ensures that every data packet is correctly received through real-time data verification and targeted retransmissions. If a transmission error occurs, the system quickly identifies and automatically corrects it without restarting the entire upgrade process. This allows for better handling of data transmission errors that may occur in complex network environments, reducing the risk of upgrade failures and providing more reliable assurance for the safe operation of medical devices.

[0096] In some preferred embodiments, after the target device receives the firmware data packet, it verifies the integrity of the firmware data packet based on the first MD5 code; if the firmware data packet is complete, the target device performs a firmware upgrade based on the BootLoader and generates an upgrade result, and then establishes an eighth frame ID that conforms to the first CAN extended frame ID structure based on the eighth command representing the upgrade feedback, the device code of the upgrade end, and the device code of the target device, establishes an eighth CAN frame based on the eighth frame ID and sends the eighth CAN frame to the upgrade end through the CAN bus, and the data of the eighth CAN frame contains the upgrade result; if the firmware data packet is incomplete, the target device establishes a ninth frame ID that conforms to the first CAN extended frame ID structure based on the ninth command representing the failure of the MD5 check, the device code of the upgrade end, and the device code of the target device, establishes a ninth CAN frame based on the ninth frame ID and sends the ninth CAN frame to the upgrade end through the CAN bus.

[0097] Specifically, the verification process of the first MD5 code can be performed in a variety of ways. For example, the target device can perform MD5 calculation on the received firmware data packet and then compare the calculation result with the first MD5 code sent by the upgrade end.

[0098] More specifically, when the firmware data package is complete, the Bootloader can first perform a version check to ensure that the new firmware version is higher than the current version. The Bootloader can then write the new firmware to a designated storage area and set a corresponding flag to indicate the upgrade status. After the upgrade is complete, the system can automatically reboot to load the new firmware.

[0099] More specifically, this design, along with the aforementioned handshake and data transmission process, forms a complete firmware upgrade process. By performing an MD5 check on the first MD5 code transmitted during the handshake phase after the firmware data packet is transmitted, the reliability of the upgrade process is greatly improved.

[0100] More specifically, in practical applications, this approach can effectively prevent firmware corruption caused by network interference, storage errors, or malicious attacks.

[0101] In some preferred embodiments, the firmware data packet is stored in the upgrade terminal based on the encapsulation structure after encryption, and the encapsulation structure includes: target device code, encryption type, first MD5 code, and encrypted firmware data packet.

[0102] Specifically, this technical solution uses a specific encapsulation structure to store encrypted firmware data packets. This structure contains several key pieces of information: the target device code ensures that the firmware data packet is accurately sent to the correct medical device; the encryption type specifies the encryption method for the firmware data, which helps the receiving end correctly decrypt it; the first MD5 code is used to verify the integrity of the firmware data packet, preventing data tampering or corruption during transmission; and the encrypted firmware data packet improves the security of the firmware content and prevents unauthorized access. This encapsulation structure effectively solves data security and integrity issues during firmware upgrades and prevents firmware damage or tampering during the copying process.

[0103] It should be noted that the encapsulation structure refers to a file storage structure, which can be formed into an independent file structure in the form of a compressed package, encrypted file, etc.

[0104] More specifically, the various elements of the package structure are closely linked. The target device code, combined with the device identification mechanism used in CAN bus communication, ensures that the firmware package can only be received and parsed by the designated device. The encryption type corresponds to the actual encryption process, and the receiver uses this information to select the correct decryption method. The first MD5 code is associated with the integrity verification process of the firmware data packet and is used to verify the integrity of the data after transmission.

[0105] It should be noted that in the embodiment of the present application, before executing the firmware upgrade method of the medical device in the embodiment of the present application, the upgrade end can extract the target device code and the first MD5 code from the imported file represented by the encapsulation structure, and decrypt and extract the firmware data packet according to the encryption type, so as to perform subsequent transmission tasks.

[0106] In some preferred embodiments, the priority code length is 3 bits, the command code page length is 1 bit, the command code length is 8 bits, the extended data packet mark code length is 5 bits, the source device code length is 6 bits, and the target device code length is 6 bits.

[0107] Specifically, the frame ID structure of the CAN extended frame is fixed at 29 bits. This solution redefines the frame ID structure of the 29-bit CAN extended frame to design a special CAN extended frame suitable for medical equipment to transmit firmware data packets; among them, the priority code uses 3 bits, which can distinguish 8 priorities and meet the needs of most medical equipment communication scenarios. This design allows different types of messages to be prioritized during the communication process to ensure that key information can be transmitted in a timely manner; the command code page number uses 1 bit, which can distinguish between two command pages, reserving space for future expansion and providing flexibility for future upgrades of the system. Functions can be expanded by adding new command pages without changing the overall framework; the command code uses 8 bits, which can It represents 256 different commands, which is enough to cover various operations in the firmware upgrade process and other CAN communication operations. This design provides a rich command set that can finely control each link of the firmware upgrade, such as starting the upgrade, data transmission, verification, and ending the upgrade. The extended data packet tag encoding uses 5 bits to generate 32 different tags, which are used to mark different frame numbers of the same data packet to realize the transmission of long data, which is conducive to the sub-packet transmission of large-capacity firmware. This design allows the data packets split from large firmware to be divided into multiple frames based on continuous frame numbers for long data transmission. The source device code and the target device code each use 6 bits, which can identify 64 different devices respectively to meet the needs of multi-chip microcomputer systems. This design supports complex medical equipment systems.

[0108] More specifically, this code length allocation scheme fully utilizes the 29-bit ID space in the CAN extended frame, ensuring the integrity of communication functions while also leaving room for future expansion. By rationally allocating the length of each code component in the first CAN extended frame ID structure, this scheme enables efficient firmware upgrade communication and improves the efficiency and reliability of data transmission. This design not only solves efficiency and reliability issues during firmware upgrades, but also provides a unified communication framework for the entire medical device system.

[0109] In some preferred embodiments, the extended data packet flag code is 0, indicating that the corresponding data packet is sent without subpacketization.

[0110] Specifically, in an implementation method where the extended data packet mark code length is 5 bits, the extended data packet mark code of 0 corresponds to 00000, which is used to indicate that the corresponding data packet is not sub-packetized and sent; the firmware data packet will be split into multiple data packets that meet the CAN extended frame requirements before being sent, and each data packet contains several data frames. If a data packet contains only one data frame, there is no need to sub-packetize and send it, so the extended data packet mark code of the corresponding CAN extended frame can be set to 0 to indicate that the data frame represents the corresponding data packet that is not sub-packetized.

[0111] More specifically, the extended data packet marker code is a component of the frame ID structure of the CAN extended frame, which is used to mark the frame number of the data packet (with 1 as the starting frame number of the data frame in the corresponding data packet). The first CAN extended frame ID structure sets the extended data packet marker code to 0 to indicate that the corresponding data packet is sent as non-packetized data, which can clearly distinguish between packetized data and non-packetized data, and indicate the completion of data transmission in a simple and effective way, which helps the receiving device to correctly process the received data and perform subsequent operations.

[0112] More specifically, in the case where the data packet is subpacketized and sent, after the data frames corresponding to all the subpacketized data of a data packet are sent, the extended data packet mark of the next CAN extended frame is encoded as the number of data frames of the data packet that has been sent plus one, and the data length is 0, to indicate that the subpacketization of the data packet has ended. For example, if the number of subpackets of a data packet is 30, the upgrade end will send another CAN extended frame with an extended data packet mark code of 31 and a data length of 0 after sending the corresponding 30 data frames to indicate that the subpacketization of the data packet has ended, which can clearly indicate the completion of the data packet transmission; in the case of non-subpacketized transmission, since the data packet has only one data frame, the process of sending the above-mentioned data frame with a data length of 0 can be skipped; this method not only simplifies the communication protocol, but also improves communication efficiency, while ensuring the reliability and integrity of the data transmission process.

[0113] In summary, the embodiments of the present application provide a firmware upgrade method for medical devices. The firmware upgrade method for medical devices realizes reliable firmware upgrade of medical devices in a multi-microcontroller system through a structured communication protocol and data transmission mechanism. It can accurately identify the target device, effectively transmit firmware data, and improve the efficiency and reliability of the upgrade process through packet transmission. It is particularly suitable for scenarios such as medical devices that have high requirements for security and reliability, and can ensure the stability and accuracy of the firmware upgrade process.

[0114] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any actual relationship or order between these entities or operations.

[0115] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, various modifications and variations of the present application are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for upgrading the firmware of a medical device, wherein the firmware of the medical device is upgraded through an upgrade terminal, characterized in that: The upgrade terminal is electrically connected to multiple single-chip microcomputers of the medical device via a CAN bus; The firmware upgrade method of the medical device is executed based on the upgrade end, and comprises the following steps: S1. Shake hands with the target device based on the first CAN extended frame ID structure, the device code and firmware size information of the target device. The target device is a single-chip microcomputer that currently needs to upgrade its firmware. The first CAN extended frame ID structure includes: a priority code, a command code page number, a command code, an extended data packet mark code, a source device code and a target device code, which are arranged in sequence. The extended data packet mark code is used to mark the frame number of the data packet, the source device code is used to indicate the device code of the data sending device, and the target device code is used to indicate the device code of the data receiving device. S2, dividing the firmware data packet into a plurality of data packets composed of data frames; S3, constructing a CAN extended frame for each data frame based on the first CAN extended frame ID structure, and sending it to the target device that has completed the handshake; Step S1 includes: S11, establishing a first frame ID conforming to the first CAN extended frame ID structure based on a first command representing the start of handshake, the device code of the upgrade end, and the device code of the target device, establishing a first CAN frame based on the first frame ID and sending the first CAN frame through a CAN bus, wherein data of the first CAN frame includes the firmware size information; S12, after receiving the third CAN frame sent by the target device, shaking hands with the target device, the third CAN frame is established by the target device based on the third frame ID, after the target device receives the firmware size information according to the target device code in the first frame ID, the target device establishes a third frame ID that conforms to the first CAN extended frame ID structure based on the third command representing upgrade readiness, the device code of the upgrade end, and the device code of the target device; Step S12 includes: S121. After receiving the third CAN frame sent by the target device, a fourth frame ID conforming to the first CAN extended frame ID structure is established based on a fourth command representing a successful handshake, the device code of the upgrade end, and the device code of the target device; a fourth CAN frame is established based on the fourth frame ID and the fourth CAN frame is sent through the CAN bus.

2. The firmware upgrade method of medical equipment according to claim 1, characterized in that: The steps between step S11 and step S12 also include: S1A. Based on the second command representing data verification, the device code of the upgrade end, and the device code of the target device, a second frame ID that conforms to the first CAN extended frame ID structure is established. Based on the second frame ID, two second CAN frames are established and the second CAN frames are sent through the CAN bus. The data of the two second CAN frames are split based on the first MD5 code, and the first MD5 code is obtained by performing MD5 calculation based on the firmware data packet.

3. The firmware upgrade method of medical equipment according to claim 1, characterized in that: Step S2 includes: S21, dividing the firmware data packet into a plurality of data frames based on 8 bytes, and reorganizing the data frames into a plurality of data packets according to the tag capacity of the extended data packet tag code.

4. The firmware upgrade method of medical equipment according to claim 1, characterized in that: Step S3 includes: S31. Based on the fifth command representing data transmission, the device code of the upgrade end, and the device code of the target device, a fifth frame ID that conforms to the first CAN extended frame ID structure is established; based on the fifth frame ID, a fifth CAN frame is established and the fifth CAN frame is sent through the CAN bus; the data of each of the fifth CAN frames includes a data frame in the data packet, and the frame number of the data frame in the data packet is recorded in the extended data packet tag code in the fifth frame ID.

5. The firmware upgrade method for medical equipment according to claim 4, characterized in that: Step S3 also includes: S32. After each data packet is sent, a sixth frame ID that conforms to the first CAN extended frame ID structure is established based on a sixth command representing data packet verification, the device code of the upgrade end, and the device code of the target device. A sixth CAN frame is established based on the sixth frame ID and the sixth CAN frame is sent through the CAN bus. The data of the sixth CAN frame includes a verification code corresponding to the data packet that has been sent.

6. The firmware upgrade method of medical equipment according to claim 1, characterized in that: The priority code length is 3 bits, the command code page code length is 1 bit, the command code length is 8 bits, the extended data packet mark code length is 5 bits, the source device code length is 6 bits, and the target device code length is 6 bits.

7. The firmware upgrade method of medical equipment according to claim 1, characterized in that: The extended data packet mark code is 0, indicating that the corresponding data packet is sent without subpacketization.

Images