Leitfaden Control Access Version 2 - ABB Group€¦ · INSUM® Leitfaden Control Access (CA) ABB 5...

ABB

ProtectIT – MNS Motor Management INSUM

Leitfaden Control Access Version 2.3

INSUM®

Leitfaden Control Access (CA)

1 1TGC 901090 M0101 Ausgabe Dezember 2002

INSUM® Leitfaden Control Access (CA) Version 2.3

INSUM®


1TGC 901090 M0101 Ausgabe Dezember 2002

WICHTIGE HINWEISE Die in diesem Handbuch angegebenen Daten gelten vorbehaltlich der Änderung und sind für ABB Schaltanlagentechnik GmbH nicht verbindlich. ABB Schaltanlagentechnik GmbH übernimmt keine Haftung für Irrtümer in diesem Handbuch. ABB Schaltanlagentechnik GmbH haftet unter keinen Umständen für unmittelbare, mittelbare, besondere, zusätzliche oder Folgeschäden jeglicher Art, die aus der Verwendung dieses Handbuchs entstehen, und ABB Schaltanlagentechnik GmbH haftet auch nicht für indirekte oder Folgeschäden aus der Verwendung von hier beschriebener Hard- oder Software. Dieses Dokument darf weder ganz noch teilweise ohne schriftliche Zustimmung von ABB Schaltanlagentechnik reproduziert oder kopiert werden, und der Inhalt darf nicht an Dritte weitergegeben oder für nicht genehmigte Zwecke verwendet werden. ABB Schaltanlagentechnik GmbH behält sich die Genehmigung zur Übersetzung dieses Dokuments vor. Nach Übersetzung ist das Handbuch zusammen mit einer Bestätigung, dass der Inhalt des Dokuments nicht geändert wurde, an ABB Schaltanlagentechnik GmbH einzusenden. Die in diesem Handbuch beschriebene Software wird gemäß einer Lizenz geliefert und darf nur gemäß den Lizenzbestimmungen verwendet, kopiert oder weitergegeben werden. 2002 ABB Schaltanlagentechnik GmbH, Deutschland WARENZEICHEN MNS und INSUM sind eingetragene Warenzeichen der ABB Schaltanlagentechnik GmbH. Microsoft, Windows und Windows NT sind eingetragene Warenzeichen der Microsoft Corporation. Echelon, LON, LONWORKS, LonTalk, Neuron sind Warenzeichen der Echelon Corporation, eingetragen in den USA und anderen Ländern. Internes Referenzdokument 1TGB 330002 R3.1

INSUM®


1TGC 901090 M0101 Ausgabe Dezember 2002

1 Einführung ..........................................................................................................................4 1.1 Zweck.........................................................................................................................4 1.2 Zugehörige Software-Version ....................................................................................4 1.3 Zugehörige Dokumentation........................................................................................4

2 Control Access Funktionsbeschreibung .........................................................................5 2.1 Zweck der Funktion....................................................................................................5 2.2 Control Access Regeln ..............................................................................................5 2.3 Control Access Strukturen .........................................................................................5

2.3.1 MCU Control Access Tabelle ........................................................................5 2.3.2 SULifeList ......................................................................................................6

2.4 ActualCA1..................................................................................................................7 2.5 SEND-CA...................................................................................................................8

2.5.1 Regeln für CA Passing (CA-Weitergabe) bei CA = aktiviert..........................8 2.5.2 Beispiele für „SEND-CA“-Befehle................................................................10

2.6 Binäreingänge der MCU ..........................................................................................12 2.6.1 VORORT/BUS - Schalter (höchste Priorität)...............................................12 2.6.2 SEND-CA an VORORT (niedrigste Priorität) ..............................................12

2.7 Failsafe ....................................................................................................................13 2.8 CA und Schaltbefehle (insbesondere RESET) ........................................................13 2.9 CA-Anforderung .......................................................................................................14 2.10 Wechsel des MCU-Parameters CA aktivieren/deaktivieren.....................................14 2.9 Ablaufdiagramm SEND-CA......................................................................................15

3 CA-Parameter ...................................................................................................................16 3.1 ICU/SU-Geräte (MMI, Gateway, OS).......................................................................16 3.2 MCU.........................................................................................................................17

4 Anwendungsbeispiel für Control Access ......................................................................18 4.1 Anwendungsfall........................................................................................................18

4.1.1 Teilnehmende Stationen .............................................................................18 4.1.2 Steuerungshierarchie ..................................................................................18

4.2 CA-Verarbeitung und -Anzeige ................................................................................20 4.2.1 Bedienung ...................................................................................................21 4.2.2 Anlagenphilosophie zur Bedienung der CA-Funktion .................................23

5 Annex A: Begriffe und Abkürzungen .............................................................................24

INSUM® Leitfaden Control Access (CA)

ABB 4 1TGC 901090 M0101 Ausgabe Dezember 2002

Notizen: 1 Einführung 1.1 Zweck

In diesem Dokument wird die Schaltberechtigungsfunktion des INSUM-Systems beschrieben. Zum besseren Verständnis wird ein Anwendungsbeispiel gegeben. Es soll dem Benutzer helfen, diese Funktionalität nachzuvollziehen und projektspezifisch anzuwenden.

1.2 Zugehörige Software-Version

Dieser Leitfaden beschreibt die Schaltberechtigungsfunktion (Control Access) für INSUM 2.3.

1.3 Zugehörige Dokumentation

Weitere Informationen entnehmen Sie bitte den nachfolgend aufgeführten Dokumenten: 1TGC 901007 INSUM Technische Information 1TGC 901021 INSUM MCU Handbuch 1TGC 901026 INSUM MCU Parameterbeschreibung 1TGC 901034 INSUM MMI Handbuch 1TGC 901030 INSUM MMI Kurzanleitung 1TGC 901042 INSUM MODBUS Gateway Handbuch 1TGC 901052 INSUM PROFIBUS Gateway Handbuch 1TGC 901060 INSUM Ethernet Gateway Handbuch 1TGC 901080 INSUM Systemuhr Handbuch 1TGC 901091 INSUM Leitfaden Failsafe 1TGC 901092 INSUM Leitfaden Redundante Ausführung 1TGC 901093 INSUM Leitfaden Netzwerk-Management SACE RH 0080 Rev.l PR112/ PD-L LON Works Interface 1SEP407948P0001 Users Manual Intelligent Tier Switch (ITS)



Notizen: 2 Control Access Funktionsbeschreibung 2.1 Zweck der Funktion

Control Access definiert die Bedien-Priorität der am Bus angeschlossenen ICU-Geräte. Ohne die Control Access Funktionalität haben alle ICU-Geräte gleiche Rechte bezüglich der Steuerung der Feldgeräte.

Feldgeräte, z.B. MCUs, werden über Befehle (START, STOP, RESET) angesteuert, die über den Bus oder über Hardwareeingänge vorgegeben werden. Die gegenseitige Verriegelung von Bus- und Hardware-befehlen lässt sich auf zwei Arten erreichen.

• Ohne Control Access haben alle ICU-Geräte gleiche Priorität. Ein einfacher Mechanismus zur Verrie-gelung von Befehlen, die über den Bus oder die Hardware gesendet werden, ist hier der hardwareseitige Schalter VORORT/BUS. Steht der Schalter in Stellung VORORT, werden über den Bus ankommende Befehle nicht beachtet. Steht der Schalter jedoch in Stellung BUS, werden nur über den Bus ankommende Befehle ausgeführt. Die MCU wertet nicht aus, von welchem „Busgerät“ ein Befehl empfangen wurde. Mit Busgerät sind hier Geräte der INSUM Communications Unit (ICU, auch SU) wie Gateway (PLT), MMI oder OS gemeint.

• Mittels Control Access kann INSUM so konfiguriert werden, dass die Verriegelung auch berücksichtigt, welches ICU Gerät einen Befehl abgesetzt hat. Die MCU übernimmt Befehle vom Bus nur von jeweils einem ICU Gerät. Control Access umfasst auch einen Mechanismus zur Weitergabe des „Rechts zum Senden von Befehlen“ von einem ICU Gerät zum anderen. Zu diesem Zweck werden den Geräten Prioritäten zugewiesen.

2.2 Control Access Regeln

Die Control Access Funktionalität in INSUM basiert auf den folgenden Regeln und Vorausetzungen: • Bedienautorisierung kann separat für jede MCU erfolgen. • Während einer Zeit t0 kann eine MCU nur von einem ICU-Gerät gesteuert werden. • Das Gerät mit höchster Bedienpriorität kann den CA einem Gerät mit niedrigerer Priorität zuweisen. • Ein Gerät mit höherer Priorität kann den CA von einem Gerät mit niedrigerer Priorität anfordern. • Um den CA zurückzuerlangen, weist ein Gerät mit hoher Priorität diesen an sich selbst zu. • Das Zuweisen des CA an Geräte mit höherer Priorität ist nicht möglich. • Die MCU akzeptiert das Zuweisen des CA lediglich an Geräte, die in der SULifeList vorhanden sind. • Die MCU kennt den CA Besitzer und akzeptiert Schaltbefehle nur von diesem. • Wenn ein CA Besitzer „stirbt“, wird die Bedienautorität seitens der MCU freigegeben. Zu beachten: CA wird unterstützt von: MODBUS GW, Ethernet GW, MMI, INSUM OS CA wird derzeit nicht unterstützt von: PROFIBUS-DP Gateway CA Anforderung wird nicht unterstützt von: MMI, INSUM OS 2.3 Control Access Strukturen

2.3.1 MCU Control Access Tabelle

Die Motor Control Unit (MCU) stellt eine „Control Access Tabelle“ zur Verfügung. In dieser Tabelle wird die Hierarchie der Stationen abgelegt. Jeder Station wird in der Tabelle eine Priorität zugewiesen. Alle Busgeräte werden über ihre LON-Adressen identifiziert, die anderen Stationen sind fest.

Der Inhalt dieser Tabelle muss in allen MCUs, die an dieselbe ICU angeschlossen sind, identisch sein. Die Prioritäten entsprechen der Bitdarstellung. Insgesamt können maximal 14 Prioritäten vergeben werden, wobei nur 12 Busstationen möglich sind. Ein ICU/SU-Gerät erhält nur eine einzige Adressenpriorität.



Notizen: Tabelle 1. MCU Control Access Tabelle

Bit Prioritäten Domain-/Subnet-/ Knotenadresse des ICU/SU-Geräts

Beispiel-eintrag

Bemerkungen

0 oberste Priorität Adressenpriorität 1: VORORT-HW 0/0/0 fest 1 ↓ Adressenpriorität 2: Adresse des SU-Geräts 0/5/10 parametrierbar

2 ↓ Adressenpriorität 3: Adresse des SU-Geräts 0/5/11 parametrierbar











13 niedrigste Priorität

Adressenpriorität 14: VORORT_SW 0/0/0 fest

14 -- -- -- 0/0/0 nicht benutzt

15 -- -- -- 0/0/0 CA Bit Hinweis zur Eintragung der Parameterwertedatei für die MCU: • Jeder der insgesamt 16 Adresstabelleneinträge, der keiner LON-Adresse zugeordnet ist,

muss mit 0/0/0 aufgefüllt werden. • Wenn im Parametersatz vorhanden, müssen die Adresstabelleneinträge für die Prioritäten

0, 13, 14, 15 auf 0/0/0 gesetzt werden.

2.3.2 SULifeList

Allgemeines Die SULifeList zeigt an, welches der ICU/SU-Geräte „am Leben“ ist. Sie wird von allen MCUs empfangen, die zu demselben System gehören.

(Wenn der eigentliche CA-Besitzer ausfällt, wird die Schaltberechtigung von der MCU auf „FREIGEGEBEN“ gesetzt. „FREIGEGEBEN“ bedeutet, dass die MCU keine Schaltbefehle ausführt. Die Schaltberechtigung können nur ICU/SU-Geräte haben, die „am Leben“ sind. Bei FREIGEGEBEN wird „SEND-CA“ (Schaltberechtigung weitergeben) von jeder Station akzeptiert. -> siehe folgende Kapitel).

Die SULifeList ist eine 16-Bit-Variable (SNVT_state), von der nur Bit1...Bit12 verwendet werden. Jedem ICU/SU-Gerät wird eines dieser Bits entsprechend der Control Access Tabelle zugewiesen. Das Bit ist gesetzt (1), wenn das Gerät „am Leben ist“, und nicht gesetzt (0), wenn es am LON-Bus nicht vorhanden ist. Nicht verwendete Bits müssen auf „0“ gesetzt werden.

Erzeugung und Belegung der SULifeList: Alle ICU/SU-Geräte senden einander das Signal „nvoLifesign“ (den "Watcher"). Diese Netzwerkvariable ist ebenfalls ein 16-Bit Parameter. Jedes ICU/SU Gerät setzt das Bit entsprechend der eigenen Adressenpriorität (CA-Priorität) in der Lifesign Struktur. Alle ICU/SU-Geräte erhalten das Lifesign von allen anderen ICU/SU-Geräten. All diese Lifesign-Bits zusammen ergeben die SULifeList. Das ICU/SU-Gerät mit der höchsten Priorität in der SULifeList muss die Liste als Rundsendung allen MCUs mitteilen. Wenn das ICU/SU-Gerät mit der höchsten Priorität ausfällt, übernimmt das ICU/SU-Gerät mit der nächsthöchsten Priorität auf der Liste die Aussendung der SULifeList.

Das Lifesign wird in dem Sendezyklus ausgesendet, der im Parameter „SU Lifesign Sendezyklus“ festgelegt wurde. Die Überwachung dieses Lifesign-Sendezyklus erfolgt entsprechend dem Parameter „SU Lifesign Überwachung“. Die SULifeList wird entsprechend dem Parameter „SU Lifelist Sendezyklus“ regelmäßig ausgesendet.



Notizen: Die MCU überwacht die SULifeList entsprechend dem Parameter „SU Lifelist Überwachung“. Wenn die „SU LifeList Überwachung“ abgelaufen ist, ohne dass die SULifeList empfangen wurde, wird die Schaltberechtigung von der MCU FREIGEGEBEN.

2.4 ActualCA1

Jede MCU sendet die ActualCA1 an alle ICU/SU-Geräte. Sie meldet damit, welche der Stationen der „CA-Besitzer“ ist, und ob die Schaltberechtigung für diese MCU FREIGEGEBEN ist. Darüber hinaus wird angegeben, ob Control Access in der MCU „aktiviert“ oder „deaktiviert“ ist. Die Meldung hat die folgende Struktur:

Tabelle 2. ActualCA Liste der MCU

Bit Beschreibung Werte

15 CA aktiviert Aktiviert = 1, Deaktiviert = 0 (entsprechend MCU-Parameter)

14 Reserviert Bit = 0

13 Priorität 14: VORORT durch SEND-CA - niedrigste Priorität Bit = 1 -> MCU wird von SEND-CA auf VORORT geschaltet

12 CA-Besitzer Adressenpriorität 13 Bit = 1 -> SU-Gerät mit dieser Priorität ist CA-Besitzer

11 CA-Besitzer Adressenpriorität 12 "











0 Priorität 1: Status des MCU-Binäreingangs VORORT/BUS - Höchste Priorität

Bit = 1 -> Status des MCU-Binäreingangs ist VORORT Bit = 0 -> Status des MCU-Binäreingangs ist BUS

Tabelle 3. Belegung der Bits

Bedeutung der Bits ActualCA1

Bit Schaltberechtigung = aktiv (Bit 15 =1)

Schaltberechtigung = nicht aktiv (Bit 15 =0)

Bits 0..13 = 0 Bit 14 = 0

CA = FREIGEGEBEN MCU führt keine Schaltbefehle aus. Über „SEND-CA“ kann die Schaltberechtigung an jede Station vergeben werden. (Genauere Angaben siehe folgende Kapitel)

CA = BUS Alle Geräte, die am „BUS“ liegen (Gateway, OS, MMI usw.), dürfen den Motor schalten

Bit0 = 1, Bit1...Bit13 = 0, Bit14 = 0

CA = VORORT-HW CA = VORORT-HW

Bit13 = 1, Bit0...Bit12 = 0, Bit14 = 0

CA = VORORT-SW CA = VORORT-SW

Eines der Bit1...Bit12=1 Bit 0 = 0, Bit13 = 0, Bit14=0

BUS-Gerät mit dieser CA-Priorität ist CA-Besitzer

-- (keine gültige Kombination)

Zu beachten: Andere Bitkombinationen sind in nvoActualCA1 nicht zulässig!!!



Notizen: 2.5 SEND-CA

Jedes ICU/SU-Gerät kann den Befehl „nvoCAPass“ für jede MCU ausgeben. Dieser Befehl wird verwendet, wenn ein ICU/SU-Gerät die Schaltberechtigung für eine bestimmte MCU an sich selbst oder eine andere Station übergeben möchte. Der Befehl besteht aus 16 Bits, wobei Bit1...Bit13 den Adressenprioritäten für ActualCA1 entspricht (siehe Kapitel 2.4). Send-CA kann auch verwendet werden, um die Schaltberechtigung freizugeben. Der Befehl Send-CA wird von der MCU nur akzeptiert, wenn die in Kapitel 2.5.1 genannten Voraussetzungen erfüllt sind.

Die Struktur gestaltet sich wie folgt:

Tabelle 4. Liste für SEND-CA

Bit CA Priorität Beschreibung Code hex 15 -- Bit = 0 (reserviert) 14 -- Bit = 0 (reserviert) 13 14 Bit = 1 -> SEND-CA an VORORT (Binäreingänge der MCU) 0x2000 12 13 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 13 0x1000 11 12 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 12 0x0800 10 11 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 11 0x0400 9 10 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 10 0x0200 8 9 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 9 0x0100 7 8 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 8 0x0080 6 7 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 7 0x0040 5 6 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 6 0x0020 4 5 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 5 0x0010 3 4 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 4 0x0008 2 3 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 3 0x0004 1 2 Bit = 1 -> SEND-CA an SU-Gerät mit Priorität 2 0x0002 0 1 Bit = 0 (reserviert) Alle Bits = 0 -> CA FREIGEGEBEN 0x0000

Tabelle 5. Belegung der Bits

Bedeutung der Bits SEND-CA Bit CA aktiviert CA deaktiviert Bits 0..15 = 0, Befehl setzt CA =

FREIGEGEBEN Befehl setzt CA = BUS

Bit13 = 1, Bit0...Bit12 = 0, Bit14 .. Bit15 = 0

Befehl setzt CA = VORORT SW Befehl setzt CA = VORORT SW

Eines aus Bits 1...Bit12 = 1, Bit 0 = 0, Bit13 = 0, Bit14 .. Bit15 = 0

Befehl setzt CA = BUS-Gerät mit der angegebenen Priorität.

--

2.5.1 Regeln für CA Passing (Weitergabe der Schaltberechtigung) bei CA = aktiviert

Die in diesem Kapitel beschriebenen Regeln gelten nur, wenn die Schaltberechtigung aktiviert ist.

2.5.1.1 Aufgabe der MCU

Die Auswertung der Schaltbefehle erfolgt in der MCU. Die MCU muss daher die Herkunftsadresse eines Schaltbefehls sowie die Adresse des aktuellen „CA-Besitzers“ prüfen. Stammt der Befehl von der Station, welche die Schaltberechtigung besitzt, wird der Befehl an den Motor weitergegeben.

Mit Schaltbefehlen sind hier START (d.h. die unterschiedlichen Startbefehle für verschiedene Antriebsarten), STOP und RESET gemeint.



Notizen: Die Auswertung des Befehls SEND-CA erfolgt in der MCU. Nach Empfang von SEND-CA wird der aktuelle CA-Besitzer von der MCU entsprechend den folgenden Regeln geändert. Der Wechsel des CA-Besitzers ist abhängig von:

• dem aktuellen CA-Besitzer, • der in der Control Access Tabelle vorgesehenen Hierarchie • dem Inhalt der SULifeList.

Die MCU empfängt die SULifeList in definierten Zeitabschnitten und erfährt so, welche SU-Geräte am Bus „am Leben“ sind. Wenn der eigentliche CA-Besitzer ausfällt, wird ActualCA1 von der MCU auf FREIGEGEBEN gesetzt. Dies bedeutet, dass die MCU keine Schaltbefehle ausführt. Über „SEND-CA“ kann die Schaltberechtigung wieder an eine der verbliebenen Stationen vergeben werden.

2.5.1.2 Beschreibung der CA Weitergabe

1. Die Station mit der Schaltberechtigung, oder eine in der Hierarchie höher stehende Station kann die Weitergabe der Schaltberechtigung an alle Stationen veranlassen, die ihr in der Hierarchie untergeordnet sind.

Zu diesem Zweck ist an die MCU eine spezielle Meldung mit der folgenden Struktur zu senden:

• Die Herkunftsadresse ist in jedem LON-Telegramm vorhanden. • Als Daten werden die Werte/Inhalte der Netzwerkvariablen übertragen.

Herkunftsadresse: Daten

Station mit CA oder höherer Priorität Station, an die die CA übergeben wird 2. Stationen, die nicht mehr in der SULifeList aufgeführt sind, können keine Schaltberechtigung erhalten.

Wenn die Station, welche die Schaltberechtigung besitzt, aus der SULifeList entfernt wird, wird ActualCA von der MCU auf FREIGEGEBEN gesetzt.

3. Ist die Schaltberechtigung FREIGEGEBEN, kann jede Station den Befehl SEND-CA an eine andere

Station einer niedrigeren Hierarchiestufe oder an sich selbst senden.

4. Eine Station mit CA kann die aktuelle Schaltberechtigung auf "FREIGEGEBEN" setzen, indem sie

SEND-CA mit dem Inhalt 0x0000 aussendet. Die Schaltberechtigung wird sodann derjenigen Station zugeteilt, welche sie als erste beansprucht.

Die folgenden Beispiele veranschaulichen Situationen, in denen die Schaltberechtigung von einer Station an eine andere weitergegeben wird.



Notizen: 2.5.2 Beispiele für „SEND-CA“-Befehle

In Tabelle 6 hat Gateway 1 entsprechend der Reihenfolge der Stationen in der Control Access Tabelle innerhalb der SU-Geräte die höchste Priorität. In diesem Fall kommuniziert das „Übergeordnete Leitsystem“ über GW1 und ist daher der „Master“ für die Weitergabe der Schaltberechtigung. Alle anderen Stationen, mit Ausnahme des Schalters VORORT/BUS, haben eine niedrigere Priorität.

Tabelle 6. Einstellbeispiel für GW1 mit Adressenpriorität 2

Priorität Station Control Access Tabelle (MCU-Parameter) Domain/Subnet/Knoten

SULifeList (als Netzwerk-variable)

Aktuelle Schaltberechtigung(als Netzw.-variable)

1, höchste

Binäreingang VORORT/BUS

-- -- KEIN CA

2, ↓ GW 1 0/5/10 VORHANDEN KEIN CA

3, ↓ GW 2 0/5/11 VORHANDEN KEIN CA

4, ↓ OS 0/5/30 VORHANDEN KEIN CA

5, ↓ MMI 1 0/5/20 NICHT VORHANDEN

KEIN CA

6, ↓ MMI 2 0/5/21 VORHANDEN CA

... ... ... ... ...

14, niedrigste

-- -- -- KEIN CA

Regel: Der aktuelle CA-Besitzer kann die Schaltberechtigung an eine in der Hierarchie untergeordnete Station weitergeben.

Beispiel: GW1 übergibt den CA mit dem folgenden Befehl SEND-CA von sich selbst an MMI 2:

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse: Daten → ActualCA

Priorität 2 5/10 (Priorität 2) Priorität 6 Priorität 6 Regel: Eine Station mit einer höheren Priorität als der aktuelle CA-Besitzer kann die Schaltberechtigung an eine in der Hierarchie untergeordnete Station weitergeben. Beispiel: GW1 übergibt den CA mit dem folgenden Befehl SEND-CA von MMI 2 an OS:

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse: Daten → ActualCA Priorität 6 5/10 (Priorität 2) Priorität 4 Priorität 4

Regel: Eine Station mit einer höheren Priorität als der aktuelle CA-Besitzer kann die Schaltberechtigung an sich selbst übergeben. Beispiel: GW1 übergibt den CA mit dem folgenden Befehl SEND-CA von GW 2 an sich selbst :




Notizen: Regel: Stationen, die nicht mehr in der SULifeList aufgeführt sind, können keine Schaltberechtigung erhalten. GW1 versucht, den CA mit dem folgenden Befehl SEND-CA an MMI 1 zu übergeben. Dieser Befehl SEND-CA wird zurückgewiesen.


Regel: Ist die Schaltberechtigung FREIGEGEBEN, kann jede Station den Befehl SEND-CA an sich selbst senden. Beispiel: OS übergibt den CA mit dem folgenden Befehl SEND-CA an sich selbst:

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse: Daten → ActualCA FREIGEGEBEN 5/30 (Priorität 4) Priorität 4 Priorität 4

Regel: Ist die Schaltberechtigung FREIGEGEBEN, kann jede Station den Befehl SEND-CA an eine andere Station derselben oder einer niedrigeren Hierarchiestufe senden. Beispiel: GW1 ändert den CA mit dem folgenden Befehl SEND-CA von FREIGEGEBEN an OS:

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse: Daten → ActualCA FREIGEGEBEN 5/10 (Priorität 2) Priorität 4 Priorität 4

Regel: Ist die Schaltberechtigung FREIGEGEBEN, kann eine Station die Schaltberechtigung nicht an eine in der Hierarchie übergeordnete Station übergeben. Beispiel: MMI 2 versucht, den CA mit dem folgenden Befehl SEND-CA von FREIGEGEBEN an GWI1 zu übergeben:

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse: Daten → ActualCA FREIGEGEBEN 5/21 (Priorität 6) Priorität 2 FREIGEGEBEN

Regel: Eine Station mit Schaltberechtigung kann diese auf FREIGEGEBEN setzen. Beispiel: GW2 setzt den CA mit dem folgenden Befehl SEND-CA auf FREIGEGEBEN :

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse: Daten → ActualCA FREIGEGEBEN 5/11 (Priorität 3) FREIGEGEBEN FREIGEGEBEN

Regel: Eine Station ohne Schaltberechtigung kann diese nicht auf FREIGEGEBEN setzen. Beispiel: GW2 versucht, den CA mit dem folgenden Befehl SEND-CA auf FREIGEGEBEN zu setzen:

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse: Daten → ActualCA Priorität 2 5/11 (Priorität 3) FREIGEGEBEN Priorität 2



Notizen: Regel: Eine Station mit Schaltberechtigung kann diese nicht an eine in der Hierarchie übergeordnete Station übergeben. Beispiel: OS versucht, den CA mit dem folgenden Befehl SEND-CA an GW1 zu übergeben:


2.6 Binäreingänge der MCU

Neben den über den Bus empfangenen Befehlen kann die MCU über ihre Binäreingänge (START1, START2, STOP und RESET) geschaltet werden. Der Zustand des Binäreingangs VORORT/BUS bestimmt, ob die über die Binäreingänge vorgegebenen Befehle akzeptiert werden. VORORT bedeutet, dass die Binäreingänge die Schaltberechtigung besitzen. (Per Bus übertragene Befehle werden nicht akzeptiert.)

2.6.1 VORORT/BUS - Schalter (höchste Priorität)

2.6.1.1 CA = AKTIVIERT

In der Control Access Tabelle hat der „VORORT/BUS-Schalter“ immer die höchste Priorität.

Steht der Binäreingang VORORT/BUS auf VORORT, weist die MCU die Schaltberechtigung automatisch den Binäreingängen zu. Der CA wird an „VORORT-HW“ übergeben. In diesem Fall kann keine andere Station in der Control Access Tabelle die Schaltberechtigung erhalten, weil alle anderen Stationen eine niedrigere Priorität haben.

Binäreingang VORORT/BUS ActualCA Stellung VORORT

→ Priorität 1 = VORORT-HW

Beim Umschalten auf BUS wird die Schaltberechtigung auf FREIGEGEBEN gesetzt.

Binäreingang VORORT/BUS ActualCA Umschalten auf BUS

→ FREIGEGEBEN

Jetzt kann jede andere Station in der Control Access Tabelle die Schaltberechtigung anfordern.

2.6.1.2 CA = DEAKTIVIERT

Steht der Binäreingang VORORT/BUS auf VORORT, weist die MCU die Schaltberechtigung automatisch den Binäreingängen zu. Der CA wird an "VORORT-HW“ übergeben. Beim Umschalten auf BUS wird die Schaltberechtigung an den BUS übergeben (alle über den „Bus“ empfangenen Schaltbefehle werden ausgeführt).

2.6.2 SEND-CA an VORORT (niedrigste Priorität)

2.6.2.1 CA = AKTIVIERT

Neben der Zuordnung der Schaltberechtigung bei Schalterstellung VORORT kann die Schaltberechtigung über den Befehl SEND-CA an die Binäreingänge übergeben werden. In diesem Fall haben die Binäreingänge die niedrigste Priorität (Adressenpriorität 14) in der Control Access Tabelle. Diese Priorität ist dann fest. Der folgende Befehl zeigt, wie die Schaltberechtigung von einem ICU/SU-Gerät an die Binäreingänge übergeben werden kann:

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse: Daten → ActualCA

Priorität 6 Priorität 6 Priorität 14 Priorität 14 = VORORT-SW Wird die Schaltberechtigung der Priorität 14 (VORORT-SW) zugewiesen, können alle anderen Stationen entsprechend den vorstehenden Regeln SEND-CA durchführen, da sie eine höhere Priorität besitzen.

Anmerkung: Es wird empfohlen, die Schaltberechtigung nicht gleichzeitig über Hardwareschalter und über den Befehl SEND-CA auf VORORT zu stellen.



Notizen: 2.6.2.2 CA = DEAKTIVIERT

Über den Befehl SEND-CA kann die Schaltberechtigung nur wie folgt an die VORORT-SW übergeben werden:

Vorher Befehl SEND-CA Ergebnis ActualCA → Herkunftsadresse Daten → ActualCA BUS Jedes BUS-Gerät Priorität 14 Priorität 14 = VORORT-SW

2.7 Failsafe

Wenn die MCU in den Failsafe-Zustand schaltet, wird die Schaltberechtigung unabhängig von dem bisherigen CA-Besitzer FREIGEGEBEN. War die Schaltberechtigung an VORORT-HW oder VORORT-SW vergeben, ignoriert die MCU die Failsafe-Funktionalität (und CA wird nicht FREIGEGEBEN). Wird der CA danach an ein ICU/SU-Gerät zurückgegeben, ist die Failsafe-Funktionalität wieder aktiv.

Eine „aktive“ Failsafe-Funktionalität bedeutet, dass die MCU den Motor bei einer Kommunikationsstörung in einen parametrierbaren Failsafe-Zustand (NOP, START, STOP ...) schaltet.

Für die Failsafe-Funktion gilt folgende Matrix:

Tabelle 7. Control Access und Failsafe

ActualCA CA=AKTIV CA-Besitzer = eines der SU-Geräte (Priorität 2...13) Failsafe-Funktionalität aktiv

Im Falle von Failsafe wird CA FREIGEGEBEN.

CA-Besitzer = VORORT-HW oder VORORT-SW (Priorität 1 oder Priorität 14)

Failsafe-Funktionalität nicht aktiv

CA = Freigegeben Failsafe-Funktionalität aktiv, CA bleibt FREIGEGEBEN

ActualCA CA = DEAKTIVIERT CA-Besitzer = BUS Failsafe-Funktionalität aktiv

Im Falle von Failsafe wird CA FREIGEGEBEN.

CA-Besitzer = VORORT-HW oder VORORT-SW Failsafe-Funktionalität nicht aktiv

2.8 CA und Schaltbefehle (insbesondere RESET)

Tabelle 8. CA und Schaltbefehle

CA=AKTIVIERT START (je nach Antriebsart) STOP TOL Bypass

RESET

CA-Besitzer = eines der SU-Geräte (Priorität 2...13)

wird für CA-Besitzer ausgeführt wird für CA-Besitzer ausgeführt

CA-Besitzer = VORORT-HW oder VORORT-SW (Priorität 1 oder Priorität 14)

wird über Binäreingänge ausgeführt, nicht über den BUS

wird über Binäreingänge ausgeführt

CA = FREIGEGEBEN nicht ausgeführt nicht ausgeführt CA = DEAKTIVIERT START (je nach Antriebsart)

STOP RESET

CA-Besitzer = BUS wird bei Befehl über BUS ausgeführt

wird bei Befehl über BUS ausgeführt

CA-Besitzer = VORORT-HW oder VORORT-SW

wird über Binäreingänge ausgeführt, nicht über den BUS

wird über Binäreingänge und über den BUS ausgeführt

Anmerkung: Wird der RESET-Befehl ausgeführt, berücksichtigt die MCU auch den Parameter "Reset Modus“. Beispiel: Bei Einstellung von CA=VORORT-HW, Reset Modus = BUS (FERN) für die entsprechende Schutzfunktion, wird der über die Binäreingänge vorgegebene Reset-Befehl nicht ausgeführt.



Notizen: 2.9 CA-Anforderung

Jede MCU besitzt eine Eingang zur Anforderung der Schaltberechtigung (nviCARequest), über den alle Stationen, welche diese MCU ansteuern, eine ANFO-CA an die ICU/SU-Geräte für diese MCU senden können.

Nach Empfang dieser Anforderung gibt die MCU die Schaltberechtigung über den Ausgang nvoCARequestFb an die ICU/SU-Geräte weiter. Das Telegramm CARequestFb enthält dann die Herkunftsadresse der MCU, für welche die Schaltberechtigung angefordert wird, und der Wert dieser Netzwerkvariablen enthält die Adressenpriorität der Station; für welche die Schaltberechtigung gefordert wird.

NviCARequest und nvoCARequestFB basieren jeweils auf einer 16 Bit-Struktur, wobei Bit1...Bit13 für ActualCA reserviert ist. Die Bearbeitung einer Anforderung übernimmt das ICU/SU-Gerät, für GWs muss die Anforderung von der angeschlossenen PLT verarbeitet werden.

Bei positiver Reaktion auf eine Anforderung muss die Meldung SEND-CA für das anfordernde Gerät erzeugt werden.

2.10 Wechsel des MCU-Parameters CA aktivieren/deaktivieren

Die folgende Tabelle zeigt die Reaktion der MCU beim Aktivieren bzw. Deaktivieren der CA-Funktion.

Tabelle 9. Auswirkungen des Parameterwechsels CA aktivieren/deaktivieren

Parameter CA-Funktion ActualCA aktivieren -> deaktivieren VORORT-HW -> VORORT-HW VORORT-SW -> VORORT-SW SU-Gerät -> BUS deaktivieren -> aktivieren VORORT-HW -> VORORT-HW VORORT-SW -> VORORT-SW BUS -> FREIGEGEBEN



Notizen: 2.9 Ablaufdiagramm SEND-CA

MMI/GW/OS: Übergabe des CA an andere Stationen

JA

JA

NEIN

NEIN

JA

NEIN

MCU für Anforderung des CA auswählen

Eigene Station? Eigene Priorität höher als Priorität

der ausgewählten Station? Ausgewählte Station

„am Leben“?

Eigene Station = CA-Besitzer?

CA = FREIGEGEBEN? Eigene Priorität höher als die

des CA-Besitzers?

ANFO - CA an MCU senden (mit Code der ausgewählten

Station)

Auf ActualCA von MCU warten

Send-CA an MCU senden

(mit Priorität der ausgewählten

Station)

CA -Übergabe erfolgreich

ActualCA = ausgewählte

Station? Noch einmal versuchen

Empfangende Station zur Übergabe des CA auswählen

Übergabe des CA an ausge- wählte Station nicht möglich

Fehlermeldung: CA verweigert



Notizen: 3 CA-Parameter 3.1 ICU/SU-Geräte (MMI, Gateway, OS)

Alle ICU/SU-Geräte verwenden zur Konfigurierung des Control Access dieselben Parameter. Die Einstellung muss für alle ICU/SU-Geräte innerhalb eines Systems gleich sein. Diese Parameter müssen auch den MCU-Parametern für den Control Access entsprechen.

Tabelle 10. Parameterliste der ICU/SU Geräte

MMI-Gruppe MMI-Bezeichnung MMI-Bereich Voreinstellung SYSTEM SU Lifesign Sendezykl 1 (1) 60 sec 2 sec SYSTEM SU Geräte Überwach 1 (1) 100 sec 6 sec SYSTEM SU Lifelist Sendezykl 0: DEAKTIVIERT

1 (1) 60 sec DEAKTIVIERT

SYSTEM CA Priorität Priorität 2... Priorität 13

Priorität 2

SYSTEM CA Name 10 Zeichen MOD GW SU Lifesign Sendezyklus Jedes SU-Gerät sendet zyklisch ein Lifesign („Lebenszeichen“) auf den Backbone-LON-Bus. In diesem Parameter wird festgelegt, in welchem Zeitabstand das Lifesign-Signal von dem ICU/SU-Gerät gesendet wird.

SU Lifesign Überwachung Jedes SU-Gerät überwacht die Lifesigns der anderen ICU/SU-Geräte am Backbone-LON-Bus. Wird innerhalb des in diesem Parameter angegebenen Zeitraums kein Lebenszeichen empfangen, wird das entsprechende ICU/SU-Gerät aus der Lifelist entfernt.

Hierbei ist folgende Regel zu beachten: SU Lifesign Überwachung >= 3 * SU Lifesign Sendezyklus

SU Lifelist Sendezyklus Die SU LifeList zeigt an, welches der ICU/SU-Geräte „am Leben“ ist.

In diesem Parameter wird festgelegt, in welchem Zeitabstand die SU Lifelist vom ICU/SU-Gerät an die MCUs gesendet wird. Dieser Zeitabstand muss dem MCU-Parameter „SCHALTBERECHTIGUNG/SU LifeList Überwachung“ entsprechen.

Hierbei ist folgende Regel zu beachten: SU Lifesign Überwachung >= 3 * SU Lifesign Sendezyklus

CA Priorität In diesem Parameter wird die Priorität der ICU/SU-Geräte innerhalb der MCU-Control Access Tabelle festgelegt. Die Regeln für die Übergabe der Schaltberechtigung von einer Station an eine andere sind von dieser Priorität abhängig.

CA Name Über diesen Klartext-Namen wird das ICU/SU-Gerät in allen MMI-Menüs im Zusammenhang mit der Schaltberechtigung angesprochen.



Notizen: 3.2 MCU

Die Einstellung der Schaltberechtigungsparameter muss für alle MCUs innerhalb eines Systems gleich sein. Diese Parameter müssen auch den ICU/SU-Geräteparametern für die Schaltberechtigung entsprechen.

Tabelle 11. MCU Parameterliste

MMI-Gruppe MMI-Bezeichnung MMI-Bereich Voreinstellung Schaltberechtigung Funktion aktiviert

deaktiviert deaktiviert

Schaltberechtigung Adressenpriorität 2: Adressenpriorität 3: Adressenpriorität 4: ... Adressenpriorität 13:

Domain/Subnet/Node Domain: 0;1 Subnet: 0(1)255 Node: 0(1)127

2: 0/005/010 (GW) 3: 0/005/020 (MMI) 4: 0/005/030 (OS) 5-13: 0/000/000

Schaltberechtigung SU Lifelist Überwachung 1 (1) 255 s 20s Funktion

Mit diesem Parameter wird zwischen den 2 Optionen für die Schaltberechtigung gewählt: „DEAKTIVIERT“ bedeutet, dass die Schaltberechtigung unterscheidet zwischen

• VORORT-HW • VORORT-SW • BUS (alle ICU/SU-Geräte haben dieselben Rechte)

„AKTIVIERT“ bedeutet, dass die Schaltberechtigung unterscheidet zwischen

• VORORT-HW • VORORT-SW • SU-GERÄETE (nur eines der angeschlossenen ICU/SU-Geräte kann jeweils den Motor schalten)

Adressenprioritäten

Diese Parameter bestimmen die „Control Access Tabelle“. Ist die Schaltberechtigung AKTIVIERT, wird die Priorität der ICU/SU-Geräte hierüber bestimmt. Die ICU/SU-Geräte werden über ihre LON-Adresse angesprochen, die aus den Domain/Subnet/Node-Daten besteht, wobei „Domain“ auf „0“ steht. Über die Hierarchie werden die Regeln für „SEND-CA“ festgelegt.

Diese Parameter müssen dem Parameter „CA-Priorität“ der SU-Geräte entsprechen.

SU Lifelist Überwachung

Jedem ICU/SU-Gerät wird in der SU-LifeList ein Bit zugewiesen. Das Vorhandensein eines SU-Geräts in dieser Liste wird entsprechend dem mit diesem Parameter festgelegten Zeitintervall überwacht.

Der Parameter muss den SU-Parametern „SU Lifesign Überwachung“ und „SU Lifelist Sendezyklus“ entsprechen.

Hierbei ist folgende Regel zu beachten:

2 * SU Lifesign Überwachung +1 * SU Lifelist Sendezyklus << SU Lifelist Überwachung

Hinweis: Wenn der Sender der Lifelist ausfällt, beträgt die maximale Umschaltverzögerung für den nächsten Sender der Lifelist

2 * SU Lifesign Überwachung + 1 * SU Lifelist Sendezyklus



Notizen: 4 Anwendungsbeispiel für Control Access Das folgende Anwendungsbeispiel veranschaulicht, wie die CA-Funktion benutzt und in Prozessleit-systemen implementiert wird.

4.1 Anwendungsfall

Das Beispiel orientiert sich an normalen Anforderungen einer Prozeßsteuerung, bei der das INSUM System mit einer Prozessleittechnik (PLT) verbunden ist und eine Schaltberechtigungsfunktion erforderlich ist. Darüber hinaus muss es möglich sein, den Vorortsteuermodus der MCU neben der fest verdrahteten Möglichkeit auch softwareseitig über die PLT zu aktivieren.

Das Anwendungsbeispiel zielt darauf ab, in der PLT eine optimierte Implementierung zu erhalten und kommt dabei mit einem minimalen Signalaustausch zwischen PLT und INSUM aus. Es beruht auf der ABB-Steuerung Advant OCS. Für einige Angaben in diesem Beispiel sind gewisse Kenntnisse des Advant-Systems erforderlich, um die verwendeten Abkürzungen und Bezeichnungen zu verstehen.

Die PLT-Schnittstelle verwendet das INSUM MODBUS Gateway, die MODBUS-Konfiguration wird hier jedoch nicht weiter erläutert.

4.1.1 Teilnehmende Stationen

• Vorortsteuerung an der Maschine (fest verdrahtet) • INSUM MODBUS Gateway (stellt PLT dar) • INSUM-Benutzeroberfläche (MMI) • INSUM Operator Station (OS) • Vorortsteuerung durch PLS aktiviert (VORORT_SW) 4.1.2 Steuerungshierarchie

Die Hierarchie der teilnehmenden Stationen ist normalerweise entsprechend den Projektanforderungen festzulegen.

Da es in diesem Beispiel um die Realisierung der CA-Funktion im PLT geht, wird davon ausgegangen, dass die PLT die Station mit der höchsten Priorität innerhalb der CA-Hierarchie ist.

Die nachstehende Tabelle zeigt die CA-Prioritäten, die den CA-Stationen zugeordnet sind. Entsprechend der Philosophie des CA-Mechanismus hat jedoch in der Praxis die fest verdrahtete Vorortsteuerung standardmäßig die höchste Priorität. Die Zuordnung der CA-Prioritäten zu den CA-Stationen ist nachstehend aufgeführt.

CA Prioritäten CA Stationen 01 Vor-Ort-Steuerung (Standard) 02 MODBUS Gateway (PLT) 03 INSUM MMI (Bedienoberfläche) 04 INSUM Operator Station 14 Software vor Ort (immer niedrigste Priorität = fest)



Notizen: Die PLT erhält die folgenden Statusdaten (binär) bezüglich der aktuellen CA-Besitzer jeder MCU über das MODBUS-Gateway. Das gesetzte Bit steht für den aktiven Modus = CA-Besitzer.

MODBUS-Adresse

LON Netzwerk-Variable CA-Besitzer Statusbeschreibung

4xxxx nwActualCA1 0x0001 (hex) 0x0002 (hex) 0x0004 (hex) 0x0008 (hex) 0x2000 (hex)

Vorort (Hardware) PLT MMI INSUM OS Vorort (Software)

Beispiel:

Die Tabelle zeigt ein Beispiel für das Setzen des MODBUS Registers von nvwActualCA1, das Register kann individuell angepasst werden mit Hilfe des POCT Tools.



Notizen: Die PLT übergibt die Schaltberechtigung an die anderen Überwachungseinrichtungen (MMI, INSUM OS und VORORT_SW) durch Aussenden des entsprechenden Hex-Codes (Wortregister) in der Netzwerkvariablen nvoCAPass an die einzelnen MCUs.

MODBUS-Adresse

LON Netzwerk-Variable CA-Priorität Code-Beschreibung

4xxxx nvoCAPass 0x0002 (hex) 0x0004 (hex) 0x0008 (hex) 0x2000 (hex)

PLT MMI INSUM OS Vorort (Software)

Beispiel:

Die PLT verwendet die Statusdaten der Schaltberechtigung zur Anzeige des CA-Besitzers für die MCU, wobei die Schaltberechtigung für die MCU über das Ausgangswort an andere Überwachungseinrichtungen weitergegeben wird, welche die CA für die MCU anfordern.

4.2 CA-Verarbeitung und -Anzeige

Der Advant Controller AC 450 verwendet das PC-Element MOTCON als Motorsteuerungsobjekt. Die CA-Verarbeitung und -Anzeige ist als Teil des PC-Elements ausgeführt.

Die Anzeige für das Motorsteuerungsobjekt MOTCON unterscheidet im Wesentlichen die folgenden Betriebsarten: • Sequence: PLT besitzt CA für die MCU • Local: alle Stationen (Vorort-verdrahtet, MMI, INSUM OS oder Vorort-Software) können

CA für die MCU besitzen. Eine zusätzliche Übersichtsanzeige zur Darstellung der von INSUM unterstützten Detailinformationen enthält bei Vorortsteuerung die genaue Angabe des aktuellen CA-Besitzers einer MCU.

Anmerkung: Die Anzeige in der PLT sollte mit Bestätigung erfolgen.



Notizen: 4.2.1 Bedienung

MOTCON verwendet im Haupt-Dialogmenü folgende Befehlswege: • Sequence: Zur Anweisung und Anzeige der PLT (d.h. der Steuerung AC450) als CA-Besitzer, • Local: Weitergabe der CA an Vorortstation (Software) und Anzeige als Vorortsteuerung Die folgenden Bildschirmanzeigen zeigen dies am Beispiel der Advant Operator Station.

PLT besitzt CA für MCU

VORORT hat CA



Notizen: Der MOTCON-Dialogtaste D6 „Order“ erlaubt die Auswahl der drei Ausgangsbefehlsaufträge von MOTCON. Dies ist eine effiziente Möglichkeit zur Übergabe der Schaltberechtigung an MMI und INSUM OS. Über einen der Ausgänge werden MCU-Fehlermeldungen zurückgesetzt.

MMI und INSUM OS zeigen den CA-Besitzer durch Angabe des parametrierten Namens des jeweiligen ICU-Gerätes an. Diese CA-Besitzer-Namen können mittels MMI parametriert werden:

1. Menü <SYTEMKONFIGURATION> wählen

2. Gerät auswählen

3. Untermenü <SYSTEM> wählen

4. CA-Benutzername auswählen

5. Funktionstaste EDIT benutzen um diesen Namen zu bestimmen oder zu ändern



Notizen: 4.2.2 Anlagenphilosophie zur Bedienung der CA-Funktion

Um die CA-Funktion effektiv nutzen zu können, müssen die Anlagenbediener die folgenden Hinweise beachten.

• Die CA-Anforderung für die jeweilige MCU von der betreffenden Steuerstelle aus muss dem Prozessbediener in der Schaltwarte gemeldet werden. Dies kann über Funk oder Telefon erfolgen.

• Es sollte immer eine Bestätigung der CA-Berechtigung seitens des Prozessbedieners erteilt werden, bevor die MCU nach der CA-Anforderung geschaltet wird.

• Es wird empfohlen, die Bedienung der MCU von allen Standorten aus zwischen dem Prozessbediener, dem Personal an MMI und INSUM OS sowie demjenigen Betriebspersonal abzusprechen, das die MCU im Vorort-Modus (per Software) schaltet.

Erstes Szenario Aktueller CA-Besitzer für die MCU: PLT Angeforderter CA-Besitzer für die MCU: Vorort (Software)

Nach Anforderung der Vorortsteuerung (Software) durch das Bedienpersonal überprüft der Bediener in der Schaltwarte die Lage und kann die Entscheidung treffen, den CA für den jeweiligen Motor zu erteilen. Sofern es ihm erlaubt ist, wählt der Bediener die gewünschten Motorobjekte aus und setzt den Motor im Dialogmenü auf Vorortsteuerung. Wenn die Anzeige für das Objekt auf Vorort wechselt (mit Bestätigung), bestätigt das Bedienpersonal vor Ort die Genehmigung zur Vorort-Schaltung durch Betätigung des Drucktasters an der lokalen Schalttafel.

Der Prozessbediener kann die Schaltberechtigung jederzeit zurückholen, es ist jedoch zu empfehlen, das Bedienpersonal vor Ort zu informieren, wenn die Vorortbedienung entzogen wird.

Das Betriebspersonal muss weiterhin den Prozessbediener informieren, wenn die Arbeiten abgeschlossen sind, um die Schaltberechtigung an das PLT zurückzugeben. Dabei sollte das Betriebspersonal auch die MMI- und INSUM OS-Bediener über den Vorortbetrieb informieren.

Zweites Szenario Aktueller CA-Besitzer für die MCU: PLT Angeforderter CA-Besitzer für die MCU: MMI oder INSUM OS

Siehe Beschreibung für 1. Szenario.

Drittes Szenario Aktueller CA-Besitzer für die MCU: PLT Angeforderter CA-Besitzer für die MCU: Vorort (fest verdrahtet)

Das Wartungspersonal teilt dem Prozessbediener mit, dass an dem jeweiligen Motor Wartungsarbeiten durchgeführt werden müssen. Obwohl hierfür die Übergabe der Schaltberechtigung vom Prozessbediener nicht erforderlich ist, wird empfohlen, dem Prozessbediener die Umschaltung auf Vorortbedienung über Schlüsselschalter mitzuteilen.

Das Wartungspersonal führt die erforderlichen Wartungsarbeiten durch, während dieser Zeit erscheint das Motorobjekt im PLS weiterhin im Vorortbetrieb. Nach Abschluss der Arbeiten schaltet das Wartungspersonal den Motor wieder auf Bus-Steuerung.



Notizen: 5 Annex A: Begriffe und Abkürzungen Abkürzung Begriff Erläuterung / Anmerkungen

Backplane (Grundplatte)

INSUM-Backbone, Bestandteil der INSUM Communications Unit (ICU). Nimmt die folgenden INSUM-Geräte auf: Router, Gateways, Uhr, Netzteil.

CA Control Access Eine Funktion des INSUM-Systems, mit der Zugriffsrechte für jede Geräteebene festgelegt werden können (z.B. Leitsystem, Gateway, Feldgerät)

CAT Control Access Table Tabelle der Zugangsberechtigungen

CB Circuit Breaker Leistungsschalter (in diesem Fall: ABB SACE Emax mit elektronischem Auslöser PR112-PD/LON)

DCS Distributed Control System siehe auch PLS (Leitsystem)

Ereignis Ein Ereignis ist eine Zustandsänderung. Es kann als Fehler definiert sein, wenn der Zustand als unnormal gilt, oder als Warnung bei einem Vorwarnzustand.

Eth Ethernet Ethernet ist eine Netzwerktechnologie z.B. für Firmennetzwerke. Der Ethernet-Standard beschreibt das physikalische Medium, die Regeln für die Zugangssteuerung und die Telegrammrahmen.

FD, FU Feldgerät Sammelbegriff für die an den LON-Feldbus angeschlossenen Geräte (z.B. Motorsteuergeräte und Leistungsschalter-Auslösegeräte)

GPI General Purpose Input Digitaler Mehrzweckeingang der MCU

GPO General Purpose Output Digitaler Mehrzweckausgang der MCU

GPS Global Positioning System System zur Erfassung der lokalen Position, der Weltzeit und der Zeitzone; die GPS-Technik versorgt Systeme mit exakten Zeitangaben

GW Gateway Ein Gateway bildet die Schnittstelle zwischen dem LON-Protokoll in INSUM und anderen Kommunikations-protokollen (z.B. TCP/IP, PROFIBUS, MODBUS)

HMI Human Machine Interface (Benutzerschnittstelle)

Allgemeine Bezeichnung für Benutzeroberflächen für Feldgeräte auf Schaltanlagenebene, in Schaltanlage integriert oder als Handgeräte

ICU INSUM Communications Unit (INSUM-Kommunikations-einheit)

Die INSUM Communications Unit besteht aus der Backplane, Gateways, Routern, der Systemuhr und dem Netzteil. Sie bildet die Kommunikationsschnittstelle innerhalb von INSUM sowie zwischen INSUM und übergeordneten Leitsystemen. Frühere Bezeichnungen: SGC, SU

INSUM Integrated System for User-optimized Motor-Management(Integriertes System für nutzeroptimiertes Motormanagement).

Das Konzept von INSUM ist eine Plattform zur Integration von intelligenten Bauteilen, Geräten und Software-Tools zum Aufbau und Betrieb der Motorsteuerungs- und Schaltanlage.

INSUM OS INSUM Operator Station Tool zur Parametrierung, Überwachung und Steuerung von Geräten innerhalb von INSUM

ITS Integrated Tier Switch (Intelligenter Sicherungslasttrenner)

Der ITS ist ein Sicherungslasttrenner der SlimLine-Baureihe mit integrierten Sensoren und einer mikroprozessorgesteuerten Elektronik für Mess- und Überwachungsaufgaben.

LON Local Operating Network LON ist die Abkürzung für das Netzwerk LonWorks. Dieses findet als Schaltanlagenbus Verwendung in INSUM.

LonTalk LonTalk Protokoll Feldbus-Kommunikationsprotokoll in LonWorks-Netzwerken.



Notizen: Abkürzung Begriff Erläuterung / Anmerkungen

LonWorks LonWorks-Netzwerk Ein Kommunikationsnetz in LonWorks-Technologie, z.B. mit einem Neuron-Chip und dem Protokoll LonTalk.

MCU Motor Control Unit (Motorsteuergerät)

MCU ist eine allgemeine Bezeichnung für eine Reihe von elektronischen Motorsteuerungsgeräten in INSUM. Sie übernimmt Schutz-, Steuerungs- und Überwachungs-funktionen für einen Motorstarter in der Schaltanlage.

MMI Man Machine Interface (Benutzerschnittstelle)

Die INSUM-Benutzerschnittstelle auf Schaltanlagenebene zur Parametrierung und Steuerung von Kommunikations- und Feldgeräten.

MNS MNS Modulare Niederspannungs-Schaltanlage von ABB

MODBUS, MODBUS RTU Feldbus-Kommunikationsprotokoll

NV,nv LON-Netzwerkvariable Eine Netzwerkvariable ist ein Datenelement im LonTalk-Protokoll mit max. 31 Bytes Daten.

Nvi, nvi LON-Netzwerkvariable, Eingang

LON-Bus Eingangsvariable

Nvo, nvo LON-Netzwerkvariable, Ausgang

LON-Bus Ausgangsvariable

OS Operator Station (OS) siehe INSUM OS

PLS Prozessleitystem Übergeordnetes Leittechnik-System,

PROFIBUS DP Feldbus-Kommunikationsprotokoll mit zyklischer Datenübertragung

PROFIBUS DP-V1 Feldbus-Kommunikationsprotokoll, Erweiterung von PROFIBUS-DP, zur azyklischen Datenübertragung und Multi-Mastering

PR Programmable Release (programmierbarer Auslöser)

Leistungsschalter-Auslösegerät (in diesem Fall: ABB SACE Emax PR112-PD/LON)

PTB Physikalisch-Technische Bundesanstalt

Deutsche Zulassungsstelle für Ex-e geschützte Anwendungen.

PTC Positiver Temperaturkoeffizient

Ein temperaturabhängiger Widerstand zur Erkennung hoher Motortemperaturen und zur Abschaltung des Motors beim Erreichen einer Alarmstufe.

RCU Remote Controlled Unit (ferngesteuertes Gerät)

Vor Ort installierte Steuerung für Motorstarter, die direkt unter Umgehung der MCU für den Vorortbetrieb mit dem Starter kommuniziert.

Router Gerät innerhalb eines LON-Netzwerks zur Verbindung mehrerer LON-Subnets. Ist Teil der INSUM Communications Unit (siehe ICU)

RTC Echtzeituhr Teil der INSUM-Systemuhr und optionaler Zeitgeber für INSUM

SCADA Supervisory Control and Data Acquisition

Überwachende Steuerung und Datenerfassung

SGC Switchgear Controller Frühere Bezeichnung der INSUM Communications Unit

SPS Speicherprogrammierbare Steuerung

Steuerung auf niedriger Ebene

Störung Folge eines ausgelösten Alarms oder eines externen Abschaltbefehls eines anderen Geräts, den Motor abzuschalten oder den Leistungsschalter auszulösen. Auch: Auslösung, Alarm

STW Stromwandler Stromwandler

SU Switchgear Unit Frühere Bezeichnung der INSUM Communications Unit

Systemuhr INSUM-Gerät zur Zeitsynchronisation zwischen Zeitgeber und allen MCUs. Gehört zur INSUM Communications Unit (siehe ICU)



Notizen: Abkürzung Begriff Erläuterung / Anmerkungen

TCP/IP Transmission Control Protocol /Internet Protocol

TCP/IP ist ein hochwertiges, verbindungsorientiertes, zuverlässiges, voll-duplexes Kommunikationsprotokoll, das zur Integration heterogener Systeme entwickelt wurde.

TFLC Thermal Full Load Current Beschreibung siehe MCU-Parameterbeschreibung

TOL Thermische Überlast Beschreibung siehe MCU-Parameterbeschreibung

UTC Coordinated Universal Time (koordinierte Weltzeit)

Die koordinierte Weltzeit ist der internationale Zeitstandard, der früher auch als Greenwich Meridian Time (GMT) bezeichnet wurde. Null (0) Uhr UTC bedeutet Mitternacht in Greenwich (England), das auf dem Längengrad Null liegt. Die Weltzeit verwendet eine Zeitbasis von 24 Stunden.

VU Voltage Unit Spannungsmess- u. Versorgungseinheit für MCU 2

Warnung Eine Warnung lässt sich definieren als ein Wechsel von Daten oder Parametern von einem beliebigen Zustand in einen unnormalen Zustand. Der Zustandswechsel zum unnormalen Zustand kann auch durch Überschreiten der festgelegten Warngrenze durch Daten erfolgen.

Wink Die Wink-Funktion erlaubt die Identifizierung eines Geräts im LON-Netzwerk. Wenn ein Gerät eine Wink-Meldung vom Feldbus erhält, reagiert es mit einer optischen Anzeige (blinkende LED).

Notes:

Herausgeber: AST/BTDruckschriften-Nr.: 1TGC 901090 M0101

ABB Schaltanlagentechnik GmbHWallstadter Str. 5968526 Ladenburg

Weitere Produkte, Neuigkeiten, Kontakte:www.abb.com/mns

Leitfaden Control Access Version 2 - ABB Group€¦ · INSUM® Leitfaden Control Access (CA) ABB 5...

Documents

Transcript of Leitfaden Control Access Version 2 - ABB Group€¦ · INSUM® Leitfaden Control Access (CA) ABB 5...