Tonnenschwere Lasten in Bereichen mit Personenverkehr mit Hilfe einer Funkfernsteuerung zu befördern, ist immer mit Risiken verbunden. Es gibt zahlreiche Möglichkeiten, die Risiken durch Sicherheitssysteme und zusätzliche Anbaugeräte zu senken. In diesem Beitrag wird eine Methode beschrieben, wie die Sicherheit durch eine Safety-Applikation in einer sicherheitsgerichteten, frei programmierbaren Steuerung erfüllt werden kann. Die Firmen KUKA und Sensor-Technik Wiedemann (STW) haben in einem gemeinsamen Projekt eine neue Art der Überwachung für ein Flurförderzeug ohne Fahrerkabine entwickelt.

KUKA omniMove

KUKA omniMove ist die Bezeichnung für eine extrem wendige Antriebsart für Flurförderzeuge. KUKA omniMove mit seinen elektrischen Antrieben ermöglicht die uneingeschränkte Manövrierbarkeit in beliebige Richtungen sowie die Rotation um sich selbst. Durch seine omnidirektional fahrenden Räder lässt sich das Fahrzeug ohne Umorientierung der Räder frei navigieren und per Fernbedienung in alle Richtungen steuern – selbst in den engsten Räumen und dies mit einer Positioniergenauigkeit bis zu ±1 mm. Gegenüber konventionell gelenkten Rädern kann so die Logistikfläche um bis zu 50% reduziert und eine größere Produktionsfläche genutzt werden.

Die KUKA omniMove-Fahrzeuge für interne Logistik heben mühelos Traglasten bis zu 100 Tonnen und bieten mit zehn verschiedenen Fahrzeugvarianten zahlreiche kundenspezifische Optionspakete für unterschiedlichste Anforderungen. Dabei sind Konfigurationen von minimal 4 bis über 20 angetriebenen Rädern sowie zahlreichen zusätzlichen Tragrädern möglich, um auch sehr große, unüberschaubare Bauteile zu transportieren. Die Bedienung erfolgt komfortabel und räumlich flexibel mittels einer Funkfernsteuerung.

Beschreibung der Steuerung 3XL

Für diese vielen, unterschiedlichen Varianten an Fahrzeugen war Kuka auf der Suche nach einem Steuerungssystem, welches neben diesen Varianten auch zahlreiche kundenspezifische Wünsche unterstützt. Mit der Steuergerätefamilie ESX^® bietet Sensor-Technik Wiedemann seit Jahren schnell und einfach anpassbare Lösungen an, welche sich in vielen Anwendungen insbesondere im Land- und Baumaschinenbereich bewährt haben. Mit dem neuen Steuergerät ESX^®-3XL mit 32-Bit-Technologie wird diese erfolgreiche Serie konsequent weitergeführt. Dementsprechend wurde bei der ESX^®-3XL schon beim Konzept Wert auf ein Höchstmaß an Flexibilität gelegt, um die unterschiedlichen funktionalen Anforderungen in verschiedenen Applikationen abdecken zu können: Mit sechs internen Steckplätzen für Erweiterungsmodule lassen sich 84 von den 162 Anschlusspins mit unterschiedlichsten Funktionen belegen; angefangen bei einfachen In/Out-Erweiterungen (beispielsweise Drehencoder bis hin zu Spezial-IOs, Datenspeichern oder Kommunikationsschnittstellen). Das Mainboard der ESX^®-3XL wartet ebenfalls mit Software-konfigurierbarer Funktionalität auf. Die 28 Eingänge sind als 12Bit- Multifunktionseingänge (MFI) ausgeführt. Multifunktion bedeutet hier, dass die Eingänge komplett per Software konfigurierbar sind. Durch einfachen Funktionsaufruf können sie einzeln als analoger Strom- oder Spannungseingang bzw. als Digital-/ Drehzahleingang verwendet werden. Weiterhin erlaubt die mitgelieferte 3XL-Softwarebibliothek direkt mit einer anwendungsspezifischen Funktion auf Änderungen des Eingangssignals zu reagieren (Funktions-Callback). Als Drehzahleingang deckt der MFI einen Bereich von 0,6 Hz bis 20 kHz ab. Zusätzlich besteht für den MFI die Möglichkeit zur Filtereinstellung per Software, womit bei Analogeingängen ein Tiefpassfilter bzw. bei Digitaleingängen eine Prellzeit eingestellt werden kann. Alle Ausgänge können pulsweitenmodulierte (PWM) Signale erzeugen, sind kurzschlussfest und mittels 12Bit-Strommessung und Statusrücklesung vollständig diagnosefähig.

Den Kern der ESX^®-3XL bildet ein 150MHz-TriCore-Controller mit 4MB RAM, 6MB (optional 34MB) Flash-Speicher und 32kB EEPROM-Parameterspeicher. Bereits in der Basisvariante sind vier CAN-Schnittstellen und eine serielle Schnittstelle (RS232) enthalten. Auch hier können durch das Konzept mit Erweiterungsmodulen quasi beliebige zusätzliche Schnittstellen realisiert werden.

Funktionale Sicherheit

Die jüngere Entwicklung bei zahlreichen Kunden-Applikationen hat gezeigt, dass die Anforderungen der Anwender an die funktionale Sicherheit wachsen. Mit zunehmender Integrationsdichte von Controller- und Speicherbausteinen lassen sich neben den eigentlichen Funktionen der Steuerungen auch die erforderlichen Sicherheitsmerkmale in einem wirtschaftlich annehmbaren Rahmen erfüllen. Woraus genau resultiert nun der Bedarf an sicherheitsgerichteten elektronischen Steuerungen? Diese Steuerungen reduzieren in Anwendungen für sicherheitstechnisch relevante Aufgaben das Risiko folgenschwerer Unfälle. Vorausgesetzt natürlich, die Kriterien der funktionalen Sicherheit werden erfüllt. Sicherheit definiert sich hier als eine Sachlage, bei der das Risiko kleiner als ein von der Allgemeinheit akzeptiertes Grenzrisiko ist. Das vorhandene Risiko wird zunächst ohne Berücksichtigung von Sicherheitsmaßnahmen bewertet und wird hauptsächlich durch die Auftrittswahrscheinlichkeit und die Schwere des Schadens bestimmt, die vom Anwendungsfall abhängen. Aus dieser Risikobewertung leiten sich erforderliche risikoverringernde Maßnahmen ab. Ein sicherheitsgerichtetes elektronisches System ist eine Möglichkeit das vorhandene Risiko abzusenken, um das Grenzrisiko zu erreichen.

Vor einer Zulassung müssen die Anforderungen an die funktionale Sicherheit bestimmt werden. Welche Sicherheitsnormen sollen zur Anwendung kommen? Die Normen bestimmen sich meist aus der Anwendung. Die hier beschriebene Anwendung betrifft omniMove Flurförderzeuge der Firma Kuka, die Lasten bis zu Gewichten von 100 Tonnen befördern können. Damit werden an diese Fahrzeuge besondere Sicherheitsanforderungen in Hinblick auf die Bremswege und damit die maximal zulässige Geschwindigkeit der Flurförderzeuge gestellt. Die Risikoanalyse für das omniMove-Flurförderzeug ergab den Performance-Level "PL c", um das Grenzrisiko zu erreichen. Der Performance-Level ist eine Sicherheitskennzahl aus der Richtlinie für Maschinensicherheit DIN EN ISO 13849-1. Die Firma STW hat die Sicherheitsanforderungen erarbeitet und einen Sicherheitsplan für die omniMove-Fahrzeuge erstellt. Das Institut für Arbeitsschutz IFA in Sankt Augustin hat die Anforderungen kontrolliert und den Entwicklungsprozess begleitet.

Im aktuellen Projekt wurden diese Bedingungen mit einem sicherheitsgerichteten Softwaremodul auf der elektronischen Steuerung ESX^®-3XL von STW realisiert. Für das Modul gelten die Software-Sicherheitsanforderungen für sicherheitsbezogene Anwendungssoftware nach DIN EN ISO 13849-1. Die Sicherheitsarchitektur wurde nach Kategorie 2 der Norm konzipiert: Die Logikeinheit besteht aus dem frei programmierbaren Hauptcontroller und einer Testeinheit, dem System Supervisor (SSV). Der SSV ist ebenfalls ein programmierbarer Microcontroller, der den Hauptcontroller überwacht, indem er Watchdog-Funktionalität übernimmt, Systemspannungen überwacht, logische Abläufe kontrolliert und somit den Einsatz des Steuergerätes in sicherheitskritischen Anwendungen erlaubt. Der Hauptcontroller ist mit Diagnoseroutinen ausgestattet, die das gesamte System in Hardware und Software kontinuierlich testen und im Fehlerfall den sicheren Zustand einleiten. Der sichere Zustand ist in dieser Applikation ein Notstopp. Die omniMove-Flurförderzeuge der Firma Kuka können bauartbedingt Geschwindigkeiten von über 6 km/h erreichen. Die Risikobetrachtungen haben jedoch deutlich niedrigere erlaubte Maximalgeschwindigkeiten ergeben. Im beschriebenen Projekt gibt es zwei Bedingungen für maximale Geschwindigkeitsgrenzen. Der erste Fall betrifft den Beladungszustand. Für ein leeres Fahrzeug ist maximal die Geschwindigkeit von 3km/h erlaubt. Diese Geschwindigkeit erreicht ein Fußgänger beim normalen Gehen. Bei einem omniMove-Flurförderzeug begleitet ein Bediener mit der Funkfernsteuerung das Fahrzeug und bewegt sich selbst mit in Gehgeschwindigkeit. Für ein beladenes Fahrzeug gilt eine deutlich abgesenkte Maximalgeschwindigkeit von 1km/h. Als zweiten Fall seien Fahrzeuge betrachtet, die mit Laserscannern ausgerüstet sind und einen Rundumschutz für Flurförderzeuge sicherstellen. Laserscanner können ein Flurförderzeug zum Abbremsen veranlassen, sobald sie im Fahrweg ein Hindernis – z. B. Personen – erkennen. Es kann allerdings Anwendungsfälle geben, die ein Abschalten der Laserscanner erfordern (Override-Betrieb), wie das Durchfahren enger Werks­tore oder das Unterfahren zum Anheben eines Bauteilträgers. Um die Sicherheit trotzdem zu gewährleisten, wird die zulässige Maximalgeschwindigkeit in diesem Betriebszustand sehr stark auf 0,1 m/s reduziert.

Die maximal zulässigen Geschwindigkeiten sind so bemessen, dass das Fahrzeug bei einer Notbremsung innerhalb eines maximal erlaubten Anhalteweges zum Stillstand kommt. OmniMove-Fahrzeuge werden in den unterschiedlichsten Anwendungen eingesetzt, wodurch ein hoher Variantenreichtum der Fahrzeuge entsteht. Dadurch können sich die Risikobetrachtungen ändern und die Höchstgeschwindigkeiten der omniMove-Fahrzeuge müssen erniedrigt werden. Die Anpassung der erlaubten Höchstgeschwindigkeiten geschieht individuell für einen Fahrzeugtyp über Software-Parametrisierung.

Das Sicherheitskonzept

Das sicherheitsgerichtete Softwaremodul zur Geschwindigkeitsüberwachung hat drei Aufgaben.

• Ermittlung der aktuell erlaubten maximalen Geschwindigkeit.
• Bestimmung der Ist-Geschwindigkeit aus vorgegebenen Signalen von 3 Rädern.
  Ein viertes Rad dient als redundante Geschwindigkeitskomponente.
• Falls die Ist-Geschwindigkeit zu groß ist oder ein sonstiger Fehler erkannt wird, muss unverzüglich ein Nothalt ausgelöst werden.

Das von KUKA bei STW in Auftrag gegebene System

Der Name des zu entwickelnden Systems ist „omniMove Speed Surveillance System“ und wird mit OM3S abgekürzt. OM3S hat folgende Kernaufgaben (funktionale Anforderungen):

• Sichere Erkennung des Beladungszustands (unbeladen/beladen) des omniMove-Fahrzeugs anhand von redundanten Beladungssensoren.
• Sichere Erkennung des Zustands des Laser-Scanner-Schutzfeldes (aktiv oder durch Override-Taster abgeschaltet) anhand von redundanten Signalwegen.
• Aus Beladungszustand und Override-Information die derzeitig erlaubte Höchstgeschwindigkeit bestimmen (siehe oben).
• Sicheres Einlesen der Drehzahlen der einzelnen Antriebsräder des omniMove-Fahrzeugs durch redundante Sensoren mit analogen bzw. digitalen Ausganssignalen.
• Berechnung der Ist-Geschwindigkeit des omniMove-Fahrzeugs aus den Drehzahlen der einzelnen Antriebsräder. Diese kann mittels eines mathematischen Modells aus den x/y-Koordinaten und den momentanen Drehzahlen von drei Antriebsrädern ermittelt werden.
• Fehlererkennungen durch Plausibilisierungen.
• Jeder erkannte Fehler oder eine Überschreitung der gegenwärtig erlaubten Höchstgeschwindigkeit muss zum Nothalt des omniMove-Fahrzeugs führen. Dies entspricht dem sicheren Zustand.
• Zudem soll die Überwachungssoftware durch Parametrisierung an alle denkbaren Fahrzeugkonfigurationen anpassbar sein bzgl. Geometrie und Ausmaße des Fahrzeugs, der Anzahl angetriebener und zusätzlicher Räder usw.
  Damit OM3S den Ansprüchen einer Sicherheitssoftware mit Performance-Level "PL c" nach DIN EN ISO 13849-1 genügt, müssen des Weiteren folgende Qualitätsmerkmale erfüllt sein:
• Die im nichtflüchtigen Speicher (EEPROM) eingestellten Parameter müssen durch CRC-Checksummen überwacht werden.
• Es muss durch geeignete Maßnahmen sichergestellt sein, dass die im Arbeitsspeicher (RAM) gehaltenen Werte nicht korrumpiert werden.
• Durch einen System-Supervisor mit Watchdog-Funktionalität muss eine Programmflusskontrolle stattfinden, um die korrekte Programmabarbeitung zu garantieren.
  In den Rahmenbedingungen für OM3S wird vorausgesetzt, dass OM3S auf der PL d-zertifizierten STW-Safety-ESX^®-3XL-Steuerung mit System Supervisor und integrierter Hardwarediagnose eingesetzt wird.
  Die von STW mit der Safety-ESX^®-3XL gelieferte Hardwarediagnose gliedert sich in 2 Teile:

• Startup-Diagnose, die bei jedem Einschalten der Steuerung durchlaufen wird und grundlegende Funktionen der Steuerung testet, wie beispielsweise das Schalten des Sicherheitsrelais. Diese Tests können im späteren Betrieb nicht wiederholt werden, da sie die Funktionalität des Fahrzeuges beeinflussen.
• Periodische Tests von Speicher und CPU auf Konsistenz der Inhalte und Funktion, welche parallel zur eigentlichen Kundenapplikation als auch OM3S im Hintergrund laufen.
   
  In diesem Projekt verwendet der Auftraggeber KUKA bereits eine STW-Safety-ESX®-3XL-Steuerung, auf welcher die Applikationssoftware für den Betrieb des Fahrzeugs implementiert ist. Auf dieser Steuerung soll zusätzlich OM3S laufen. Für das zu entwickelnde System OM3S ergeben sich somit Schnittstellen zu folgenden (für OM3S) externe Entitäten:

• Steuerungssoftware der Firma Kuka.
• Die Hardware-Abstraction-Layer (HAL) der ESX^®-3XL-ECU (Electronic Control Unit).

Entwicklungsprozess bei STW

Der Entwicklungsprozess einer Sicherheitssoftware nach DIN EN ISO 13849-1 orientiert sich am V-Modell (siehe Abbildung 5).

Requirements-Engineering mit einer Anforderungsmanagement-Software

Das Pflichtenheft dieses Projektes wurde von Anfang an ausschließlich in einer Datenbank-orientierten Anforderungsmanagement-Software bearbeitet. Dies fördert die atomare Erfassung einzelner Anforderungen (= Einzelentitäten), die über Identitätsnummern (ID) referenziert und einzeln getestet werden können. Dies führt gleichzeitig zu testbaren Anforderungen und zudem können die einzelnen Forderungen über den Lebenszyklus der Anwendung bis zur ihrer Entstehung/Quelle zurückverfolgt werden.

Pflichtenheft-Reviews

Die einzelnen Pflichtenheftstände wurden jeweils durch verschiedene Fachkräfte auf folgende Aspekte mittels Reviews überprüft sowie die Ergebnisse dokumentiert, um in der nächsten Version eingearbeitet werden zu können.

• Eindeutigkeit
• Vollständigkeit
• Testbarkeit

Architekturentwurd und Review

Vor dem Entwurf der einzelnen Softwarekomponenten wurde die Systemarchitektur entworfen, durch einen außenstehenden Softwarearchitekten mittels Review überprüft und nochmals verfeinert.

Embedded-Unit-Tests (Komponententests)

Zu jeder Funktion, die eine Softwarekomponente erfüllen soll, wurde jeweils ein Unit-Test geschrieben.

Somit können bei jeder Änderung der Software alle Tests in Sekundenschnelle per Knopfdruck wiederholt werden. Dies schafft die Gewissheit, dass auch nach einer Änderung noch alle bisherigen Funktionalitäten weiterhin fehlerfrei funktionieren.

Systemspezifikation und -durchführung

Nachdem im Pflichtenheft die Anforderungen spezifiziert sind, werden diese zunächst in Reviews auf Testbarkeit geprüft. Für testbare Anforderungen werden dann Systemtests in einer eigenen Systemtestspezifikation erstellt.

Konfigurationsmanagement

Um den Überblick zu behalten, welche Versionsstände der einzelnen Entwicklungsartefakte (Pflichtenheft, Architekturentwurf, Systemtestspezifikation, Implementierung, Testprotokolle) zusammenpassen, wird ein Konfigurationsmanager bestimmt, der sich um die Konfigurationsverwaltung kümmert.

Testmanagement

Die Wichtigkeit der Softwaretests wird durch das Vorhandensein eines Testmanagers unterstrichen. Der Testmanager wird vom Projektmanagement beauftragt. Er erstellt einen Testmanagementplan, organisiert die Tests und koordiniert die Tätigkeiten der Softwaretester.

Äbweichungsmanagement

Ebenfalls zu den Aufgaben eines Softwaretesters gehört die Verwaltung der bei den Tests ermittelten Abweichungen. Diese müssen zunächst in einem Ticket-System protokolliert werden. Danach wird die weitere Bearbeitung einschließlich Status (z. B. durch Entwickler bearbeitet, durch Tester als behoben gekennzeichnet) jeder einzelnen Abweichung verfolgt.

Änderungsmanagement

Nachdem eine erste Version des Pflichtenhefts fertiggestellt und freigegeben ist, kann offiziell mit der Erstellung der Systemtestspezifikation und dem Entwurf der Software-Architektur begonnen werden. In der Praxis wird mit Anforderungen, deren Spezifikation als ausreichend stabil erachtet wird, natürlich bereits früher begonnen. Ab diesem Zeitpunkt dürfen sämtliche Änderungswünsche nur noch über ein Änderungsmanagement eingebracht werden. Dazu wird jeder einzelne Änderungswunsch in einem Ticket-System erfasst und muss eine Reihe von verschiedenen Statuszuständen durchlaufen, ehe er schließlich genehmigt ist und umgesetzt wird.

Die Inbetriebnahme

Sind die Bedingungen der funktionalen Sicherheit erfüllt, sollte das Flurförderzeug möglichst ohne Ausfälle arbeiten. Die Verfügbarkeit ist für den Kunden eine wesentliche Richtgröße.

Im Fall der Sicherheits-Applikation OM3S musste STW die Verfügbarkeit erhöhen, denn die Konstruktion der omniMove-Räder führt zu systemimmanenten Schwingungen. Die gute Umsetzung wurde erreicht durch den Einbau von „gleitenden Mittelwert“-Filtern beim Einlesen der Drehzahlen der Antriebsräder. Dazu bedurfte es mehrerer Iterationen von Fahrtests mit dem omniMove-Fahrzeug, Diskussionen der technisch möglichen Verbesserungen mit den Sicherheits-Fachleuten und erneuten Anpassungen in der Anforderungsspezifikation von OM3S, bis eine aus allen Betrachtungsweisen akzeptable Lösung gefunden wurde, bei welcher zudem die Wirtschaftlichkeit gegeben ist.

Fazit

Die sicherheitsgerichtete Anwendung auf Basis eines Softwaremoduls kann unter Erfüllung der Aspekte der funktionalen Sicherheit sowohl die Verfügbarkeit des Systems gewährleisten, als auch die Flexibilität in Bezug auf den Variantenreichtum der Flurförderzeuge in bester Weise erfüllen. Die Parametrisierung wurde in die Sicherheitsbetrachtungen einbezogen, sodass zukünftige kundenspezifische Weiterentwicklungen der omniMove-Flurförderfahrzeuge in einfacher Weise umgesetzt werden können.