DE69201965T2 - Verfahren zur Zuteilung von Nachrichtenkennungen im Datenübertragungsnetzwerk eines Aufzugsystems. - Google Patents

Verfahren zur Zuteilung von Nachrichtenkennungen im Datenübertragungsnetzwerk eines Aufzugsystems.

Info

Publication number
DE69201965T2
DE69201965T2 DE69201965T DE69201965T DE69201965T2 DE 69201965 T2 DE69201965 T2 DE 69201965T2 DE 69201965 T DE69201965 T DE 69201965T DE 69201965 T DE69201965 T DE 69201965T DE 69201965 T2 DE69201965 T2 DE 69201965T2
Authority
DE
Germany
Prior art keywords
identifier
message
node
network
identifiers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69201965T
Other languages
English (en)
Other versions
DE69201965D1 (de
Inventor
Lauri Lamberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kone Corp
Original Assignee
Kone Elevator GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kone Elevator GmbH filed Critical Kone Elevator GmbH
Application granted granted Critical
Publication of DE69201965D1 publication Critical patent/DE69201965D1/de
Publication of DE69201965T2 publication Critical patent/DE69201965T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • BPERFORMING OPERATIONS; TRANSPORTING
    • B66HOISTING; LIFTING; HAULING
    • B66BELEVATORS; ESCALATORS OR MOVING WALKWAYS
    • B66B1/00Control systems of elevators in general
    • B66B1/34Details, e.g. call counting devices, data transmission from car to control system, devices giving information to the control system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5038Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B66HOISTING; LIFTING; HAULING
    • B66BELEVATORS; ESCALATORS OR MOVING WALKWAYS
    • B66B1/00Control systems of elevators in general
    • B66B1/34Details, e.g. call counting devices, data transmission from car to control system, devices giving information to the control system
    • B66B1/3415Control system configuration and the data transmission or communication within the control system
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B66HOISTING; LIFTING; HAULING
    • B66BELEVATORS; ESCALATORS OR MOVING WALKWAYS
    • B66B1/00Control systems of elevators in general
    • B66B1/34Details, e.g. call counting devices, data transmission from car to control system, devices giving information to the control system
    • B66B1/3415Control system configuration and the data transmission or communication within the control system
    • B66B1/3446Data transmission or communication within the control system
    • B66B1/3453Procedure or protocol for the data transmission or communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5046Resolving address allocation conflicts; Testing of addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5092Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Indicating And Signalling Devices For Elevators (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)
  • Monitoring And Testing Of Nuclear Reactors (AREA)
  • Greenhouses (AREA)

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Zuteilen von Nachrichtenkennungen im Datenübertragungsnetzwerk eines Auf Zugsystems gemäß dem Oberbegriff des Anspruchs 1.
  • Das Datenübertragungsnetzwerk eines Auf zugsystem besteht aus einem Bus, einem Steuercomputer und damit verbundenen Betätigungseinrichtungen wie z. B. Rufknöpfen an den Aufzugeingängen und Flurrufknöpfen in den Aufzugkabinen, der Türmotorsteuerung etc., welche die Netzwerkknoten bilden. In CAN (Controller Area Network) Netzwerken, deren Geschwindigkeitscharakteristiken die gute Eignung für deren Verwendung in Aufzugsystemen begründen, wird durch den übermittelnden Knoten bei der Übertragung einer Nachricht eine Nachrichtenkennung benutzt, wohingegen in normalen lokalen Netzwerken eine Knotenkennung (in CAN-Netzwerken eine Nachrichtenkennung) für die Auswahl der zu empfangenden Nachrichten verwendet wird.
  • Die US-A 4 587 511 zeigt ein Netzwerk für ein Aufzugsystem, bei dem Nachrichtenkennungen mittels separater in den Knoten vorgesehener Einstellungsschalter eingestellt werden können, wobei für jeden Knoten separat eine feste Nachrichtenkennung programmiert wird. Oder die Kennungen werden bei dem Knoten unter Verwendung eines separaten Werkzeugs eingestellt. Die Verwendung von Einstellungsschaltern macht den Knoten teurer und schwieriger in der Installation. Wenn fest programmierte Kennungen verwendet werden, stellt jeder Knoten eine Einheit individueller Charakteristiken dar. Dies erschwert deren Herstellung und in einigen Fällen kann es schwierig werden, ein Ersatzteil zu erhalten. Die Verwendung eines separaten Werkzeugs erfordert Zeit und die Verfügbarkeit des in Frage stehenden Werkzeugs, beseitigt jedoch nicht das Risiko falscher Einstellungen.
  • GB-A 2 172 779 zeigt ein lokales Netzwerk für unterschiedliche Zwecke, bei dem Daten zwischen mehreren datenerzeugenden Quellen ausgetauscht werden, die an ein gemeinsames Kabel für die Datenübertragung und den Empfang angekoppelt sind. Eine neue Datenquelle, die an das Kabel angekoppelt wird, teilt sich selber eine einzigartige Adresse auf dem Kabel zu, die aus einer Zufallszahl in einem vorbestimmten Bereich generiert wird. Der neue Teilnehmer übermittelt ein Anfragesignal an die neue Adresse, um festzustellen, ob der neue Adresscode bereits durch einen anderen Teilnehmer verwendet wird oder nicht. Wenn ein Acknowledge-Signal von dem neuen Teilnehmer in Beantwortung des Anfragesignals empfangen wird, wird eine andere Zufallszahl als neuer Adresscode generiert. Die Anfrageprozedur wird mit dem neuen Adresscode wiederholt. Dieses bekannte Verfahren hat jedoch den Nachteil, daß, wenn der festgelegte Rahmen der möglichen Adresscodes gering und die Anzahl der Knoten sehr hoch ist, ein bereits gewählter Adresscode in einer Abfrageprozedur wiederholt als möglicher neuer Adresscode ausgewählt werden kann. In diesem Fall wird eine längere Zeit zur Auswahl eines geeigneten Adresscodes benötigt.
  • Es ist Ziel der vorliegenden Erfindung, die Nachteile der bekannten Lösungen zu vermeiden. Bei dem erfindungsgemäßen Verfahren gemäß Anspruch 1 wählt ein Knoten einen der verfügbaren Nachrichtenkennungen, ohne daß eine separate Einstellung erforderlich wäre.
  • Das erfindungsgemäße Verfahren ermöglicht es, Einstellungsfehler in Verbindung mit der Installation zu vermeiden. Darüber hinaus bietet es eine einfachere Möglichkeit für die Installation der Knoten. Weiterhin sind die Knoten selber billiger, weil z. B. keine separaten Schalter für die Einstellung der Nachrichtenkennungen benötigt werden.
  • Darüber hinaus ist die Herstellung von Knoten die für die gleiche Funktion benötigt werden, leichter, weil sie völlig identisch sind, inklusive der Software. Das Verfahren ermöglicht weiterhin die Feststellung falscher oder identischer Flurnummereinstellungen. In gleicher Weise ermöglicht das Verfahren die Installation völlig identischer Knoten (z. B. Flurrufknöpfe) in dem gleichen Netzwerk.
  • Nachfolgend wird die Erfindung detailliert unter Zuhilfenahme eines Ausführungsbeispiels mit Bezug auf die beiliegende Zeichnung beschrieben. In dieser zeigen:
  • Figur 1 das Datenübertragungsnetzwerk eines Aufzugsystems,
  • Figur 2 die Verbindungen eines Knotens mit dem Netzwerk,
  • Figur 3 die Auswahl einer Kennung,
  • Figur 4 die Verkettungen in dem Auswahlverfahren,
  • Figur 5 ein Diagramm zur Darstellung des Auswahlverfahrens,
  • Figur 6 die Verkettungen in dem Bestätigungsverfahren, und
  • Figur 7 ein Diagramm zur Darstellung des Bestätigungsverfahrens.
  • Figur 1 zeigt eine vereinfachte Darstellung eines CAN-Datenübertragungsnetzwerks in einem Aufzugsystem. Zusätzlich zu dem Bus 1 und dem Steuercomputer (nicht dargestellt) bestehen die Knoten des Netzwerks aus Rufknöpfen 2,3, die auf der gleichen Höhe angeordnet sind, den Flurrufknöpfen 4 in der Aufzugkabine, einem Flur- und Richtungsanzeiger 5 und einer Steuereinheit für den Türmotor (M). Selbstverständlich werden z. B. die Rufknöpfe auf den Fluren für jeden Flur benötigt, so daß ihre Zahl beträchtlich größer ist, als in Figur 1 dargestellt.
  • In dem erfindungsgemäßen Verfahren überprüft bzw. beobachtet jeder mit dem Netzwerk verbundene Knoten 2-6 alle Übertragungen in dem Netzwerk und zeichnet alle Nachrichten auf, die er erkennt. Der Knoten wählt für sich selber eine Nachrichtenkennung unter den Kennungen aus, die er in dem Netzwerk nicht beobachtet, indem er eine Zufallszahl verwendet, die er, wie später erklärt wird, aus einem freilaufenden Zähler erhält. Nachdem der Knoten für sich selber eine Kennung ausgewählt hat, sendet er eine Versuchsabfrage bzw. einen Vorschlag in das Netzwerk, wobei er die Zufallszahl zu der Nachricht hinzufügt. Die Zusatzzahl wird zu der Nachricht hinzugefügt, um sicherzustellen, daß, wenn ein anderer Knoten gerade die gleiche Nachrichtenkennung auswählt und ihre Versuchsabfrage gleichzeitig in das Netzwerk sendet, die Nachrichten kollidieren werden, während ansonsten in einem CAN-Netzwerk eine Kollision zweier gleichzeitig gesendeter identischer Nachrichten nicht detektiert wird.
  • Wenn die Nachricht ohne Kollision übertragen wurde, wird der übertragende Knoten für eine bestimmte Minimalzeit plus einer zusätzlichen zufälligen Verzögerung warten, während der alle anderen Knoten antworten können, ob sie dieselbe Kennung vorher ausgewählt haben. Wenn der Knoten von dem Netzwerk eine Antwort erhält mit der Wirkung, daß die Kennung nicht akzeptiert werden kann, oder wenn eine Kollision während der Übertragung auftritt, wird der Auswahlprozeß wiederholt gestartet, und die in dem vorhergehenden Versuch verwendete Kennung wird in Abhängigkeit von der Antwort als bereits benutzt oder als von einem anderen Knoten vorgeschlagen gespeichert. Im Fall einer Kollision ist der Status "in use", in anderen Fällen wie von der Antwortnachricht angezeigt.
  • Es gibt drei Stufen von Vorschlagsnachrichten ("I propose", "in use", und "I am using"), und jeder Knoten sendet eine "I don't accept"-Nachricht, wenn die von dem Netzwerk erhaltene Nachricht sich auf einer geringeren Stufe oder der gleichen Stufe wie die eigene Nachricht des Knotens befindet. "In use" bedeutet, daß der Knoten beabsichtigt, die fragliche Kennung zu benutzen.
  • Der normale Betrieb eines Knoten wird begonnen, nachdem der Knoten erfolgreich eine Nachricht der "I am using"-Stufe in das Netzwerk gesendet hat, und die Nachricht von den anderen Knoten akzeptiert worden ist. Während des normalen Betriebs überwacht bzw. beobachtet der Knoten die Übertragungen in dem Netzwerk soweit seine eigene Nachrichtenkennung betroffen ist, und, wenn er herausf indet, daß ein anderer Knoten versucht, die gleiche Kennung zu benützen, sendet er eine "I don't accept"-Nachricht, die den Status seiner eigenen Kennung enthält.
  • In Startsituationen können einige Nachrichtenkennungen in dem "I propose"- oder "in use"-Status eines anderen Knotens verbleiben. Deshalb muß etwas vorgesehen sein, um derartige Nachrichtenkennungen in den freien Status zurückzuführen, damit sichergestellt wird, daß auch wenn nahezu alle Kennungen bereits verwendet werden, eine freie Kennung dennoch irgendwo gefunden werden kann. Dies kann z. B. erreicht werden durch eine Anordnung, bei der, wenn die Kennung einen der oben genannten Zustände hat, der mit diesem Status assoziierte Zähler herabgesetzt wird, bis er in den freien Zustand zurückkehrt.
  • Figur 2 zeigt die Knotensoftware der Erfindung in der Form eines SA-Diagramms, dessen Funktion nachfolgend beschrieben ist.
  • Zwischen dem Block 21, der die Auswahl einer Kennung für einen Knoten und ein Netzwerk repräsentiert, und dem Block 22, der die Systemumgebung bzw. Konfiguration repräsentiert, zeigt die Figur den Wert "timer 2" als einen Pfeil, der von der systemumgebung in Richtung der Auswahl zeigt, und das Time-out-Signal als einen Pfeil mit einer unterbrochenen Linie. Zusätzlich zeigt Figur 2 die mit einer unterbrochenen Linie versehenen Pfeile "stop timer", "start timer" und "start timer 2", die von der Auswahl in Richtung auf die Systemumgebung zeigen. Mit Richtung von dem CAN-Chip 23 in Richtung auf die Auswahl sind die mit einer unterbrochenen Linie dargestellten Pfeile "collision" und "bus free" und in der entgegengesetzten Richtung der Pfeil "initialize CAN" und der ebenfalls mit einer unterbrochenen Linie versehen Pfeil "reset CAN" dargestellt. Mit Richtung von der Auswahl zu den andern Knoten 24 sind Pfeile dargestellt, die die drei oben besprochenen Vorschlagsnachrichtenstuf en repräsentieren, die "I don't accept"-Nachricht und die entsprechenden Nachrichten, wie sie in entgegengesetzter Richtung von den anderen Knoten übertragen werden.
  • Figur 3 zeigt eine detailliertere Darstellung des Verfahrens der Kennungsauswahl in dem Netzwerk und einem Knoten. Sie besteht aus dem Kennungsauswahlverfahren 31 und einem Bestätigungsverfahren 32. Zusätzlich enthält Figur 3 eine Tabelle 33 der in dem Netzwerk verwendeten Kennungen, umfassend die freien Kennungen als auch die in Benützung befindlichen. Die oben beschriebenen Nachrichten werden mit diesen auf die in Figur 3 dargestellte Weise wie folgt verbunden: Das Kennungsauswahlverfahren gibt die Ausgangssignale timer stop und start, start of timer 2, network initialization und reset aus. Zusätzlich gibt das Kennungsauswahlverfahren die oben genannten Nachrichtenstufen und seine eigene Nachrichtenkennung an das Bestätigungsverfahren 32 ab. Die Eingänge des Kennungsauswahlverfahrens sind das time-out-Signal, der Wert des timer 2 und bus free als auch cancel von dem Bestätigungsverfahren 32 und collision. Sowohl der Auswahl als auch der Bestätigungsprozeß sind mit der Kennungstabelle 33 verbunden, so daß Information entsprechend der Pfeildarstellung von dem Bestätigungsverfahren zu der Tabelle fließt und in gleicher Weise von dem Auswahlverfahren zu der Tabelle und vice versa.
  • Das Auswahlverfahren 31 wählt die Nachrichtenkennungen unter Verwendung der Tabelle und einer Zufallszahl aus. Die Zufallszahl wird ebenfalls als Basis für die Übertragungsverzögerung verwendet, um Kollisionen zu vermeiden, und sie wird ebenfalls in das Netzwerk gesendet, um eine Kollision im Falle einer gleichzeitigen Übertragung mit den gleichen Kennungen sicherzustellen.
  • Das Bestägigungsverfahren 32 empfängt alle Nachrichten und aktualisiert die Tabelle mit den vorgeschlagenen und verwendeten Kennungen. Es sendet ebenfalls die Abbruchnachrichten (cancel) zu dem Auswahlverfahren, wenn die gleiche Kennung in dem Netzwerk erkannt wird, und stellt sicher, daß vorgeschlagene jedoch nicht in Gebrauch genommene Kennungen freigegeben werden.
  • Wie aus Figur 4 ersichtlich ist, empfängt das Auswahlverfahren 31 die cancel-, time-out-, und bus-free-Nachrichten. Es übermittelt die timer-start- und stop-Nachrichten. Der Wert des timer 2 wird der Zufallszahlgenerierung 41 zugeführt, welche mit dem Auswahlprozeß, der Übertragung der Vorschläge 42-44 und der Auswahl einer neuen Kennung 45 verbunden ist. Die Kennungen werden ebenfalls der Auswahl zugeführt, welche mit einem Speicher 48 verbunden ist, der die ausgewählte Kennung und eine Zufallszahl enthält. Aus diesem Speicher werden die Vorschlagsübertragungs- und freie Kennungs 47-Funktionen gesteuert. Zusätzlich steuert der Auswahlprozeß alle genannten Unterverfahren 41-47, inklusive der reset und initialize CAN Chipfunktion 46. Darüber hinaus empfängt der Auswahlprozeß ein Steuerungssignal von dem "I am using"-Unterprozeß.
  • Wie in Figur 5 dargestellt, startet das Kennungsauswahlverfahren durch Aktivierung der Funktion "reset and initialize CAN chip" eines mit dem Netzwerk verbundenen Knotens und durch Starten des ersten Timer (timer 2'). Der timer 2' kann ein frei laufender Zähler sein. Wenn der Bus frei ist (keiner der Knoten überträgt irgend etwas) wird eine Zufallszahl durch Lesen des Wertes des timers 2 generiert.
  • Danach wird das Verfahren zur Auswahl einer neuen Kennung aktiviert, und eine neue Kennung wird ausgewählt, indem diejenige Kennung gewählt wird, die sich an der durch die Zufallszahl festgelegten Adresse in dem Kennungsspeicher befindet. Wenn die Kennung frei ist, wählt der Knoten sie aus. Hiernach wird ein zweiter Timer gestartet, und das Verfahren wartet auf eine Nachricht in dem Netzwerk oder auf den Start der durch den zweiten Timer aktivierten watchdog Funktion. Wenn eine in dem Netzwerk übertragene Nachricht oder der Start der Zeitüberwachung detektiert wird, wird auf der Basis des Zufallssignals von timer 2' eine zufallsgesteuerte Verzögerung ausgewählt.
  • Nach der Verzögerung wird die erste Nachricht (I propose) in das Netzwerk abgesendet. Die Nachricht enthält die Kennung, die Zufallszahl und den "I propose"-Status. Die Zufallszahl wird verwendet, um eine Kollision im Falle einer gleichzeitigen Übertragung zweier Nachrichten sicherzustellen, weil die Kennungen, wie oben beschrieben wurde, nicht kollidieren, wenn sie identisch sind, wohingegen die Zufallszahlen kollidieren werden. Hiernach wartet das Verfahren eine der Verzögerung entsprechende Zeitspanne, um zu sehen, ob die Kennung bereits verwendet wird. In dieser Stufe ist die Steuergröße k, die die Anzahl der übertragenen "in use"-Statusnachrichten repräsentiert gleich null.
  • Hat nach dem Verstreichen der Verzögerung (time out) keiner der Knoten geantwortet, daß die Kennung bereits in irgendeinem anderen Knoten verwendet wird, wird die zweite Nachricht (in use) in das Netzwerk gesendet. Zur gleichen Zeit wird eine zweiter Timer gestartet, welcher z. B. nach 250 Millisekunden, ein time-out-Signal senden kann. Die zweite Nachricht wird z. B. drei Mal (k < 3) gesendet, wenn keiner der anderen Knoten geantwortet hat, daß die fragliche Kennung reserviert ist. Zwischen den Übertragungen wird eine Wartezeit von beispielsweise 250 Millisekunden eingerichtet.
  • Schließlich wird nach einer festgelegten Verzögerung die dritte Nachricht (I am using) übermittelt, und nach dem time-out-Signal verläßt das Programm den Auswahlprozeß.
  • Wenn ein anderer Knoten die fragliche Kennung an irgendeiner Stufe der Nachrichtenübertragung für sich selbst reserviert hat, (sein Vorschlag befindet sich auf einer höheren Stufe) oder eine Kollision der Nachrichten stattfindet, dann kehrt das Verfahren zu der Generierung einer neuen Zufallszahl zurück.
  • Wie in Figur 6 dargestellt ist, steuert das Bestätigungsverfahren 32 den Nachrichtenempfang 61, die Aktualisierung der Kennungstabelle 62, die Nachrichtenübertragung 63 und das Herabsetzen des Kennungszählers 64. Das Bestätigungsverfahren empfängt die time-out- und collision-Signale als auch die Kennung von dem Nachrichtenempfang. Darüber hinaus ist das Empfangsverfahren mit den Übertragungs- und Aktualisierungsverfahren verbunden.
  • Zusätzlich empfängt das Bestätigungsverfahren die eigene Kennung und die eigenen Vorschläge des Knotens und gibt start-timer-, stop-timer- und cancel-Signale ab.
  • Wie in Figur 7 dargestellt ist, wartet der Kennungsbestätigungsverfahren auf Nachrichten, die von anderen Knoten eintreffen. Wenn eine Nachricht eintrifft, wird sie mit der knoteneigenen Nachrichtenkennung verglichen. Wenn sie von den knoteneigenen Nachrichten abweicht, wird der Status der Nachricht in einem Speicher gespeichert. Wenn die Kennung mit der knoteneigenen Nachricht identisch ist, wird der Status der Nachrichten miteinander verglichen. Wenn die eintreffende Nachricht "does not accept" ist, wird dessen Status in die Tabelle geschrieben, und ein "cancel"-Signal wird an den Auswahlprozeß abgegeben.
  • Wenn die eintreffende Nachricht einen "proposes"-Status hat, und die knoteneigene Nachricht den gleichen Status aufweist, dann wird die eigene Nachricht des Knotens nicht in Benutzung genommen, sondern dem anderen Knoten überlassen. Wiederum wenn die eigene Nachricht des Knotens einen höheren Vorschlagstatus hat, sendet er eine "I don't accept"-Nachricht in das Netzwerk und wartet weiterhin. Ein entsprechendes Verfahren wird auch in den anderen Statusbereichen verfolgt Wenn die Nachrichten den gleichen Status haben, stellt der Knoten die Übertragung ein, und wenn dessen Nachricht einen höheren Status hat, setzt er die Übertragung fort. Jedesmal wenn der Knoten die Übertragung abbricht, aktualisiert er die Tabelle mit der Kennung des anderen Knotens.
  • Wenn nach der Übermittlung einer "I don't accept"-Nachricht keine Kollision stattfindet, beginnt der Knoten auf eine neue Nachricht zu warten. Wenn eine Kollision stattfindet, wird der CAN-Chip zurückgesetzt und initialisiert, bevor mit dem Warten auf eine neue Nachricht begonnen wird. Dies ist ein kontinuierlicher Prozeß. Wenn ein time out stattfindet, während der Knoten auf eine Nachricht wartet, werden die in dem "I propose"und "in use"-Status befindlichen Kennungszähler herabgesetzt, und der Knoten kehrt wiederum in Warteposition zurück. Die Figuren 5 und 7 zeigen für die Bedingung des Verlassens des Status eine Linie, und die hiernach vorzunehmenden Vorgänge werden unterhalb der Linie dargestellt.
  • Es ist für den Fachmann offensichtlich, daß unterschiedliche Ausführungsformen der Erfindung nicht auf die oben beschriebenen Beispiele beschränkt sind, sondern innerhalb des Schutzbereichs der nachfolgenden Ansprüche variiert werden können. Z. B. wenn der Bereich der Nachrichtenkennungen in dem gesamten CAN-Netzwerk verwendet werden soll, kann ein Knoten für sich mehrere Nachrichtenkennungen durch das gleiche Verfahren auswählen.

Claims (6)

1. Verfahren zum Zuteilen von Nachrichtenkennungen zu Nachrichten, die von den Knoten eines CAN-Datenübertragungsnetzwerks in einem Auzugsystems herrühren, derart, daß die Nachrichtenkennungen bei der nachfolgenden Übermittlung korrespondierender Nachrichten verwendet werden können,
dadurch gekennzeichnet,
daß,
- jeder Knoten (2-6) die in dem Netzwerk stattfindenden Datenübertragungen beobachtet bzw. überwacht und jede Nachrichtenkennung speichert, die bereits in dem Netzwerk verwendet wird, und daß
- ein Knoten, immer wenn er eine weitere Kennung anf ordert, eine gültige Nachrichtenkennung auswählt, die noch nicht als im Netzwerk in Benutzung befindlich gespeichert ist, wobei der Auswahlprozeß folgende Schritte umfaßt: Eine Nachricht, die die ausgewählte Kennung enthält, wird in das Netzwerk für einen Verfügbarkeitstest abgesendet, und der Auswahlprozeß wird wiederholt, wenn ein anderer Knoten bereits die entsprechende ausgewählte Kennung ausgewählt hat, in welchem Fall die Kennung als Nachrichtenkennung des anderen Knotens markiert wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Knoten beim Auswählen einer Nachrichtenkennung eine Zufallszahl verwendet, um eine Kennung in einer Kennungstabelle (33) oder dergleichen auszuwählen.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die von dem Knoten abgesendete Nachricht zusätzlich zu der Kennung eine Zufallszahl enthält.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die die Nachrichtenkennung aufweisende Nachricht für einen Verfügbarkeitstest in Form dreier Nachrichten mit unterschiedlichem Status in das Netzwerk gesendet wird, und daß jeder Knoten die von einem anderen Knoten übermittelte Kennung aufhebt, wenn diese den gleichen oder einen geringeren Status als die eigene Kennung des Knotens aufweist.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein Knoten mehrere Nachrichtenkennungen auswählen kann.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Knoten den normalen Betrieb aufnimmt, nachdem er eine Nachricht mit höchstem Status in das Netzwerk gesendet hat und die anderen Knoten diese akzeptiert haben, und daß während des normalen Betriebs der Knoten die Übertragungen in dem Netzwerk überwacht soweit die eigene Nachrichtenkennung betroffen ist, und daß er, wenn er herausfindet, daß ein anderer Knoten versucht, die gleiche Kennung in Benutzung zu nehmen, eine Abbruchmeldung absendet, die den Status der eigenen Kennung enthält.
DE69201965T 1991-01-17 1992-01-17 Verfahren zur Zuteilung von Nachrichtenkennungen im Datenübertragungsnetzwerk eines Aufzugsystems. Expired - Fee Related DE69201965T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FI910260A FI87290C (fi) 1991-01-17 1991-01-17 Foerfarande foer bestaemning av meddelandeidentifierare i ett foer hissar avsett datanaet

Publications (2)

Publication Number Publication Date
DE69201965D1 DE69201965D1 (de) 1995-05-18
DE69201965T2 true DE69201965T2 (de) 1995-08-24

Family

ID=8531758

Family Applications (2)

Application Number Title Priority Date Filing Date
DE69201965T Expired - Fee Related DE69201965T2 (de) 1991-01-17 1992-01-17 Verfahren zur Zuteilung von Nachrichtenkennungen im Datenübertragungsnetzwerk eines Aufzugsystems.
DE199292100752T Pending DE495515T1 (de) 1991-01-17 1992-01-17 Verfahren fuer die erfassung von nachrichtenidentifizierern im datenuebertragungsnetzwerk eines aufzugssystem.

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE199292100752T Pending DE495515T1 (de) 1991-01-17 1992-01-17 Verfahren fuer die erfassung von nachrichtenidentifizierern im datenuebertragungsnetzwerk eines aufzugssystem.

Country Status (10)

Country Link
US (1) US5502818A (de)
EP (1) EP0495515B1 (de)
JP (1) JP2582982B2 (de)
AT (1) ATE121050T1 (de)
AU (1) AU635675B2 (de)
BR (1) BR9200127A (de)
CA (1) CA2059447C (de)
DE (2) DE69201965T2 (de)
ES (1) ES2072025T3 (de)
FI (1) FI87290C (de)

Families Citing this family (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5634009A (en) * 1993-10-01 1997-05-27 3Com Corporation Network data collection method and apparatus
JP3454931B2 (ja) * 1994-08-30 2003-10-06 株式会社東芝 ネットワークシステム
US6246696B1 (en) * 1995-09-11 2001-06-12 Kabushiki Kaisha Toshiba Method of controlling a communication and apparatus for the same
US5697485A (en) * 1995-12-19 1997-12-16 Otis Elevator Company Passenger conveyor control system having decentralized inputs and outputs
US5708778A (en) * 1996-05-09 1998-01-13 Sun Microsystems, Inc. Automatic configuration of protocol parameters in protocol layers for public area networks
US5854454A (en) * 1996-09-16 1998-12-29 Otis Elevator Company Message routing in control area network (CAN) protocol
DE19713240C2 (de) * 1997-03-29 1999-01-28 Endress Hauser Gmbh Co Verfahren zur automatischen Adressenvergabe in einem CAN-Netz
DE19830803C2 (de) * 1998-07-09 2000-06-08 Siemens Ag CAN-Modul
US6353775B1 (en) 1998-07-28 2002-03-05 Honeywell International Inc. Multiple instance single value identifiers environmental control communication method and system
US6721799B1 (en) * 1999-09-15 2004-04-13 Koninklijke Philips Electronics N.V. Method for automatically transmitting an acknowledge frame in canopen and other can application layer protocols and a can microcontroller that implements this method
US6968359B1 (en) * 2000-08-14 2005-11-22 International Business Machines Corporation Merge protocol for clustered computer system
NL1016338C2 (nl) * 2000-10-05 2002-04-11 Roelof Reinders Werkwijze voor het toekennen van een identificatiecode aan knooppunten in een netwerk, het communiceren in een netwerk, alsmede het aansturen van een netwerk.
US6839752B1 (en) 2000-10-27 2005-01-04 International Business Machines Corporation Group data sharing during membership change in clustered computer system
US7185099B1 (en) 2000-11-22 2007-02-27 International Business Machines Corporation Apparatus and method for communicating between computer systems using a sliding send window for ordered messages in a clustered computing environment
US7769844B2 (en) 2000-12-07 2010-08-03 International Business Machines Corporation Peer protocol status query in clustered computer system
US7333504B2 (en) * 2001-03-08 2008-02-19 Honeywell International Inc. Simultaneous serial transmission of messages with data field arbitration
US7231461B2 (en) * 2001-09-14 2007-06-12 International Business Machines Corporation Synchronization of group state data when rejoining a member to a primary-backup group in a clustered computer system
KR20030047167A (ko) * 2001-12-08 2003-06-18 주식회사 만도 캔 통신을 이용한 제어기간의 제어충돌 회피방법
NL1024730C2 (nl) * 2003-11-07 2005-05-10 Beijer Automotive B V Koppelelement voor een voertuigbesturingssysteem.
CN100345739C (zh) * 2004-03-22 2007-10-31 武汉理工大学 一种基于分布式多路can总线的智能电梯控制方法及装置
FR2884630B1 (fr) * 2005-04-18 2007-07-06 Peugeot Citroen Automobiles Sa Systeme d'adaptation du protocole de communication d'un calculateur embarque a bord d'un vehicule automobile
CN102131724B (zh) * 2008-08-29 2014-10-29 奥蒂斯电梯公司 自动电梯装置器编址
US8452456B2 (en) 2008-10-27 2013-05-28 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8239066B2 (en) 2008-10-27 2012-08-07 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8977794B2 (en) 2008-10-27 2015-03-10 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9152155B2 (en) 2008-10-27 2015-10-06 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8543243B2 (en) 2008-10-27 2013-09-24 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8442693B2 (en) 2008-10-27 2013-05-14 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8694164B2 (en) 2008-10-27 2014-04-08 Lennox Industries, Inc. Interactive user guidance interface for a heating, ventilation and air conditioning system
US8855825B2 (en) 2008-10-27 2014-10-07 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US9377768B2 (en) 2008-10-27 2016-06-28 Lennox Industries Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US8560125B2 (en) 2008-10-27 2013-10-15 Lennox Industries Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9261888B2 (en) 2008-10-27 2016-02-16 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8725298B2 (en) 2008-10-27 2014-05-13 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network
US9632490B2 (en) 2008-10-27 2017-04-25 Lennox Industries Inc. System and method for zoning a distributed architecture heating, ventilation and air conditioning network
US8352080B2 (en) 2008-10-27 2013-01-08 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8762666B2 (en) 2008-10-27 2014-06-24 Lennox Industries, Inc. Backup and restoration of operation control data in a heating, ventilation and air conditioning network
US8352081B2 (en) 2008-10-27 2013-01-08 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8774210B2 (en) 2008-10-27 2014-07-08 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8463442B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8433446B2 (en) 2008-10-27 2013-04-30 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US9678486B2 (en) 2008-10-27 2017-06-13 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8661165B2 (en) 2008-10-27 2014-02-25 Lennox Industries, Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8788100B2 (en) 2008-10-27 2014-07-22 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US9651925B2 (en) * 2008-10-27 2017-05-16 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US9325517B2 (en) 2008-10-27 2016-04-26 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8437877B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8892797B2 (en) 2008-10-27 2014-11-18 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9432208B2 (en) 2008-10-27 2016-08-30 Lennox Industries Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8600559B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. Method of controlling equipment in a heating, ventilation and air conditioning network
US8655490B2 (en) 2008-10-27 2014-02-18 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8295981B2 (en) 2008-10-27 2012-10-23 Lennox Industries Inc. Device commissioning in a heating, ventilation and air conditioning network
US8798796B2 (en) 2008-10-27 2014-08-05 Lennox Industries Inc. General control techniques in a heating, ventilation and air conditioning network
US8655491B2 (en) 2008-10-27 2014-02-18 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8437878B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8463443B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US9268345B2 (en) 2008-10-27 2016-02-23 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8874815B2 (en) 2008-10-27 2014-10-28 Lennox Industries, Inc. Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network
US8802981B2 (en) 2008-10-27 2014-08-12 Lennox Industries Inc. Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system
US8615326B2 (en) 2008-10-27 2013-12-24 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8548630B2 (en) 2008-10-27 2013-10-01 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8564400B2 (en) 2008-10-27 2013-10-22 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8994539B2 (en) 2008-10-27 2015-03-31 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8255086B2 (en) 2008-10-27 2012-08-28 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8452906B2 (en) 2008-10-27 2013-05-28 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8744629B2 (en) 2008-10-27 2014-06-03 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8600558B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
USD648642S1 (en) 2009-10-21 2011-11-15 Lennox Industries Inc. Thin cover plate for an electronic system controller
USD648641S1 (en) 2009-10-21 2011-11-15 Lennox Industries Inc. Thin cover plate for an electronic system controller
US8260444B2 (en) 2010-02-17 2012-09-04 Lennox Industries Inc. Auxiliary controller of a HVAC system
CN101877727B (zh) * 2010-06-21 2014-07-16 中兴通讯股份有限公司 一种can网络节点地址的自动设置方法和装置
GB2495246B (en) * 2010-07-27 2016-08-10 Otis Elevator Co Fixture device control
US8954622B1 (en) 2011-01-19 2015-02-10 Marvell International Ltd. Embedded programmable logic for logic stacking on application processor
CN103518337B (zh) 2012-04-27 2017-02-08 三菱电机株式会社 传送线地址重复检测方式以及在该方式中使用的子站点终端
DE102012224234A1 (de) * 2012-12-21 2014-06-26 Continental Teves Ag & Co. Ohg Verfahren zur Kontrolle von Daten-Frames mit redundantem Identifikator auf einem Datenbus sowie Datenbus-Schnittstellenmodul
US9961044B2 (en) * 2013-09-26 2018-05-01 Intellihot, Inc. Routerless identification code assignment system and method
MY177704A (en) * 2013-10-23 2020-09-23 Inventio Ag Method and apparatus for commissioning a lift installation
CN103625997B (zh) * 2013-11-29 2015-08-19 无锡英威腾电梯控制技术有限公司 一种电梯外呼召唤显示板楼层地址自动设置方法及系统
CN104555632B (zh) * 2014-12-31 2016-05-18 中建三局集团有限公司 即插即用式的智能楼层呼叫系统及实施方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4410889A (en) * 1981-08-27 1983-10-18 Burroughs Corporation System and method for synchronizing variable-length messages in a local area network data communication system
US4587511A (en) * 1983-08-30 1986-05-06 Westinghouse Electric Corp. Elevator system with hall lamp status monitoring
JPS60229546A (ja) * 1984-04-27 1985-11-14 Matsushita Electric Ind Co Ltd ネツトワ−ク分散資源番地割付方法
GB2167274A (en) * 1984-11-14 1986-05-21 Philips Electronic Associated Local area network
CA1246681A (en) * 1985-01-30 1988-12-13 Northern Telecom Limited Terminal address assignment in a broadcast transmission system
US4689786A (en) * 1985-03-21 1987-08-25 Apple Computer, Inc. Local area network with self assigned address method
US4912627A (en) * 1985-08-14 1990-03-27 Apple Computer, Inc. Method for storing a second number as a command address of a first peripheral device and a third number as a command address of a second peripheral device
US4683989A (en) * 1986-02-14 1987-08-04 Westinghouse Electric Corp. Elevator communication controller
US4762204A (en) * 1987-10-16 1988-08-09 Westinghouse Electric Corp. Elevator system master car switching
JPH01125141A (ja) * 1987-11-10 1989-05-17 Nec Corp 計算機アドレス割当て方式
DE3820613A1 (de) * 1988-06-17 1990-02-08 Merten Gmbh & Co Kg Geb Digitales signaluebertragungssystem
US5053883A (en) * 1988-12-23 1991-10-01 Scientific-Atlanta, Inc. Terminal polling method
US4949337A (en) * 1989-01-30 1990-08-14 Honeywell Inc. Token passing communication network including a node which maintains and transmits a list specifying the order in which the token is passed
JP2728760B2 (ja) * 1990-02-13 1998-03-18 株式会社東芝 データ伝送装置並びに受信データ処理方法
JP2703391B2 (ja) * 1990-06-18 1998-01-26 株式会社東芝 ブリッジ装置

Also Published As

Publication number Publication date
ATE121050T1 (de) 1995-04-15
CA2059447A1 (en) 1992-07-18
FI87290C (fi) 1992-12-10
FI87290B (fi) 1992-08-31
AU1015692A (en) 1992-07-23
US5502818A (en) 1996-03-26
EP0495515A3 (en) 1993-06-09
DE495515T1 (de) 1993-02-25
ES2072025T3 (es) 1995-07-01
BR9200127A (pt) 1992-10-06
FI910260A0 (fi) 1991-01-17
EP0495515A2 (de) 1992-07-22
AU635675B2 (en) 1993-03-25
FI910260A7 (fi) 1992-07-18
DE69201965D1 (de) 1995-05-18
EP0495515B1 (de) 1995-04-12
JP2582982B2 (ja) 1997-02-19
JPH0512161A (ja) 1993-01-22
CA2059447C (en) 1996-03-05

Similar Documents

Publication Publication Date Title
DE69201965T2 (de) Verfahren zur Zuteilung von Nachrichtenkennungen im Datenübertragungsnetzwerk eines Aufzugsystems.
DE3424866C2 (de) Verfahren und Anordnung zur Übertragung von Daten, insbesondere in einem Flugzeug
EP2622826B1 (de) Verfahren zur automatischen adressvergabe an gleichartige busteilnehmer
EP1309920B1 (de) Adressvergabeverfahren für mindestens einen neu an ein bussystem angeschlossenen busteilnehmer
DE3779694T2 (de) Rechnernetzwerksystem.
DE69123663T2 (de) Kanäle in einem Rechnerein-Ausgabesystem
DE19713240C2 (de) Verfahren zur automatischen Adressenvergabe in einem CAN-Netz
EP2266297B1 (de) Automatische busadressvergabe mittels kollisionsprüfung
EP0842472B1 (de) Verfahren zum betreiben eines datenübertragungssystems
DE19721740B4 (de) Steuerungsverfahren für den Medienzugriff bei einem seriellen Bus
EP0388687B1 (de) Verfahren zum Austauschen von Daten
DE69434976T2 (de) Rangadressenzuweiseung in einem modulsystem
EP2733910B1 (de) BUS-System, Verfahren zum Betrieb eines BUS-Systems und fluidisches System mit einem BUS-System
EP2719128B1 (de) Verfahren zum betrieb eines bussystems zur kommunikation mit mehreren kommunikationsteilnehmern und kraftfahrzeug
DE68927157T2 (de) Deblockierverfahren eines Multiprozessor-Multibus-Systems
EP1642207B1 (de) Zuordnung von stationsadressen zu kommunikationsteilnehmern in einem bussystem
DE4210094C2 (de) Multiplexes Übertragungsverfahren
DE10329682B4 (de) Busadressvergabe mittels Kollisionsprüfung
DE4209877C2 (de) Multiplexes Übertragungsverfahren
DE69608331T2 (de) Verfahren zur Steuerung der Übertragung von Nachrichten im Übertragungsnetzwerk eines elektronischen Bordsystems eines Automobils
EP3681109B1 (de) Verfahren zum erkennen eines zustands eines teilnehmers eines kommunikationsbusses, kommunikationsbussystem, verriegelungsanlage mit einem kommunikationsbussystem und transceiver
DE102017117225B3 (de) Kommunikationssystem mit Bus und Codierleitung
DE1762761B2 (de) Verfahren zum Aufbau von Rundschreibverbindungen in zentralgestuerten Fernschreib- Wählvermittlungsanlagen
DE19549462C2 (de) Multiplex-Kommunikationssystem
EP1868328B1 (de) Verfahren zum Betrieb eines Automatisierungsgerätes und Automatisierungsgerät

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: KONE CORP., HELSINKI, FI

8339 Ceased/non-payment of the annual fee