Service decoupling data transmission architecture, method and device

Abstract

A business-decoupled data transmission architecture, method, and device are disclosed, relating to the field of elevator data transmission. The data transmission architecture includes: a cloud platform, a gateway, an elevator main control unit, and an in-car operation panel. The cloud platform is configured to send variable-length data frames to the gateway and receive variable-length data frames from the gateway. The gateway performs protocol conversion, transparent transmission, or forwarding of variable-length data frames between the cloud platform and the elevator main control unit. Upon receiving a variable-length data frame from the gateway or the elevator control unit (COP), the elevator main control unit performs only integrity verification and extracts the destination address. If the destination address indicates that the data frame is destined for a device other than the elevator main control unit, the elevator main control unit forwards the variable-length data frame directly to the COP or gateway without parsing. The COP receives and parses the data frame from the elevator main control unit, performs corresponding operations, generates a data frame, and sends it to the elevator main control unit. This disclosure reduces the burden on the elevator main control unit and improves the response speed and operational reliability of real-time elevator control tasks.

Description

Technical Field

[0001] This article relates to data transmission technology, particularly a business-decoupled data transmission architecture, method, and equipment. Background Technology

[0002] With the development of intelligent elevator technology, elevator systems need to frequently interact with external systems such as cloud-based smart home platforms, building management systems, and user mobile terminals. For example, they need to receive remote call commands, report elevator operating status, send advertising information, and update floor registration strategies. As a result, the amount of data transmitted by elevator systems has increased significantly.

[0003] In related technologies, elevator control systems typically employ a closed architecture. All data generated by the elevator car control panel (COP) must be centrally processed and forwarded by the elevator main controller. This data transmission architecture is highly dependent on the main controller's computing power. However, with the increasing demands for this data transmission, the elevator main controller needs to simultaneously handle real-time operation control tasks and a large amount of data processing, leading to a significant increase in its computational load and consequently affecting the response speed and operational reliability of the elevator's real-time control tasks. Summary of the Invention

[0004] This disclosure provides a business decoupled data transmission architecture, method, and device that can reduce the burden on the elevator main control system, thereby improving the response speed and operational reliability of elevator real-time control tasks.

[0005] The first aspect of this application proposes a business decoupled data transmission architecture for use in an elevator control system, including: a cloud platform, a gateway, an elevator main control unit, and an in-car operation panel. The cloud is configured to send variable-length data frames to the gateway and receive variable-length data frames from the gateway. The gateway is configured to perform protocol conversion, transparent transmission, or forwarding of variable-length data frames between the cloud and the elevator main control. The elevator master controller is configured to, upon receiving a variable-length data frame from the gateway or the COP, only perform integrity verification on the variable-length data frame and extract the destination address. If it is determined based on the destination address in the variable-length data frame that the target device to which the variable-length data frame is to be sent is not the elevator master controller, it will not parse the service data in the variable-length data frame, but will directly forward the variable-length data frame to the COP or the gateway based on the destination address. The COP is configured to receive and independently parse variable-length data frames from the elevator main control and perform corresponding operations, and is also configured to generate variable-length data frames and send them to the elevator main control.

[0006] In some exemplary embodiments, the elevator master controller is further configured to: Before forwarding the variable-length data frame to the COP or the gateway according to the destination address, extract the checksum field in the variable-length data frame and perform CRC data integrity verification. After the CRC data integrity check passes, the variable-length data frame is forwarded to the COP or the gateway according to the destination address. If the CRC data integrity check fails, it is determined that the variable-length data frame was damaged during transmission. The elevator master controller directly discards the variable-length data frame and does not perform a forwarding operation to prevent the damaged data from interfering with the elevator's local control network.

[0007] In some exemplary embodiments, the variable-length data frame sent from the cloud includes a first variable-length data frame, the destination address in the first variable-length data frame indicating that the target device to which the variable-length data frame is to be sent is the COP, and the first variable-length data frame also carries first data, the first data containing first information for displaying to passengers in the elevator car; The COP receives and independently parses variable-length data frames from the elevator master control and performs corresponding operations, including: The COP receives and parses the first variable-length data frame forwarded by the elevator master control, and determines the target device to which the first variable-length data frame is to be sent as the COP based on the destination address in the first variable-length data frame. The first data is extracted from the first variable-length data frame, and based on the first data, the display module inside the elevator car is controlled to display the first information.

[0008] In some exemplary embodiments, the variable-length data frame sent from the cloud includes a second variable-length data frame, wherein the destination address in the second variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the COP, and the second variable-length data frame also carries second data, the second data including second information for voice output to passengers inside the elevator car: The receiving and independent parsing of variable-length data frames from the elevator main control and the execution of corresponding operations include: The COP receives and parses the second variable-length data frame forwarded by the elevator master control, and determines the target device to which the second variable-length data frame is to be sent as the COP based on the destination address in the second variable-length data frame. The second data is extracted from the second variable-length data frame, and based on the second data, the voice module inside the elevator car is controlled to output the second information via voice.

[0009] In some exemplary embodiments, the cloud-based transmission of variable-length data frames is implemented in the following ways: The cloud generates the variable-length data frame based on the content of the to-do items set by the terminal, and sends the variable-length data frame to the gateway when the planned execution time of the to-do items arrives; wherein, the to-do items include the content of the items and the planned execution time.

[0010] In some exemplary embodiments, the variable-length data frame generated by the COP includes a third variable-length data frame, wherein the destination address in the third variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the cloud, and the third variable-length data frame also carries third data, wherein the third data includes at least one of the following: third information for reporting COP faults to the cloud, fourth information for initiating a query request to a machine learning model on the cloud, and fifth information for enabling the cloud to control smart home devices.

[0011] In some exemplary embodiments, the variable-length data frames are transmitted between the COP and the elevator main control, and between the elevator main control and the gateway, using the VLFTP protocol; the variable-length data frame of the VLFTP protocol includes: a frame type field, a service type field, a data length field, and a data field, wherein the data field is a field with a variable length; The frame type field is used to indicate the purpose of the variable-length data frame; The service type field is used to indicate the service type of the service data in the variable-length data frame when the frame type field indicates that the purpose of the variable-length data frame is service; The data length field is used to indicate the length of the business data in the variable-length data frame; The data field is used to carry the business data in the variable-length data frame.

[0012] In some exemplary embodiments, the gateway and the cloud transmit the variable-length data frames using the HTTP protocol or the MQTT protocol; The gateway is also configured to: When a variable-length data frame is received from the cloud, the format of the variable-length data frame is converted into the variable-length data frame format of the VLFTP protocol; when a variable-length data frame is received from the elevator main control, the format of the variable-length data frame is converted into the variable-length data frame format of the HTTP protocol or the MQTT protocol. When a communication link with the cloud is detected to be disconnected, a network disconnection caching mechanism is activated to temporarily store the variable-length data frames to be transmitted in the local cache, and take over some cloud services locally to respond to the COP request. Data synchronization will be performed after the communication link is restored.

[0013] An embodiment of the second aspect of this application provides a service decoupling data transmission method, applied to any of the service decoupling data transmission architectures described above, the method comprising: The gateway forwards variable-length data frames from the cloud to the elevator main control, and the destination address in the variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the COP; After receiving the variable-length data frame, the elevator main controller only performs integrity verification and obtains the destination address in the variable-length data frame. When it is determined that the object corresponding to the destination address is the COP, the controller does not parse the business data and directly forwards the variable-length data frame to the COP. The COP receives and independently parses variable-length data frames from the elevator main control and performs corresponding operations; And / or, COP generates variable-length data frames and sends them to the elevator main control. The destination address in the variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is a cloud device. After receiving the variable-length data frame, the elevator main controller only performs integrity verification and obtains the destination address in the variable-length data frame. When it is determined that the object corresponding to the destination address is the cloud, it does not parse the business data in the variable-length data frame, but forwards the variable-length data frame to the gateway. The gateway transmits the variable-length data frame to the cloud.

[0014] An embodiment of the third aspect of this application provides an elevator master control that can communicate with a gateway and a COP, including: a first memory and a first processor, wherein the first memory is configured to store an executable program; The first processor is configured to read and execute the executable program, performing the following steps: When a variable-length data frame is received from the gateway, the system performs integrity verification and extracts the destination address of the variable-length data frame. If the system determines that the target device to which the variable-length data frame is to be sent is not the elevator main control based on the destination address in the variable-length data frame, the system does not parse the service data in the variable-length data frame and directly forwards the variable-length data frame to the COP based on the destination address. Upon receiving a variable-length data frame from the COP, the system performs integrity verification on the variable-length data frame and extracts the destination address. If, based on the destination address in the variable-length data frame, it determines that the target device to which the variable-length data frame is to be sent is not the elevator main control unit, the system does not parse the service data in the variable-length data frame and directly forwards the variable-length data frame to the gateway based on the destination address.

[0015] An embodiment of the fourth aspect of this application provides an elevator car operation panel (COP), including: a second memory and a second processor, wherein the second memory is configured to store an executable program; The second processor is configured to read and execute the executable program, performing the following steps: The system receives and independently parses variable-length data frames from the elevator master control and performs corresponding operations. The variable-length data frames from the elevator master control are received from the gateway. The elevator master control only performs integrity verification on the variable-length data frames and extracts the destination address. When it determines that the object corresponding to the destination address is a COP, it does not parse the business data in the variable-length data frames and directly forwards the variable-length data frames. The system generates a data frame and sends it to the elevator main control unit. Upon receiving the variable-length data frame, the elevator main control unit performs only integrity verification and obtains the destination address in the variable-length data frame. When it determines that the object corresponding to the destination address is the cloud, it does not parse the business data in the variable-length data frame and forwards the variable-length data frame to the gateway.

[0016] Compared with related technologies, the service decoupled data transmission architecture, method, and device provided in this disclosure, upon receiving a variable-length data frame from the gateway or the COP, only performs integrity verification on the variable-length data frame and extracts the destination address. If, based on the destination address in the variable-length data frame, it is determined that the target device to which the variable-length data frame is to be sent is not the elevator master control, the service data in the variable-length data frame is not parsed; instead, the variable-length data frame is directly forwarded to the COP or the gateway based on the destination address. Simultaneously, the COP possesses independent data reception, parsing, and execution capabilities. It can receive, parse, and execute corresponding operations on variable-length data frames issued by the elevator master control, and can also autonomously generate variable-length data frames and send them through the elevator master control. Therefore, the elevator master control only undertakes address determination and forwarding functions, while the data parsing and service processing tasks unrelated to itself are offloaded to the COP, significantly reducing the computational load on the elevator master control. This allows it to concentrate more computing resources on the real-time elevator control task, thereby improving the response speed and operational reliability of the real-time elevator control task.

[0017] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0018] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0019] Figure 1 This is a schematic diagram of a service decoupling data transmission architecture according to an embodiment of the present disclosure; Figure 2 This is a flowchart illustrating a service decoupling data transmission method according to an embodiment of the present disclosure; Figure 3 This is a flowchart illustrating another service decoupling data transmission method according to an embodiment of this disclosure. Detailed Implementation

[0020] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0021] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0022] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that the method or process does not depend on the specific order of steps described herein. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims relating to the method and / or process should not be limited to the steps performed in the order written, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments disclosed herein.

[0023] This disclosure provides a service decoupled data transmission architecture applied to an elevator control system, such as... Figure 1 As shown, it includes: cloud 11, gateway 12, elevator main control 13 and COP 14; The cloud 11 is configured to send data frames to the gateway 12 and receive data frames from the gateway 12. The gateway 12 is configured to perform protocol conversion, transparent transmission, or forwarding of variable-length data frames between the cloud 11 and the elevator main control 13. The elevator master controller 13 is configured to, upon receiving a variable-length data frame from the gateway 12 or the COP 14, only perform integrity verification on the variable-length data frame and extract the destination address. If it is determined based on the destination address in the variable-length data frame that the target device to which the variable-length data frame is to be sent is not the elevator master controller 13, the elevator master controller 13 will not parse the service data in the variable-length data frame and will directly forward the variable-length data frame to the COP 14 or the gateway 12 based on the destination address. The COP 14 is configured to receive and independently parse variable-length data frames from the elevator main control 13 and perform corresponding operations, and is also configured to generate data frames and send them to the elevator main control 13.

[0024] For example, the cloud acts as the remote data hub of the entire business decoupled data transmission architecture, responsible for bidirectional data interaction with the elevator's local network. In the downlink direction, the cloud can send various types of variable-length data frames to the gateway, such as remote call commands (e.g., users calling the elevator to a specific floor in advance via a mobile app), advertising information or announcements (e.g., building management pushing notifications to the car's display screen via the cloud), floor registration policy updates (e.g., dynamically adjusting elevator scheduling algorithms during peak hours based on building passenger flow patterns), and firmware or software remote upgrade packages. In the uplink direction, the cloud receives variable-length data frames uploaded from the gateway, such as elevator operating status information (e.g., current floor, direction of travel, load weight, door open / close status), fault alarm information (e.g., door operator malfunction, traction machine overheating, safety circuit triggering), passenger flow statistics, and energy consumption data.

[0025] For example, the cloud can be deployed in a public cloud, private cloud, or hybrid cloud environment, and can interact with the gateway via IoT communication protocols such as MQTT, HTTP, and CoAP. In addition, the cloud can also integrate machine learning models or big data analysis modules to make intelligent decisions on elevator maintenance cycles, fault prediction, and energy consumption optimization based on historical operating data, and send the decision results to the elevator main control or COP for execution via variable-length data frames through the gateway.

[0026] For example, the gateway is deployed between the cloud and the elevator's local network, undertaking the function of transparent transmission or forwarding of variable-length data frames, and establishing a communication bridge between the cloud and the elevator's local network. Specifically, the gateway receives variable-length data frames from the cloud in the downlink direction and forwards them to the elevator's main control; in the uplink direction, the gateway receives variable-length data frames from the elevator's main control and forwards them to the cloud.

[0027] For example, during the transparent transmission process, the gateway can perform protocol conversion on variable-length data frames as needed, such as converting the MQTT protocol used on the cloud side to industrial communication protocols such as Modbus, CAN bus, or VLFTP used on the elevator local network side, thereby achieving interconnection and interoperability between different communication protocols.

[0028] In addition, the gateway can also have a data caching function. When the communication link between the cloud and the elevator's local network is briefly interrupted, the gateway can temporarily store the variable-length data frames to be transmitted in the local cache and forward them after the communication link is restored, thereby ensuring the reliability and integrity of data transmission.

[0029] In other exemplary instances, the gateway can perform certain security gateway functions, such as authenticating, encrypting and decrypting, and verifying access permissions for variable-length data frames from the cloud, in order to prevent unauthorized commands from being injected into the elevator control system and ensure the safe operation of the elevator.

[0030] For example, the elevator master controller, as the core control node of the elevator local network, undertakes the dual responsibilities of real-time elevator operation control and variable-length data frame routing and forwarding. In terms of real-time operation control, the elevator master controller is responsible for executing the core safety and control logic of the elevator, such as making elevator scheduling decisions based on the floor selection signals inside the car and the call signals outside the hall, controlling the start and stop of the traction machine, monitoring the status of the safety circuit, and executing door interlock protection. These tasks have extremely high real-time requirements, and any delay may lead to abnormal elevator operation or even safety accidents.

[0031] For example, in variable-length data frame routing and forwarding, after receiving a variable-length data frame from the gateway or COP, the elevator master controller needs to perform data integrity verification on the variable-length data frame to ensure that the variable-length data frame to be forwarded has not been erroneous or tampered with during transmission. Then, it parses the destination address field in the header of the variable-length data frame to determine whether the target device of the variable-length data frame is the elevator master controller itself. If the target device is the elevator master controller itself, the elevator master controller performs complete parsing and processing of the variable-length data frame, such as receiving floor registration policy update instructions from the cloud and adjusting the scheduling algorithm accordingly. If the target device is not the elevator master controller (e.g., the destination address points to the COP or gateway), the elevator master controller does not parse the payload of the variable-length data frame, but directly forwards it to the corresponding COP or gateway based on the destination address. This "address-first, forward-on-demand" mechanism allows the elevator master controller to avoid performing deep parsing and business processing on every variable-length data frame passing through it, thereby concentrating limited computing resources on the core elevator control tasks with higher real-time requirements.

[0032] For example, the COP, as an intelligent terminal device within the elevator car, possesses independent data reception, parsing, and execution capabilities. Within the elevator's local network, it undertakes business processing responsibilities for passenger interaction and data communication with external systems. Regarding passenger interaction, the COP receives floor selection commands and door opening / closing commands input by passengers via physical buttons or a touchscreen, encapsulates these commands into variable-length data frames, and sends them to the elevator master control for scheduling and processing. For data communication with external systems, the COP can both receive, parse, and execute corresponding operations on variable-length data frames sent by the elevator master control, and can also autonomously generate variable-length data frames and send them via the elevator master control. For instance, when the COP needs to report passenger flow data collected by cameras inside the car to the cloud, the COP autonomously generates a variable-length data frame containing this data and sends it to the elevator master control. The elevator master control then forwards it to the gateway based on the destination address, and the gateway uploads it to the cloud.

[0033] By giving COP independent data processing capabilities, a large number of data interaction tasks that originally required the elevator main control to perform in-depth analysis and business processing are offloaded to the COP side. The elevator main control only needs to undertake the light work of address determination and frame forwarding, which significantly reduces the computational load of the elevator main control, allowing it to concentrate more computing resources on elevator real-time control tasks, thereby improving the response speed and operational reliability of elevator real-time control tasks.

[0034] The service decoupled data transmission architecture provided in this disclosure, upon receiving a variable-length data frame from the gateway or the COP, only performs integrity verification and extracts the destination address from the variable-length data frame. If, based on the destination address in the variable-length data frame, it determines that the target device to which the variable-length data frame is to be sent is not the elevator master control, it does not parse the service data in the variable-length data frame, but directly forwards the variable-length data frame to the COP or the gateway based on the destination address. Simultaneously, the COP possesses independent data receiving, parsing, and execution capabilities. It can receive, parse, and execute corresponding operations on variable-length data frames issued by the elevator master control, and can also autonomously generate variable-length data frames and send them through the elevator master control. Therefore, the elevator master control only undertakes address determination and forwarding functions, while offloading data parsing and service processing tasks unrelated to itself to the COP side. This significantly reduces the computational load on the elevator master control, allowing it to concentrate more computing resources on real-time elevator control tasks, thereby improving the response speed and operational reliability of the real-time elevator control tasks.

[0035] In one exemplary instance, the elevator master controller is further configured to: Before forwarding the variable-length data frame to the COP or the gateway according to the destination address, extract the checksum field in the variable-length data frame and perform CRC data integrity verification. After the CRC data integrity check passes, the variable-length data frame is forwarded to the COP or the gateway according to the destination address. If the CRC data integrity check fails, it is determined that the variable-length data frame was damaged during transmission. The elevator master controller directly discards the variable-length data frame and does not perform a forwarding operation to prevent the damaged data from interfering with the elevator's local control network.

[0036] For example, after receiving a variable-length data frame from the gateway or COP, the elevator master controller first extracts the verification information carried in the variable-length data frame. This verification information can be a Cyclic Redundancy Check (CRC), a checksum, or a Message Authentication Code (MAC), etc. Then, the elevator master controller recalculates the checksum based on the payload portion of the variable-length data frame excluding the verification information and compares the recalculated checksum with the verification information carried in the variable-length data frame. If they match, the integrity check of the variable-length data frame is deemed successful, indicating that no bit errors or data tampering occurred during transmission, and the elevator master controller can continue to forward the variable-length data frame to the COP or gateway according to the destination address. If they do not match, the integrity check of the variable-length data frame is deemed unsuccessful, indicating that bit errors or illegal tampering may have occurred during transmission. In this case, the elevator master controller will discard the variable-length data frame and not forward it to prevent damaged data from interfering with the elevator's local control network, such as erroneous data or illegal commands being transmitted to downstream devices.

[0037] For example, the aforementioned integrity verification mechanism can form a data quality checkpoint in the elevator main control's forwarding process, effectively preventing the erroneous propagation of variable-length data frames due to communication link interference, electromagnetic noise, or malicious attacks. In the elevator operating environment, the electromagnetic environment within the shaft is complex. High-power electrical equipment such as traction machines and frequency converters generate strong electromagnetic interference during operation, which may cause bit flips or data loss in variable-length data frames during transmission. By setting up integrity verification on the elevator main control side, damaged variable-length data frames can be detected and intercepted in time before they enter the next hop of the elevator's local network, preventing erroneous data from being parsed and executed by COP or transmitted back to the cloud via the gateway, thereby ensuring the reliability and security of the entire data transmission link. Furthermore, the calculation and comparison process of integrity verification is lightweight and will not impose a significant additional computational burden on the elevator main control.

[0038] In one exemplary instance, the variable-length data frame sent from the cloud includes a first variable-length data frame, the destination address in which the variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the COP, and the first variable-length data frame also carries first data, the first data containing first information for displaying to passengers in the elevator car. The COP receives and independently parses variable-length data frames from the elevator master control and performs corresponding operations, including: The COP receives and parses the first variable-length data frame forwarded by the elevator master control, and determines the target device to which the first variable-length data frame is to be sent as the COP based on the destination address in the first variable-length data frame. The first data is extracted from the first variable-length data frame, and based on the first data, the display module inside the elevator car is controlled to display the first information.

[0039] For example, the cloud can send various types of variable-length data frames to the elevator's local network in the downlink direction, including a first variable-length data frame. The destination address in this first variable-length data frame is set to indicate that the target device to which the variable-length data frame is to be sent is COP. This means that the variable-length data frame is not parsed and processed by the elevator master control, but needs to be forwarded to the COP for processing by the elevator master control. The first variable-length data frame also carries first data, which contains first information to be displayed to passengers inside the elevator car. The specific content of this first information can be flexibly configured according to the actual application scenario. For example, it can be announcements and notices issued by building management (such as water and power outage reminders, fire drill notices, etc.), commercial advertising content (such as promotional information from nearby merchants, brand promotional videos, etc.), elevator operation status prompts (such as current floor, estimated arrival time, direction of travel, etc.), safety reminders (such as overload reminders, civilized elevator riding tips, etc.), or convenient service content such as holiday greetings and weather information. The first data can be in the form of multimedia data such as text, images, or videos, depending on the display capabilities of the display module inside the elevator car and the business requirements.

[0040] For example, after the first variable-length data frame arrives at the elevator's local network, it is first received by the elevator master controller. The elevator master controller reads the destination address in the variable-length data frame and determines that the target device of the variable-length data frame is the COP rather than the elevator master controller itself. Therefore, the elevator master controller does not parse the first data carried in the variable-length data frame, but directly forwards the first variable-length data frame to the COP according to the destination address. In this process, the elevator master controller only undertakes the lightweight work of address determination and frame forwarding, without consuming computing resources to decode, render, or process business logic for the first data, thus ensuring that the elevator master controller can concentrate more computing resources on the real-time control tasks of the elevator.

[0041] For example, after receiving the first variable-length data frame forwarded by the elevator master control, the COP first determines the target device to which the variable-length data frame is to be sent based on the destination address in the variable-length data frame, confirming itself as the final recipient of the variable-length data frame. Subsequently, the COP extracts the first data from the first variable-length data frame and performs parsing processing on the first data.

[0042] For example, COP can perform corresponding decoding operations based on the type and format of the first data, such as character encoding parsing for text data, image decoding for image data, and video stream decoding for video data. After parsing, COP outputs the parsed first information to the display module inside the elevator car for display. This display module can be a liquid crystal display (LCD), organic light-emitting diode display (OLED), LED dot matrix screen, or projection device embedded in the inner wall of the car, etc., and the specific form can be selected according to the car design requirements.

[0043] Through the above process, display information sent from the cloud can be transmitted collaboratively by the gateway, elevator main control, and COP, and finally displayed on the display module inside the elevator car, realizing the information push function for passengers. However, throughout the entire data flow, the elevator main control does not parse or process the initial data; it only performs the lightweight tasks of destination address determination and frame forwarding.

[0044] In one exemplary instance, the variable-length data frame sent from the cloud includes a second variable-length data frame. The destination address in the second variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the COP. The second variable-length data frame also carries second data, which includes second information for voice output to passengers inside the elevator car. The receiving and independent parsing of variable-length data frames from the elevator main control and the execution of corresponding operations include: The COP receives and parses the second variable-length data frame forwarded by the elevator master control, and determines the target device to which the second variable-length data frame is to be sent as the COP based on the destination address in the second variable-length data frame. The second data is extracted from the second variable-length data frame, and based on the second data, the voice module inside the elevator car is controlled to output the second information via voice.

[0045] For example, the cloud can send various types of variable-length data frames to the elevator's local network in the downlink direction, including a second variable-length data frame. The destination address in this second variable-length data frame is set to indicate that the target device to which the variable-length data frame is to be sent is the COP (Content Optimizer), meaning that the final processor of the variable-length data frame is not the elevator master control, but rather it needs to be forwarded by the elevator master control to the COP for processing. The second variable-length data frame also carries second data, which includes second information for providing voice output to passengers inside the elevator car. The specific content of this second information can be flexibly configured according to the actual application scenario. For example, it can be voice broadcasts of elevator operation status (such as "The elevator is about to arrive at the 5th floor" or "The elevator is going up, please pay attention to safety"), safety reminder voices (such as "Do not lean against the elevator door" or "Overload alarm, please have some passengers exit"), welcome messages or greetings (such as "Welcome to this elevator" or "Have a pleasant ride"), building notification voices (such as "This elevator will undergo routine maintenance at 2 PM and will be out of service at that time"), or emergency voice prompts triggered in special scenarios (such as evacuation guidance voices during fire alarms or reassuring voices when people are trapped in the elevator). The second data can be in the form of pre-recorded audio files (such as MP3, WAV, AAC, etc.), text-to-speech (TTS) synthesis instructions (which carry the text content to be broadcast and speech synthesis parameters, and the COP completes the speech synthesis locally), or a combination of both.

[0046] For example, after the second variable-length data frame arrives at the elevator's local network, it is first received by the elevator master controller. The elevator master controller reads the destination address in the variable-length data frame and determines that the target device of the variable-length data frame is the COP rather than the elevator master controller itself. Therefore, the elevator master controller does not parse the second data carried in the variable-length data frame, but directly forwards the second variable-length data frame to the COP according to the destination address. In this process, the elevator master controller only undertakes the lightweight work of address determination and frame forwarding, without consuming computing resources to perform audio decoding, voice synthesis, or playback control of the second data, thus ensuring that the elevator master controller can concentrate more computing resources on real-time elevator control tasks.

[0047] For example, after receiving the second variable-length data frame forwarded by the elevator master control, the COP first determines the target device to which the variable-length data frame is to be sent, based on the destination address in the data frame, confirming itself as the final recipient of the data frame. Subsequently, the COP extracts the second data from the second variable-length data frame and parses it. Specifically, when the second data is a pre-recorded audio file, the COP decodes the audio file to restore a playable audio signal; when the second data is a TTS (Text-to-Speech) synthesis instruction, the COP calls the built-in or external speech synthesis engine to synthesize a speech signal in real time based on the text content and speech parameters (such as speech rate, pitch, and timbre) in the instruction. After parsing or synthesis, the COP outputs the obtained audio signal to the voice module inside the elevator car for playback. This voice module can be a speaker embedded in the car wall, a ceiling speaker, or a directional sound source device, the specific form of which can be selected according to the acoustic design requirements of the car.

[0048] In one exemplary instance, the cloud-based transmission of variable-length data frames is achieved in the following manner: The cloud generates the variable-length data frame based on the content of the to-do items set by the terminal, and sends the variable-length data frame to the gateway when the scheduled execution time of the to-do items arrives; wherein, the to-do items include the content of the items and the scheduled execution time.

[0049] For example, the cloud-based transmission of variable-length data frames is achieved in the following way: the cloud generates the variable-length data frame according to the content of the to-do items set by the terminal, and sends the variable-length data frame to the gateway when the planned execution time of the to-do items arrives; wherein, the to-do items include the content of the items and the planned execution time.

[0050] Specifically, there are two ways to retrieve to-do items from the cloud. The first method is for the cloud to read existing to-do items on the terminal: Users can authorize the cloud to read existing to-do items on their terminals. These to-do items can be pre-created by the user through the terminal's built-in calendar, memo, to-do list, or other third-party schedule management applications. After obtaining user authorization, the terminal extracts the item content and planned execution time from the locally stored to-do items, encapsulates it into a terminal command, and sends it to the cloud. The second method is for users to actively upload to-do items to the cloud: Users can manually create a new to-do item on the terminal through the cloud-supported client application or web management backend, fill in the item content, set the planned execution time, and trigger the sending of a terminal command after confirmation. The terminal then encapsulates the item content and planned execution time into a terminal command and uploads it to the cloud.

[0051] After receiving instructions from the terminal, the cloud parses them, extracts the task content and planned execution time, and generates a corresponding to-do record, storing it in the cloud's local task database. Simultaneously, it generates a corresponding variable-length data frame based on the task content. The task content defines the specific information to be displayed or broadcast to passengers in the elevator car (e.g., "This elevator will undergo routine maintenance at 3 PM and will be temporarily out of service"). The planned execution time defines the target time when this information is expected to be displayed or broadcast (e.g., "August 12, 2026, 14:55," meaning a push notification 5 minutes in advance so passengers are aware). The cloud does not immediately send the variable-length data frame to the gateway after generation; instead, it temporarily stores it in the cloud's local task queue, waiting for the planned execution time. When the planned execution time arrives, the cloud automatically sends the temporarily stored variable-length data frame to the gateway, which then forwards it to the elevator master controller or COP in the elevator's local network.

[0052] Through the aforementioned scheduled task mechanism, the cloud can accurately and timely distribute variable-length data frames, thereby meeting the needs of various scheduled information pushes in elevator scenarios. For example, property management personnel can set a to-do item in the morning via a terminal, with the content "A fire drill will be conducted from 2 PM to 4 PM. During this time, the elevator will be out of service. Please use the stairs," and the scheduled execution time is set to "1:55 PM." After receiving this instruction, the cloud generates a variable-length data frame containing the above content and temporarily stores it in the task queue. When 1:55 PM arrives, the cloud automatically sends the variable-length data frame to the gateway, which forwards it to the COP via the elevator main control, and finally displays the notification on the display module in the elevator car or broadcasts it in the voice module. This scheduled distribution mechanism allows users to plan and set up in advance, rather than waiting for the information to be displayed, so that the cloud can automatically distribute the variable-length data frame at the specified time. This improves usability and avoids the problem of information push delays caused by human forgetfulness or untimely operation.

[0053] For example, a communication connection can be established between the terminal and the cloud via mobile Internet (such as 4G / 5G network) or wired network (such as Ethernet), and data can be exchanged using application layer protocols such as HTTP / HTTPS, MQTT, and WebSocket.

[0054] In one exemplary instance, the variable-length data frame generated by the COP includes a third variable-length data frame, the destination address in which the variable-length data frame is sent indicates that the target device to which the variable-length data frame is to be sent is the cloud, the third variable-length data frame also carries third data, the third data including at least one of the following: third information for reporting COP faults to the cloud, fourth information for initiating a query request to a machine learning model on the cloud, and fifth information for enabling the cloud to control smart home devices.

[0055] For example, the third information is used by the COP to report faults or abnormal states detected during its operation to the cloud. Specifically, during operation, the COP can continuously perform self-checks on its various functional modules (such as the display screen, voice module, button panel, communication interface, power module, etc.). When an abnormality is detected in a certain module, the COP generates third data containing fault information and encapsulates it into a third variable-length data frame. The fault information may include fields such as fault type (e.g., black screen, silent voice module, communication link interruption, button malfunction, etc.), fault occurrence time, fault duration, and fault severity level.

[0056] After receiving the third variable-length data frame, the cloud can generate a maintenance work order to notify maintenance personnel to promptly investigate and repair the fault, thereby shortening the fault response time and ensuring the normal operation of the human-machine interaction equipment in the elevator car.

[0057] For example, when a query request is initiated by the COP itself, the COP autonomously detects during operation that an intelligent task requires the assistance of a cloud-based machine learning model. It then automatically encapsulates the input data to be reasoned into a fourth piece of information and sends it to the cloud as a third variable-length data frame. Specific application scenarios include: With authorization from a passenger's facial image, the COP collects the passenger's image through a camera inside the elevator car, encapsulates the image feature data as input in the fourth piece of information, and requests the cloud-based facial recognition model to perform identity verification, so as to provide authorized passengers with personalized floor recommendations or welcome announcements; another example is that the COP sends environmental data inside the elevator car (such as temperature, humidity, light intensity, etc.) to the cloud, requesting the cloud-based intelligent adjustment model to return the optimal environmental control strategy; yet another example is that when the COP detects that the passenger density inside the elevator car exceeds a preset threshold, it sends the current passenger flow data to the cloud, requesting the cloud-based passenger flow prediction model to determine whether congestion will occur in the near future, so as to adjust the elevator scheduling strategy in advance.

[0058] For example, when a query request is indirectly initiated by a user through COP, the user asks a question or command in natural language form through the COP's voice module or touch screen inside the car. COP converts the user's voice or text input into a query request, generates fourth information, and encapsulates it into a third variable-length data frame to send to the cloud's large language model. The cloud's large language model generates an answer and returns it to COP. COP then presents the answer to the user through the voice module or display screen. Specific application scenarios include: During an elevator ride, a user might use the COP's voice module to ask, "What's the weather like today?" or "Can you find some good restaurants nearby?" The COP converts the user's voice input into text, generates a fourth piece of information, encapsulates it into a variable-length data frame, and sends it to the cloud-based large language model. The cloud-based large language model generates an answer and returns it to the COP, which then reads the answer aloud via the voice module or displays it on the screen. Alternatively, a user might input "Can you find out how to pay the property management fees for Building 3?" through the COP's touchscreen. The COP generates a fourth piece of information from this text, encapsulates it into a variable-length data frame, and sends it to the cloud. The cloud-based large language model generates an answer based on a pre-built property management knowledge base and returns it to the user, which the COP then presents to the user. Through these methods, the COP acts as an interactive bridge between the user and the cloud-based large language model, allowing users to conveniently access information and services during fragmented elevator rides, thus improving the elevator experience.

[0059] For example, the fifth piece of information is used to enable cloud-based control of smart home devices associated with the building where the elevator is located. With the development of smart buildings and smart homes, the Control Point (COP) inside the elevator car can serve as an interaction point between the user and the building's smart devices. When a user triggers a specific control command on the COP (such as clicking the "Home Mode" button on a touchscreen or saying "Turn on the air conditioner"), the COP generates the fifth piece of information to enable cloud-based control of home devices and encapsulates it into a third variable-length data frame, which is then sent to the cloud. Upon receiving the third variable-length data frame, the cloud parses it and, based on the target device identifier and operation type in the control command, sends control commands to the corresponding smart home devices (such as smart door locks, smart air conditioners, smart lighting, smart curtains, and smart robot vacuums) to achieve remote control.

[0060] It's important to note that the cloud's ability to determine which user and which set of home devices to control relies on the user's pre-completed identity registration and device binding process. Users must register an account on the cloud via a terminal (such as a mobile app) and bind their account to their home smart devices, establishing a "user account - home device" mapping relationship. When a user triggers "Home Mode" in the elevator, the COP (Content Optimization Program) includes the current user's identity identifier (such as facial recognition ID, IC card ID, or logged-in user account) in the fifth piece of information, encapsulated in a third variable-length data frame, and sent to the cloud. Upon receiving the third variable-length data frame, the cloud queries the corresponding home device mapping relationship based on the user's identity identifier to determine the user's bound smart home devices, and then sends control commands to the corresponding devices according to the operation type in the control instructions. For example, if user A triggers "Home Mode" via COP while taking the elevator home, the cloud, based on user A's identity identifier, queries the bound smart door lock, living room lights, air conditioner, and other devices, and then sends control commands such as unlocking, turning on lights, and adjusting temperature to these devices respectively, thus pre-setting the home environment before the user arrives home, enhancing the user's living experience.

[0061] In one exemplary instance, the variable-length data frames are transmitted between the COP and the elevator main control unit, and between the elevator main control unit and the gateway, using the VLFTP protocol. The variable-length data frames of the VLFTP protocol include: a frame type field, a service type field, a data length field, and a data field, wherein the data field is a field with a variable length. The frame type field is used to indicate the purpose of the variable-length data frame; The service type field is used to indicate the service type of the service data in the variable-length data frame when the frame type field indicates that the purpose of the variable-length data frame is service; The data length field is used to indicate the length of the business data in the variable-length data frame; The data field is used to carry the business data in the variable-length data frame.

[0062] For example, the COP and the elevator main control, as well as the elevator main control and the gateway, both use the Video and Lift File Transfer Protocol (VLFTP) to transmit variable-length data frames. VLFTP is a lightweight data transmission protocol designed for communication between devices in an elevator's local network. Its goal is to achieve efficient and reliable transmission of variable-length data frames between the COP and the elevator main control, and between the elevator main control and the gateway, in network environments with limited bandwidth and high real-time requirements within the elevator car. Using a unified VLFTP protocol allows the COP, elevator main control, and gateway to communicate using the same variable-length data frame format, simplifying protocol conversion complexity and reducing the risk of data loss or parsing errors due to protocol incompatibility.

[0063] For example, the variable-length data frame structure defined by the VLFTP protocol includes a frame type field, a service type field, a data length field, and a data field. The frame type field indicates the purpose of the variable-length data frame, that is, it identifies the type of communication to which the variable-length data frame belongs. For instance, the frame type field can distinguish whether the variable-length data frame is a service variable-length data frame, a heartbeat frame, an acknowledgment frame, or a control frame, etc., so that the receiver can know the function of the variable-length data frame based on this field.

[0064] The service type field is used to further indicate the specific service type of the service data carried in the variable-length data frame when the frame type field indicates that the variable-length data frame is a service variable-length data frame. For example, when the frame type field indicates that the variable-length data frame is a service variable-length data frame, the receiver further reads the service type field to determine what kind of service scenario the service data carried in the variable-length data frame belongs to, such as floor instruction data, status reporting data, fault alarm data, multimedia display data, user query request data, etc. Through the two-level classification mechanism of the frame type field and the service type field, the receiving device can quickly and accurately identify the category and specific service meaning of the variable-length data frame, thereby distributing the variable-length data frame to the corresponding processing module for subsequent processing, improving the parsing efficiency of the variable-length data frame and the modularity of the system.

[0065] For example, the data length field indicates the actual byte length of the business data carried by the data field in the variable-length data frame. Since the data field in the VLFTP protocol is a variable-length field, meaning the amount of business data carried by the data field may vary significantly in different business scenarios, the data length field can explicitly inform the receiver of the actual length of the business data in the variable-length data frame. This allows the receiver to accurately extract the complete business data from the variable-length data frame, avoiding data truncation or out-of-bounds reading issues. For instance, when the cloud sends an advertising image to the COP, the business type is "ad update," the data length field indicates 50000, and the data field carries approximately 50KB of image binary stream. After receiving the image, the COP determines the number of bytes to read based on the data length field, thus completely extracting the image data and storing it locally. Similarly, when the COP reports a fault log to the cloud, the business type is "log reporting." Since the log content varies in length depending on the fault condition, the data length field indicates the actual byte length of the log, and the data field carries the corresponding log text. After receiving the log, the cloud accurately parses the complete log content based on the data length field. The above scenario demonstrates that the existence of the data length field enables the VLFTP protocol to flexibly adapt to business data of different sizes, enhancing the protocol's versatility and scalability.

[0066] For example, the data field carries the business data in the variable-length data frame and is the part of the actual valid information transmitted in the variable-length data frame. As mentioned earlier, the data field is a field with a variable length, and its specific length is indicated by the data length field. The specific content of the business data carried in the data field depends on the business type indicated by the business type field: when the business type is floor instruction data, the data field carries the floor information input by the user through COP; when the business type is status reporting data, the data field carries the operating status information of COP or elevator master control; when the business type is fault alarm data, the data field carries alarm information such as fault type and fault time; when the business type is user query request data, the data field carries the user's query content (such as the aforementioned fourth information, fifth information, etc.). Through this variable-length data field design, the VLFTP protocol can support the data transmission of multiple business scenarios under the same frame format, taking into account both the simplicity and flexibility of the protocol.

[0067] For example, the variable-length data frame of the VLFTP protocol also includes a frame header field, a source address field, a checksum field, and a frame trailer field. The fields, lengths, and descriptions of the variable-length data frame of the VLFTP protocol can be shown in Table 1. Table 1 In one exemplary instance, the gateway and the cloud transmit the variable-length data frame using the HTTP protocol or the MQTT protocol; The gateway is also configured to: When a variable-length data frame is received from the cloud, the format of the variable-length data frame is converted into the variable-length data frame format of the VLFTP protocol; when a variable-length data frame is received from the elevator main control, the format of the variable-length data frame is converted into the variable-length data frame format of the HTTP protocol or the MQTT protocol. When a communication link with the cloud is detected to be disconnected, a network disconnection caching mechanism is activated to temporarily store the variable-length data frames to be transmitted in the local cache, and take over some cloud services locally to respond to the COP request. Data synchronization will be performed after the communication link is restored.

[0068] For example, the gateway and the cloud use either HTTP or MQTT protocols to transmit variable-length data frames. HTTP is a widely used stateless application layer protocol suitable for request-response communication scenarios. It offers advantages such as good compatibility and easy deployment, making it suitable for non-real-time data interaction between the gateway and the cloud (e.g., issuing to-do items, returning query results). MQTT is a lightweight publish / subscribe messaging protocol designed for low-bandwidth, high-latency, or unstable network environments. It features low message overhead, support for different message service quality levels, and support for persistent sessions, making it suitable for real-time data interaction between the gateway and the cloud (e.g., real-time reporting of fault alarms, immediate issuance of control commands). In practical applications, the choice between HTTP or MQTT can be made flexibly based on factors such as the real-time requirements of the business scenario, network conditions, and power consumption constraints, or both protocols can be used to adapt to different business needs.

[0069] For example, the gateway performs protocol conversion during the transmission of variable-length data frames to achieve interconnection between the VLFTP protocol used in the elevator's local network and the HTTP or MQTT protocol used in the wide area network. Specifically, when the gateway receives a variable-length data frame from the cloud, the frame is encapsulated in the format of the HTTP or MQTT protocol. The gateway first parses the frame to extract the service data, and then re-encapsulates the extracted service data into a VLFTP variable-length data frame according to the VLFTP protocol's frame format specification. This involves filling in the frame type field, service type field, data length field, and data field according to the VLFTP variable-length data frame structure. The encapsulated VLFTP variable-length data frame is then sent to the elevator master control via the elevator's local network, and the master control forwards it to the COP or other target devices. Through this protocol conversion process, the cloud does not need to be aware of the VLFTP protocol used in the elevator's local network; it only needs to send variable-length data frames in the format of the HTTP or MQTT protocol, reducing the coupling between the cloud and the elevator equipment.

[0070] For example, when the gateway receives a variable-length data frame from the elevator master control, the variable-length data frame is encapsulated in the VLFTP protocol format. The gateway first parses the variable-length data frame to extract the business data. Then, according to the current communication protocol used between the gateway and the cloud, the extracted business data is re-encapsulated into a variable-length data frame in the HTTP protocol format or MQTT protocol format. Finally, the encapsulated variable-length data frame is sent to the cloud via the mobile Internet or wired network. For example, when the COP detects a fault in its own module, it generates third data containing fault information and encapsulates it into a variable-length data frame in VLFTP protocol format. This data frame is forwarded to the gateway via the elevator master control. The gateway parses the variable-length data frame, extracts the fault information, encapsulates it into a variable-length data frame in MQTT protocol format, and sends it to the cloud. The cloud then generates a maintenance work order based on this. Similarly, when a user triggers a home control command on the COP, it generates fifth information containing the control command and encapsulates it into a variable-length data frame in VLFTP protocol format. This data frame is forwarded to the gateway via the elevator master control. The gateway parses the variable-length data frame, extracts the control command, encapsulates it into a variable-length data frame in HTTP protocol format, and sends it to the cloud. The cloud then sends control commands to the corresponding smart home devices based on this. Through the gateway's protocol conversion function, the COP and elevator master control in the elevator's local network do not need to be aware of the communication protocol used in the wide area network; they only need to send variable-length data frames in VLFTP protocol format, simplifying design and implementation.

[0071] For example, the gateway also possesses network outage caching and local takeover capabilities to ensure continuous system operation when the communication link is abnormal. When the gateway detects a disconnection in the communication link with the cloud through a heartbeat timeout or connection status detection mechanism, it immediately activates the network outage caching mechanism: On the one hand, it temporarily stores the variable-length data frames to be transmitted in the local cache according to their arrival order. The local cache can adopt a first-in-first-out queue management, and each frame is marked with a sequence number and timestamp. When the cache occupancy reaches a preset threshold, the earliest temporarily stored variable-length data frame is overwritten or the reception of new frames is stopped to prevent storage overflow. On the other hand, the gateway takes over some services originally provided by the cloud locally to respond to the COP request, including but not limited to responding to query requests locally, caching control commands to be issued, and maintaining the basic business closed loop within the elevator's local network. After the communication link is restored, the gateway retransmits the variable-length data frames in the local cache to the cloud in order according to the sequence number and timestamp, and performs data reconciliation with the cloud to ensure that the data is not lost, duplicated, and ordered; at the same time, the control commands temporarily stored during the network outage are executed or reported in order to complete the synchronization of local and cloud status. Through the aforementioned network outage caching and local takeover mechanisms, the elevator local network can still maintain basic operation even when the communication link is interrupted. The coupling between the cloud and the elevator local network is further reduced, and the system's reliability and autonomy are significantly improved.

[0072] The service decoupled data transmission architecture provided in this disclosure embodiment is further configured such that the cloud, gateway, elevator main control, and COP, when acting as data frame receivers, perform duplicate frame detection upon receiving the data frame and discard the data frame upon detecting a duplicate frame.

[0073] The service decoupled data transmission architecture provided in this embodiment is configured such that the cloud, the gateway, the elevator main control, and the COP are further configured to start a timeout retransmission timer after the data frame is sent. If no response frame is received from the COP before the timer expires, the data frame is retransmitted.

[0074] The business decoupled data transmission architecture provided in this disclosure can be applied to elevator control systems. This architecture adopts a layered design of "main control transparent transmission, gateway intelligence, and COP autonomy." The elevator main control only performs data transparent transmission and minimal parsing, implementing only frame header verification, address recognition, CRC verification, and simple read / write interfaces. For frames whose destination address is not the main control, they are directly forwarded; for frames whose destination address is the main control, only the data in the specified register area needs to be retrieved or written, without needing to understand the specific meaning of the business data. The gateway, as the intelligent core, handles all high-level protocol conversions (HTTP / MQTT↔VLFTP), data caching, and other processing, undertaking the responsibility of protocol adaptation and data relay between the cloud and the equipment inside the elevator car. The COP integrates intelligent capabilities, possessing modules for voice recognition, facial recognition, and touchscreen interaction. It can directly communicate with the gateway to complete functions such as floor selection and information query without the main control's involvement. The program running on the elevator main control system (hereinafter referred to as the main control program) is solidified. The main control program only needs to support the VLFTP basic version. Since the intelligent functions are all deployed on the gateway or COP, all subsequent upgrades of intelligent functions only involve software updates of the gateway or COP, without changing the main control program, thus eliminating the need for re-authentication of the elevator main control system.

[0075] To ensure the reliability of the communication link, an exemplary embodiment provides a service decoupled data transmission architecture with several enhancement measures. At the link level, the gateway, elevator main control unit, and COP employ a dual-bus (CAN + Ethernet) or primary / backup communication path, automatically switching to the backup link in case of a single link failure. At the transmission level, the sender starts a retransmission timer; if no acknowledgment frame is received, a retry is performed, up to a maximum of three retries. Each frame carries an incrementing sequence number; the receiver detects and discards duplicate frames to avoid data duplication. At the disaster recovery level, the gateway has network outage caching capabilities; when the cloud is unreachable, the local system can still serve COP requests, ensuring that basic functions within the elevator car are unaffected. At the operation and maintenance level, the elevator main control unit and COP periodically send heartbeat frames to the gateway, which uses these frames to detect the online status of each device and promptly identify and handle communication anomalies.

[0076] Compared with related technologies, the business decoupled data transmission architecture provided in this disclosure has the following technical effects: In terms of reducing dependence on the elevator main control system, the elevator main control system no longer carries intelligent business logic, but only performs reliable transparent transmission, significantly reducing the complexity of the main control program. In terms of reducing elevator main control system changes, all intelligent function iterations can be completed through software upgrades of the gateway or COP, avoiding frequent changes to the main control program and repeated authentication, saving a significant amount of time and cost. In terms of improving reliability, the elevator main control system failure rate is reduced, and the gateway and COP can form local autonomy; even if the cloud network is down or the elevator main control system experiences a brief anomaly, basic operations inside the car (such as floor selection and door opening) can still function normally. In terms of data carrying capacity, it supports the transmission of variable-length data and can carry complex business data such as images, voice, logs, and configuration files, providing a foundation for functions such as advertising push, remote upgrades, and fault diagnosis. In terms of communication efficiency, communication between the cloud and the COP can be relayed through the gateway; when passing through the elevator main control system, the elevator main control system only performs data integrity verification and does not participate in the processing of other business data, reducing processing latency.

[0077] This disclosure provides a service decoupling data transmission method, applicable to the service decoupling data transmission architecture described in any of the above embodiments, such as... Figure 2 As shown, the method includes: Step 201: The gateway forwards the variable-length data frame from the cloud to the elevator main control. The destination address in the variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is COP. Step 202: After receiving the variable-length data frame, the elevator main control only performs integrity verification and obtains the destination address in the variable-length data frame. When it is determined that the object corresponding to the destination address is the COP, the elevator main control does not parse the business data in the variable-length data frame, but directly forwards the variable-length data frame to the COP. Step 203: The COP receives and independently parses the variable-length data frame from the elevator master control and performs corresponding operations.

[0078] This disclosure also provides a service decoupling data transmission method, applied to the service decoupling data transmission architecture described in any of the above embodiments, such as... Figure 3 As shown, the method includes: Step 301: COP generates a variable-length data frame and sends it to the elevator main control. The destination address in the variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is a cloud device. Step 302: After receiving the variable-length data frame, the elevator main controller only performs integrity verification and obtains the destination address in the variable-length data frame. When it is determined that the object corresponding to the destination address is the cloud, the elevator main controller does not parse the business data in the variable-length data frame and forwards the variable-length data frame to the gateway. Step 303: The gateway transmits the variable-length data frame to the cloud.

[0079] In one exemplary instance, the method further includes: before forwarding the variable-length data frame to the COP or the gateway according to the destination address, the elevator master controller extracts the checksum field in the variable-length data frame and performs CRC data integrity verification; After the CRC data integrity check passes, the variable-length data frame is forwarded to the COP or the gateway according to the destination address. If the CRC data integrity check fails, it is determined that the variable-length data frame was damaged during transmission. The elevator master controller directly discards the variable-length data frame and does not perform a forwarding operation to prevent the damaged data from interfering with the elevator's local control network.

[0080] In one exemplary instance, the variable-length data frame sent from the cloud includes a first variable-length data frame, the destination address in which the variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the COP, and the first variable-length data frame also carries first data, the first data containing first information for displaying to passengers in the elevator car. The COP receives and independently parses variable-length data frames from the elevator master control and performs corresponding operations, including: The COP receives and parses the first variable-length data frame forwarded by the elevator master control, and determines the target device to which the first variable-length data frame is to be sent as the COP based on the destination address in the first variable-length data frame. The first data is extracted from the first variable-length data frame, and based on the first data, the display module inside the elevator car is controlled to display the first information.

[0081] In one exemplary instance, the variable-length data frame sent from the cloud includes a second variable-length data frame. The destination address in the second variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the COP. The second variable-length data frame also carries second data, which includes second information for voice output to passengers inside the elevator car. The receiving and independent parsing of variable-length data frames from the elevator main control and the execution of corresponding operations include: The COP receives and parses the second variable-length data frame forwarded by the elevator master control, and determines the target device to which the second variable-length data frame is to be sent as the COP based on the destination address in the second variable-length data frame. The second data is extracted from the second variable-length data frame, and based on the second data, the voice module inside the elevator car is controlled to output the second information via voice.

[0082] In one exemplary instance, the cloud-based transmission of variable-length data frames is achieved in the following manner: The cloud generates the variable-length data frame based on the content of the to-do items set by the terminal, and sends the variable-length data frame to the gateway when the planned execution time of the to-do items arrives; wherein, the to-do items include the content of the items and the planned execution time.

[0083] In one exemplary instance, the variable-length data frame generated by the COP includes a third variable-length data frame, the destination address in which the variable-length data frame is sent indicates that the target device to which the variable-length data frame is to be sent is the cloud, the third variable-length data frame also carries third data, the third data including at least one of the following: third information for reporting COP faults to the cloud, fourth information for initiating a query request to a machine learning model on the cloud, and fifth information for enabling the cloud to control smart home devices.

[0084] In one exemplary instance, the variable-length data frames are transmitted between the COP and the elevator main control unit, and between the elevator main control unit and the gateway, using the VLFTP protocol. The variable-length data frames of the VLFTP protocol include: a frame type field, a service type field, a data length field, and a data field, wherein the data field is a field with a variable length. The frame type field is used to indicate the purpose of the variable-length data frame; The service type field is used to indicate the service type of the service data in the variable-length data frame when the frame type field indicates that the purpose of the variable-length data frame is service; The data length field is used to indicate the length of the business data in the variable-length data frame; The data field is used to carry the business data in the variable-length data frame.

[0085] In one exemplary instance, the gateway and the cloud transmit the variable-length data frame using the HTTP protocol or the MQTT protocol; the method further includes: When a variable-length data frame is received from the cloud, the format of the variable-length data frame is converted into the variable-length data frame format of the VLFTP protocol; when a variable-length data frame is received from the elevator main control, the format of the variable-length data frame is converted into the variable-length data frame format of the HTTP protocol or the MQTT protocol. When a communication link with the cloud is detected to be disconnected, a network disconnection caching mechanism is activated to temporarily store the variable-length data frames to be transmitted in the local cache, and take over some cloud services locally to respond to the COP request. Data synchronization will be performed after the communication link is restored.

[0086] The decoupled data transmission method provided in this embodiment, upon receiving a variable-length data frame from the gateway or the COP, only performs integrity verification on the variable-length data frame and extracts the destination address. If, based on the destination address in the variable-length data frame, it is determined that the target device to which the variable-length data frame is to be sent is not the elevator master control, the service data in the variable-length data frame is not parsed; instead, the variable-length data frame is directly forwarded to the COP or the gateway based on the destination address. Simultaneously, the COP possesses independent data reception, parsing, and execution capabilities. It can receive, parse, and execute corresponding operations on variable-length data frames issued by the elevator master control, and can also autonomously generate variable-length data frames and send them through the elevator master control. Therefore, the elevator master control only undertakes address determination and forwarding functions, while data parsing and service processing tasks unrelated to itself are offloaded to the COP, significantly reducing the computational load on the elevator master control. This allows it to concentrate more computing resources on real-time elevator control tasks, thereby improving the response speed and operational reliability of the real-time elevator control tasks.

[0087] This disclosure provides an elevator master control system that can communicate with a gateway and a COP, including: a first memory and a first processor, wherein the first memory is configured to store an executable program; The first processor is configured to read and execute the executable program, performing the following steps: When a variable-length data frame is received from the gateway, the system performs integrity verification and extracts the destination address of the variable-length data frame. If the system determines that the target device to which the variable-length data frame is to be sent is not the elevator main control based on the destination address in the variable-length data frame, the system does not parse the service data in the variable-length data frame and directly forwards the variable-length data frame to the COP based on the destination address. Upon receiving a variable-length data frame from the COP, the system performs integrity verification on the variable-length data frame and extracts the destination address. If, based on the destination address in the variable-length data frame, it determines that the target device to which the variable-length data frame is to be sent is not the elevator main control unit, the system does not parse the service data in the variable-length data frame and directly forwards the variable-length data frame to the gateway based on the destination address.

[0088] In one exemplary instance, the first processor further performs the following steps: Before forwarding the variable-length data frame to the COP or the gateway according to the destination address, extract the checksum field in the variable-length data frame and perform CRC data integrity verification. After the CRC data integrity check passes, the variable-length data frame is forwarded to the COP or the gateway according to the destination address. If the CRC data integrity check fails, it is determined that the variable-length data frame was damaged during transmission. The elevator master controller directly discards the variable-length data frame and does not perform a forwarding operation to prevent the damaged data from interfering with the elevator's local control network.

[0089] This disclosure provides an elevator car control panel (COP), including: a second memory and a second processor, wherein the second memory is configured to store an executable program; The second processor is configured to read and execute the executable program, performing the following steps: The system receives and independently parses variable-length data frames from the elevator master control and performs corresponding operations. The variable-length data frames from the elevator master control are received from the gateway. The elevator master control only performs integrity verification on the variable-length data frames and extracts the destination address. When it determines that the object corresponding to the destination address is a COP, it does not parse the business data in the variable-length data frames and directly forwards the variable-length data frames. The system generates variable-length data frames and sends them to the elevator main control unit. Upon receiving the variable-length data frame, the elevator main control unit performs only integrity verification and obtains the destination address in the variable-length data frame. When it determines that the object corresponding to the destination address is the cloud, it does not parse the business data in the variable-length data frame and forwards the variable-length data frame to the gateway.

[0090] In one exemplary instance, the variable-length data frame sent from the cloud includes a first variable-length data frame, the destination address in which the variable-length data frame is sent indicates that the target device to which the variable-length data frame is to be sent is the COP, and the first variable-length data frame also carries first data, the first data containing first information for displaying to passengers inside the elevator car; the second processor is configured to read and execute the executable program, and further performs the following steps: The COP receives and parses the first variable-length data frame forwarded by the elevator master control, and determines the target device to which the first variable-length data frame is to be sent as the COP based on the destination address in the first variable-length data frame. The first data is extracted from the first variable-length data frame, and based on the first data, the display module inside the elevator car is controlled to display the first information.

[0091] In one exemplary instance, the variable-length data frame sent from the cloud includes a second variable-length data frame, the destination address in which the variable-length data frame is sent indicates that the target device to which the variable-length data frame is to be sent is the COP, and the second variable-length data frame also carries second data, the second data containing second information for voice output to passengers in the elevator car; the second processor is configured to read and execute the executable program, and further perform the following steps: The COP receives and parses the second variable-length data frame forwarded by the elevator master control, and determines the target device to which the second variable-length data frame is to be sent as the COP based on the destination address in the second variable-length data frame. The second data is extracted from the second variable-length data frame, and based on the second data, the voice module inside the elevator car is controlled to output the second information via voice.

[0092] In one exemplary instance, the variable-length data frame generated by the COP includes a third variable-length data frame, the destination address in which the variable-length data frame is sent indicates that the target device to which the variable-length data frame is to be sent is the cloud, the third variable-length data frame also carries third data, the third data including at least one of the following: third information for reporting COP faults to the cloud, fourth information for initiating a query request to a machine learning model on the cloud, and fifth information for enabling the cloud to control smart home devices.

[0093] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A business-decoupled data transmission architecture, applied to an elevator control system, characterized in that, include: Cloud, gateway, elevator main control, and in-car control panel (COP); The cloud is configured to send variable-length data frames to the gateway and receive variable-length data frames from the gateway. The gateway is configured to perform protocol conversion, transparent transmission, or forwarding of variable-length data frames between the cloud and the elevator main control. The elevator master controller is configured to, upon receiving a variable-length data frame from the gateway or the COP, only perform integrity verification on the variable-length data frame and extract the destination address. If it is determined based on the destination address in the variable-length data frame that the target device to which the variable-length data frame is to be sent is not the elevator master controller, it will not parse the service data in the variable-length data frame, but will directly forward the variable-length data frame to the COP or the gateway based on the destination address. The COP is configured to receive and independently parse variable-length data frames from the elevator main control and perform corresponding operations, and is also configured to generate variable-length data frames and send them to the elevator main control.

2. The business decoupling data transmission architecture according to claim 1, characterized in that, The elevator main control system is also configured to: Before forwarding the variable-length data frame to the COP or the gateway according to the destination address, extract the checksum field in the variable-length data frame and perform CRC data integrity verification. After the CRC data integrity check passes, the variable-length data frame is forwarded to the COP or the gateway according to the destination address. If the CRC data integrity check fails, it is determined that the variable-length data frame was damaged during transmission. The elevator master controller directly discards the variable-length data frame and does not perform a forwarding operation to prevent the damaged data from interfering with the elevator's local control network.

3. The business decoupling data transmission architecture according to claim 1, characterized in that, The variable-length data frame sent from the cloud includes a first variable-length data frame. The destination address in the first variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the COP. The first variable-length data frame also carries first data, which includes first information for displaying to passengers in the elevator car. The receiving and independent parsing of variable-length data frames from the elevator main control and the execution of corresponding operations include: The COP receives and parses the first variable-length data frame forwarded by the elevator master control, and determines the target device to which the first variable-length data frame is to be sent as the COP based on the destination address in the first variable-length data frame. The first data is extracted from the first variable-length data frame, and based on the first data, the display module inside the elevator car is controlled to display the first information.

4. The business decoupling data transmission architecture according to claim 1, characterized in that, The variable-length data frame sent from the cloud includes a second variable-length data frame. The destination address in the second variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the COP. The second variable-length data frame also carries second data, which includes second information for voice output to passengers inside the elevator car. The receiving and independent parsing of variable-length data frames from the elevator main control and the execution of corresponding operations include: The COP receives and parses the second variable-length data frame forwarded by the elevator master control, and determines the target device to which the second variable-length data frame is to be sent as the COP based on the destination address in the second variable-length data frame. The second data is extracted from the second variable-length data frame, and based on the second data, the voice module inside the elevator car is controlled to output the second information via voice.

5. The business decoupled data transmission architecture according to claim 3 or 4, characterized in that, The cloud-based transmission of variable-length data frames is achieved through the following methods: The cloud generates the variable-length data frame based on the content of the to-do items set by the terminal, and sends the variable-length data frame to the gateway when the planned execution time of the to-do items arrives; wherein, the to-do items include the content of the items and the planned execution time.

6. The business decoupling data transmission architecture according to claim 1, characterized in that, The variable-length data frame generated by COP includes a third variable-length data frame. The destination address in the third variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is the cloud. The third variable-length data frame also carries third data, which includes at least one of the following: third information for reporting COP faults to the cloud, fourth information for initiating a query request to the machine learning model on the cloud, and fifth information for enabling the cloud to control smart home devices.

7. The business decoupling data transmission architecture according to claim 1, characterized in that, The variable-length data frames are transmitted between the COP and the elevator main control, and between the elevator main control and the gateway, using the VLFTP protocol. The variable-length data frame of the VLFTP protocol includes: a frame type field, a service type field, a data length field, and a data field, wherein the data field is a field with a variable length. The frame type field is used to indicate the purpose of the variable-length data frame; The service type field is used to indicate the service type of the service data in the variable-length data frame when the frame type field indicates that the purpose of the variable-length data frame is service; The data length field is used to indicate the length of the business data in the variable-length data frame; The data field is used to carry the business data in the variable-length data frame.

8. The business decoupling data transmission architecture according to claim 7, characterized in that, The gateway and the cloud transmit the variable-length data frames using the HTTP or MQTT protocol. The gateway is also configured to: When a variable-length data frame is received from the cloud, the format of the variable-length data frame is converted into the variable-length data frame format of the VLFTP protocol; when a variable-length data frame is received from the elevator main control, the format of the variable-length data frame is converted into the variable-length data frame format of the HTTP protocol or the MQTT protocol. When a communication link with the cloud is detected to be disconnected, a network disconnection caching mechanism is activated to temporarily store the variable-length data frames to be transmitted in the local cache, and take over some cloud services locally to respond to the COP request. Data synchronization will be performed after the communication link is restored.

9. A service decoupling data transmission method, applied to the service decoupling data transmission architecture as described in any one of claims 1-8, characterized in that, The method includes: The gateway forwards variable-length data frames from the cloud to the elevator main control unit, and the destination address in the variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is COP; After receiving the variable-length data frame, the elevator main controller only performs integrity verification and obtains the destination address in the variable-length data frame. When it is determined that the object corresponding to the destination address is the COP, it does not parse the business data in the variable-length data frame, but directly forwards the variable-length data frame to the COP. The COP receives and independently parses variable-length data frames from the elevator main control and performs corresponding operations; And / or, COP generates variable-length data frames and sends them to the elevator main control. The destination address in the variable-length data frame indicates that the target device to which the variable-length data frame is to be sent is a cloud device. After receiving the variable-length data frame, the elevator main controller only performs integrity verification and obtains the destination address in the variable-length data frame. When it is determined that the object corresponding to the destination address is the cloud, it does not parse the business data in the variable-length data frame, but forwards the variable-length data frame to the gateway. The gateway transmits the variable-length data frame to the cloud.

10. An elevator main control system, capable of communicating with a gateway and a COP, characterized in that, include: A first memory and a first processor, wherein the first memory is configured to store an executable program; The first processor is configured to read and execute the executable program, performing the following steps: When a variable-length data frame is received from the gateway, the system performs integrity verification and extracts the destination address of the variable-length data frame. If the system determines that the target device to which the variable-length data frame is to be sent is not the elevator main control based on the destination address in the variable-length data frame, the system does not parse the service data in the variable-length data frame and directly forwards the variable-length data frame to the COP based on the destination address. Upon receiving a variable-length data frame from the COP, the system performs integrity verification on the variable-length data frame and extracts the destination address. If, based on the destination address in the variable-length data frame, it determines that the target device to which the variable-length data frame is to be sent is not the elevator main control unit, the system does not parse the service data in the variable-length data frame and directly forwards the variable-length data frame to the gateway based on the destination address.

11. A COP (Control Panel for Elevator Cars), characterized in that, include: A second memory and a second processor, the second memory being configured to store an executable program; The second processor is configured to read and execute the executable program, performing the following steps: The system receives and independently parses variable-length data frames from the elevator master control and performs corresponding operations. The variable-length data frames from the elevator master control are those received from the gateway. After receiving the variable-length data frames from the gateway, the elevator master control only performs integrity verification on the variable-length data frames and extracts the destination address. When it determines that the object corresponding to the destination address is a COP, it does not parse the business data in the variable-length data frames and directly forwards the variable-length data frames. The system generates variable-length data frames and sends them to the elevator main control unit. Upon receiving the variable-length data frame, the elevator main control unit performs only integrity verification and obtains the destination address in the variable-length data frame. When it determines that the object corresponding to the destination address is the cloud, it does not parse the business data in the variable-length data frame and forwards the variable-length data frame to the gateway.

Images