Classifications

• • B—PERFORMING OPERATIONS; TRANSPORTING
  • B66—HOISTING; LIFTING; HAULING
  • B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
  • B66B1/00—Control systems of elevators in general
  • B66B1/34—Details, e.g. call counting devices, data transmission from car to control system, devices giving information to the control system
  • B66B1/3415—Control system configuration and the data transmission or communication within the control system
  • B66B1/3446—Data transmission or communication within the control system
  • B66B1/3453—Procedure or protocol for the data transmission or communication
• • B—PERFORMING OPERATIONS; TRANSPORTING
  • B66—HOISTING; LIFTING; HAULING
  • B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
  • B66B1/00—Control systems of elevators in general
  • B66B1/34—Details, e.g. call counting devices, data transmission from car to control system, devices giving information to the control system
• • B—PERFORMING OPERATIONS; TRANSPORTING
  • B66—HOISTING; LIFTING; HAULING
  • B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
  • B66B1/00—Control systems of elevators in general
  • B66B1/34—Details, e.g. call counting devices, data transmission from car to control system, devices giving information to the control system
  • B66B1/3415—Control system configuration and the data transmission or communication within the control system
  • B66B1/3446—Data transmission or communication within the control system
• • B—PERFORMING OPERATIONS; TRANSPORTING
  • B66—HOISTING; LIFTING; HAULING
  • B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
  • B66B5/00—Applications of checking, fault-correcting, or safety devices in elevators
  • B66B5/0006—Monitoring devices or performance analysers
  • B66B5/0018—Devices monitoring the operating condition of the elevator system
  • B66B5/0031—Devices monitoring the operating condition of the elevator system for safety reasons
• • B—PERFORMING OPERATIONS; TRANSPORTING
  • B66—HOISTING; LIFTING; HAULING
  • B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
  • B66B5/00—Applications of checking, fault-correcting, or safety devices in elevators
  • B66B5/0087—Devices facilitating maintenance, repair or inspection tasks

Definitions

• the disclosed technology pertains to transmitting safety related information in an elevator installation.
• the technology disclosed herein can be used to implement a safety information communication system comprising an input device and an output device.
• the input device can comprise a communication module and a first plurality of microcontrollers
• the output device can comprise a plurality of serial peripheral interfaces and a second plurality of microcontrollers.
• a first plurality of microcontrollers from an input device can be comprised of microcontrollers which are each configured to periodically receive a plurality of items of safety related data for an elevator car, build a first data package, and send the first data package to the communication module.
• the communication module in turn, can be configured to transmit the first data package to the output device in a serial format.
• a second plurality of microcontrollers in an output device can also comprise microcontrollers which are each configured to perform a set of tasks.
• a set of tasks that the microcontrollers from the second plurality of microcontrollers could be configured to perform could comprise receiving the first data package, checking for errors in the first data package, building a second data package, and sending the second data package to an elevator controller via the plurality of serial peripheral interfaces.
• the input device can be configured to cross check the safety related data among the microcontrollers from the first plurality of microcontrollers comprised by the input device.
• a first data package built by the microcontrollers comprised by the input device could comprise the plurality of items of safety related data for the elevator car and a code for errors detected by the input device.
• the second data package built by the microcontrollers comprised by the output device could comprise the plurality of items of safety data for the elevator car, the code for errors detected by the first input device, and a code for errors detected by the output device.
• Figure 1 depicts a high level overview of a system which could be used to capture elevator safety related information and transmit it over a serial connection.
• Figure 2 illustrates an exemplary set of components which could be used to implement a serialization module such as shown in figure 1.
• Figure 3 illustrates and exemplary format which could be used for the transmission of data between serialization and deserialization modules in a system such as shown in figure 1.
• Figure 4 illustrates an exemplary set of components which could be used to implement a deserialization module such as shown in figure 1.
• Figure 5 illustrates an exemplary format which could be used for data packages communicated between a deserialization module and a controller.
• figure 1 depicts a high level overview of a system which could be used to capture elevator safety related information and transmit it over a serial connection.
• safety related information is captured from switches [101][102][116] representing elevator doors, stop switches, inspection switches and various other safety based switches.
• a typical set of switches could be Car Door Contact Front (CDCF), Car Door Contact Rear (CDCR), Final Limit (FTSD), Safety Gear Switch (SAFGR), In-car stop switch (CST), Cartop inspection transfer switch (INCTM), Cartop inspection up (INCTU), Cartop inspection down (INCTD), Cartop Inspection Enable (INCTE), Hoistway Enable switch (INHAM), and 7 other switches wired in series to 1 input (SAFCAR) including Emergency Exit switch, Comp Chain Pull-out switch, Pendant Station Stop switch, Car Movement Lock, Cartop stop switch, Rear Cartop stop switch, and fireman stop switch.
• Other switches or combinations of switches are also possible, and the particular switches used can vary from installation to installation (e.g., based on local safety codes).
• the inventors' technology might be configured to read information from a larger number of switches than are actually present, in which case the absent switch(es) could be replaced by wire jumper(s).
• a system such as shown in figure 1 can also capture safety related information from other types of devices, such as one or more sensors [117] used to detect the position, velocity and/or speed of an elevator car.
• This capture can be achieved through use of a serialization module [118], which could be configured to read the safety related information from the switches [101] [102] [116] and/or various sensors [117], and to send it in serial form over a traveling cable [119] to a deserialization module [120].
• the deserialization module [120] could be configured to, once it had received the safety related information, deserialize the information and communicate it to an elevator controller [121].
• other types of safety related information could be captured and sent to the deserialization module [120] as well.
• external sensors [117] such as shown in that figure could be absolute position sensors which could be configured to detect faults as part of their position and velocity calculations.
• any faults detected by an external sensor [117] could be sent to the serialization module [118] from which they could be communicated to, and handled by, a controller [121] via the deserialization module [120] in a manner similar to that described herein for other types of errors.
• the serialization module [118] will be configured to send the safety related information via transmissions taking place every 5ms over a single twisted pair cable up to 1500 meters long using a non-return to zero code.
• the serialization module [118] will be configured to send the safety related information via transmissions taking place every 5ms over a single twisted pair cable up to 1500 meters long using a non-return to zero code.
• variations on that preferred approach such as the use of other transmission frequencies, other types of physical media for the traveling cable [119] (e.g., redundant transmission wires), or other types of encoding schemes (e.g., Hamming codes, return to zero codes, etc) known to those of ordinary skill in the art could also be used to implement a system shown in figure 1.
• FIG. 1 To illustrate how those components could interact with each other and operate in a serialization module [118], the components of figure 2 are described in the context of performing four main functions: reading safety related switches [ 101 ] [ 102] [116], reading information from an external sensor [117], building a data package for transmission to the deserialization module [120], and transmitting the safety related information to the deserialization module [120].
• the functions of reading the safety related switches [101] [102] [116] and reading the information from the external sensor [117] can be performed using two microcontrollers [201][202] and two network interfaces (depicted as CAN interfaces [204] [205]).
• These microcontrollers [201][202] would preferably be configured (e.g., through appropriately programmed software or firmware) to compare the read signals on the switch input terminals [203] (shown as 16 input terminals in figure 2, though different numbers (e.g., more terminals in a serialization module [118] which intended to capture input from more than 16 switches) could also be used).
• microcontrollers [201] [202] would also preferably each be configured to receive and cross check information from multiple external sensors [117] via the corresponding CAN interfaces [204] [205]. These comparisons and cross checks could be used to detect data corruption, short circuits or stuck-at-failures, thereby increasing the overall safety of the system.
• each microcontroller [201] [202] will independently build the data package. This allows the integrity of the microcontrollers [201] [202] to be checked through comparison of the independently built data packages.
• one of the microcontrollers [201] could operate as a master microcontroller [which would transmit a data package to the communiation module [206], while the other microcontroller [202] could operate as a slave microcontroller which would not transmit a data package, but would instead monitor the communication module [206] for data packages transmitted by the master microcontroller [201].
• a slave microcontroller when a slave microcontroller detects a transmission from the master microcontroller it will compare the data package in that communication with its own independently build data package and disable the inbound transmission to the communication module if the packages are inconsistent.
• other approaches to ensuring the consistency of the data packets such as using a separate comparison component of the serialization module [118] (not shown in figure 1), or through use of microcontrollers in the deserialization module [120] are also possible, and will be immediately apparent to, and could be implemented without undue experimentation by, those of ordinary skill in the art in light of this disclosure.
• the information in a data package can also support increased reliability, and therefore safety, for the system.
• the microcontrollers [201] [202] and/or a separate communications module [206] can be configured to create the data package to include, in addition to safety related information captured from sensors or switches, failure codes or status information determined by the serialization module [118] itself.
• microprocessors [201] [202] in a serialization module could be configured to detect and generate error codes for internal errors, such as failures of components or failures to communicate with external sensors [107].
• microprocessors [201] [202] could be configured to detect errors in the operation of an external sensor [107], such as by checking, for example, the sequence number, time expectation, or CRC from a frame used in communicating data from an external sensor [107], to verify that that data is valid.
• a microprocessor [201] [202] from a serialization module could be configured to cross check information from those channels (e.g., by comparing the positions of the two channels and, if they do not match an expected fixed position offset, logging a communication error).
• Various types of administrative data could also be added to a data package, such as a sequence counter and a cyclic redundancy check/checksum value over the whole data carrier which could potentially be used by the deserialization module [120] to find corrupted data.
• FIG 3 An exemplary format which could be used for a data package to be transmitted between the serialization module [118] (referred to as S3I) and the deserialization module [120] (referred to as S30) is illustrated in figure 3.
• the first byte of the package [301] will include the sequence counter added by the microcontrollers [201] [202].
• the next ten bytes of the package [302] will include position and speed information retrieved from external sensors (referred to in figure 3 as data from the APS, an acronym for Absolute Position Sensor).
• the following two bytes of the package [303] include information on the status of the safety related switches, with the values of the individual bits (e.g., zero or one) indicating the status of the individual switches.
• the two bytes after that [304] include information on the status of the serialization module [118].
• This status information can include information such as the manufacturer of the external sensors, whether the external sensors are properly aligned or need alignment for some reason (e.g., reading too close, reading too far, reading too left, reading too right), and whether the elevator car associated with the serialization module is ok, is recommended for service, is operating in a warning state (e.g., that it should go to its target floor then cease operation), and whether it is (or should be) stopped.
• the next one byte field in the package [305] would include codes providing information on errors.
• error codes could indicate error types such as that there is an error in the position or velocity found by an external sensor, that an internal error was detected in the serialization module, that there is a fault in a switch, that there are alignment errors, communication faults or internal errors in a sensor, or other types of error information.
• the last two bytes [306] of a package sent using the format of figure 3 will include a cyclic redundancy check value which, as described previously, can be used to identify corrupted data in the package.
• the elevator associated with the serialization module [118] which sent the package with the error codes will be immediately stopped so that the problem associated with the error codes can be addressed and the elevator can resume safe operation.
• the elevator associated with the serialization module [118] whose package was not received will preferably be stopped so that the problem which caused the loss of communication can be identified and addressed, thereby allowing the elevator to resume safe operation.
• FIG 4 that figure illustrates an exemplary set of components which could be used to implement a deserialization module [120] such as shown in figure 1.
• the discussion of figure 4 focuses on three main functions those components could perform - reading data packages received from the serialization module [118], building new data packages for transmission to the controller [121], and actually transmitting the new data packages to the controller [121] - to illustrate how those components could operate and interact with each other.
• the following discussion of the components depicted in figure 4 should be understood as being illustrative only, and should not be treated as implying limitations on the protection accorded by this document or any related document.
• the exemplary deserialization module [120] depicted in figure 4 includes parallel microcontrollers [401] [402]. These microcontrollers [401] [402] can be configured to retrieve the data packages sent from the serialization module [118] and check those packages for consistency with each other, as well as for internal data corruption (e.g., using sequence numbers and cyclic redundancy check values, as described previously). The microcontrollers [401][402] can also be configured to, once the data packages have been retrieved and checked, use the information from those data packages to build new data packages which will be sent to the elevator controller [121].
• a deserialization module [120] such as discussed in the context of figure 4 could be implemented in a variety of manners, including using a master/slave design similar to that discussed in the context of figure 2.
• a master microprocessor [401] would receive data packages from the serialization module [118] and build a new data package which could be transmitted to the elevator controller [121].
• the slave microprocessor [402] would receive the same data package from the serialization module [118] and independently build a new data package.
• the slave microprocessor [402] would monitor for transmissions from the master microprocessor [401] and would compare the two independently created new data packages. If the slave microprocessor [402] detected any inconsistencies across the two independently created new data packages it would prevent the elevator controller [121] from receiving the new data package sent by the master microcontroller [401].
• FIG. 5 An exemplary format which could be used for new data packages created by a deserialization module [120] is shown in figure 5. As shown in the labels in that figure, most of the data from the new data package is actually taken directly from the data packages received from the serialization module [118]. However, a new data package following the format of figure 5 will differ from the data package received from the serialization module [118] in that the first [501] and last [502] bytes of the new package include new sequence counter and cyclic redundancy check values determined by the deserialization module [120], rather than simply repeating the values from the original data package.

Landscapes

• Engineering & Computer Science (AREA)
• Automation & Control Theory (AREA)
• Computer Networks & Wireless Communication (AREA)
• Maintenance And Inspection Apparatuses For Elevators (AREA)
• Indicating And Signalling Devices For Elevators (AREA)

Priority Applications (5)

Applications Claiming Priority (4)

Publications (1)

Family

ID=52146550

Family Applications (1)

Country Status (7)

Cited By (2)

Families Citing this family (10)

Citations (4)

Family Cites Families (34)

• 2014
  • 2014-03-19 US US14/219,494 patent/US9452909B2/en active Active
  • 2014-10-23 EP EP14819070.5A patent/EP3060507B1/en active Active
  • 2014-10-23 CN CN201480058006.2A patent/CN105764825B/zh active Active
  • 2014-10-23 WO PCT/IB2014/002553 patent/WO2015059565A1/en not_active Ceased
  • 2014-10-23 BR BR112016009081-0A patent/BR112016009081B1/pt active IP Right Grant
  • 2014-10-23 CA CA2926769A patent/CA2926769A1/en not_active Abandoned
  • 2014-10-23 ES ES14819070T patent/ES2908606T3/es active Active

Patent Citations (4)

Also Published As

Similar Documents

Legal Events