Patent Description:
In an elevator management system, information coming from car mounted information of things (IoT) sensors may need to be related to a car position in a hoistway for example on which floor doors were open, or where the condition based maintenance (CBM) data is coming from. However, establishing the position based on single sensors such as accelerometer is difficult and can be less precise for longer runs due to accelerometer drift. <CIT> discloses a communication system to be used in a system having a plurality of sensors and controllers, comprising a main gateway connected to a first controller of the system, the main gateway wirelessly connectable to a management center of the system via the internet or a cloud system, and at least one satellite gateway connected to at least one second controller of the system. Each of the sensors and controllers collects data according to its intended purpose which is then transferred to the respective satellite gateway. The main gateway then passes data to the management center via the internet or the cloud system. <CIT> discloses a method for data transfer in a conveyance system.

According to a first aspect of the present invention there is provided an elevator system, including a gateway configured to: receive, from an elevator car controller of an elevator car that is operationally positioned in a hoistway of a building, car controller data for the elevator car that includes a car positional log of the elevator car in the hoistway; receive, from a beacon mounted to the elevator car, car operational data for the elevator car that includes car and door data representing car and door events; and transmit, to one of an elevator management center and a cloud service, a combination of the car controller data and the car operational data to identify an alert condition and a position of the elevator car in the hoistway during the alert condition, wherein the gateway is configured to stitch together the car controller data and the car operational data to identify the alert condition and position of the elevator car during the alert condition.

The car controller data and the car operational data are both timestamped so that stitching together the car controller data and the car operational data identifies the alert condition and position of the elevator car during the alert condition.

In some embodiments, the beacon communicates wirelessly with the gateway; and the gateway communicates wirelessly with the one of the elevator management center and the cloud service.

In some embodiments, the elevator car controller communicates wirelessly with the beacon via a service tool. In some embodiments, the service tool communicates wirelessly with the controller via a wireless dongle. In some embodiments, the service tool is a mobile phone or tablet.

In some embodiments, mounted to the elevator car, that communicate by wired or wireless connections with the beacon, wherein the car and door data includes sensor detected data and beacon detected data.

In some embodiments, to identify the alert condition: the sensor data is processed, in whole or part, by one or more of: one of more of the sensors; the beacon; the gateway; the elevator management center; and the cloud service; and the beacon detected data is processed, in whole or part, by one or more of: the beacon; the gateway; the elevator management center; and the cloud service.

In some embodiments, the sensors are configured to sense one or more of elevator car speed, current draw, door loading, leveling, position, acceleration, and vibration; and/or the beacon is mounted on or near an elevator car door of the elevator car to detect a number of door openings of elevator doors per hoistway landing, and elevator car starts and stops.

According to a second aspect of the invention there is provided a method of monitoring an elevator system, including receiving by a gateway, from an elevator car controller of an elevator car that is operationally positioned in a hoistway of a building, car controller data for the elevator car that includes a car positional log of the elevator car in the hoistway; receiving by the gateway, from a beacon mounted to the elevator car, car operational data for the elevator car that includes car and door data representing car and door events; transmitting, by the gateway to one of an elevator management center and a cloud service, a combination of the car controller data and the car operational data to identify an alert condition and a position of the elevator car in the hoistway during the alert condition; and the gateway or the one of the elevator management center and the cloud service stitching together the car controller data and the car operational data to identify the alert condition and position of the elevator car during the alert condition.

The method includes timestamping the controller data and the car operational data so that stitching together the car controller data and the car operational data identifies the alert condition and position of the elevator car during the alert condition.

In some embodiments, the method includes the beacon communicating wirelessly with the gateway; and the gateway communicating wirelessly with the one of the elevator management center and the cloud service.

In some embodiments, the method includes the elevator car controller communicating wirelessly with the beacon via a service tool. In some embodiments, the service tool communicates wirelessly with the controller via a wireless dongle. In some embodiments, the service tool is a mobile phone or tablet.

In some embodiments, the method includes sensors, mounted to the elevator car, communicating by wired or wireless connections with the beacon, wherein the car and door data includes sensor detected data and beacon detected data.

In some embodiments, the method includes identifying the alert condition by: processing the sensor data, in whole or part, by one or more of: one of more of the sensors; the beacon; the gateway; the elevator management center; and the cloud service; and processing the beacon detected data, in whole or part, by one or more of: the beacon; the gateway; the elevator management center; and the cloud service.

In some embodiments, the method includes the sensors sensing one or more of elevator car speed, current draw, door loading, leveling, position, acceleration, and vibration; and/or the beacon, mounted on or near an elevator car door of the elevator car, detecting a number of door openings of elevator doors per hoistway landing, and elevator car starts and stops.

<FIG> is a perspective view of an elevator system <NUM> including an elevator car <NUM> having an elevator door <NUM>, a counterweight <NUM>, a tension member <NUM>, a guide rail <NUM>, a machine <NUM>, a position reference system <NUM>, and an elevator car controller (controller) <NUM>. The counterweight <NUM> is configured to balance a load of the elevator car <NUM> and is configured to facilitate movement of the elevator car <NUM> concurrently and in an opposite direction with respect to the counterweight <NUM> within an elevator hoistway (hoistway) <NUM> and along the guide rail <NUM>.

The position reference system <NUM> may be mounted on a fixed part at the top of the hoistway <NUM>, such as on a support or guide rail, and may be configured to provide position signals related to a position of the elevator car <NUM> within the hoistway <NUM>. The position reference system <NUM> can be any device or mechanism for monitoring a position of an elevator car and/or counterweight, as known in the art.

The controller <NUM> is located, as shown, in a controller room <NUM> of the hoistway <NUM> and is configured to control the operation of the elevator system <NUM>, and particularly the elevator car <NUM>. When moving up or down within the hoistway <NUM> along guide rail <NUM>, the elevator car <NUM> may stop at one or more landings <NUM> as controlled by the controller <NUM>.

The machine <NUM> may include a traction sheave that imparts force to tension member <NUM> to move the elevator car <NUM> within the hoistway <NUM>.

Although shown and described with a roping system including tension member <NUM>, elevator systems that employ other methods and mechanisms of moving an elevator car within an hoistway may employ embodiments of the present disclosure.

<FIG> is a schematic diagram depicting a communication system implemented in an elevator system according to an exemplary embodiment of the invention. The communication system shown in <FIG> comprises a main gateway (GW) 20a and first to fourth satellite gateways 20b-20e which are wirelessly connected to each other via a wireless local area network (WLAN). The main gateway 20a is connected to an elevator controller <NUM> and each of the first to fourth satellite gateways 20b-20e is connected to at least one sensor arranged at a certain place in the elevator system <NUM> to collect data necessary for operation and management of the elevator system <NUM>. For example, in <FIG>, the first satellite gateway 20b is connected a speed sensor 30a, a current sensor 30b, and an encoder 30c, the second satellite gateway 20c is connected to a door sensor 30d and a load sensor 30e, the third satellite gateway 20d is connected with a leveling sensor 30f and an elevator hall control panel 230b, and the fourth satellite sensor 20e is connected with an elevator hall control panel 230a and a position sensor <NUM>. The elevator controller panels 230a/230b may connect with the elevator controller <NUM> by means of electrical lines (not shown), in particular by an electric bus, e.g. a field bus such as a CAN bus, or by means of wireless data transmission.

The connection between each sensor and each gateway may be wireless or wired. Wireless connections may apply protocols that include local area network (LAN, or WLAN for wireless LAN) protocols and/or a private area network (PAN) protocols. LAN protocols include WiFi technology, based on the Section <NUM> standards from the Institute of Electrical and Electronics Engineers (IEEE). PAN protocols include, for example, Bluetooth Low Energy (BTLE), which is a wireless technology standard designed and marketed by the Bluetooth Special Interest Group (SIG) for exchanging data over short distances using short-wavelength radio waves. PAN protocols also include Zigbee, a technology based on Section <NUM>. <NUM> protocols from the IEEE, representing a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios for low-power lowbandwidth needs. Such protocols also include Z-Wave, which is a wireless communications protocol supported by the Z-Wave Alliance that uses a mesh network, applying low-energy radio waves to communicate between devices such as appliances, allowing for wireless control of the same. Other applicable protocols include Low Power WAN (LPWAN), which is a wireless wide area network (WAN) designed to allow long-range communications at a low bit rates, to enable end devices to operate for extended periods of time (years) using battery power. Long Range WAN (LoRaWAN) is one type of LPWAN maintained by the LoRa Alliance, and is a media access control (MAC) layer protocol for transferring management and application messages between a network server and application server, respectively. Such wireless connections may also include radio-frequency identification (RFID) technology, used for communicating with an integrated chip (IC), e.g., on an RFID smartcard. In addition, Sub <NUM> RF equipment operates in the ISM (industrial, scientific and medical) spectrum bands below Sub <NUM> - typically in the <NUM> - <NUM>, <NUM> and the <NUM> frequency range. This spectrum band below <NUM> is particularly useful for RF IOT (internet of things) applications. The above is not intended on limiting the scope of applicable wireless technologies. Wireless communications for the disclosed systems include cellular, e.g. <NUM>/<NUM>/<NUM> (etc.).

Wired connections may include, for example, cables/interfaces conforming to RS (recommended standard)-<NUM>, also known as the TIA/EIA-<NUM>, a technical standard supported by the Telecommunications Industry Association (TIA) and the Electronic Industries Alliance (EIA) that specifies electrical characteristics of a digital signaling circuit. Wired connections also include cables/interfaces conforming to RS-<NUM>, a technical standard for serial communication transmission of data, which defines signals connecting between a DTE (data terminal equipment) such as a computer terminal, and a DCE (data circuit-terminating equipment or data communication equipment), such as a modem. Wired connections may also include cables/interfaces conforming to the Modbus serial communications protocol, managed by the Modbus Organization, which is a master/slave protocol designed for use with programmable logic controllers (PLCs) and which is utilized to connect industrial electronic devices. Wired connections may also include cables/interfaces under the PROFibus (Process Field Bus) standard managed by PROFIBUS & PROFINET International (PI), and is a standard for fieldbus communication in automation technology, published as part of IEC (International Electrotechnical Commission) <NUM>. Wired communications may also include a Controller Area Network (CAN) bus, utilizing a CAN protocol released by the International Organization for Standards (ISO), which is a standard that allows microcontrollers and devices to exchange messages with each other in applications without a host computer. The above is not intended on limiting the scope of applicable wired technologies.

As described above, the elevator controller <NUM> is configured to control operation of the elevator system by, e.g. controlling the machine <NUM>. In one embodiment, the ones of the sensors 30a-<NUM> communicates directly with the main gateway 20a while others of the sensors 30a-<NUM> communicate with the satellite gateways 20b-20C. In one embodiment all of the sensors 30a-<NUM> communicate directly with the main gateway 20a.

It is to be understood that the configuration depicted in <FIG> is exemplary. In other words, there is no limitation in the number of sensors which are connected with each of the main gateway 20a and the satellite gateways 20b-20d. For example, it may also be possible for one main gateway or one satellite gateway to be connected with one sensor or one controller. In addition, there may be other types of sensors or controllers arranged somewhere in the elevator system <NUM>. As another example, at least one sensor like a temperature sensor may be connected to the main gateway <NUM>.

In <FIG>, each of the sensors 30a-<NUM>, the elevator controller <NUM> and the elevator control panel 230a collects data according to its intended purpose. For example, the speed sensor 31a measures a speed of an elevator car <NUM> in the elevator system <NUM>, the current sensor 30b detects a working current of a motor used in the elevator system <NUM>, and the encoder 30c detects a rotation speed of the motor, etc. The data collected by each of the sensors 30a-<NUM>, the elevator controller <NUM>, the elevator control panel 230a is transferred to a corresponding gateway, i.e. one of the main gateway 20a and the first to fourth gateways 20b-20d which is connected with the sensor transferring the data. In one embodiment in addition to or in place of one of the sensors 30a-<NUM>, an accelerometer is used to detect accelerations and/or vibrations.

Each of the satellite gateways 20b-20e receiving the data from a corresponding sensor or controller performs a predefined data processing on the received data and transfers the resulting data to the main gateway 20a via the WLAN. Alternatively, it may also be possible for the satellite gateways 20b-20e to transfer the data received from the sensors or controllers to the main gateway 20a without data processing.

The WLAN, as indicated, may be any of a Bluetooth Low Energy (BLE), a Sub-<NUM> RF, a Low-Power Wide-Area Network (LPWAN) including narrowband internet of things (NB-IOT) and Category M1 internet of things (Cat M1-IOT), and a Low-Range Wide-Area-Network (LoRaWAN). The main gateway 20a and the satellite gateways 20b-20e may perform edge computing. Instead of transferring all obtained raw data, each of the main gateway 20a and the satellite gateways 20b-20e performs the predefined data processing with the raw data and the processed data is transferred to the main gateway 20a. For example, in <FIG>, all speed data detected by the speed sensor 30a does not need to be delivered to the elevator management center <NUM> (<FIG>) via the main gateway 20a. Instead, the first satellite gateway 20b connected to the speed sensor 30a may be configured to transmit data only when the measured speed exceeds a predetermined threshold. For the edge computing, each of the main gateway 20a and the satellite gateways 20b-20e needs to be equipped with a data processor necessary for performing the predefined data processing. From the edge computing, real-time data processing near the source of data, i.e. a sensor, is possible and thereby the entire volume of data to be delivered through the network can be significantly decreased. The main gateway 20a is configured to pass the received data to the elevator management center <NUM> via the Internet or the cloud system <NUM> (<FIG>).

<FIG> is another schematic illustration of the elevator system that may employ various embodiments of the present disclosure. <FIG> is a data flow diagram for a communication system associated with the elevator system according to an embodiment. As shown in <FIG>, the elevator system <NUM> may include a gateway <NUM>, which may be any gateway 20a-20d shown in <FIG>, which may also be located in the controller room <NUM>. For simplicity, the gateway <NUM> of <FIG> may be construed as the main gateway 20a of <FIG>.

The gateway <NUM> may be configured to communicate with a controller <NUM> of the elevator car <NUM> that is operationally positioned in the hoistway <NUM> of a building <NUM>. From this communication, the gateway <NUM> may receive car controller data. The car controller data may include a car positional log that identifies a time-based positioning of the elevator car <NUM> in the hoistway <NUM>. The position is, for example, relative to a level (floor) in the hoistway <NUM>.

The gateway <NUM> is configured to communicate with a beacon <NUM> mounted to the elevator car <NUM> to receive car operational data. The car operational data may include car and door data representing time-based car and door events. In one embodiment, the beacon <NUM> may include a wireless transceiver with edge-computing capabilities. These wireless communications may be based on one or more of the protocols and standards identified above.

In one embodiment, the beacon <NUM> may communicate with each of the sensors 30a-<NUM> to obtain, as part of the car operational data, data related to elevator car speed, current draw, door loading, leveling, position, acceleration, vibrations. The connection between the beacon <NUM> and the sensors 30a-<NUM> may also be wired or wireless based on one of the protocols and standards identified above. The beacon <NUM> may also detect car and door events, for the car and door data, including a number of door openings of elevator doors <NUM> per hoistway landing, and elevator car starts and stops.

In one embodiment, the beacon <NUM> may be able to process the car operational data against predetermined thresholds to identify alert conditions, which may be transmitted to the gateway <NUM>. In one embodiment, the sensors 30a-<NUM> may be configured for edge computing and may be able to process sensor data against predetermined thresholds to identify alert conditions. In such embodiment the beacon <NUM> may transmit to the gateway <NUM> the alert conditions identified by the sensors 30a-<NUM> and alert conditions it (the beacon <NUM>) identifies from the detected car and door events.

In one embodiment, the beacon <NUM> may transmit, unprocessed, some or all of the sensor and detected data to the gateway <NUM>. In such embodiment, the gateway <NUM> may process the data to identify alert conditions. In one embodiment, the gateway <NUM> may transmit, unprocessed, some or all of the sensor and beacon detected data to the elevator management center <NUM> or the cloud service <NUM> to process the data and identify alert conditions.

In one embodiment the car operational data transferred by the beacon <NUM> to the gateway <NUM> includes condition based maintenance (CBM) data. The gateway <NUM> may transmit this data to the elevator management center <NUM> or the cloud service <NUM>. The CBM data may be obtained by the beacon <NUM> while acting on the senor and beacon detected data. Condition based maintenance (sometimes referred to as condition based monitoring) is maintenance that is performed when a need arises. CBM is part of an industry based predictive maintenance effort, enabled by artificial intelligence (AI) technologies and connectivity abilities. CBM is performed after one or more indicators (e.g. from the collected data) show that equipment is going to fail or that equipment performance is deteriorating. CBM may be applicable to missioncritical systems that incorporate active redundancy and fault reporting. CBM may also be applicable to non-mission critical systems that lack redundancy and fault reporting. CBM is based on using real-time data to prioritize and optimize maintenance resources, e.g., to determine equipment health, and act when maintenance is necessary. CBM utilizes instrumentation (such as the sensors) together with analytical tools to enable maintenance personnel to decide the right time to perform maintenance on equipment. CBM may minimize spare parts cost, system downtime and time spent on maintenance.

In one embodiment, the gateway <NUM> stitches the car controller data with the car operational data, that is then sent to the elevator management center <NUM> or the cloud service <NUM>. The stitching is based on timestamps in the different sets of data. In one embodiment, the gateway <NUM>, elevator management center <NUM> or cloud service <NUM> may be configured to synchronize the stitched data to identify alert conditions and exact locations of the elevator <NUM> by time.

In one embodiment, the gateway <NUM> may be configured to communicate with the controller <NUM> to obtain car controller data every few seconds to every few minutes. The gateway <NUM> may be configured to communicate with the beacon <NUM> every few seconds to every few minutes to obtain car operational data. The gateway <NUM> may be configured to transmit data to elevator management center <NUM> or cloud service <NUM> multiple times an hour, such as every ten minutes.

In one embodiment, the gateway <NUM> may be configured to wirelessly communicate with the controller <NUM> via a smart service tool (SSVT) <NUM> to obtain the car controller data. That is, a Service Tool (SVT) is a known device that allows a mechanic to obtain and modify information from within the elevator controller. Information to be viewed or modified may be parameter settings, such as duration timers, max elevator speed, addresses for each hall call button, etc. Information viewed may also be fault logs, such as time-stamped occurrences of communication errors, stuck doors, faulty switches, etc. Information viewed may also be event logs, such as time-stamped occurrences of activity events like door opened, door closed, car moved up, car parked, etc. A Smart Service Tool (SSVT) is a known device that has increased capabilities as compared with the SVT. For example, SSVT is based on technology in a smart phone so it has additional connectivity options. In some implementations, the SSVT is executable software on a mobile device such as a mobile phone or tablet. Additionally, there is the ability to add more functions to the SSVT than what is on the traditional SVT. Such capabilities include being able to store and forward large amounts of data, including for example an elevator event log (e.g., which may store timestamped events), a list of all parameter settings from the elevator controller, and the ability to store a new/updated software/firmware images that will be installed in the elevator controller. For the SSVT to perform these functions, it may need to communicate with elevators controllers (such as legacy controllers) via a wired SVT port connection, which may utilize RS422 compliant connectors (or wired connectors compliant with any other one of the wired specifications identified in this disclosure). With such controllers, the use of a wireless adaptor (dongle) may facilitate the connection. Other controllers may be equipped for wireless communications, which enable for a wireless communications with the SSVT applying any one of the wireless protocols identified in this disclosure.

According to the embodiments, the SSVT <NUM> may be used as a passthrough connection device to synchronize the gateway <NUM> and beacon <NUM>, or pass relevant information from one to the other. These communications may occur when a mechanic is on the jobsite, with the SSVT <NUM> nearby. Alternatively, the gateway <NUM> may communicate with the elevator controller <NUM> equipped with a wireless transceiver (e.g., wireless dongle), as indicated above. Through this wireless connection, the gateway <NUM> may obtain the information that would normally be obtained through the wired connection with the SVT.

Turning to <FIG>, a flowchart shows a method of monitoring an elevator system <NUM>. As shown in block <NUM>, the method includes receiving by the gateway <NUM>, from the elevator car controller <NUM> of the elevator car <NUM> that is operationally positioned in the hoistway <NUM> of the building <NUM> via one or more of the wireless protocols identified above, car controller data for the elevator car <NUM> that includes a car positional log of the elevator car <NUM> in the hoistway <NUM>. As shown in block <NUM>, the method includes receiving by the gateway <NUM>, from the beacon <NUM> mounted to the elevator car <NUM> via one or more of the wireless protocols identified above, car operational data for the elevator car <NUM> that includes car and door data representing car and door events. As shown in block <NUM>, the method includes transmitting, by the gateway <NUM> to one of the elevator management center <NUM> and the cloud service <NUM> via one or more of the wireless protocols identified above, a combination of the car controller data and the car operational data to identify an alert condition and a position of the elevator car <NUM> in the hoistway <NUM> during the alert condition.

As shown in block <NUM>, the method includes the gateway <NUM> or the one of the elevator management center <NUM> and the cloud service <NUM> stitching together the car controller data and the car operational data to identify the alert condition and position of the elevator car <NUM> during the alert condition.

As shown in block <NUM> the method includes timestamping the car controller data and the car operational data so that stitching together the car controller data and the car operational data may identify the alert condition and position of the elevator car during the alert condition.

As shown in block <NUM> the method may include the elevator car controller <NUM> communicating wirelessly with the beacon <NUM> via the service tool <NUM>, via one or more of the wireless protocols identified above. As indicated the service tool <NUM> may communicate with the elevator controller via a wireless dongle. More specifically, the service tool may be a mobile phone or tablet.

As shown in block <NUM>, the method may include the sensors 30a-<NUM>, mounted to the elevator car <NUM>, communicating by wired or wireless connections with the beacon <NUM>, via connections complying with one or more of the wired and wireless standards and protocols identified above. As indicated the car and door data includes sensor detected data and beacon detected data.

As shown in block <NUM>, the method may include identifying the alert condition by processing the sensor data, in whole or part, by one or more of: one of more of the sensors 30a-<NUM>; the beacon <NUM>; the gateway <NUM>; the elevator management center <NUM>; and the cloud service <NUM>. The processing on the sensor 30a-<NUM> and beacon <NUM> may be, for example, via edge computing. As shown in block <NUM>, the method may include identifying the alert condition by processing the beacon detected data, in whole or part, by one or more of: the beacon <NUM>; the gateway <NUM>; the elevator management center <NUM>; and the cloud service.

As shown in block <NUM>, the method may include the sensors 30a-<NUM> sensing one or more of elevator car speed, current draw, door loading, leveling, position, acceleration, and vibration. As shown in block <NUM>, the method may include the beacon <NUM>, mounted on or near the elevator car door <NUM> of the elevator car <NUM>, detecting a number of door openings of elevator doors per hoistway landing, and elevator car starts and stops.

With the disclosed embodiments, the controller knowledge about precise car position is leveraged to ensure correct labeling of beacon readings with car position in the hoistway. The disclosed embodiments include: a system where smart device is connected to the controller and a beacon is mounted on the car; the smart device reads a car position from the controller; a beacon detects and collects information on car and door actions, for example, a number of door openings at the landing, car start, car stop, CBM data for door cycles/runs; the beacon sending data related to event to a gateway; the gateway attaching the an identified car position to the message; and a smart device adding additional data from the controller to the message sent to the beacon, for example, an event log and a load weighing system. This would provide information about the load inside the elevator car (empty, lightly loaded, fully loaded).

Benefits of the disclosed embodiments include reliable CBM data, due timestamping events with car position; and a precise car positioning system, as the controller knows a car position with exacting (millimeter) accuracy. Additionally, the disclosed embodiments may provide for a relatively simpler elevator car commissioning process, there may be no need for calibrating sensors to learn run locations. Further, a discrepancy between what an on-board sensor position logic determines and the actual location based on the controller may enable fine-tuning an overall fleet-wide position algorithm to be used on elevators, e.g., without controller information.

As described above, embodiments can be in the form of processorimplemented processes and devices for practicing those processes, such as a processor.

Claim 1:
An elevator system (<NUM>), comprising
a gateway (<NUM>) configured to:
receive (<NUM>), from an elevator car controller (<NUM>) of an elevator car (<NUM>) that is operationally positioned in a hoistway (<NUM>) of a building (<NUM>), car controller data for the elevator car (<NUM>) that includes a car positional log of the elevator car (<NUM>) in the hoistway (<NUM>);
receive (<NUM>), from a beacon (<NUM>) mounted to the elevator car (<NUM>), car operational data for the elevator car (<NUM>) that includes car and door data representing car and door events; and
transmit (<NUM>), to one of an elevator management center (<NUM>) and a cloud service (<NUM>), a combination of the car controller data and the car operational data to identify an alert condition and a position of the elevator car (<NUM>) in the hoistway during the alert condition, and
characterized in that:
the gateway (<NUM>) is configured to stitch (<NUM>) together the car controller data and the car operational data to identify the alert condition and position of the elevator car (<NUM>) during the alert condition,
and in that the car controller data and the car operational data are both timestamped (<NUM>) so that stitching together the car controller data and the car operational data identifies the alert condition and position of the elevator car (<NUM>) during the alert condition.