Verriegelungen und Blockierungen

Einleitung

Verriegelungen in Schaltanlagen sind dazu da, Fehlschaltungen zu verunmöglichen. Die Freigabe, resp. die Blockierung einer Schalthandlung wird dafür aus dem Zustand der Anlage logisch erzeugt. Das klingt sehr einfach. Passt man jedoch nicht auf, und geht bei der Planung nicht systematisch vor, passieren immer wieder Fehler und es entstehen Diskussionen darüber, welche Betriebszustände nun betrieblich ausgeschlossen werden können oder es wird auf der Anlage nachgebessert. Einen Weg zur Erstellung des Verriegelungs-Konzepts das später zur Prüfung dient und in die Dokumentation einfliesst wird in Folgendem vorgestellt.

Konzept

Als erstes sollten immer grundsätzlich betriebliche Aspekte definiert und klargestellt werden. Werden beispielsweise Blockierungen von Verriegelungen unterschieden, sollte das in ein paar Zeilen, die etwa so aussehen könnten, niedergeschrieben werden:

Blockierungen

Die Anlage ist prozesseitig nicht operativ da die Anlage topologisch nicht ausreichend definiert oder betrieblich blockiert ist. Eine Blockierung kann nicht umgangen werden (Betriebsart
«unverriegelt» nicht möglich).

Verriegelungen

Sie entstehen meistens aus topologischen Zuständen, um Fehlschaltungen zu verhindern. Verriegelungen können umgangen werden (Betriebsart «unverriegelt» möglich).

Ausserdem sollte klar sein ob die Schalter auch als Trennstelle gelten und wie die Verriegelungen und Blockierungen bei Verstoss reagieren. Für unser Beispiel sieht das so aus:

• Ein Leistungsschalter gilt nicht als Trennstelle, daher sind Schaltelemente die an einen Leistungsschalter anschliessen benachbart .
• Blockierungen und Verriegelungen die beim Schaltbefehl nicht freigegeben sind (keine Freigabe), führen zur Meldung «Verriegelungsverstoss»

Nun wird es Zeit einen Blick auf unsere Topologie zu werfen:

Regeln

Im Beispiel wird nun die Verriegelung und Blockierungen für den Erdtrenner -QC9 erstellt. Dazu müssen Regeln definiert werden:

1. Blockierung: Die Schaltelemente mit GWS gelten als blockiert. Sie können nicht geöffnet oder geschlossen werden.
2. Blockierung: Die Abgangserdtrenner können bei ausgelöstem U-Wdl Automat nicht geschlossen werden (alle U-Wdl Automat sind zu berücksichtigen).
3. Verriegelung: Die Trenner und die Erdtrenner können nicht geöffnet oder geschlossen werden, wenn die benachbarte Elemente in Zwischen- oder Störstellung stehen.
4. Verriegelung: Die Elemente die in Zwischen- oder Störstellung stehen, können nicht geöffnet oder geschlossen werden.
5. Verriegelung: Die Erdtrenner können bei benachbartem geschlossenem Trenner nicht geöffnet oder geschlossen werden.
6. Verriegelung: Die Abgangserdtrenner können bei anstehender Spannung nicht geschlossen werden.

Die obenstehenden Regeln wurden immer gleich aufgebaut nach dem Schema:

Erdtenner kann bei Situation xy nicht geschaltet werden.

Die Formulierung läuft in unserem Beispiel immer auf eine Verriegelung / Blockierung und nicht auf eine Freigabe aus. Wie man das ganz festlegt ist Geschmackssache. Wichtig ist, dass die Regeln einheitlich formuliert werden und danach die Logik einheitlich geplant wird. Das ist nicht zu unterschätzen weil somit keine Verrieglungen / Blockierungen erzeugt werden, die sich gegenseitig beeinflussen.

In Fällen mit verdrahteter Verriegelung ist es häufig vorzuziehen mit Sätzen wie

Erdtenner kann bei Situation xy geschaltet werden.

zu arbeiten, da die Signale direkt auf die Antriebe der Schaltelemente wirken.

Umsetzung

Für die Planung ist wieder mal eine Wahrheitstabelle eine gute Sache um die Bedingungen sauber darstellen zu können. Jede Spalte entspricht einem Zustand und jede Zeile kann einer Regel zugeordnet werden. Verriegelungen werden vorzugsweise fail-safe ausgeführt, jedoch muss man häufig mit dem leben, was ins Steuergerät eingelesen wird oder an Kontakten bei einer verdrahteten Verriegelung zur Verfügung steht.

Wobei 1 für true und 0 für false stehen.

Mit dieser Darstellungsweise bietet sich Logik mit Sum of Products an und sieht für die jeweilige Regel wie folgt aus: (‚x bedeutet x negiert)

'-SW1 ein * '-SW1 aus * '-SW1 entnommen +
-SW1 ein * -SW1 aus * '-SW1 entnommen +
-QC9 GWS +
VT MCB aus +
'-QC9 ein * '-QC9 aus * Betriebsart verriegelt +
-QC9 ein * -QC9 aus * Betriebsart verriegelt +
-SW1 ein * Betriebsart verriegelt +
U auf Abgang * Betriebsart verriegelt

Jede Zeile kann einer Regel zugewiesen werden. In einem Steuergerät mit stuctured text, FUP oder CFC sollten die Verriegelungen auch direkt so umgesetzt werden. Anpassungen oder Erweiterungen sind so sehr einfach und übersichtlich vorzunehmen.

Direkt verdrahtet

Werden die Regeln mit Verdrahtung umgesetzt sollte, um Kontakte zu sparen, ausgeklammert werden:

('-SW1 ein * '-SW1 aus + -SW1 ein * -SW1 aus) * '-SW1 entnommen +
-QC9 GWS +
VT MCB aus +
('-QC9 ein * '-QC9 aus + -QC9 ein * -QC9 aus + -SW1 ein + U auf Abgang) * Betriebsart verriegelt

Im Schema könnte das auf einer Seite wie folgt dargestellt werden:

In grün ist noch eine Kontakt-Optimierung dargestellt. Sind Kontakte knapp – und das sind sie immer – kann das natürlich gemacht werden. Kreuz und quer auch durch Verriegelungen anderer Elemente hindurch sollte aber wenn möglich nicht optimiert werden.

Prüfung und Dokumentation

Für die Prüfung und die Dokumentation macht es keinen Sinn Kontakt-Optimierungen boolisch darzustellen, weil die Funktion und die Regel dahinter nicht mehr einfach ersichtlich ist. Geprüft und Dokumentiert wird nach Sum of Products pro Schaltelement, am besten gleich mit der Wahrheitstabelle. So kann Zeile für Zeile der jeweilige Zustand erstellt werden und einen Haken gemacht werden, wenn die Bedingung erfüllt ist. Negativchecks sind dabei nicht nötig, den ein Fehler der dabei gefunden werden könnte, würde sofort einer weiteren Zeile in der Wahrheitstabelle entsprechen was man der Verdrahtung oder der Parametrierung des Steuergerätes gleich ansehen würde. Ausserdem, wie in obenstehendem Beispiel würde dies einer zusätzlichen Verriegelung entsprechen was betrieblich „ungefährlich“ wäre.

zurück