Abnormal behavior real-time identification method based on data fusion and graph neural network

Abstract

The application discloses an abnormal behavior real-time identification method based on data fusion and a graph neural network, and belongs to the technical field of intelligent fault diagnosis. Real-time operation data of each elevator is acquired, and a call event that has been answered but not completed is screened out from the real-time operation data; a graph structure with elevator nodes and call event nodes as vertices and with an answering relationship as an edge is constructed, and a node attribute is directly input into a graph neural network, and a representation of each node is updated through a message passing mechanism; based on the updated node representation, an expected arrival order of each call event is compared with an actual arrival order in pairs, sequence reversal abnormalities, path detour abnormalities and repeated answering abnormalities are identified, and an abnormal type and corresponding elevator identification and call identification are output. The application can fully utilize the modeling capability of the graph neural network on a structured association relationship, real-time detect operation abnormalities of multiple elevators caused by sequence deviation after answering calls, and effectively improve the accuracy, response timeliness and accuracy of abnormal identification.

Description

Technical Field

[0001] This invention discloses a real-time abnormal behavior identification method based on data fusion and graph neural networks, belonging to the field of intelligent fault diagnosis technology. Background Technology

[0002] Currently, in multi-elevator parallel or group-controlled systems, each elevator responds to passenger calls, including external calls and internal floor selections, and plans its operating sequence accordingly. Traditional elevator scheduling methods typically employ preset priority rules or queue-based scheduling logic, such as determining the order in which each elevator responds to calls based on parameters like the floor level of the call, the degree of match between the call direction and the elevator's current direction of travel. While these rules can maintain basic operational order under normal conditions, when multiple calls occur almost simultaneously, or when the actual stopping order deviates from expectations due to passengers temporarily changing their destination floor or external interference, the system lacks effective real-time anomaly identification methods. Often, it relies solely on manual review of operational logs afterward to analyze for sequence errors or route detours.

[0003] Existing elevator operation monitoring technologies attempt to determine whether an elevator is experiencing obvious malfunctions, such as unresponsive calls or prolonged stops, by collecting time-series data on elevator location, direction, and door status, combined with threshold comparisons or state machine models. However, these methods primarily address isolated behavioral anomalies of a single elevator and struggle to handle operational sequence anomalies caused by irrational call response allocation among multiple elevators. For example, an elevator might prematurely answer a high-priority call that should be served by another elevator, or it might detour to handle a lower-priority call on its way to a higher-priority call. Furthermore, due to the complex relationships between call events and elevators—a single elevator may answer multiple calls, and different calls may implicitly compete and constrain each other through elevator path planning—traditional rule-based or simple statistical methods cannot effectively model this structured dependency, resulting in low accuracy in identifying anomalies such as reversed order or duplicate responses.

[0004] In recent years, graph neural networks have demonstrated advantages in pattern recognition tasks involving graph-structured data, capturing the mutual influence between entities through message passing mechanisms between nodes. Simultaneously, data fusion technology can integrate various information such as elevator operating status and call event attributes into a unified graph structure. However, in the field of elevator operation control, there is still no technical solution for real-time identification of abnormal operating sequences after responding to call events using graph neural networks, especially for the dynamic detection of multiple elevators deviating from the expected operating sequence after responding to a call. A method that can automatically learn abnormal patterns from the graph structure without relying on a large number of prior rules is still lacking. This invention addresses this technological gap by proposing a real-time identification scheme based on data fusion and graph neural networks to solve the problem that existing technologies cannot effectively detect abnormal operating sequences after multiple elevators respond to call events. Summary of the Invention

[0005] To achieve the above objectives, this application provides the following technical solution: A method for identifying anomalies in the operating sequence of multiple elevators after call response based on data fusion and graph neural networks includes the following steps: S1, acquire real-time operating data for each elevator, including the elevator's current position, current direction of travel, list of registered floors to be called, and the response status of each call; S2, based on the response status of each elevator, select calls from the registered call floor list of each elevator that have been answered but have not yet arrived as call events, and record the starting floor and target floor of the call for each call event. S3, Construct a graph structure, including elevator nodes and call event nodes. Each call event node corresponds to a call event. The edges in the graph structure connect elevator nodes with the call event nodes that have been answered by the elevator. S4. Input the attribute information of each elevator node and the attribute information of each call event node into the graph neural network. Update the representation of each node through the message passing mechanism. Each node receives messages sent by neighboring nodes and updates its own representation vector based on the received messages. S5, based on the updated elevator node representation and call event node representation of the graph neural network, identifies whether there is an abnormal running order for each elevator's response to the call event; S6, output the anomaly identification result, which includes at least the elevator identifier and the call event identifier corresponding to the call event with an abnormal operating sequence.

[0006] Furthermore, the graph structure constructed in S3 also includes: A weight is calculated for each edge. The weight is determined based on the estimated travel time of the elevator corresponding to the elevator node from its current position to the starting floor of the call event node connected to the edge. The estimated travel time is calculated based on the elevator's current running direction, current speed, and the floor distance between the starting floor and the current position. This weight is used as the attenuation coefficient of messages between adjacent nodes during message transmission.

[0007] Furthermore, the message passing mechanism of the graph neural network in S4 specifically includes: Each elevator node sends its current position, current direction of travel, and number of currently answered calls as messages along the edge to all call event nodes connected to it. Each call event node sends its own starting floor, target floor, and the waiting time from the initiation of the call to the present as a message to all elevator nodes connected to it along the edge; After receiving a message from a neighboring node, each node aggregates the received message with its current representation. The aggregated result is then transformed nonlinearly and used as the new representation of that node.

[0008] Furthermore, the step S5 of identifying whether there is an abnormal operating sequence for each elevator's response to a call event specifically includes the following sub-steps: S5A, for the target elevator, filter out all call events that the target elevator has answered but has not yet arrived from the call events, and form the set of call events to be processed for the target elevator; S5B: Obtain the current position, current direction of travel, and current speed of the target elevator, and obtain the starting floor and target floor of each call event in the set of call events to be processed; S5C determines the expected arrival order of each call event according to the basic logic of elevator path planning; S5D monitors the actual running path of the target elevator in real time, records the time when the elevator actually arrives at the target floor for each call event, and assigns an actual arrival sequence number to each call event. S5E: Iterate through each call event in the set of call events to be processed, compare the expected arrival sequence number of the call event with the actual arrival sequence number. If there is a call event whose expected arrival sequence number is less than that of another call event, but whose actual arrival sequence number is greater than that of the other call event, then it is determined that the order between the call event and the other call event has been reversed, and the call event is marked as having an abnormal running order. S5F: For all call events marked as having abnormal running order, determine the severity level of the abnormality. The severity level of the abnormality is determined based on the absolute value of the difference between the expected arrival order and the actual arrival order of the call event. The larger the absolute value of the difference, the higher the severity of the abnormality.

[0009] Furthermore, the graph neural network in S4 adopts a three-layer graph convolutional network structure, wherein the first layer of graph convolutional network maps the attribute features of the input nodes to intermediate dimension representations, the second layer of graph convolutional network aggregates node messages in two-hop neighborhoods based on the intermediate dimension representations, and the third layer of graph convolutional network maps the aggregated representations to output dimension representations. Each layer of graph convolutional network is followed by a non-linear activation layer, and no skip connections are used inside each layer of graph convolutional network.

[0010] Furthermore, each call event in S2 records the call initiation time and call type, whereby the call type includes uplink calls and downlink calls; The construction of the diagram structure in S3 also includes: For each call event node, a region identifier is generated based on the call type and the physical partition information of the building where the starting floor is located. This region identifier is used as the node attribute input to the graph neural network. Call event nodes in different physical partitions are not directly connected, but they indirectly affect each other's representation updates through the elevator nodes that are connected together.

[0011] Furthermore, the call event in S2 that indicates a response has been received but the elevator has not yet arrived specifically includes: Each call record is read from the registered call floor list of each elevator, including the called floor, call direction, response flag, and completion flag. When the response flag is true and the completion flag is false, the call record is defined as a call event. The starting floor of each call event is equal to the called floor in the call record, and the target floor is determined according to the call direction. If the call direction is upward, the target floor is a preset reference floor other than the top floor of the building; if the call direction is downward, the target floor is a preset reference floor other than the bottom floor of the building. The graph structure built in S3 is a dynamic construction process, triggered each time a call answer event or call completion event occurs: When a new call is detected and answered, a new call event node is added at the time of the answer, and a new edge is established between the new node and the elevator node that answered the call. When a completed call is detected, the corresponding call event node and all edges connected to that node are removed from the graph structure at the completion time. During the dynamic construction process, call event nodes that are not removed and their edges are retained in the original graph structure, and the attribute information of all nodes is updated synchronously with the elevator's real-time operation data. The attribute information of each elevator node in S3 includes the following items: The elevator's current floor value, the status code of the elevator's current direction of travel, the elevator's current speed value, the status code of whether the elevator doors are fully closed or open, the total number of call events that the elevator has answered but not yet completed, and the number of call events that the elevator has completed in the past time window. The attribute information for each call event node includes the following items: The floor number of the starting floor of the call event, the floor number of the target floor of the call event, the call type code of the call event, the waiting time count from the time the call was initiated to the current time, and the flag indicating whether the call event has been actually stopped by the elevator.

[0012] Furthermore, in step S5, when identifying abnormal operating sequences, the abnormality determination is also based on the physical constraints of the paths between adjacent elevator call events: For any two call events that have been answered by the target elevator, if the intermediate floors between the starting floors of the first call event and the starting floors of the second call event contain the starting floor of another unanswered call event, and the other unanswered call event is bypassed by the actual running path of the elevator, then it is determined that there is a path constraint violation before the starting floor of the second call event, and the second call event is marked as a suspected anomaly. The abnormal results identified based on graph neural networks are combined with the suspected abnormalities identified based on path physical constraints. When both methods determine that the same call event is abnormal, the call event is confirmed to be an abnormal running sequence.

[0013] Furthermore, S4 is preceded by S4A: Based on the real-time operation data of each elevator, a historical operation data sequence of a fixed time length is extracted with the current time as the endpoint. The historical operation data sequence includes the elevator position sequence, running direction sequence, and door status sequence sampled at uniform time intervals. Each sampling point in the historical operation data sequence is used as a time node to construct a time series graph, where the time nodes are connected in chronological order to form a chain structure. Each time node contains the elevator position, running direction and door status at that sampling time. The time series graph is merged with the graph structure constructed by S3, so that the elevator node corresponding to the same elevator is connected to all time nodes belonging to that elevator across the graph. The merged overall graph structure is input into the graph neural network. Message passing on the time series graph proceeds along the time direction, enabling the representation of elevator nodes to incorporate historical operating trajectory information.

[0014] Furthermore, the anomaly identification result output by S6 also includes an anomaly type identifier, which includes at least three types: Order reversal exception, path detour exception, and duplicate response exception; The sequence reversal anomaly corresponds to the situation where the expected arrival order is completely opposite to the actual arrival order. The path detour anomaly corresponds to the situation where the elevator stops at the floor where the lower priority call event is located before heading to the higher priority call event. The duplicate response anomaly corresponds to the situation where the same call event is answered by two or more different elevators at the same time and all of them go to the floor where the call started in subsequent operation. When the identification result is a duplicate response anomaly, the output of S6 additionally includes the identifiers of each elevator involved in the duplicate response and the starting floor of the call event of the duplicate response.

[0015] This invention discloses a real-time abnormal behavior identification method based on data fusion and graph neural networks, belonging to the field of intelligent fault diagnosis technology. The method acquires real-time operating data of each elevator and filters out call events that have been answered but not yet completed. A graph structure is constructed with elevator nodes and call event nodes as vertices and response relationships as edges. Node attributes are directly input into the graph neural network, and the representation of each node is updated through a message passing mechanism. Based on the updated node representations, the expected arrival order of each call event is compared pairwise with the actual arrival order to identify order reversal anomalies, path detour anomalies, and duplicate response anomalies. The anomaly type and the corresponding elevator and call identifiers are output. This invention fully utilizes the modeling capability of graph neural networks for structured relationships to detect operational anomalies caused by order deviations after multiple elevators answer calls in real time, effectively improving the accuracy and timeliness of anomaly identification. Attached Figure Description

[0016] Figure 1 The present invention seeks to protect the flowchart of a real-time abnormal behavior identification method based on data fusion and graph neural networks; Figure 2 The present invention requests protection for a second flowchart of a real-time abnormal behavior identification method based on data fusion and graph neural networks; Figure 3 The present invention requests protection for a third flowchart of a real-time abnormal behavior identification method based on data fusion and graph neural networks. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," and "third" in this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of those features. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. All directional indications in the embodiments of this application, such as up, down, left, right, front, back, etc., are only used to explain the relative positional relationships and movements between components in a specific orientation as shown in the accompanying drawings. If the specific orientation changes, the directional indications will change accordingly. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0019] References to embodiments herein mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] According to a first embodiment of the present invention, referring to Figure 1 This invention claims protection for a real-time abnormal behavior identification method based on data fusion and graph neural networks, comprising the following steps: S1, acquire real-time operating data for each elevator, including the elevator's current position, current direction of travel, list of registered floors to be called, and the response status of each call; S2, based on the response status of each elevator, select calls from the registered call floor list of each elevator that have been answered but have not yet arrived as call events, and record the starting floor and target floor of the call for each call event. S3, Construct a graph structure, including elevator nodes and call event nodes. Each call event node corresponds to a call event. The edges in the graph structure connect elevator nodes with the call event nodes that have been answered by the elevator. S4. Input the attribute information of each elevator node and the attribute information of each call event node into the graph neural network. Update the representation of each node through the message passing mechanism. Each node receives messages sent by neighboring nodes and updates its own representation vector based on the received messages. S5, based on the updated elevator node representation and call event node representation of the graph neural network, identifies whether there is an abnormal running order for each elevator's response to the call event; S6, output the anomaly identification result, which includes at least the elevator identifier and the call event identifier corresponding to the call event with an abnormal operating sequence.

[0021] In this embodiment, the specific implementation process of real-time abnormal behavior identification based on data fusion and graph neural network is involved in a building with six elevators ranging from the 2nd basement floor to the 30th floor above ground.

[0022] Each elevator is equipped with a control unit that collects elevator operation data in real time. The collection frequency is once every 100 milliseconds. The real-time operation data includes the elevator's current position, represented by an integer floor number, such as currently at the 15th floor; the current direction of travel, indicated as up, down, or stopped; and a list of registered call floors. This list records all uncompleted external and internal floor selection calls. Each call record includes the call initiation time, the called floor, the call direction, and the response status. The response status is divided into no response, responded, and completed. In this embodiment, the list of registered call floors is stored in a first-in-first-out queue, but the queue order does not directly determine the actual operating order of the elevator, as the elevator will adjust itself according to directional logic.

[0023] For each elevator control unit, the elevator's registered call floor list is scanned every 200 milliseconds during each calculation cycle. For each call record in the list, its response status field is checked. If the value of this field is "responded," and the target floor corresponding to the call has been actually reached by the elevator and the service has been completed (i.e., the completion flag is false), then the call record is filtered out. For example, elevator A has responded to three calls: call 1 is a passenger pressing the up button on the 8th floor to request to go to the 20th floor; call 2 is a passenger pressing the down button on the 12th floor to request to go to the 5th floor; and call 3 is a passenger pressing the up button on the 25th floor to request to go to the 30th floor. If the elevator has not yet reached any of the 8th, 12th, and 25th floors, then all three calls are defined as call events. The information recorded for each call event includes: the starting floor (the floor the passenger called), the target floor (the floor the passenger wants to go to), the call initiation time accurate to milliseconds, and the call type (up or down).

[0024] Construct the graph structure; first, establish elevator nodes: there are six elevator nodes, labeled Lift_1, Lift_2, Lift_3, Lift_4, Lift_5, and Lift_6. Each elevator node contains attributes such as current floor, direction of travel, and current speed; second, establish call event nodes: assuming that at a certain moment, 15 call events are selected from all six elevators using S2 (e.g., Lift_1 handles 5 events, Lift_2 handles 3 events, etc.), then 15 call event nodes are established, each containing attributes such as starting floor, target floor, call type, and waiting time; rule for constructing edges: for each elevator node, traverse its responded call event nodes and establish an undirected edge between them. In practice, message transmission can be bidirectional, but logically it represents a response relationship. For example, if Lift_1 responds to call events C1, C2, and C3, then edges are established between Lift_1 and C1, between Lift_1 and C2, and between Lift_1 and C3, respectively. Different elevator nodes are not directly connected, nor are different call event nodes directly connected. The graph structure is stored as an adjacency list, where each node records a list of identifiers of its neighboring nodes.

[0025] The graph structure is input into a pre-trained graph neural network. This network has been trained offline, and this embodiment does not involve the training process, but only uses its inference. The graph neural network contains two graph convolutional layers. When inputting, the initial representation of each elevator node is a fixed-dimensional feature vector, such as 16-dimensional. Each component of this vector is directly filled with the original data: for example, the first component is the current floor value, such as 15; the second component is the running direction encoding, up=1, down=0, stop=2; the third component is the current speed, etc., without normalization. The initial representation of each call event node is also a fixed-dimensional vector: for example, the starting floor value, the target floor value, the call type encoding, up=1, down=0, the waiting time, etc. The graph neural network starts message passing: in the first round, each elevator node sends its own feature vector as a message along the edge to all adjacent call event nodes; at the same time, each call event node sends its own feature vector as a message along the edge to all adjacent elevator nodes. After receiving the message, each node sums the multiple message vectors received, then concatenates them with its current vector, and then passes them through a fully connected layer with fixed weights to generate a new representation. The same operation is performed in the second round; after the two rounds, each node still receives a 16-dimensional updated representation vector.

[0026] For each elevator node, such as Lift_1, its updated representation vector is extracted. Based on the information implied in this representation vector, the following actual decision logic is executed: First, from the call event node representation output by the graph neural network, all call event nodes connected to Lift_1, i.e., the call events answered by Lift_1, are identified. Assume Lift_1 has currently answered three call events: C1 (starting from floor 8, target floor 20), C2 (starting from floor 12, target floor 5), and C3 (starting from floor 25, target floor 30). The current position of Lift_1 is then obtained. Currently on the 10th floor, the direction of travel is upward. According to elevator industry standard logic, the expected arrival order is determined as follows: Since the current direction is upward, priority is given to all upward calls whose starting floor is not lower than the current floor and whose target floor is higher than the starting floor. Call C1 starts at the 8th floor, which is lower than the current 10th floor, but its target floor is the 20th floor, which is higher than the starting floor. Although C1 is an upward call, because the starting floor is lower than the current floor, the elevator will not actually turn around to pick it up, so C1 should not be prioritized and should wait until the upward direction is completed before processing. Call C3 starts at the 25th floor, which is higher than the current 10th floor, and its target floor is the 30th floor, which is higher than the starting floor. This is a typical uplink call, expected to arrive first at the starting floor (25th floor) of C3. C2 starts at floor 12 but its destination floor 5 is downlink, requiring a change of direction after the uplink is complete. Therefore, the expected arrival order is: first arrive at the starting floor (25th floor) of C3, then continue uplinking to the destination floor (30th floor) of C3; then change direction and go downlink, passing the 25th and 12th floors. In reality, after changing direction, the question arises whether to process the starting floor (12th floor) of C2 or the starting floor (8th floor) of C1 first. Since higher starting floors have higher priority when downlinking, the starting floor (12th floor) of C2 is higher than the starting floor (8th floor) of C1, so the call arrives at the starting floor (12th floor) of C2 first. Then, starting from floor C1 at floor 8, the expected sequence numbering is: C3 as sequence 1, C2 as sequence 2, and C1 as sequence 3. In actual operation, the elevator control unit records the floor and time of each stop. If the elevator actually stops at floor 8 (starting from C1) first, and then goes to floor 25, the actual arrival order is: C1 as sequence 1, C3 as sequence 2, and C2 as sequence 3. After comparison, it is found that the expected sequence 3 of C1 is greater than the expected sequence 1 of C3, but the actual sequence 1 is less than the actual sequence 2 of C3. Therefore, it is determined that the order between C1 and C3 is reversed, and C1 has an abnormal running order. Output the judgment result.

[0027] Information on call events with abnormal operating sequences is aggregated to generate an anomaly identification report. This report includes at least: the timestamp of the anomaly, the elevator identifier of the anomaly (e.g., Lift_1), the call event identifier (e.g., C1), and the anomaly type in reverse order. The report can be sent to the monitoring center display screen in JSON structured data format and trigger an audible and visual alarm. Monitoring personnel can then use this information to investigate whether there are any faults or human interference in the elevator control system.

[0028] Furthermore, the graph structure constructed in S3 also includes: A weight is calculated for each edge. The weight is determined based on the estimated travel time of the elevator corresponding to the elevator node from its current position to the starting floor of the call event node connected to the edge. The estimated travel time is calculated based on the elevator's current running direction, current speed, and the floor distance between the starting floor and the current position. This weight is used as the attenuation coefficient of messages between adjacent nodes during message transmission.

[0029] In this embodiment, after establishing the edge between the elevator node and the call event node, a weight value is calculated for each edge, such as the edge connecting the elevator node Lift_1 and the call event node C1. The weight calculation does not use any mathematical formula, but is implemented through the following logical steps: First, obtain the current position of elevator node Lift_1, for example, the 10th floor, the current direction of travel is upward, and the current speed is 1.5 meters / second; the height of each floor is 3 meters; obtain the starting floor of call event node C1, which is the 8th floor.

[0030] Next, determine the path direction from the elevator's current position to the starting floor: Since the current position (10th floor) is 8 floors higher than the starting floor, and the elevator is currently going upwards but the starting floor is below, the elevator cannot go directly downwards; it must complete all tasks in the current upward direction before changing direction. Therefore, it is necessary to calculate the estimated travel time: estimate that the elevator will continue upwards to the currently registered highest upward call floor, for example, the 30th floor, and then turn around and go downwards from the 30th floor to the 8th floor. Assume the stop time at each floor is a fixed value (door opening and closing time). Based on the floor spacing, speed, and the number of floors that need to be stopped, a relative time estimate is obtained. This time estimate is used as the edge weight.

[0031] When an elevator node sends a message to a call event node, the message vector is multiplied by 1 / weight before being sent. That is, the larger the weight, the stronger the message attenuation; conversely, the smaller the weight, the stronger the message. Similarly, when a call event node sends a message to an elevator node, the same weight coefficient is used for attenuation. This makes the impact of call events that are far away or difficult to reach quickly on the elevator node's representation weaker.

[0032] In this embodiment, the weights are determined not by numerical calculation, but by a lookup table: a table of estimated elevator travel time levels between any two points is pre-established based on the building's floor distribution, divided into five levels: extremely close, near, medium, far, and extremely far. Each level corresponds to a weight coefficient range. For example, extremely close corresponds to a weight of 0.9-1.0, and extremely far corresponds to a weight of 0.1-0.2. During calculation, the level is obtained by looking up the table based on the floor difference between the starting floor and the current position, as well as the direction matching, and a weight value is randomly assigned or assigned according to a preset mapping. In this way, each edge has a weight scalar.

[0033] Furthermore, the message passing mechanism of the graph neural network in S4 specifically includes: Each elevator node sends its current position, current direction of travel, and number of currently answered calls as messages along the edge to all call event nodes connected to it. Each call event node sends its own starting floor, target floor, and the waiting time from the initiation of the call to the present as a message to all elevator nodes connected to it along the edge; After receiving a message from a neighboring node, each node aggregates the received message with its current representation. The aggregated result is then transformed nonlinearly and used as the new representation of that node.

[0034] In this embodiment, before the first round of message passing begins, each elevator node maintains a representation vector, for example, 16-dimensional, and each call event node also maintains a 16-dimensional representation vector.

[0035] First, each elevator node uses its own three attribute values ​​as message content: the current floor number, for example, 15; the status code of the current direction of travel, up = 1, down = 0, stopped = 2; and the number of currently answered calls, for example, 5. These three values ​​are directly concatenated into a 3-dimensional original message vector without any transformation. Then, the elevator node traverses all its neighbor call event nodes, and for each neighbor, sends the 3-dimensional message vector along the edge.

[0036] Meanwhile, each call event node uses its own three attribute values ​​as message content: the starting floor value, for example 8, the target floor value, for example 20, and the waiting time from the time the call was initiated to the current time, for example 45 seconds; these three values ​​are also concatenated into a 3D message vector; then, the call event node traverses all its neighboring elevator nodes and sends the 3D message vector to each neighbor.

[0037] Each node caches messages received from its neighbors. Assuming Lift_1 has three neighbors C1, C2, and C3, it receives three 3-dimensional message vectors. Lift_1 adds these message vectors element-wise to obtain a 3-dimensional aggregated message vector. Then, Lift_1 concatenates its current 16-dimensional representation vector with this 3-dimensional aggregated message vector to obtain a 19-dimensional vector. Next, this 19-dimensional vector is input into a fully connected layer with a pre-trained 19×16 weight matrix. The layer outputs a new 16-dimensional vector, which is then passed through a non-linear activation function to obtain Lift_1's new representation.

[0038] For a call event node, similarly: C1 receives a 3D message from Lift_1 and messages that may come from other elevators. If C1 is answered by multiple elevators, but by definition each call can only be answered by one elevator, in this embodiment each call event node is only connected to one elevator node, so only one message is received; C1 concatenates the received message vector with its own 16-dimensional representation vector, and then obtains a new representation of C1 through a fully connected 19×16 layer and nonlinear activation.

[0039] The second round of message passing repeats the above process, but the message content is updated with some dimensions of the new representation of each node after the first round, for example, taking the first 3 dimensions of the new representation as the message; after the two rounds, the final node representation is used for subsequent identification.

[0040] Furthermore, referring to Figure 2 The step S5, which identifies whether there is an abnormal operating sequence for each elevator's response to a call event, specifically includes the following sub-steps: S5A, for the target elevator, filter out all call events that the target elevator has answered but has not yet arrived from the call events, and form the set of call events to be processed for the target elevator; S5B: Obtain the current position, current direction of travel, and current speed of the target elevator, and obtain the starting floor and target floor of each call event in the set of call events to be processed; S5C determines the expected arrival order of each call event according to the basic logic of elevator path planning; S5D monitors the actual running path of the target elevator in real time, records the time when the elevator actually arrives at the target floor for each call event, and assigns an actual arrival sequence number to each call event. S5E: Iterate through each call event in the set of call events to be processed, compare the expected arrival sequence number of the call event with the actual arrival sequence number. If there is a call event whose expected arrival sequence number is less than that of another call event, but whose actual arrival sequence number is greater than that of the other call event, then it is determined that the order between the call event and the other call event has been reversed, and the call event is marked as having an abnormal running order. S5F: For all call events marked as having abnormal running order, determine the severity level of the abnormality. The severity level of the abnormality is determined based on the absolute value of the difference between the expected arrival order and the actual arrival order of the call event. The larger the absolute value of the difference, the higher the severity of the abnormality.

[0041] In this embodiment, for a target elevator such as Lift_1, from all call events obtained in S2, call events whose responding elevator identifier is Lift_1 and which have not yet been completed are selected. Specifically, a Lift_1 call event table is maintained, where each row corresponds to a call event and includes the fields: event ID, starting floor, target floor, initiation time, response time, and completion flag. Rows with a false completion flag are pending call events; these events are stored in a set S.

[0042] Read the following from the real-time running data of Lift_1: current position, e.g., floor 10, current running direction (upward), and current speed (1.5 m / s); for each call event in S, read its starting floor and target floor; assuming there are three events in S: E1 (starting floor 8, target floor 20, upward), E2 (starting floor 12, target floor 5, downward), and E3 (starting floor 25, target floor 30, upward).

[0043] The expected arrival order is determined based on the basic logic of elevator route planning; the specific logic implementation is as follows: First, determine the current direction of movement; if it is upward, then execute the upward priority rule: Construct two sublists: an uplink call list where the starting floor is greater than or equal to the current floor and the target floor is greater than the starting floor, and a downlink call list containing the remaining calls.

[0044] For the uplink call list, sort it from smallest to largest starting floor.

[0045] For the downward call list, since the elevator needs to complete all upward calls before changing direction, during the downward phase, the calls are sorted from the starting floor to the lowest, because higher floors arrive first when descending.

[0046] The expected final order is: first execute the sorted uplink call list, then execute the sorted downlink call list.

[0047] Applying this example: Current floor 10, uplink; E1 starts at 8, less than 10, not an uplink call; E2 starts at 12, greater than 10, but the target 5 is less than the starting floor, a downlink call; E3 starts at 25, greater than 10, and the target 30 is greater than the starting floor, an uplink call; therefore, the uplink call list only contains E3, and the downlink call list contains E1 and E2. After sorting the uplink calls, only E3 remains; the downlink calls are ordered by starting floor from largest to smallest: E2 (starting at 12) > E1 (starting at 8), so the order is E2, E1; therefore, the expected arrival order is: E3 1st, E2 2nd, E1 3rd. Assign a sequence number to each event: E3 1st, E2 2nd, E1 3rd.

[0048] Monitor the actual running path of Lift_1 in real time; the elevator control unit records the stopping floor and timestamp at each stopping moment; for example, during actual operation, the elevator first goes up to the starting point E3 on the 25th floor to pick up passengers, then continues to go up to the destination E3 on the 30th floor to drop off passengers, and then changes direction to go down. But when going down, it first passes the starting point E2 on the 12th floor. Actually, it may stop at the 8th floor first because someone presses other floors. Assume the actual arrival order is: the elevator first stops at the starting point E1 on the 8th floor, then stops at the starting point E2 on the 12th floor, and then stops at the starting point E3 on the 25th floor; record the moment when the target floor of each event is reached. Note: The completion of an event is based on the arrival of its target floor. The arrival of the starting floor only means picking up passengers, but in the abnormal judgment, the target floor order is considered. In this embodiment, for simplicity, taking the starting floor arrival order as an example, it is expressed as the actual arrival order of the elevator at the target floors of each call event. Therefore, it should be based on the target floor; Reset: Assume the target of E1 is the 20th floor, the target of E2 is the 5th floor, and the target of E3 is the 30th floor; Actual operation: The elevator first arrives at the target E1 on the 20th floor, then arrives at the target E2 on the 5th floor, and then arrives at the target E3 on the 30th floor; Then the actual arrival time sorting: E1 is the 1st, E2 is the 2nd, E3 is the 3rd; Actual order number: E1 order 1, E2 order 2, E3 order 3.

[0049] Traverse each call event in the set to be processed, and compare the expected order number with the actual order number. For E1: expected 3, actual 1, expected is greater than actual; For E2: expected 2, actual 2, equal. For E3: expected 1, actual 3, expected is less than actual; Now check if there exists an event whose expected order number is less than another event, while the actual order number of this one event is greater than the actual order number of the other event; Compare E3 and E1: expected E3(1) < E1(3), but actual E3(3) > E1(1), the condition holds, and it is determined that the order between E3 and E1 is reversed; Then mark E3 as having an abnormal running order. The event that occurs later in the actual reversal is usually marked; At the same time, E1 can also be marked.

[0050] Judge the severity level of the abnormality; for E3, the expected order is 1, the actual order is 3, and the difference is 2. According to the preset level division: a difference of 1 is a minor abnormality, a difference of 2 is a medium abnormality, and a difference of 3 and above is a severe abnormality; Therefore, E3 is marked as a medium abnormality; Store the level information.

[0051] Furthermore, the graph neural network in S4 adopts a three-layer graph convolutional network structure, where the first layer of the graph convolutional network maps the attribute features of the input nodes to intermediate-dimensional representations, the second layer of the graph convolutional network aggregates the node messages within the two-hop neighborhood based on the intermediate-dimensional representations, the third layer of the graph convolutional network maps the aggregated representations to output-dimensional representations, and each layer of the graph convolutional network is followed by a non-linear activation layer, and no skip connections are used inside each layer of the graph convolutional network.

[0052] In this embodiment, the graph neural network in S4 is set as a three-layer graph convolutional network (GCN). The operation of each layer is as follows: The first layer of the graph convolutional network: The dimension of the input node feature matrix is ​​the same as the input feature dimension, for example, each node has 10 original features; the first layer contains a trainable weight matrix of size 10×32. The operations performed in this layer are as follows: For each node, its own feature vector is weighted and summed with the feature vectors of its neighbors (weights determined by the adjacency matrix), then multiplied by the weight matrix to output a 32-dimensional intermediate feature; an adjacency matrix A is constructed, where A(i,j)=1 if there is an edge between node i and node j, otherwise 0. For each node i, its degree d_i is calculated; then the sum of the neighbor features is divided by d_i, multiplied by a coefficient, and added; the result is transformed by the weight matrix to output a 32-dimensional vector; immediately following the first layer is a non-linear activation layer, which performs the following operation on each component of the 32-dimensional vector: if the component value is greater than 0, it remains unchanged; if it is less than or equal to 0, it is set to 0. The activated 32-dimensional vector is then output.

[0053] The second layer of the graph convolutional network takes as input the 32-dimensional features output from the first layer and has a weight matrix of size 32×64. Its operation is similar to the first layer, but the aggregation range is extended to the two-hop neighborhood, achieved indirectly through two message passes. Specifically, it still uses the adjacency matrix for two consecutive aggregation operations, but internally it directly aggregates the representations of each node's neighbors and their neighbors' neighbors. The output is a 64-dimensional feature, which is then passed through a non-linear activation layer following the same rules.

[0054] The third layer of the graph convolutional network takes as input the 64-dimensional features output from the second layer; the weight matrix of the third layer is 64×16; the operation is still to aggregate neighbor information, but no longer expand the range, only using one-hop neighborhood. It outputs 16-dimensional features; then passes through a non-linear activation layer; finally, a 16-dimensional representation of each node is obtained.

[0055] In this embodiment, skip connections are not used within each layer of the graph convolutional network, meaning there is no operation of directly adding the input to the output; it relies entirely on inter-layer propagation.

[0056] Furthermore, each call event in S2 records the call initiation time and call type, whereby the call type includes uplink calls and downlink calls; The construction of the diagram structure in S3 also includes: For each call event node, a region identifier is generated based on the call type and the physical partition information of the building where the starting floor is located. This region identifier is used as the node attribute input to the graph neural network. Call event nodes in different physical partitions are not directly connected, but they indirectly affect each other's representation updates through the elevator nodes that are connected together.

[0057] In this embodiment, in S2, each call event records the call type (uplink or downlink) and the starting floor; in S3, the physical partition information of the building is predefined: for example, the building is divided into low zone (floors 1-10), middle zone (floors 11-20), and high zone (floors 21-30); for each call event, a zone identifier is generated according to the physical partition of its starting floor; specifically: if the starting floor is between 1-10, the zone identifier is low zone; between 11-20, it is middle zone; between 21-30, it is high zone; in addition, if the call type is uplink, _UP is appended to the zone identifier; if it is downlink, _DOWN is appended; for example, an uplink call starting from the 8th floor has the zone identifier of low zone _UP; a downlink call starting from the 25th floor has the zone identifier of high zone _DOWN.

[0058] The region identifier is converted into a one-hot encoded vector with a dimension equal to the number of partitions multiplied by the number of directions, i.e., 3×2=6 dimensions, which is used as part of the call event node attributes; therefore, in addition to the starting floor, target floor, and waiting time, the initial representation of each call event node also includes this 6-dimensional region information.

[0059] When inputting into a graph neural network, this regional information is input along with other numerical attributes. Call event nodes in different physical zones are not directly connected and there are no edges in the graph, but they may be connected to the same elevator node. For example, if Lift_1 answers both a low-zone call and a high-zone call, then both the low-zone call node and the high-zone call node are connected to Lift_1. When Lift_1 sends messages to these call nodes, the messages carry Lift_1's own features, thus indirectly fusing the information from the low-zone and high-zone calls together. Conversely, the regional information of the low-zone call node is passed to Lift_1 through messages, affecting Lift_1's representation, and thus affecting the messages received by the high-zone call node. In this way, the representation updates of each other are indirectly affected through a common elevator node.

[0060] Furthermore, the call event in S2 that indicates a response has been received but the elevator has not yet arrived specifically includes: Each call record is read from the registered call floor list of each elevator, including the called floor, call direction, response flag, and completion flag. When the response flag is true and the completion flag is false, the call record is defined as a call event. The starting floor of each call event is equal to the called floor in the call record, and the target floor is determined according to the call direction. If the call direction is upward, the target floor is a preset reference floor other than the top floor of the building; if the call direction is downward, the target floor is a preset reference floor other than the bottom floor of the building. The graph structure built in S3 is a dynamic construction process, triggered each time a call answer event or call completion event occurs: When a new call is detected and answered, a new call event node is added at the time of the answer, and a new edge is established between the new node and the elevator node that answered the call. When a completed call is detected, the corresponding call event node and all edges connected to that node are removed from the graph structure at the completion time. During the dynamic construction process, call event nodes that are not removed and their edges are retained in the original graph structure, and the attribute information of all nodes is updated synchronously with the elevator's real-time operation data. The attribute information of each elevator node in S3 includes the following items: The elevator's current floor value, the status code of the elevator's current direction of travel, the elevator's current speed value, the status code of whether the elevator doors are fully closed or open, the total number of call events that the elevator has answered but not yet completed, and the number of call events that the elevator has completed in the past time window. The attribute information for each call event node includes the following items: The floor number of the starting floor of the call event, the floor number of the target floor of the call event, the call type code of the call event, the waiting time count from the time the call was initiated to the current time, and the flag indicating whether the call event has been actually stopped by the elevator.

[0061] In this embodiment, each elevator control unit maintains a call registration table. Each row of the table corresponds to a call, and the fields include: called floor, call direction / up / down, response flag Boolean value, completion flag Boolean value, and call ID. The system scans the table every 100 milliseconds. For each row, if the response flag is true (meaning a passenger has pressed the floor button inside the elevator or the external call button has been responded to by an elevator) and the completion flag is false (meaning the elevator has not yet reached the target floor of the call and completed the door opening action), then the row is defined as a call event. The starting floor of the call event is directly taken from the value of the called floor field. The rule for determining the target floor is as follows: if the call direction is upward, the target floor is a preset reference floor other than the top 30 floors of the building. This preset reference floor is not a fixed value, but is dynamically determined according to the elevator control strategy. For upward calls, the target floor is usually the floor selected by the passenger inside the elevator, so the actual target floor is the internal selection registered floor, not a preset reference value. Each call record has already recorded the target floor after the internal selection button or external call when responding, so the target floor is directly read from the target floor field in the call record.

[0062] The graph structure is not static, but is updated each time a call response event or call completion event occurs. Specifically, the system has an event listener. When the elevator controller detects that the response flag of a call has changed from false to true, meaning that the driver or the system has assigned the call to an elevator, a new node event is triggered: a new call event node is created and assigned a unique identifier; all attributes of the node, such as the starting floor and the target floor, are recorded; then the elevator node that responded to the call, such as Lift_2, is found, and an edge is established between the two; at the same time, the new node is added to the global graph structure. When the completion flag of a call is detected to have changed from false to true, the elevator reaches the target floor and opens the door, triggering a node removal event: the corresponding call event node is found in the graph structure, and the node and all edges connected to it are deleted; the remaining nodes and edges remain unchanged; the attribute information of all nodes is updated synchronously every 200 milliseconds in each calculation cycle: the current position, direction, speed, etc. of the elevator node are read from the sensors in real time; the waiting time of the call event node is accumulated from the time the call was initiated to the current time.

[0063] Each elevator node's attribute information includes the following six items, all stored in raw numerical form without normalization: Current floor number: an integer, such as -2, 1, 15, 30, etc. The status code for the current direction of movement is: directly stored as a character or integer, such as UP or 1; Current speed value: floating-point number, in meters per second, e.g., 1.5; The status code for whether the elevator door is fully closed or open: for example, CLOSED or 0, OPEN or 1; The total number of currently answered but not completed call events for this elevator: an integer, e.g., 5; The number of call events completed by this elevator in the past time window, such as the past 60 seconds: an integer, such as 3; The attribute information for each call event node includes the following four items: Starting floor number: an integer, such as 8; The floor number of the target floor: an integer, such as 20; Call type encoding: uplink is 1, downlink is 0; Waiting time count from the time the call was initiated to the current time: in seconds, floating point number, e.g., 45.2; The flag indicating whether the call event has actually stopped: a Boolean value, for example, 0 indicates that it has not stopped.

[0064] These attributes are input directly as raw values ​​without any normalization or standardization transformations before being fed into the graph neural network; for example, the waiting time of 45.2 seconds is directly used as a component of the feature vector without dividing by the maximum value or subtracting the mean.

[0065] Furthermore, in step S5, when identifying abnormal operating sequences, the abnormality determination is also based on the physical constraints of the paths between adjacent elevator call events: For any two call events that have been answered by the target elevator, if the intermediate floors between the starting floors of the first call event and the starting floors of the second call event contain the starting floor of another unanswered call event, and the other unanswered call event is bypassed by the actual running path of the elevator, then it is determined that there is a path constraint violation before the starting floor of the second call event, and the second call event is marked as a suspected anomaly. The abnormal results identified based on graph neural networks are combined with the suspected abnormalities identified based on path physical constraints. When both methods determine that the same call event is abnormal, the call event is confirmed to be an abnormal running sequence.

[0066] In this embodiment, in step S5, in addition to utilizing the results of the graph neural network, a constraint check based on the physical path is added; the specific operation is as follows: For the target elevator, such as Lift_1, let's assume all its answered call events are E1, E2, E3, and E4. Define the path physical constraint as follows: If the elevator wants to go from one starting floor to another, it must pass through all intermediate floors in between. If there is an intermediate floor that corresponds to a starting floor that has not yet been answered, and the elevator's actual running path directly passes through that floor without stopping, then the path constraint is violated.

[0067] Specific determination steps: List the starting floors of all answered call events for Lift_1, sorted by floor number; assuming the sorted floors are: 5th floor (E4), 8th floor (E1), 12th floor (E2), 25th floor (E3).

[0068] Obtain the sequence of floors stopped in the actual elevator route in chronological order; assuming the actual stopping order is: 8th floor, 25th floor, 12th floor, 5th floor.

[0069] For two adjacent actual stopping floors, such as from floor 8 to floor 25, the intermediate floors are floors 9-24; check if there is a starting floor for an unanswered call event among these intermediate floors. Note that "unanswered" means not answered by any elevator, not that it has been answered. Suppose there is an unanswered external call on floor 9, then the elevator would go directly from floor 8 to floor 25, skipping floor 9, which would violate physical constraints. However, in this embodiment, it is described as the starting floor corresponding to another unanswered call event, and this other unanswered call event is bypassed by the actual running path. Therefore, if there is such an unanswered call on floor 9 and the elevator does not stop, the second call event on floor 25 is marked as a suspected anomaly.

[0070] Combining the anomalies identified by the graph neural network: Suppose the graph neural network determines that there is an order anomaly starting from the 25th floor of E3, and the physical constraint check also believes that E3 causes a path violation, then E3 is finally confirmed as an abnormal running order; if only the graph neural network determines the anomaly and the physical constraints do not find it, it is marked as requiring manual review; if only the physical constraints are found and the graph neural network does not determine it, it is also marked as an anomaly.

[0071] Furthermore, referring to Figure 3 The process begins with S4A: Based on the real-time operation data of each elevator, a historical operation data sequence of a fixed time length is extracted with the current time as the endpoint. The historical operation data sequence includes the elevator position sequence, running direction sequence, and door status sequence sampled at uniform time intervals. Each sampling point in the historical operation data sequence is used as a time node to construct a time series graph, where the time nodes are connected in chronological order to form a chain structure. Each time node contains the elevator position, running direction and door status at that sampling time. The time series graph is merged with the graph structure constructed by S3, so that the elevator node corresponding to the same elevator is connected to all time nodes belonging to that elevator across the graph. The merged overall graph structure is input into the graph neural network. Message passing on the time series graph proceeds along the time direction, enabling the representation of elevator nodes to incorporate historical operating trajectory information.

[0072] In this embodiment, for each elevator, a historical running data sequence of a fixed time length is extracted from the current time as the endpoint. Assuming the fixed time length is 10 seconds and the sampling interval is 0.5 seconds, a total of 20 sampling points are obtained. Each sampling point records three quantities: elevator floor position, running direction (up / down / stopped), and door status (open / closed / opening / closing). These 20 sampling points are connected in chronological order into a chain graph: each sampling point is a time node, and directed edges are established between adjacent time nodes, i.e., between temporally continuous sampling points, with the direction from old to new.

[0073] For each elevator node, such as Lift_1, establish cross-graph connections between the elevator node and all time nodes belonging to that elevator; specifically, establish an undirected edge or a bidirectional edge from the Lift_1 node to each time node; thus, the entire graph structure includes the original relational graph of elevators and call events as well as the newly added time sequence graph part.

[0074] The merged overall graph structure is input into the graph neural network. The graph neural network structure needs to support cross-graph message passing: in each layer of message passing, the message propagates not only along the elevator-call edge, but also along the time series edge and along the elevator-time node edge. Specifically, first, messages are passed between time nodes in chronological order, so that the representation of each time node integrates the information of the previous and next times. Then, through the elevator-time node edge, the information in the time series is passed to the elevator node, and at the same time, the elevator node also passes its current representation to the time node, so that the representation of the elevator node can integrate historical running trajectory information. For example, if the elevator has stopped briefly on a certain floor and then suddenly changed direction in the past 5 seconds, this historical pattern can be passed to the elevator node through the time series graph, thus affecting the anomaly judgment.

[0075] Furthermore, the anomaly identification result output by S6 also includes an anomaly type identifier, which includes at least three types: Order reversal exception, path detour exception, and duplicate response exception; The sequence reversal anomaly corresponds to the situation where the expected arrival order is completely opposite to the actual arrival order. The path detour anomaly corresponds to the situation where the elevator stops at the floor where the lower priority call event is located before heading to the higher priority call event. The duplicate response anomaly corresponds to the situation where the same call event is answered by two or more different elevators at the same time and all of them go to the floor where the call started in subsequent operation. When the identification result is a duplicate response anomaly, the output of S6 additionally includes the identifiers of each elevator involved in the duplicate response and the starting floor of the call event of the duplicate response.

[0076] In this embodiment, the output of the anomaly identification result includes identifiers for three anomaly types.

[0077] The anomaly identification result output by S6 is a structured report, which includes an anomaly type identifier field; this field can take one of the following three values: sequence reversal anomaly, path detour anomaly, or duplicate response anomaly.

[0078] This type of output is generated when the system determines that the actual arrival order of a certain call event is reversed from the expected order of another call event. Example of output content: {Exception type: Order Reversal Exception, Elevator ID: Lift_1, Call event ID: C3, Related call event ID: C1, Timestamp: 2025-01-15 14:23:45.123}.

[0079] When an elevator stops at the floor of a lower-priority call on its way to a higher-priority call, and the starting floor of that lower-priority call is not on the same path in the current direction; for example, the elevator is currently going up, and the highest priority call is on floor 25, but the elevator stops at floor 10, the starting floor of a downward call that should have been processed after the upward call is completed, this constitutes a path detour exception; Output example: {Exception type: Path detour exception, Elevator ID:Lift_2, Detour stop floor: 10, Starting floor of the detoured high-priority call: 25, Timestamp: ...}.

[0080] The system detects that the same call event, with the same starting floor, the same call direction, and a similar initiation time, is answered simultaneously by two or more elevators, and all of them subsequently travel to the starting floor of the call. Detection method: Listen to call answer events; if the same call ID is marked as answered by two different elevator controllers within a short period of time, such as 1 second, it is recorded; subsequently, monitor the running paths of these elevators; if they all actually arrive at the starting floor, stop, and open the door, the duplicate answering anomaly is confirmed. The output additionally includes: a list of the identifiers of each elevator involved in the duplicate answering, such as [Lift_1, Lift_3], and the starting floor of the call event with the duplicate answering, such as the 8th floor; Output example: {Anomaly type: Duplicate answering anomaly, Starting floor: 8, Call direction: Upward, Elevators involved: [Lift_1, Lift_3], Timestamp: ...}.

[0081] After summarizing all anomaly identification results, the system sends them to the monitoring platform via a message queue and highlights the corresponding elevator and call events on the monitoring interface.

[0082] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0083] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0084] The specific embodiments of the invention have been described in detail above, but they are only examples, and this application is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications or substitutions to the invention are also within the scope of this application. Therefore, all equivalent changes, modifications, and improvements made without departing from the spirit and principles of this application should be covered within the scope of this application.

Claims

1. A method for identifying abnormal operating sequence of multiple elevators after call response based on data fusion and graph neural networks, characterized in that, Includes the following steps: S1, acquire real-time operating data for each elevator, including the elevator's current position, current direction of travel, list of registered floors to be called, and the response status of each call; S2, based on the response status of each elevator, select calls from the registered call floor list of each elevator that have been answered but have not yet arrived as call events, and record the starting floor and target floor of the call for each call event. S3, Construct a graph structure, including elevator nodes and call event nodes. Each call event node corresponds to a call event. The edges in the graph structure connect elevator nodes with the call event nodes that have been answered by the elevator. S4. Input the attribute information of each elevator node and the attribute information of each call event node into the graph neural network. Update the representation of each node through the message passing mechanism. Each node receives messages sent by neighboring nodes and updates its own representation vector based on the received messages. S5, based on the updated elevator node representation and call event node representation of the graph neural network, identifies whether there is an abnormal running order for each elevator's response to the call event; S6, output the anomaly identification result, which includes at least the elevator identifier and the call event identifier corresponding to the call event with an abnormal operating sequence.

2. The method according to claim 1, characterized in that, The graph structure constructed in S3 also includes: A weight is calculated for each edge. The weight is determined based on the estimated travel time of the elevator corresponding to the elevator node from its current position to the starting floor of the call event node connected to the edge. The estimated travel time is calculated based on the elevator's current running direction, current speed, and the floor distance between the starting floor and the current position. This weight is used as the attenuation coefficient of messages between adjacent nodes during message transmission.

3. The method according to claim 1, characterized in that, The message passing mechanism of the graph neural network in S4 specifically includes: Each elevator node sends its current position, current direction of travel, and number of currently answered calls as messages along the edge to all call event nodes connected to it. Each call event node sends its own starting floor, target floor, and the waiting time from the initiation of the call to the present as a message to all elevator nodes connected to it along the edge; After receiving a message from a neighboring node, each node aggregates the received message with its current representation. The aggregated result is then transformed nonlinearly and used as the new representation of that node.

4. The method according to claim 1, characterized in that, The step S5, which identifies whether there is an abnormal operating sequence for each elevator's response to a call event, specifically includes the following sub-steps: S5A, for the target elevator, filter out all call events that the target elevator has answered but has not yet arrived from the call events, and form the set of call events to be processed for the target elevator; S5B: Obtain the current position, current direction of travel, and current speed of the target elevator, and obtain the starting floor and target floor of each call event in the set of call events to be processed; S5C determines the expected arrival order of each call event according to the basic logic of elevator path planning; S5D monitors the actual running path of the target elevator in real time, records the time when the elevator actually arrives at the target floor for each call event, and assigns an actual arrival sequence number to each call event. S5E: Iterate through each call event in the set of call events to be processed, compare the expected arrival sequence number of the call event with the actual arrival sequence number. If there is a call event whose expected arrival sequence number is less than that of another call event, but whose actual arrival sequence number is greater than that of the other call event, then it is determined that the order between the call event and the other call event has been reversed, and the call event is marked as having an abnormal running order. S5F: For all call events marked as having abnormal running order, determine the severity level of the abnormality. The severity level of the abnormality is determined based on the absolute value of the difference between the expected arrival order and the actual arrival order of the call event. The larger the absolute value of the difference, the higher the severity of the abnormality.

5. The method according to claim 1, characterized in that, The graph neural network in S4 adopts a three-layer graph convolutional network structure. The first layer of graph convolutional network maps the attribute features of the input nodes to intermediate dimension representations. The second layer of graph convolutional network aggregates node messages in two-hop neighborhoods based on the intermediate dimension representations. The third layer of graph convolutional network maps the aggregated representations to the output dimension representations. Each layer of graph convolutional network is followed by a non-linear activation layer, and no skip connections are used inside each layer of graph convolutional network.

6. The method according to claim 1, characterized in that, Each call event in S2 records the call initiation time and call type, where the call type includes uplink calls and downlink calls. The construction of the diagram structure in S3 also includes: For each call event node, a region identifier is generated based on the call type and the physical partition information of the building where the starting floor is located. This region identifier is used as the node attribute input to the graph neural network. Call event nodes in different physical partitions are not directly connected, but they indirectly affect each other's representation updates through the elevator nodes that are connected together.

7. The method according to claim 1, characterized in that, The call event in S2 that determines that the call has been answered but the elevator has not yet arrived specifically includes: Each call record is read from the registered call floor list of each elevator, including the called floor, call direction, response flag, and completion flag. When the response flag is true and the completion flag is false, the call record is defined as a call event. The starting floor of each call event is equal to the called floor in the call record, and the target floor is determined according to the call direction. If the call direction is upward, the target floor is a preset reference floor other than the top floor of the building; if the call direction is downward, the target floor is a preset reference floor other than the bottom floor of the building. The graph structure built in S3 is a dynamic construction process, triggered each time a call answer event or call completion event occurs: When a new call is detected and answered, a new call event node is added at the time of the answer, and a new edge is established between the new node and the elevator node that answered the call. When a completed call is detected, the corresponding call event node and all edges connected to that node are removed from the graph structure at the completion time. During the dynamic construction process, call event nodes that are not removed and their edges are retained in the original graph structure, and the attribute information of all nodes is updated synchronously with the elevator's real-time operation data. The attribute information of each elevator node in S3 includes the following items: The elevator's current floor value, the status code of the elevator's current direction of travel, the elevator's current speed value, the status code of whether the elevator doors are fully closed or open, the total number of call events that the elevator has answered but not yet completed, and the number of call events that the elevator has completed in the past time window. The attribute information for each call event node includes the following items: The floor number of the starting floor of the call event, the floor number of the target floor of the call event, the call type code of the call event, the waiting time count from the time the call was initiated to the current time, and the flag indicating whether the call event has been actually stopped by the elevator.

8. The method according to claim 1, characterized in that, When identifying abnormal operating sequences in S5, the anomaly determination is also based on the physical constraints of the paths between adjacent elevator call events: For any two call events that have been answered by the target elevator, if the intermediate floors between the starting floors of the first call event and the starting floors of the second call event contain the starting floor of another unanswered call event, and the other unanswered call event is bypassed by the actual running path of the elevator, then it is determined that there is a path constraint violation before the starting floor of the second call event, and the second call event is marked as a suspected anomaly. The abnormal results identified based on graph neural networks are combined with the suspected abnormalities identified based on path physical constraints. When both methods determine that the same call event is abnormal, the call event is confirmed to be an abnormal running sequence.

9. The method according to claim 1, characterized in that, S4 is preceded by S4A: Based on the real-time operation data of each elevator, a historical operation data sequence of a fixed time length is extracted with the current time as the endpoint. The historical operation data sequence includes the elevator position sequence, running direction sequence, and door status sequence sampled at uniform time intervals. Each sampling point in the historical operation data sequence is used as a time node to construct a time series graph, where the time nodes are connected in chronological order to form a chain structure. Each time node contains the elevator position, running direction and door status at that sampling time. The time series graph is merged with the graph structure constructed by S3, so that the elevator node corresponding to the same elevator is connected to all time nodes belonging to that elevator across the graph. The merged overall graph structure is input into the graph neural network. Message passing on the time series graph proceeds along the time direction, enabling the representation of elevator nodes to incorporate historical operating trajectory information.

10. The method according to claim 1, characterized in that, The anomaly identification result output by S6 also includes an anomaly type identifier, which includes at least three types: Order reversal exception, path detour exception, and duplicate response exception; The sequence reversal anomaly corresponds to the situation where the expected arrival order is completely opposite to the actual arrival order. The path detour anomaly corresponds to the situation where the elevator stops at the floor where the lower priority call event is located before heading to the higher priority call event. The duplicate response anomaly corresponds to the situation where the same call event is answered by two or more different elevators at the same time and all of them go to the floor where the call started in subsequent operation. When the identification result is a duplicate response anomaly, the output of S6 additionally includes the identifiers of each elevator involved in the duplicate response and the starting floor of the call event of the duplicate response.

Images