Die in dieser Dokumentation aufgeführten Produkte und Systeme werden unter Anwendung eines von DQS zertifizierten Qualitätsmanagementsystems nach DIN ISO 9001 hergestellt und vertrieben. Das DQS-Zertifikat ist in allen EQ Net-Ländern anerkannt.
Rechte
SIMATIC® und SIBAS® sind eingetragene Marke der Siemens AG. Die übrigen Be-zeichnungen in dieser Dokumentation/Information können Marken sein, deren Benutzung durch Dritte für deren Zwecke die Rechte der Inhaber verletzen könnte.
Courier New Schriftart Courier New kennzeichnet Programmtext, Benutzereingaben und auf dem Bildschirm erscheinenden Text.
GROSSBUCHSTABEN Verzeichnisnamen, Dateinamen, Namen von Anwendungen und Akronyme werden in Großbuchstaben geschrieben.
Ausnahme: Namen von Header-Dateien werden wie im Quelltext in Kleinbuchstaben angegeben.
Kursiv Kursiv hervorgehobene Wörter bezeichnen Namen von Variablen, Konstanten, Funktionen, Befehlen, Klassen und Strukturen.
fett Fett hervorgehobene Wörter bezeichnen Schaltflächen und Buttons in der Software.
Datei ⏐ Öffnen Senkrechte Trennstriche stellen die Befehlsfolge in Menüstrukturen dar. Datei ⏐ Öffnen bezieht sich auf den Öffnen-Befehl im Menüpunkt Datei.
[Tastenbezeichnung]
Kursive Schrift in eckigen Klammern stellen Tasten auf der Tastatur dar. Beispiel: "Drücken Sie [Strg], [Esc] oder [F1]."
[Taste1]+[Taste2] Mit einem "+" verbundene Tastenbezeichnungen, bedeuten das gleichzeitige Betätigen beider Tasten.
[] Eckige Klammern weisen in Text- oder Syntaxbeispielen auf optionale Elemente hin. Bei der Eingabe werden die eckigen Klammern weggelassen.
Zahlen in eckigen Klammern weisen im Text auf Literaturverweise im Quellenverzeichnis hin.
<> Spitze Klammern weisen in Text- oder Syntaxbeispielen auf einen variablen String hin. An dieser Stelle muss ein String eingegeben werden. Die spitzen Klammern werden dann weggelassen.
... Drei Punkte weisen in Text- oder Syntaxbeispielen auf weggelassenen Code hin.
Mit einem am linken Rand durch einen Strich markierte Textpassagen sind für den Anwender der PN PC/104 Baugruppe nicht relevant, da diese Beschriebenen Eigenschaften / Funktionen durch die Baugruppe realisiert sind.
2.5.5 Web-Server für gerätespezifische Diagnose und Service ................ 71 2.5.5.1 Webinhalte........................................................................................ 71 2.5.5.2 Anforderungen bzgl. funktionaler Sicherheit an die Webapplikation 71 2.5.5.3 HTTP-Authentifizierung .................................................................... 72
2.6.3.1 Definition des Funktionsstatus.......................................................... 76 2.6.3.2 Definition des Betriebsstatus ............................................................ 77
2.6.4 Diagnosebeispiel .............................................................................. 83 2.6.4.1 Szenario 1 – Betriebs- und Funktionsstatus für eine offene Tür....... 84 2.6.4.2 Szenario 2 – Betriebs- und Funktionsstatus für eine defekte Tür..... 84 2.6.4.3 Szenario 3 – Betriebs- und Funktionsstatus für eine ausgruppierte Tür
.......................................................................................................... 84 2.6.5 Betriebs- und Parameterdaten.......................................................... 84 2.6.6 Diagnosewahrheit ............................................................................. 85 2.6.7 Generierung und Übertragung von Diagnoseereignissen ................ 87 2.6.8 Diagnosegenerierung im Subsystem................................................ 87
Abbildung 2-32: Funktionen, Funktionsträger, Betriebsstatus und Funktionsstatus am Beispiel der Türsteuerung.................................................................................. 83
1.1 Inhalt des Dokumentes Dieses Papier ist eine Beschreibung zur Einbindung von Subsystemen in das Projekt Sibas PN. Zum Zeitpunkt der Erstellung befindet sich die Komponenten von Sibas PN noch in der Entwicklung, so dass Änderungen und Erweiterungen nicht auszuschließen sind. Das Papier stellt eine Zusammenstellung des gegenwärtigen Erkenntnisstandes dar. Weitere Versionen können folgen.
Die gezeigten Leittechnikstrukturen sind als Beispiel zur Veranschaulichung gedacht. Konkrete Festlegungen erfolgen durch Vorgaben der Fahrzeugprojekte.
1.2 Voraussetzungen an den Leser Grundsätzlich werden zum Verständnis keine speziellen Kenntnisse vorausgesetzt, jedoch sind Kenntnisse über SIMATIC und PROFINET vorteilhaft.
1.3 Ausgangssituation Die Integrationsplattform für Komponenten des Leittechniksystems ist das Kommunikationssystem PROFINET der PROFIBUS Nutzerorganisation (PNO) [1].
1.4 Zielsetzung und Randbedingungen Es ist explizit keine Kompatibilität zu Vorgängersystemen, wie z.B. Sibas 32 gegeben.
Für die Anbindung an PROFINET kommen Produkte der Industrieautomatisierungstechnik von SIEMENS I IA zum Einsatz.
Damit sind folgende Ziele erreichbar:
• Integration der Informationstechnologien (Internet, http, ftp...)
• Nutzung von weit verbreiteter Hard- und Software und offenen Standards
• Partizipieren am hohen Innovationsgrad der Industrie-Automatisierungstechnik
2.1.1 Gerätekonzept Sibas PN umfasst die für die Automatisierung von Schienenfahrzeugen notwendigen Steuerungs- und Kommunikationssysteme inklusive der Anbindung von Subsystemen. Dazu gehören auch notwendige Projektierungswerkzeuge.
Integrationsplattform ist PROFINET als Fahrzeugbus, mit dem im Wesentlichen folgende Steuerungssysteme leittechnisch verbunden werden:
Sub Die Subsystem-Steuerung erfüllt Fahrzeugteilfunktionen. Eine wichtige leittechnische Schnittstelle ist die Schnittstelle zwischen Subsystem-Steuerung und Fahrzeugsteuerung am Fahrzeugbus.
SP CS SP CS (Sibas PROFINET Control System)
Mittels des SP CS werden fahrzeugweite und zugweite Funktionen erfüllt und Subsysteme koordiniert.
SP CS ist die Steuerung, die Echtzeit- und Sicherheitsanforderungen erfüllen muss.
SP SR SP SR (Sibas PROFINET System Server) ist der zentrale Server innerhalb von Sibas PN. SP SR beschreibt eine SW Komponente. Im Rahmen der Konfigurationen bzw des Mengengerüstes wird festgelegt, welche Komponenten auf einer HW laufen können „2in1 Lösung“
SP HMI SP HMI (Sibas PROFINET Human Machine Interface) sind die Bedien- und Anzeigefunktionen von Sibas PN.
SP DP
Mittels der Dezentralen Peripherie können binäre und analoge Prozesssignale eingelesen oder ausgegeben werden und über den Fahrzeugbus übertragen werden.
WTB Link Der WTB Link bindet den Zugbus an den Fahrzeugbus an.
Die Verbindung zwischen Zugbus und Fahrzeugbus wird durch den WTB Link realisiert. Der WTB Link übernimmt das Verteilen der Daten zwischen Fahrzeugbus und Zugbus unter Berücksichtigung der (dynamisch änderbaren) Zugkonfiguration.
Der WTB dient zur Kommunikation zwischen betrieblich kuppelbaren Fahrzeugen oder Zugteilen. Internationale Standards (z.B. UIC 556 und weitere UIC-Merkblätter) ermöglichen dabei die Interoperabilität von Fahrzeugen unterschiedlicher Hersteller. Der derzeit international standardisierte Zugbus ist der „Wire Train Bus“ (WTB) nach IEC 61375, auf diesem Standard bauen auch o.g. UIC-Merkblätter auf
MVB Link Der MVB Link ermöglicht den Anschluss von Geräten mit MVB an den Fahrzeugbus.
RDA RT Train /
Groundstation
Eine Anbindung an die stationäre Seite erfolgt funkbasiert über die Funkkopplung Train (RDA RT Train) bzw der Gegenstelle Groundstation auf der stationären Seite.
2.2.1 PROFIBUS Nutzerorganisation Eine offene Technologie bedarf zu ihrer Pflege, Fortentwicklung und Verbreitung am Markt einer unternehmensunabhängigen Institution als Arbeitsplattform. Zu diesen Zwecken wurde im Jahre 1989 die PROFIBUS Nutzerorganisation e.V. (PNO) als eine nonprofit Interessensvertretung von Herstellern, Anwendern und Instituten gegründet.
Die PNO ist Mitglied im 1995 gegründeten internationalen Dachverband PROFIBUS/PROFINET international (PI). Mit 24 regionalen Nutzerorganisationen (Regional PROFIBUS/PROFINET Associations, RPA) und ca. 1300 Mitgliedern, darunter in den USA, China und Japan, stellt PI die weltweit größte Interessengemeinschaft auf dem Gebiet industrieller Kommunikation dar. Die RPAs organisieren Messeauftritte und Informationsveranstaltungen und sorgen auch dafür, dass neue Anforderungen der Märkte bei Weiterentwicklungen berücksichtigt werden.
Aufgaben
Wesentliche Aufgaben von PROFIBUS/PROFINET international (PI) sind:
• Pflege und Weiterentwicklung der Technologien PROFIBUS und PROFINET.
• Förderung der weltweiten Verbreitung der Technologien.
• Investitionsschutz für Anwender und Hersteller durch Einflussnahme auf die Standardisierung und Normung.
• Interessensvertretung der Mitglieder gegenüber Normungsgremien und Verbänden.
• Weltweite technische Unterstützung durch Competence und Training Center http://www.profibus.com/pn/support/pccs/
• Qualitätssicherung durch Gerätezertifizierung.
Mitgliedschaft
Die Mitgliedschaft ist regional organisiert.
Sie steht allen Unternehmen, Verbänden, Instituten sowie Personen offen, die sich in konstruktiver Weise an der Entwicklung und Verbreitung der Technologien PROFIBUS und PROFINET beteiligen wollen. Durch das gemeinsame Wirken der oft sehr unterschiedlichen und aus verschiedenen Branchen stammenden Mitglieder wird ein erheblicher Synergieeffekt und ein breiter Informationsaustausch generiert. Das führt zu innovativen Lösungen, effektiver Ressourcennutzung und letztlich zu Wettbewerbsvorteilen am Markt.
Die Aktivitäten zur Technologieentwicklung werden durch den Beirat (Advisory Board) gesteuert. Die Entwicklungsteams sind organisiert in Fachausschüssen (Technical Committees, TC) mit über 50 festen Arbeitskreisen (Working Groups, WG). Dazu kommt eine wechselnde Zahl von Ad Hoc WGs, die spezifische zeitlich begrenzte Themen aufnehmen. Die WGs erarbeiten neue Spezifikationen und Profile, kümmern sich um Qualitätssicherung und Standardisierung, arbeiten in Normungsgremien mit und führen wirkungsvolle Marketingmaßnahmen (Ausstellungen, Präsentationen) zur Verbreitung der Technologien durch. Die Geschäftsstelle (PI Support Center) koordiniert alle anfallenden Aktivitäten. An der Entwicklung und Verbreitung der Technologie sind in den Arbeitskreisen mehr als 500 Experten aktiv.
Die Unterteilung in die über 50 WGs erlaubt eine sehr effiziente Entwicklungsarbeit mit Konzentration auf bestimmte Themen und Branchen.
Alle Mitglieder haben das Recht zur Mitarbeit in den Arbeitskreisen und können damit auf die Weiterentwicklung Einfluss nehmen. Alle neuen Arbeitsergebnisse werden den Mitgliedern zur Kommentierung vorgelegt, bevor sie durch den Beirat freigegeben werden.
Geräteprofil
Für die Erstellung von Profilen von Komponenten der Bahnautomatisierung wurde in der PNO die Arbeitsgruppe WG19 „Train Applications“ eingerichtet. Hier werden allgemeine und subsystemspezifische Festlegungen für Geräteprofile definiert. Zunächst wird ein Profil für die Anbindung des Zugbusses nach UIC556 an PROFINET erstellt. Weitere Geräteprofile werden folgen.
Ein Profil ermöglicht das applikationsgerechte Zusammenwirken von Geräten verschiedener Hersteller am PROFINET. Profile werden durch Spezialisten von (unterschiedlichen) Firmen definiert, mit dem Ziel, dass alle Gerätehersteller diese Profildefinition anwenden.
PROFINET Profile sind:
o herstellerübergreifende Festlegungen über gleichartiges Geräteverhalten
o dokumentiert in PROFINET-Richtlinien
o optional einsetzbar
PROFINET Profile beschreiben:
o Geräteklassen, z. B. Antriebe
o Betriebsarten, z. B. Redundanz
o anwendungsspezifische Anforderungen
o den Ablauf einer Kommunikation und die Mindestanforderungen an Geräte
o den Dateninhalt der auszutauschenden Daten (Bedeutung und Format)
o Interoperabilität auf Applikationsebene (einheitlicher Zugriff auf die ausgetauschten Daten ohne Änderung der Anwendersoftware)
o die Vereinfachung einer Ausschreibung (herstellerunabhängig)
o die Austauschbarkeit der eingesetzten Geräte
Technischer Support
PI unterhält weltweit über 30 Competence und Training Center und hat 7 Testlabore für Zertifizierungsarbeiten akkreditiert. Diese Einrichtungen beraten, schulen und unterstützen die Anwender und Hersteller vielfältig bzw. führen Tests zur Zertifizierung von Geräten durch. Als Einrichtung von PI bieten sie ihre Dienste im Rahmen des vereinbarten Regelwerkes firmenneutral an. Sie werden regelmäßig auf ihre Eignung hin in einem der jeweiligen Gruppe zugeschnittenen Akkreditierungsprozess überprüft. Aktuelle Adressen finden sich auf der Website der Organisation [1] (http://www.profibus.com/pn/support/pccs/).
2.2.2 Übersicht PROFINET PROFINET ist der innovative Automatisierungsstandard der PROFIBUS Nutzerorganisation für die Realisierung einer ganzheitlichen und durchgängigen Automatisierungslösung auf Basis von Industrial Ethernet.
Mit PROFINET können dezentrale Feldgeräte sowie zeitkritische Anwendungen genauso in die Ethernet Kommunikation eingebunden werden, wie verteilte Automatisierungssysteme auf Basis von Komponenten.
Durch die Möglichkeit neben der Felddatenübertragung auch IT-Standards zu nutzen, ist eine durchgängige Infrastruktur realisierbar, die IT-Offenheit und Echtzeitfähigkeit bietet. PROFINET ist die Realisierung eines Realtime-Ethernet (RT-Ethernet) für die Automatisierungstechnik, die auch im Bahnbereich anwendbar ist.
Mit PROFINET wird bei Sibas PN der Fahrzeugbus realisiert, der Steuerungsrechner innerhalb eines Bahnfahrzeuges verbindet.
PROFINET ist ein Switched Ethernet mit einer Erweiterung zur Übertragung von Felddaten in Realtime. Diese RT-Eigenschaften sind ein Merkmal von PROFINET und werden durch das übliche Ethernet nicht erfüllt. Erreicht werden diese Eigenschaften durch den PROFINET Protokollstack und einem hierfür entwickelten Ethernet Controller ERTEC (Enhanced Realtime Ethernet Controller), mit dem sowohl die Switchfunktionalität, wie auch die Kommunikationsanbindung von Steuerrechnern realisierbar sind.
Die Netzkomponenten für ein Switched Ethernet bestehen aus den aktiven Switches, PROFINET-Anschaltungen und den zugehörigen Leitungen und Steckern.
Die Komponenten stammen aus dem Produktspektrum von Siemens I IA.
Im Folgenden sind die wesentlichen Eigenschaften von PROFINET zusammengestellt.
2.2.3 Eigenschaften PROFINET PROFINET setzt auf Fast Ethernet mit den Eigenschaften 100 Mbit/s, Full-Duplex und Switching auf. Im Rahmen von Sibas PN werden für die Signalübertragung nach 100Base-TX symmetrische Kupferleitungen (Twisted Pair) verwendet.
Alle Steuergeräte werden über aktive Netzkomponenten angeschlossen. Netzkomponenten bei PROFINET sind Switches. Zwischen den Switches läuft die Kommunikation kollisionsfrei ab.
Um Determinismus und Taktsynchronität für die Echtzeiteigenschaften zu garantieren, bilden hochsynchrone Switches das echtzeitfähige Netzwerk. Sie sorgen für das zeitgenaue Ein- und Ausschleusen der Daten und die Durchleitung im Netzwerk.
Um die Anzahl der Komponenten und die Kosten zu minimieren, wird der Switch in die Ethernet-Anschaltung und damit in das Steuergerät integriert.
Abbildung 2-2: Integration der Switches in die Ethernetanschaltungen der Teilnehmer
Für die Übertragung von Echtzeit und Nicht-Echtzeit-Daten wird die Bandbreite von Ethernet, die beim Standard-Ethernet komplett für spontane Kommunikation zur Verfügung steht, in getrennte Zeitbereiche für diese Datenarten aufgeteilt.
Hinweis: Die im folgenden beschriebenen PROFINET Mechanismen, bzw. Eigenschaften entsprechen dem aktuellen Stand der PROFINET Implementierung. Aufgrund von Funktionsänderungen, bzw. Erweiterungen können diese Mechanismen, bzw. Eigenschaften von PROFINET zukünftig abweichend zu dieser Dokumentation sein.
Um die zur Verfügung stehende Übertragungsbandbreite von Ethernet in Bereiche für Echtzeit- und Nicht-Echtzeit-Daten aufzuteilen, wird die Bandbreite in Zeitzyklen aufgeteilt. Alle angeschlossenen Switches werden auf diese Zyklen synchronisiert. Dies geschieht durch einen Automatismus, der alle Zeitparameter der Strecke erfasst und somit eine hochgenaue Synchronisation aller Switches auf den Zyklusstart ermöglicht. Die Zyklussynchronisation erfolgt auf Basis von Synchronisationstelegrammen und der dafür entwickelten Switch-Hardware (ERTEC).
Durch die Einteilung in Zyklen ist es möglich, einen bestimmten Anteil der Bandbreite für die Übertragung von Echtzeitdaten zu reservieren. Die restliche Bandbreite steht bis zum Beginn des nächsten Zyklus für Nicht-Echtzeit-Daten zur Verfügung.
Zum besseren Verständnis sind hier zunächst die verschiedenen verwendeten Begriffe beschrieben.
Für Echtzeitdaten werden auch die Begriffe Realtime- oder RT-Daten verwendet. Damit sind Feld- oder Prozessdaten gemeint, die zyklisch zu fest definierten Zeitpunkten übertragen werden. Die Übertragung ist unabhängig davon, ob sich die Werte dieser Daten verändert haben oder nicht. Es wird also immer ein aktuelles Abbild der Daten übertragen. Für diese deterministische Datenübertragung bietet PROFINET folgende Protokolle an:
• IRT (Isochrone Realtime)
• RT (Realtime)
Bei den Nicht-Echtzeit-Daten (Non Realtime, NRT) werden Standard-Protokolle, die bei Ethernet verwendet werden, eingesetzt. Die Übertragung von NRT-Daten findet in der Regel spontan statt. Als Protokolle werden TCP/UDP/IP genutzt.
Kommunikation. Die deterministische Kommunikation erfolgt nur für zyklische IRT- und RT Telegramme, während die TCP/IP-Telegramme im offenen Kanal transportiert werden.
Um die uneingeschränkte Offenheit für NRT-Telegramme nicht einzuschränken, dürfen TCP/IP-Telegramme mit maximaler Länge nicht behindert werden. Damit ist eine Einschränkung hinsichtlich der minimalen Zykluszeit gegeben (ein Telegramm mit 1440 Byte Länge benötigt ca. 125 μs ).
Auf der anderen Seite dürfen TCP/IP-Telegramme maximaler Länge den Zyklusbeginn nicht verzögern. Die PROFINET-Switches verzögern deshalb TCP/IP-Frames, die kurz vor Zyklusbeginn und während der IRT-Phase anstehen, solange, bis die IRT-Phase beendet ist.
Die Basiszykluszeit ist für das Gesamtsystem einstellbar und wird für Siemens Mobility-Anwendungen bei 1 ms oder 2 ms liegen. Die Sende- und Empfangszyklen der einzelnen Steuergeräte sind in Vielfachen der Basiszykluszeit projektierbar (z.B. 4, 8, 16 ms).
Die für IRT reservierte Zeit wird bei der Projektierung einer Anlage ermittelt und ergibt sich aus der Anzahl der Steuergeräte, die IRT-Daten austauschen und deren zyklischem Datenaufkommen (Datenmenge und Zykluszeit). Diese Bandbreitenreservierung wird zur Laufzeit strengstens eingehalten. Dies ist möglich, da in dieser Phase nur geplante Kommunikation stattfindet. Ein Einfluss durch das Kommunikationsaufkommen während der Phase für offene Kommunikation ist durch den Einsatz des ERTEC Switch ausgeschlossen.
Die Real-Time-Kommunikation nutzt für die bevorzugte Weiterleitung der RT-Frames den VLANTag nach IEEE802.1Q. Damit können Prioritätsstufen vorgegeben werden. PROFINET RT arbeitet mit der Prioritätsstufe sechs.
Die TCP/IP und UDP/IP- und RT-Kommunikation sind mit handelsüblichen Ethernet-Controllern realisierbar.
Die Länge von RT- und IRT-Telegrammen kann zwischen 64 und 1440 Byte liegen.
Für die NRT-Kommunikation können alle IP-basierten Protokolle genutzt werden. Die Bandbreite von Fast Ethernet wird durch die Bandbreitenreservierung für Synchronisation und deterministische Kommunikation eingeschränkt.
Abbildung 2-4: Protokolle und Anwendungen für PROFINET
Abbildung 2-4 zeigt zusammenfassend die bei PROFINET verwendeten Protokolle bzw. Protokollschichten und die zugehörigen Anwendungsfälle. IT und PROFINET-Applikationen können über TCP/UDP/IP kommunizieren.
Im Zuge von Sibas PN wurde eine Betrachtung bezüglich der Anforderungen von Automatisierungskomponenten (z.B. Door Unit, Brake usw.) an das Kommunikationssystem durchgeführt.
Betrachtet wurden hierbei folgende Kriterien:
• notwendiger Übertragungszyklus
o Zyklische Datenübertragung mit einer Zykluszeit von >= 32ms
• Jitter
o Die Anforderungen bezüglich Jitter, welcher sich im Worst Case durch die Einleitung von TCP/IP- bzw. RT-Telegrammen und den Durchlaufzeiten der Switche ergibt.
• Determinismus
o Ausreichende Eigenschaften bezüglich Determinismus. Diese werden durch eine zentrale Projektierung der PROFINET RT Kommunikation im Simatc Rail Engineeringsystem und durch eine systembedingte Priorisierung der RT-Kommunikation erreicht.
HINWEIS
Erfolgt die Anbindung einer nicht PROFINET-Kommunikatonskomponente an den Fahrzeugbus, so ist eine Priorisierung der Frames mittels VLAN-Tag gemäß IEEE802.1q größer / gleich Prioritätsstufe sechs nicht zulässig.
Aufgrund dieser Betrachtung wurde PROFINET RT als Kommunikationsprotokoll für den Fahrzeugbus in Sibas PN festgelegt. PROFINET IRT wird bei Sibas PN nicht verwendet.
Die PROFINET „PN PC/104“ (Kap. 2.2.8.4) ist hierbei als bevorzugte Schnittstellenbaugruppe von Subsystemen für die PROFINET Kommunikation zu verwenden.
2.2.4 PROFINET IO Das Anwendungsmodell zur Anbindung von dezentralen Feldgeräten, das auch bei Sibas PN angewendet wird, ist „PROFINET IO“. Dabei wird die IO-Sicht von PROFIBUS DP verwendet, bei der die Nutzdaten der Feldgeräte zyklisch in die Steuerung eingelesen werden, dort verarbeitet und wieder an die Feldgeräte übertragen werden [1].
2.2.4.1 Übersicht
Das bei PROFIBUS DP bekannte Master-Slave-Verfahren ist bei PROFINET in ein Provider-Consumer-Modell übergeführt. Ein Provider erzeugt und versendet Daten, die der Consumer empfängt und verarbeitet.
Aus Kommunikationssicht sind alle Geräte am Ethernet gleichberechtigt. Über die Projektierung wird jedoch die Zuordnung der Feldgeräte zu einer zentralen Steuerung festgelegt. PROFINET IO teilt die Steuergeräte konsequent in IO-Controller und IO-Device auf. IO-Controller sind typischerweise Steuerungen (zentrale Fahrzeugsteuerung). Deren Schnittstellen sind durch die PNO nicht herstellerübergreifend standardisiert, insbesondere sind die Lade-Protokolle unterschiedlich.
Für IO-Devices ist die Schnittstelle über die PNO standardisiert (PROFINET IO und GSD). Damit können Steuerungen unterschiedlicher Hersteller mit IO-Devices kommunizieren. IO-Devices werden bei der Projektierung logisch einem IO-Controller zugeordnet.
Zusätzlich können durch PNO Profile auch Applikationsprofile für Geräte festgelegt werden.
Bei Siemens Mobility-Projekten wird eine Steuerung auf Basis SIMATIC als IO-Controller eingesetzt, alle anderen Geräte agieren als IO-Device (auch z. B. externe Switches, die keinem Gerät zugeordnet sind).
Neben IO-Controllern und IO-Devices gibt es noch Geräte mit SIMATIC Inbetriebnahme- und Diagnosefunktionen, die nur temporär an PROFINET angebunden werden. Diese Geräte sind unter dem Begriff IO-Supervisor zusammengefasst.
Die in der Abbildung genannte Diagnose mit IO-Supervisor beschränkt sich auf die Standard SIMATIC Diagnosemechanismen. Für zusätzliche, im Projekt Sibas PN definierte Diagnosemechanismen, können weitere Tools notwendig sein.
Zum Datenaustausch zwischen den Geräten wird, je nach Datenart, der Echtzeit- und der Nicht-Echtzeit-Kanal genutzt:
• Zyklische Nutzdaten über den Echtzeit-Kanal
• Ereignisgesteuerte Alarme über den Echtzeit-Kanal
• Parametrierung und Konfigurierung sowie Lesen von Diagnoseinformationen über den offenen Kanal auf Basis UDP/IP.
Abbildung 2-7: Kommunikationsbeziehungen bei PROFINET IO
Die Kommunikation zwischen den Geräten wird durch verschiedene Applikations- und Kommunikationsbeziehungen beschrieben. Beim Anlauf wird zwischen dem IO-Controller und dem IO-Device eine Applikationsbeziehung (IO-AR) mittels des sogenannten Context Managements (CM) aufgebaut. Eine Applikationsbeziehung enthält mehrere Kommunikationsbeziehungen (CRs), auf denen Konfigurations-daten, Nutzdaten und Alarme übertragen werden. Der IO-Controller überträgt über die „Record Data CR“ die Parametrier- und Konfigurationsdaten zum IO-Device. Die zyklische Übertragung der Nutzdaten erfolgt über die „IO CR“, die azyklischen Ereignisse/Events werden über die „Alarm CR“ an den IO-Controller gesendet und quittiert. Alarmtypen bei PROFINET sind Ziehen, Stecken, Diagnose, Status, Update-Alarm. Herstellerspezifische Alarme sind ebenfalls möglich. Alarme können hochprior oder niederprior sein.
Für das PROFINET IO-Device ist ein einheitliches Gerätemodell spezifiziert, welches die Modellierung von modularen und kompakten Feldgeräten ermöglicht. Es orientiert sich an den Grundzügen von PROFIBUS DP und besteht für ein modular aufgebautes Feldgerät aus Steckplätzen (Slots), zur Aufnahme von Baugruppen (Module). Auf den Baugruppen befinden sich IO-Kanäle, über welche die Prozesssignale eingelesen bzw. ausgegeben werden. Die Slots bzw. Module können nochmals in Subslots/Submodule (siehe Abbildung 2-9: Gerätemodell bei PROFINET IO, Slot – Subslot) unterteilt sein. Die Submodule enthalten die Datenobjekte in Form von Kanälen.
Jedes PROFINET IO-Device verfügt über die PROFINET-Anschaltung, den Device Access Point (DAP), dieser befindet sich immer in Slot 0. Die Minimalvariante eines PROFINET IO-Device verfügt demnach über den DAP in Slot 0 und ein Modul mit einem Submodul in Slot 1.
Kanal 0
Kanal 1
Kanal 2
Kanal x
Kanal 0
Kanal 1
Kanal 2
Kanal x
Kanal 2
Kanal x
E/A Modul
E/A Modul
E/A Modul
Interface Modul
Slot 1 Slot 2 Slot 3
E/A - Adr. n
E/A - Adr. n+1
E/A - Adr. n+2
E/A - Adr. n+x
... ... ...
Kanal 0
Kanal 1
Kanal 0
Kanal 1
Kanal 2
Kanal x
Kanal 0
Kanal 1
Kanal 2
Kanal x
Kanal 2
Kanal x
E/A Modul
E/A Modul
E/A Modul
Interface Modul
Slot Slot
E/A - Adr. n
E/A - Adr. n+1
E/A - Adr. n+2
E/A - Adr. n+x
... ... ...
Kanal 0
Kanal 1
Slot 0
Abbildung 2-8: Gerätemodell bei PROFINET IO
Subsysteme können auf dieses Modell abgebildet werden, in dem die verschiedenen Gerätefunktionen Modulen bzw. Submodulen zugeordnet werden.
Die Eigenschaften eines PROFINET IO-Devices werden vom Gerätehersteller in einer Gerätebeschreibung, der Generic Station Description (GSD) beschrieben. Die GSD wird in der Generic Station Description Markup Language (GSDML) erstellt.
Die GSDML ist in der PNO Guideline „GSDML Specification for PROFINET IO“ beschrieben:
Für den Zugriff ist ein Login bei der PNO notwendig (PNO Mitgliedschaft).
Die GSDML enthält alle notwendigen Informationen für das Feldgerät:
• Eigenschaften des IO-Device (z. B. Kommunikationsparameter)
• Steckbare Module (Anzahl und Typ)
• Konfigurationsdaten der einzelnen Module (z. B. Analogeingabemodul)
• Parameter der Module (z. B. 4...20 mA)
• Fehlertexte für die Diagnose (z. B. Drahtbruch, Kurzschluss)
Beschreibungsbasis für GSDML ist XML. Da XML ein offener, weit verbreiteter und akzeptierter Standard zur Beschreibung von Daten ist, stehen leistungsfähige Werkzeuge und abgeleitete Eigenschaften automatisch zur Verfügung, wie:
• Erstellung und Validierung durch Einsatz von Standardwerkzeugen
• Fremdsprachenintegration
• Hierarchische Strukturierung
Die Struktur der GSDML entspricht der ISO 15745, bestehend aus einem gerätespezifischen Teil mit den Konfigurationsdaten und Parametern der Module und einem kommunikationsspezifischen Teil.
Durch standardisierte Geräteschnittstellen bzw. PNO-Profile können Teile der GSD bereits vordefiniert sein, so dass „nur noch“ die gerätespezifischen Eigenschaften zu ergänzen sind.
Jedes Gerät bekommt im Rahmen von PROFINET eine weltweit eindeutige Geräteidentifikation zugewiesen. Die 32-bit Device-Ident-Number ist bei der PNO durch den Gerätehersteller zu beantragen.
Diese Nummer teilt sich auf in Herstellerkennung und Gerätekennung.
Abbildung 2-10: Beispiel für eine Device-Ident-Number
Die 16-Bit Herstellerkennung wird von der PNO vergeben. Die 16-Bit Gerätekennung kann der Hersteller im Rahmen seiner Produktentwicklung selbstständig festlegen.
Der Gerätehersteller vergibt für Module eine Geräte-weit eindeutige Modulidentifikation, die Modul_Ident_Number. Diese 32Bit-Nummer ist vom Gerätehersteller zu verwalten und in der Gerätebeschreibung zu hinterlegen.
Für Submodule vergibt der Gerätehersteller eine Modul-weit eindeutige Submodulidentifikation, die Submodul_Ident_Number. Diese 32Bit-Nummer wird vom Gerätehersteller definiert und in der Gerätebeschreibung hinterlegt.
2.2.4.4 Projektierung
Die GSD Datei eines IO-Devices wird in ein Engineeringsystem importiert und bildet dort die Grundlage für die Planung der Konfiguration eines PROFINET IO Systemes.
Im Engineeringsystem werden die IO-Devices mit einem NameOfStation (Gerätename) versehen. Das Projektierungswerkzeug gewährleistet, dass der NameOfStation innerhalb des Projektierungsbereiches eindeutig ist und deshalb als eindeutiger Schlüssel zur Identifikation im Netz verwendet werden kann.
Der NameOfStation muss in das IO-Device bei der Inbetriebnahme geladen und dort persistent gespeichert werden. Er dient zur Identifikation des IO Devices beim IO-Controller und des Einbauortes (Instanziierung von IO Devices). Zusammen mit dem NameOfStation kann auch die IP-Adresse in das IO-Device geladen werden und persistent abgespeichert werden (alternativ möglich: IP-Adresse wird beim Anlauf durch den IO-Controller aufgrund des NameOfStation vergeben).
Den einzelnen IO-Kanälen der Feldgeräte werden im IO-Controller Peripherieadressen zugeordnet. Die Peripherieeingangsadressen enthalten die empfangenen Prozesswerte. Das Anwenderprogramm wertet diese aus und verarbeitet sie. Das Anwenderprogramm bildet die Peripherieausgangswerte und gibt sie an den Prozess aus. Zusätzlich erfolgt im Engineeringsystem die Parametrierung der einzelnen Peripheriemodule bzw. Kanäle, z.B. 4...20 mA Strombereich eines Analogkanals. Nach Abschluss der Projektierung erfolgt der Download der Projektier- und Konfigurierdaten in den IO-Controller. Die IO-Devices werden im Betrieb automatisch vom IO-Controller parametriert und konfiguriert und gehen anschließend in den zyklischen Datenaustausch.
11GSD-Import und Netz-Projektierung im Engineeringtool
22 Download der Projektierungin den Controller
33 Zyklischer Datenaustausch zwischen Controller und Feldgeräten
1
2
3Ethernet
GSDProjektierung im Engineering-Tool Controller
11GSD-Import und Netz-Projektierung im Engineeringtool
22 Download der Projektierungin den Controller
33 Zyklischer Datenaustausch zwischen Controller und Feldgeräten
1
2
3Ethernet
Abbildung 2-11: Weg von der Projektierung zum Datenaustausch
2.2.4.5 Datentypen
In diesem Abschnitt werden die Grundlagen für die Spezifikation von Binärlayouts definiert. Grund-legend ist hierbei der Begriff des Oktetts (Octet), der eine Folge von 8 Bits beschreibt. Für ein Oktett gelten die folgenden Konventionen:
• Das niederwertigste Bit erhält die Bitnummer 0.
• Das höchstwertigste Bit erhält die Bitnummer 7.
Dieses Schema ist in der nachfolgenden Abbildung dargestellt:
Abbildung 2-12: Nomenklatur: Oktett (Octet)
Damit kann die Bitbelegung eines Oktetts entweder über die Definition der Bits an den Stellen 0-7 erfolgen oder über die Definition einer Dezimalzahl. Um die Bitpositionen eindeutig adressieren zu können, wird die Bitnummer als Index verwendet, wobei mit dem Index 7 das höchstwertigste Bit und mit dem Index 0 das niedrigwertigste Bit adressiert wird. Die nachfolgende Abbildung veran-schaulicht die Spezifikation einer Bitbelegung unter Verwendung der beiden Alternativen:
In den Beschreibungen wird ein Oktett gelegentlich in zwei gleich große Hälften aufgeteilt. Um die-se Aufteilung eindeutig zu machen wird in dem gesamten Dokument für die beiden Hälften eines Oktetts das folgende Modell zugrunde gelegt:
• Die Bitgruppe bestehend aus den Bits [4-7] (jeweils einschließlich) wird als unteres Nibble bezeichnet.
• Die Bitgruppe bestehend aus den Bits [0-3] (jeweils einschließlich) wird als oberes Nibble bezeichnet.
Bitnummer: 01234567
Wertigkeit: 128 1248163264O
bere
s N
ibbl
e
Unt
eres
N
ibbl
e
Abbildung 2-14: Nomenklatur: Unteres und oberes Nibble
2.2.4.5.1 Skalare Datentypen Im Sibas PN System stehen die folgenden skalaren Datentypen zur Verfügung:
Name Oktett- Anzahl Wertebereich Beschreibung
BOOL 1 -1, 0, 1
Wahrheitswert, der über eine ganze Zahl (INT8) kodiert wird: -1: nicht definiert, 0 = FALSE (falsch), 1 = TRUE (wahr).
OCTET 1 0-255
Ein Oktett ist ein Binärdatum, das nicht als druckbares Zeichen oder Zahl interpretiert wird. Hinweis: Folgen von Oktetts und CHARs werden z. B. bei der der Konvertierung in druckbare Zeichenketten unterschiedlich behandelt.
CHAR 1 0-127
Zulässig sind die Werte (jeweils einschließlich) U+0000 und U+0020 – U+007E aus dem Unicode-Zeichensatz (entspricht den ASCII-Zeichen).
FLOAT32 4 IEEE Single Precision Float (1 Bit Vorzeichen, 8 Bits Exponent, 23 Bit Mantisse).
INT8 1 -128 - +127 Ganze Zahl zwischen -128 und +127 (Zweierkomplement).
INT16 2 -32768 - +32767 Ganze Zahl zwischen -32768 und +32767 (Zweierkomplement).
INT32 4 -(231) – +231-1 Ganze Zahl zwischen -231 und +231-1 (Zweierkomplement).
INT64 8 -(263) – +263-1 Ganze Zahl zwischen -263 und +263-1 (Zweierkomplement).
UINT8 1 0-255 Natürliche Zahl zwischen 0 und 255. UINT16 2 0-65535 Natürliche Zahl zwischen 0 und 65535. UINT32 4 0-232-1 Natürliche Zahl zwischen 0 und 232-1. UINT64 8 0-264-1 Natürliche Zahl zwischen 0 und 264-1.
2.2.4.5.2 Felder von skalaren Datentypen Bei Feldern handelt es sich um eine Folge von Daten des gleichen Datentyps (homogene Folge). Die Anzahl der Daten ist à priori bekannt (feste Länge der Folge). Felder von skalaren Datentypen werden über die Array-Notation mit eckigen Klammern nach folgendem Schema notiert:
<Typname>[<Feldanzahl>]
Beispiele:
• CHAR[12]
• BYTE[8].
Die Berechnung der Länge erfolgt für Felder nach der folgenden Berechnungsvorschrift:
Feldanzahl * Oktett_Anzahl(Type).
Die Größe des entsprechenden skalaren Datentyps kann Tabelle Tabelle 1 Skalare Datentypen Felder skalarer Datentypen entnommen werden.
2.2.4.5.3 Sonderfall: Bit[] Für die Berechung der Größe von Bitfeldern gelten die folgenden Regeln:
• Die Größe von Bitfeldern wird in Oktetts angegeben (Vielfache von 8 Bits).
• Berechungsformel für ein Bitfeld der Länge n:
o Fall 1: 08mod ==n : ⎣ ⎦8/])[( nnBitLen = Oktetts
o Fall 2: 08mod ≠n : ⎣ ⎦ 18/])[( += nnBitLen Oktetts
• Die Bits werden oktettspezifisch adressiert, wobei das least signifikant Bit das Bit mit dem Index 0 darstellt.
• Ein Feldindex i wird damit wie folgt auf eine Bitposition abgebildet:
o Oktettindex = ⎣ ⎦8/i
o Bitindex = 8modi
Hinweis: ⎣x⎦ bezeichnet die Gaußklammer (auch als sogenannte Abrundungsfunktion bekannt).
Im Speicher sind die Bitfelder damit aneinandergereiht, wie es in nachfolgende Abbildung z. B. für ein Bitfeld der Länge 17 aufgezeigt ist (die nicht benutzten Bits sind durchgestrichen):
Abbildung 2-15: Beispiel: Feldindex in Bitfeldern
2.2.4.5.4 Byte-Reihenfolge, Alignment und Padding Für die Spezifikation von Binärdatenformaten gelten die folgenden Regeln:
• Besteht ein Datentyp aus mehr als einem Oktett, so wird das Big-Endian-Format einge-setzt.
• Die folgenden skalaren Datentypen können an beliebigen Speicheradressen abgelegt wer-den (Byte-Alignment):
• BIT, BOOL, OCTET, CHAR, INT8, UINT8
• Die folgenden Datentypen können ausschließlich an geraden Speicheradressen abgelegt werden:
Jedes IO-Device muss zur Identifizierung seinen NameOfStation (Gerätename) wissen. Bei der Projektierung wird jedem IO-Device ein Parameterblock zugewiesen, der über NameOfStation eindeutig identifizierbar ist. Dieser Parameterblock ist im IO-Controller verfügbar. Der Gerätename muss bei der Inbetriebnahme des Subsystems mittels des SIMATIC Managers oder durch das PrimarySetupTool (PST) erfolgen. Das PrimarySetupTool kann kostenfrei von der Siemens AG bereitgestellt werden.
Nach Einschalten der Spannungsversorgung und erfolgreichem Hochlauf der Geräte ermitteln die IO-Devices zunächst ihre Nachbarschaftsbeziehungen. Dazu teilt jedes IO-Device seinen „Nachbarn“ Parameter, wie z.B. NameOfStation oder MAC-Adresse, mit. Nachbarn sind die nächsten Geräte, die direkt über Ethernet-
ports mit dem Switch eines IO-Devices verbunden sind. Die Nachbarschafts-beziehungen werden über das LLDP-Protokoll ermittelt und zyklisch aktualisiert.
Zum Anlauf meldet sich das IO-Device beim IO-Controller über seinen Stations-namen an. Dieser überträgt durch die Protokolle des Context Managements die Parametrierdaten an das IO-Device. Falls das IO-Device seine IP-Adresse nicht remanent gespeichert hat, erhält es damit auch seine IP Adresse.
Im Gegenzug übermittelt das IO-Device seine ermittelten Nachbarschaftsbe-ziehungen an den IO-Controller.
Im Rahmen des ersten Teils des Context Management erfolgt auch die Synchronisation von PROFINET, um die Vorbedingungen für den IRT-Datenaustausch zu erfüllen. Im zweiten Teil des CM werden die Applikationsbeziehungen aufgebaut. Diese Zweiteilung ist notwendig, um PROFINET mit seinen Switches hochfahren zu können, ohne dass die Applikationen in den IO-Devices laufen müssen.
Zyklische Daten (RT- und IRT-Daten) werden in einem festen Raster vom Provider zum Consumer übertragen. Beim Consumer wird das Ausbleiben von zyklischen Daten durch eine projektierbare Zeitüberwachung festgestellt und eine entsprechende Fehlermeldung an die Applikation ausgelöst.
Das Einrichten und der Abbau der IO CR (z. B. Verbindungsbeziehung zwischen IO-Controller und IO-Device) erfolgt durch ein übergeordnetes Protokoll. IO-Controller und IO-Device können je nach Richtung der Kommunikationsbeziehung Provider oder Consumer sein. Ein Provider erhält keine explizite Rückmeldung vom Consumer, ob die Daten angekommen sind. Für den Rückkanal zwischen den zwei Geräten ist eine weitere Verbindung mit getauschten Rollen notwendig.
CM CMEinrichten der
Kommunikationsbeziehung
Zyklische Nutzdaten in Echtzeit RT-
TreiberRT-
Treiber
IO-Controller IO-Device
Nutz-Daten
Nutz-Daten
CM CMEinrichten der
Kommunikationsbeziehung
Zyklische Nutzdaten in Echtzeit RT-
TreiberRT-
Treiber
IO-Controller IO-Device
Nutz-Daten
Nutz-Daten
CM: Context Management
Abbildung 2-16: Zyklische Nutzdatenkommunikation
Die zyklischen Protokolle unterstützten keine Segmentierung und Reassemblierung der Datensätze. Das bedeutet, dass die Gesamtlänge eines Datenpaketes inklusive aller Protokollheader, die Länge eines Ethernet-Paketes nicht überschreiten darf. Den einzelnen Speicherblöcken im Paket sind bestimmte Funktionalitäten zugeordnet, die für jede IO CR fest bestehen bleiben. Die Anwendungsschnittelle beim Provider und beim Consumer arbeitet gepuffert („buffered“). Werden Daten schneller in die Schnittstelle eingetragen als sie abgeholt werden, werden vorherige Daten überschrieben. Jedem Provider wird ein Aktualisierungsintervall zugeordnet, das nicht unterschritten werden darf. Jeder Consumer überwacht seinen Provider durch Prüfung auf regelmäßigen Empfang.
Für jedes Submodul werden die zyklischen Daten mit Informationen versehen, die Auskunft über die Gültigkeit der Daten geben (IOPS, Producer Status der IO-Daten und IOCS, Consumer Status der IO-Daten).
2.2.4.8 Azyklische Datenübertragung
Azyklische Daten (NRT-Daten) werden zu bestimmten Zeitpunkten ereignisgesteuert vom Provider zum Consumer übertragen. Die Anwendungsschnittellen beim Provider und beim Consumer arbeiten als „queued“-Schnittstellen. Werden Daten schneller in die Schnittstelle eingetragen als sie abgeholt werden, kann es zum Überlauf (mit entsprechender Fehlerreaktion) und damit zum Datenverlust kommen.
Als azyklischer Dienst wird der bei Profinet-IO spezifizierte Record-Daten lesen/schreiben Dienst verwendet.
Die in diesem Dokument definierten Datensätze sind grundsätzlich bidirektional zu sehen, d.h. sie können sowohl gelesen wie auch geschrieben werden.
Anwendungsfälle für die azyklische Kommunikation in Sibas PN sind:
• Parameter als Anlaufparameter die keinen Änderungen unterliegen wie z.B. NTP-Serveradressen
• Parameterdaten von Subsystemen die Änderungen unterliegen (z.B. Türschließzeiten)
• Betriebsdaten, wie z.B. Schaltspiele, Betriebsstundenzähler etc.
• Diagnosedaten
Bezüglich azyklischer Datenkommunikation werden zwei Anwendungsfälle in Sibas PN unterschieden, die „Anlaufparameter“ und „normale Record-Datensätze“
2.2.4.8.1 Anlaufparametersätze Ein Anlaufparametersatz hat folgende Eigenschaften:
• Der Aufbau des Parametersatzes wird in der GSD beschrieben
• Die Projektierung erfolgt im Simatic Manager unter HW-Konfig (Sibas PN Projektierungssystem)
• Eine explizite Vergabe der Datensatznummer muss nicht vorgenommen werden, sondern erfolgt automatisch durch die Beschreibung in der GSD
• Der Datensatz wird bei jedem Hochlauf, bzw. nach Wiederanlauf des SP CS (PROFINET I/O Controller) an das Subsystem übermittelt.
• Der Wert eines Anlaufparameters wird im Betrieb nicht geändert.
• Anlaufparameter werden auf das Subsystem geschrieben, d.h. der Transfer erfolgt vom SP CS zum Subsystem.
2.2.4.8.2 „normaler Record-Datensatz“ Der Anstoß, wann ein Datensatz gelesen oder geschrieben wird, erfolgt nie vom Subsystem, sondern immer von der Fahrzeugsteuerung (z.B. SP CS). Ein „normaler Record-Datensatz“ hat folgende Eigenschaften:
• Der Aufbau muss dem Subsystem und der auslesenden/schreibenden Stelle bekannt sein
• Der Aufbau wird nicht in der GSD beschrieben
• Die Projektierung kann nicht in Simatic Manager im HW-Konfig erfolgen(Sibas PN Projektierungssystem)
• Es muss sichergestellt werden, dass der „gewollte“ Datensatz aktiv ist, d.h.
o Wird der Datensatz im Subsystem gespeichert, kann nach jedem Hochlauf des Systems geprüft werden, ob die Parameter noch stimmen.
o Wird der Datensatz nicht im Subsystem gespeichert muss dieser nach jedem Hochlauf erneut zugestellt werden.
• Es ist eine Datensatznummer zu definieren
• Der Wert eines Anlaufparameters kann im Betrieb geändert werden.
• Normale Record-Datensätze können auf das Subsystem geschrieben und vom Subsystem gelesen werden.
• Um sicherzustellen, dass der Datensatz im Subsystem den gleichen Aufbau wie im SP CS hat wird eine Versionsnummer in jedem Datensatz ausgetauscht.
In den Nutzdaten jeden Records wird eine Versionsnummer geschrieben. Die Versionsnummer ist vom Datentyp INT16 (Integer16) und beginnt bei der ersten Version mit 1. Jegliche Änderung der Nutzdatenschnittstelle zieht auch eine Änderung der Version nach sich, d.h bei jeder Änderung wird die Versionsnummer um 1 inkrementiert.
Byte 0 Version INT // Versionskennung Byte 2 (Nutzdadten) Xyz // Beginn der eigentlichen Nutzdaten
Anmerkung: Auf eine Versionsangabe in den Anlaufparametern wird verzichtet, da diese Spezifikation in der jeweiligen GSD beschrieben wird und hierdurch schon eine Schnittstellenbeschreibung in einer definierten Version bereit gestellt wird.
Die Behandlung von Versionsfehlern eines „normaler Record-Datensatz“ ist wie folgt:
1. Lesende Richtung (Subsystem zum SP CS)
Die Versionskennung ist im SP CS zu prüfen. Bei unterschiedlichen Versionsnummern wird vom SP CS ein Diagnoseeintrag generiert und der gelesene Wert zu verwerfen.
2. Schreibende Richtung (SP CS zum Subsystem)
Die Versionskennung ist im Subsystem zu prüfen. Bei Unterschiedlichen Versionsnummern wird vom Subsystem ein Diagnoseeintrag generiert und der Schreibauftrag des SP CS wird negativ beantwortet.
2.2.5 Netzstrukturen PROFINET Netzwerke können in Linien-, Baum-, Ringstrukturen oder in Kombinationen davon aufgebaut werden. Ringstrukturen bieten den Vorteil, disjunkte Pfade zwischen den Geräten zu ermöglichen (Medienredundanz) und damit Single Point of Failure zu beherrschen.
Die Switchfunktion der ERTEC-basierten Anschaltungsbaugruppen kann genutzt werden, um Ringstrukturen aufzubauen. Die Vorteile sind:
• Kostengünstige Lösung, da keine zusätzlichen externe Switches notwendig sind.
• Einfachfehler (der Ausfall eines Gerätes oder ein Leitungsbruch) können toleriert werden.
Abbildung 2-17: Einfacher Ring
Bei Ringstrukturen kommt das Redundanzprotokoll MRP zum Einsatz. Zum korrekten Betrieb von MRP wird im Ring ein Switch Sibas PN SP SW als Redundanzmaster benötigt.
Die PROFINET Netzwerkstruktur wird anlagenspezifisch festgelegt. Mit der Festlegung der Struktur wird definiert, ob die jeweiligen Subsysteme im Ring oder durch eine Stichleitung außerhalb des Ringes betrieben werden. Der Anschluss erfolgt hierbei an einem freien Port eines Switches, der im Ring betrieben wird.
2.2.6 Switch Die für Fast Ethernet notwendigen Switches werden bei Sibas PN, so weit möglich, in die Steuergeräte integriert und bilden gleichzeitig die Anbindung des Steuergerätes an PROFINET. Über diese Schnittstelle kann auch die Service-/Debug-Schnittstelle realisiert werden.
Kernstück ist der Ethernet Controller ERTEC. Ein Switch weist folgende Eigenschaften auf:
• 2/4-Port-Switch
• Alle Ports wahlweise 10 oder 100 Mbit (für PROFINET und Sibas PN wird nur 100 Mbit vollduplex verwendet)
• Routing auf Ebene 2
• Routing des IRT-Protokolls
• Eigendiagnose nach SNMP (simple network monitoring protocol)
Der Einsatz von externen Switches wird aus Kostengründen vermieden, kann aber zur Anbindung einzelner Steuergeräte oder für spezielle Funktionen notwendig sein.
Switches werden, wie IO-Devices auch, einem IO-Controller zugeordnet. Von diesem erhalten sie die notwendigen Parametrierinformationen.
2.2.7 Externe Spannungsversorgung Um das PROFINET Netzwerk voll betriebsfähig zu erhalten, können die in die Kommunikationsanschaltung integrierten Switches auch dann mit Spannung versorgt werden, wenn das angebundene Steuergerät abgeschaltet wird (z.B. betriebliches Abschalten oder Abschaltung im Fehlerfall). D.h. die in den Geräten integrierten Switches arbeiten auch bei Ausfall bzw. Abschaltung des Steuergerätes weiter. Die Kommunikationswege werden hierdurch nicht beeinflusst.
Zu diesem Zweck können die PROFINET-Switches separat mit Spannung versorgt werden.
Spannungsversorgung Switches
Kommunikations-anschaltung
Spannungsversorgung Steuergerät
Ste
uerg
erät
Kommunikations-anschaltung
Spannungsversorgung Steuergerät
Ste
uerg
erät
A
B B
C C
Abbildung 2-18: Prinzip der externen Speisung der Switches (Kommunikationsanschaltung)
Abbildung 2-18 zeigt das Prinzip der externen Spannungsversorgung (potentialgetrennt) von Steuergeräten mit in die Kommunikationsanschaltung integriertem Switch.
Die externe Spannungsversorgung muss für alle Subsysteme realisiert werden, deren integrierter Switch im Kommunikationsweg anderer Subsysteme liegt (z.B. Switch in einer Ringstruktur) und die betrieblich einzeln abgeschaltet werden können.
Die Notwendigkeit einer externen Spannungsversorgung ist für die einzelnen Subsysteme durch SIEMENS Mobility in Zusammenarbeit mit dem Subsystemhersteller festzulegen.
2.2.8 PROFINET-Anschaltungen für Subsysteme Für die Anschaltung von Subsystemen als IO Devices an PROFINET gibt es folgende Möglichkeiten:
• PROFINET IRT-Kommunikation (synchronisierte Kommunikation) oder RT-Kommunikation mit Kommunikations-ASIC.
• PROFINET RT-Kommunikation (unsysnchronisierte Kommunikation) mit einem Standard-Ethernet-Controller und PROFINET IO Firmware.
Für die synchronisierte Kommunikation (IRT, isochronous realtime) ist die Verwendung des Enhanced Realtime Ethernet Controller ASIC (ERTEC) Voraussetzung. Der ERTEC wird auch benötigt, wenn die PROFINET-Switchfunktion integriert und das Gerät am PROFINET-Ring betrieben werden soll.
Hinweis: Um Steuerungsrechner von Subsystemen (z. B. Tür, Klimaanlage, Fahrgastinformation, ...) in verschiedene Netzwerktopologien (Ring-, Linien-, Stern oder Baumtopologie) ohne zusätzliche Switch-Geräte integrieren zu können, ist es notwendig, einen integrierten PROFINET Switch im Steuerungsrechner des Subsystems zu implementieren. Bei Verwendung der SIEMENS PROFINET PC/104 (siehe Kapitel 2.2.8.4) oder einer ERTEC Integration (siehe Kapitel 2.2.8.2) wird dies bereits durch deren Hardware unterstützt. Für Sibas PN steht mit der PROFINET PC/104 Baugruppe eine hoch integrierte Interfacebaugruppe zur Verfügung. Sie implementiert neben PROFINET noch zahlreiche Sibas PN Systemdienste und erleichtert so die Integration des Subsystems in Sibas PN. Die PROFINET PC/104 Baugruppe von SIEMENS ist von folgendem Hersteller verfügbar: Siemens AG I IS MS EDM http://www.siemens-edm.de/pn_pc104.0.html Mail: [email protected] Frauenauracher Str. 98 91056 Erlangen
Der ERTEC ASIC ist von folgenden Herstellern verfügbar:
SIEMENS: Development Kit für PN IO für Ethernet Prozessor und für ERTEC 200/400
Neben dem ERTEC ASIC stehen für die Kommunikationsanbindung an PROFINET Kommunikationsbaugruppen und Development-Kits von verschiedenen Herstellern zur Verfügung. Eine Übersicht gibt die PNO-Webseite:
2.2.8.1 ERTEC ASIC Als PROFINET Switch und zur Anbindung von Geräten an PROFINET steht der Enhanced Realtime Ethernet Controller ASIC (ERTEC) der Siemens AG bzw. NEC zu Verfügung. Der ASIC ist in den Ausprägungen ERTEC 200 (2 Port) und ERTEC 400 (4 Port) erhältlich. Informationen zu den SIEMENS Produkten können unter
http://www.automation.siemens.com/microsite/ertec/html_76/ertec_e.swf abgerufen werden.
Der Industrial Ethernet ASIC ERTEC ist ein hochperformanter 2-Port-Switch (ERTEC200) bzw. 4-Port-Switch (ERTEC400) mit integriertem 32-Bit Mikroprozessor, der für den industriellen Einsatz entwickelt wurde. Mit ihm können PROFINET-Anschaltungen und Switches realisiert werden, die Offenheit zur IT-Welt und Echtzeitfähigkeit bieten. Ein einfacher platzsparender Anschluss von Geräten an Switched Ethernet ist durch die Implementierung eines hochintegrierten Switch möglich. Die hohe Verarbeitungsleistung des integrierten high-performance ARM 946 RISC ermöglicht eine optimale Kommunikationseinbindung mit zukunftsweisenden Internetapplikationen. Mit dem integrierten PCI-Interface können weitere Komponenten einfach an PROFINET angebunden werden.
Dank des integrierten ARM 946-Prozessors kann der ERTEC als System-on-Chip-Implementierung für Einfachgeräte verwendet werden. Da die prozessorbelastende zyklische Datenübertragung für PROFINET IO mit Real-Time und Isochronem Real-Time komplett durch die ERTEC-Hardware abgewickelt wird, verbleiben genügend Prozessorressourcen, um die Applikationen einfacher Feldgeräte mit zu bearbeiten. Externe Prozessoren können entfallen. On-Chip-Peripherie ermöglicht den direkten Anschluss von IO-Signalen, seriellen Schnittstellen und Timern.
Der ASIC ERTEC steht RoHS-konform zur Verfügung. Die bleihaltigen Varianten werden ab 1. Oktober 2007 nicht mehr geliefert.
Als Peripherie benötigt der ERTEC typisch 4 MB ROM- und 32 MB Flash-Speicher.
Die Anbindung des ERTEC an die CPU des Subsystemes kann – je nach ERTEC Typ – durch die Local Bus Unit (LBU) oder eine PCI-Schnittstelle erfolgen.
Nachfolgende Tabelle zeigt die wesentlichen Unterschiede von ERTEC 200 und ERTEC 400:
Eigenschaft ERTEC 200 ERTEC 400
Anzahl Ports 2-Port-Switch 4-Port-Switch
Ethernet-PHY Integriert Extern
Host-Interface Local Bus Unit (LBU) PCI und Local Bus Unit (LBU)
Für die Ankopplung der Ethernet-Controller an die Physik des Kommunikationsnetzwerkes werden so genannte PHYs benötigt, Bausteine für den Übergang von der internen in die externe Welt.
Beim ERTEC 200 sind diese bereits integriert. Bei Verwendung der empfohlenen PHYs für den ERTEC 400 und beim ERTEC 200 werden die Funktionen Auto-Negotiation und Auto-Crossing unterstützt.
2.2.8.2 Development Kit ERTEC
Mit Hilfe der PROFINET IO Development Kits ERTEC 400 und ERTEC 200 können PROFINET Hardware und Software-Applikationen unter Verwendung der ERTEC ASICs entwickelt und getestet werden.
Mit dem entsprechenden Development Kit wird die PROFINET-Technologie Geräteherstellern und Anwendern zugänglich gemacht.
Das Development Kit ERTEC enthält alle Komponenten für die Entwicklung eines PROFINET IO-Devices mit Real-Time (RT) und Isochronem Real-Time (IRT):
• Evaluation Board mit ERTEC 200 oder 400 als PROFINET IO Device
• PROFINET IO Stack für PROFINET IO Device (Bereitstellung als Object-Code für VxWorks verfügbar und als Source-Code geplant)
• CP 1616 (PCI-Karte) für PROFINET IO Controller
• NCM PC Softwarepaket zur Projektierung des CP 1616 als Engineeringsystem für PN IO
Für Nicht-ERTEC Ethernetanschaltungen steht das Development Kit für PROFINET IO auf Basis von Standard-Ethernetcontrollern (mit Anwenderbeispiel für NetARM-Prozessoren) zur Verfügung. Hiermit können Kommunikations-anschaltungen ohne Switchfunktion für den PROFINET IO RT-Protokollstack realisiert werden.
Das Develoment Kit besteht aus:
• Firmware-Stack im Sourcecode für PROFINET IO, beispielhaft angepasst an den NetARM-Prozessor Net+50 von NetSilicon. Dieser FW-Stack kann natürlich auch auf jeden anderen Prozessor der Firma NetSilicon oder den eines anderen Herstellers portiert werden.
• Anwenderbeschreibung des PN IO Stacks
• Umfassende Dokumentation und Beispielsprogramme für ein I/O Device
• Umfassenden Dokumentation und Beispielsprogramme für eine CPU317-2 PN/DP, die als Testpartner (IO Controller) eingesetzt werden kann.
Das Developmentkit ist für 32 Bit Systeme ausgelegt. Die empfohlenen HW Voraussetzungen für den Einsatz sind:
• 32 Bit Prozessor, 32 Bit Betriebssystem
• >= 4MB RAM, 2MB Flash
2.2.8.4 PROFINET PC/104
Die PROFINET PC/104-Baugruppe, nachfolgend PN PC/104 genannt, ist eine Schnittstellenbaugruppe, mit der elektronische Steuerungen an PROFINET angebunden werden können. Die PN PC/104 Baugruppe fungiert hierbei als PROFINET IO-Device. Die Funktion eines PROFINET IO-Controllers kann hiermit nicht übernommen werden.
Dem Anwender der PN PC/104-Baugruppe wird für seine Entwicklung eine API-Software als Sourcecode zur Verfügung gestellt, um die Baugruppe als Schnittstelle für seine Steuerung als PROFINET IO-Device betreiben zu können. Das bietet eine einfache Möglichkeit, die PROFINET Baugruppen in beliebige Betriebssystemumgebungen mit Standard PC/104 Interface zu integrieren.
Den hochperformanten Datenaustausch über PROFINET erledigt die Hardware der PN PC/104 selbstständig. Die Hostanbindung erfolgt über ein DPRAM mittels Anwender-Progammierschnittstelle. Damit ist ein schnellstmöglicher Zugriff auf die Daten gewährleistet.
Neben der PROFINET-Anbindung gewährleistet die PN PC/104-Baugruppe auch eine komfortable Anbindung an die Sibas PN-Systemdienste Download, Identifikation, Uhrzeitsynchronisation und Werkstattdiagnose.
Hierbei bietet der ERTEC 200 als hochperformanter Ethernet-Controller mit integriertem Real-Time Switch und 32-Bit-Mikoprozessor die optimale Lösung zur Anbindung von elektronischen Steuerungen an PROFINET, bzw. Ethernet.
• Software im Source Code als Anwender-Progammierschnittstelle für die Hostanbindung
• Kostengünstige Migration vom MVB nach PROFINET (wenn MVB PC/104 eingesetzt wurde)
• Keine Lizenzkosten für Subsystemhersteller
• Geringe Hostbelastung, da PN-Stack auf der PN PC/104 abläuft
• Einheitliche Subsystemschnittstelle zur Leittechnik durch einheitliche Diensteschnittstelle
• Durch den integrierten Switch (ERTEC ASIC) ist eine Anbindung von Subsystemen in einer Linien- und Ringstruktur mit nur einem Typ der PN PC/104 Baugruppe möglich.
• Verbergen des Profinet-Protokolls und der Sibas PN spezifischen Dienste.
• Die Kommunikation zwischen der PN PC/104-Baugruppe und dem Host-System erfolgt über einen DPRAM. Zur einfachen Nutzung durch den Anwender werden die Orginalprotokolle abstrahiert, d.h. sind mit einer übersichtlichen Schnittstelle für den Anwender nutzbar.
• Unterstützung von Webapplikationen auf Basis von Java-Applets
• HTTP-Kommunikation über den integrierten Web-Server
• Transparente Kommunikation über die PN PC/104 mittels TCP-IP zum Host (Subsystem) möglich
• Zertifizierung nach SIL 1 EN50128 / EN 50129. Dies ermöglicht die problemlose Anbindung von nicht zertifizierten Subsystemen an Sibas PN (siehe auch Kapitel 2.3.4).
2.2.8.5 Bestellinformationen / Technischer Support Folgende Komponenten können bei SIEMENS I IA bezogen werden:
• Development Kit DK ERTEC 400 PN IO Bestellnummer: 6GK1953-0CA00
• Development Kit ERTEC 200 Bestellnummer: 6GK1953-0BA00
• Development Kit für PN IO für Ethernet Prozessor (NS9360) Bestellnummer: 6ES7 195-3BC00-0YA0
Detailierte Informationen zu den PROFINET Technologiekomponenten stehen unter: http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=de&siteid=csius&aktprim=0&extranet=standard&viewreg=WW&objid=18880585&treeLang=de
Die Integrationszentren in Europa und USA bieten kostenfreien Telefonsupport für Entwickler und Implementierer. Auftragsentwicklungen für Soft- und Hardware sowie Unterstützung vor Ort gehören zum umfangreichen Leistungsangebot der Integrationszentren. Ebenso werden eintägige Crashseminare für Entwickler und Implementierer angeboten. Dieser Dienst richtet sich primär an PROFINET Anwender aus der Industrieautomatisierung. Durch Einsatz eines der genannten Development-Kits und der Gerätebeschreibung mittels GSD stehen Schnittstellen für die durch die PNO definierten Standardinformationen zur Verfügung. Diese Schnittstellen sind entsprechend ihrer Spezifikation durch den Subsystemhersteller mit Informationen zu versorgen.
2.2.9 Einbindung Standard-Ethernet Subsysteme, die bereits mit einer Ethernet-Anschaltung (d. h. nicht mit einer PROFINET-Anschaltung) ausgestattet sind und die nicht dem PROFINET IO Modell entsprechen, können über einen Switch an PROFINET angebunden werden. Diese Anbindungsart ist im Projekt Sibas PN nur in Ausnahmefällen zulässig (siehe Kapitel 2.2.8). Die Kommunikation erfolgt ausschließlich über Non-Realtime-Daten (TCP/IP). Das PROFINET IO Gerätemodell und die PROFINET IO Protokolle können hiermit nicht genutzt werden.
2.3.1 Funktionsschnittstelle Die Schnittstelle zwischen Fahrzeugsteuerung und Subsystem (funktionale Schnittstelle eines Subsystemes) wird separat festgelegt und nicht in diesem Dokument beschrieben. Die Festlegungen sind zwischen SIEMENS Mobility und dem Subsystemhersteller zu treffen. Über die Funktionsschnittstelle werden u. a. spezifische Festlegungen zu folgenden Funktionen getroffen:
• Zyklische Daten
• Azyklische Daten
• Betriebszustand Fahrzeug und Subsystem
• Funktionale Strukturierung der Subsystemschnittstelle
• Ersatzwertverhalten
• Bedienen und Beobachten (z.B. Anzeige am HMI)
• Funktions- und Komponentendiagnose
2.3.2 Geräteverhalten Das Subsystem darf in keinem Betriebszustand undefiniertes Verhalten zeigen oder undefinierte Daten an Ausgängen bereitstellen. Wenn keine aktuellen Daten zur Verfügung stehen, sind definierte Ersatzwerte bereitzustellen bzw. die Daten als ungültig zu kennzeichnen. Nach Einschalten der Spannungsversorgung ist ein definierter Anlauf durchzuführen. Durch das Betriebsverhalten eines Steuergerätes darf die Kommunikation am PROFINET durch den in die Kommunikationsanschaltung integrierten Switch nicht beeinträchtigt werden (siehe auch Kapitel 2.3.4).
2.3.3 Überwachungszeiten Beim IO-Device sind für verschiedene Mechanismen Werte für Überwachungszeiten einzustellen. Die Einstellung erfolgt bei der Anlagenprojektierung. Die Parameter werden beim Anlauf vom IO-Controller in das IO-Device geladen bzw. sind im IO-Device einzustellen.
2.3.4 Funktionale Sicherheit Der Subsystemlieferant trägt die Verantwortung für die von den Funktionen seines Subsystems geforderte Sicherheitsintegrität auch bei Einbindung in Sibas PN / PROFINET gemäß dieser vorliegenden Spezifikation. Diese Forderungen gelten für alle Betriebsmodi des Fahrzeugs, wie Fahrgast-betrieb, Wartung, etc. Sie gelten also i.b. auch z.B. für Anwendungsfälle wie Parametrierung, Durchführung von Prüfläufen durch oder unter Beteiligung des Subsystems sowie für SW-Updates des Subsystems.
Falls diese Sicherheitsforderungen mit anderen Forderungen, im besonderen. der Forderung nach Nutzung von Funktionen von Sibas PN, nicht vereinbar seien sollten, gelten vorrangig die Sicherheitsforderungen. Weitere Festlegungen sind in diesem Fall zwischen SIEMENS Mobility und dem Subsystemhersteller gemeinsam zu treffen.
Sibas PN bietet Funktionen mit SIL 1.Der Subsystemlieferant kann diese Funktionen (z.B. Kommunikation, Lokale Dienste) nach eigenem Ermessen benutzen, wenn er damit die von den Funktionen seines Subsystems geforderte Sicherheitsintegrität erreicht.
2.4 Leitungen und Stecker Gerätesteckverbindungen für PROFINET werden als M12 Steckverbindung D-codiert ausgeführt. Als Kommunikationsleitung sind bahnfeste Leitungen einzusetzen. Spezifikationen und Herstellerhinweise sind über I MO RS PT EN TC C zu beziehen.
2.5 Lokale Dienste
2.5.1 Definition Lokale Dienste sind auf einzelnen Geräten realisiert, wie z.B. ein Download-Dienst für Software und Parameter in einer Steuerung oder in einem Subsystem. Diese lokalen Dienste übernehmen die Funktion (z.B. Software-Download) für das jeweilige Gerät als lokal realisierter Server auf dem Gerät. Die Funktion des Servers kann prinzipiell von allen Applikationen genutzt werden, die bzgl. Kommunikationsverbindung und Sicherheitsumgebung Zugang zu dem lokalen Server haben. Solche Clients sind beispielsweise: Applikationen zum Download und zur Parametrierung eines Subsystems, die das Gerät über den Fahrzeugbus direkt erreichen können.
Lokale Dienste laufen auf den Kommunikationsteilnehmern ab. Die gezeigten Schnittstellen sind für Teilnehmer am Fahrzeugbus zugänglich.
UhrzeitsnchronisationUhrzeitSync
Abbildung 2-19: Ansicht für einheitliche (lokale) Dienste.
Zunächst werden die folgenden lokalen Dienste realisiert:
• Download, • Identifikation, • Uhrzeitsynchronisation, • Diagnosedienst für die Instandhaltung (Werkstattdiagnose)
Weitere Dienste können in späteren Ausbaustufen folgen.
Die Schnittstelle „ISubsystemStatus“ definiert eine einheitliche Statusschnittstelle mit dem jedes Subsystem seinen Funktionsstatus mitteilt, wie z.B. „ok“, „gestört“, „Test läuft“, „Testanforderung“ im Service-Modus, Betrieb etc. Die Definition dieser Schnittstelle wird durch die Spezifikation der Funktionsschnittstelle der Subsysteme genauer angegeben.
Der lokale Downloaddienst realisiert das Laden von Software und Parametern auf Geräten am Fahrzeugbus. Der Ladevorgang erfolgt dabei über den Fahrzeugbus. Damit sind auch an schwer zugänglichen Stellen verbaute Geräte effizient ladbar1.
Der lokale Downloaddienst ist obligatorisch für alle Busteilnehmer, die ladbare Software und Parameter unterstützen.
Der Laden der Firmware erfolgt über den Fahrzeugbus PROFINET mit FTP. Dazu muss auf dem Gerät, das den Download unterstützt, lokal ein FTP Server mit Password-geschütztem Zugang vorhanden sein. Durch diesen FTP-Server kann dann die Firmware geladen werden. Nach dem Ladevorgang erfolgt eine Gültigkeitsüberprüfung der geladenen Firmware und die Daten bei erfolgreicher Überprüfung in den aktiven Bereich schreibt. Nach einem Reset (oder einem Aus/Anschalten) wird der neue SW/Parameterstand dann vom Gerät verwendet.
Der „aktive Bereich“ bezeichnet dabei den Speicherbereich, in dem das zu startende Image beim Booten des Gerätes liegt.
Der Systemdienst Sibas PN Download dient dazu, alle updatefähigen Softwareobjekte eines Subsystems über die PROINET - Kommunikationsschnittstelle zu aktualisieren.
PROFINET
SIBAS PN KomponenteLokaler Downloaddienst
Zentraler Downloaddienst
Abbildung 2-20: lokaler- und zentraler Downloaddienst
Die Abbildung 2-20: lokaler- und zentraler Downloaddienst zeigt die prinzipiellen Mechanismen für den Softwaredownload von Sibas PN-Komponenten. Die Mechanismen gelten gleichermaßen für PROFINET-Devices als auch alle anderen Systemkomponenten von Sibas PN. Der Downloaddienst basiert auf einer Kommunikationsverbindung zu dem Gerät über Ethernet und TCP/IP. Von dem Downloaddienst gibt es zwei Ausprägungen:
1 IT-begrifflich gesehen ist der „Download“ eigentlich ein Upload auf den in dem Gerät befindlichen FTP-Server. Da sich in der Kommunikation innerhalb von SIEMENS Mobility aber die Bezeichnung „Download in Steuerung/Subsystem/...“ etabliert hat, wird die Bezeichnung „Download“ hier auch weiter verwendet.
• Lokaler Downloaddienst: Der Download wird von einem qualifizierten Anwender vorgenommen, welcher über Ethernet mit der Sibas PN-Komponente verbunden ist. Er startet den Download für eine Komponente lokal von seinem Rechner aus. Die Verfügbarkeit von anderen Sibas PN-Komponenten ist dafür nicht notwendig. Die Komponente kann in diesem Fall sogar ausgebaut sein und keine weitere Verbindung zu anderen Systemkomponenten haben.
• Zentraler Downloaddienst: Der Download wird von einem qualifizierten Anwender am Sibas PN System Server gestartet; dieser ist über PROFINET mit allen anderen Systemkomponenten verbunden. Beim zentralen Downloaddienst wird typischerweise das ganze Fahrzeug auf einen aktuellen, konsistenten Softwarestand gebracht.
Der Sibas PN Downloaddienst arbeitet immer nach dem Push-Prinzip, d.h. alle Dateien werden vom Downloadrechner zur Sibas PN Komponente übertragen. Ein Gerät kann dabei über mehrere Downloadobjekte (Downloadable Object) verfügen.
2.5.2.1 Downloadable Object
2.5.2.1.1 Struktur Die Übertragung eines Downloadobjekts vom Downloadrechner zur Sibas PN Komponente erfolgt dateibasiert mit Hilfe eines Downloadable Objects (DO). Die Übertragung des Downloadobjekts zu einer Komponente löst dort außer einer Speicherung noch keine Aktivitäten aus. Der Dateiname muss innerhalb einer Komponente eindeutig und über die Lebensdauer des Produkts konstant sein. Er ist nach folgender Nomenklatur zu bilden: [DO Type]_[DO Version].do
DO Type und DO Version sind in Kapitel 2.5.2.1.2 beschrieben. Bei der DO Version sind Punkte (z.B. zwischen Major und Minor) durch Bindestriche zu ersetzen. Der Aufbau eines DOs ist bei Sibas PN standardisiert.
Jedes Downloadobjekt (DO) besteht aus einer Datei, diese wiederum besteht immer aus zwei Bestandteilen:
• Header, dieser ist im System Sibas PN eindeutig definiert.
• Container, dieser enthält das Objekt, welches Bestandteil des Downloads ist. Der Container wird vom Downloaddienst nur transportiert und weder analysiert noch modifiziert. Der Downloaddienst transportiert den Container als binäre Daten.
2.5.2.1.2 Header Die Abbildung 2-22: Header Sibas PN Downloadobjekt zeigt den Aufbau des Headers eines DOs. Dabei gilt folgende Zahlendarstellung:
• Binär: Der Wert ist als Binärzahl in der Datei enthalten. Für das binäre Zeichen 0 enthält die Datei den Wert 0.
• ASCII: Der Wert ist in der ASCII-Codierung in der Datei enthalten. Für das ASCII-Zeichen 0 enthält die Datei den Wert 0x30.
• U08 ist ein binäre Zahl mit der Länge 1 Byte.
• U16 ist eine binäre Zahl mit der Länge 2 Bytes und Big Endian Darstellung, d.h. das höherwertige Byte ist in der Datei an der vorderen Stelle abgespeichert.
• U32 ist eine binäre Zahl mit der Länge 4 Bytes und Big Endian Darstellung, d.h. das höherwertige Byte ist in der Datei an der vorderen Stelle abgespeichert.
Der Header besteht aus den nachfolgenden Strukturelementen. Diese sind teilweise binär, teilweise ASCII codiert.
• Magic Number: 4 Bytes in binärer Codierung mit dem konstanten Wert 0x08075352.
• DO Header Version: Version des Headers. Darstellung als 1 Byte in binärer Codierung, aktuell mit dem Wert 0x0 belegt.
• Header Len: Länge des gesamten Headers (roter Balken). Darstellung als 2 Bytes in binärer Codierung.
• DO Len: Länge des gesamten Downloadobjekts (DO) inklusive Header (blauer Balken). Darstellung als 4 Bytes in binärer Codierung.
• DO Version: Version des im Container enthaltenen Objekts. Das Strukturelement enthält wiederum zwei Elemente:
o VLen: Länge des nachfolgenden Versionstexts (VText). Darstellung als 2 Bytes in binärer Codierung.
o VText: Versionstext in ASCII-Codierung. Der Text enthält keine Nullterminierung. VText enthält als nur die Anzahl der Zeichen des Versionstexts. Das Versionsformat entspricht der Nomenklatur major.minor[.revision[.build]], wobei revision und build optional sind. Die Versionsbestandteile major, minor und revision nehmen einen Wertebereich zwischen 0 und 255 und build von 0-65535 an.
• DO Type: Systemweite Kennung des im Container enthaltenen Objekts. Der Typ muss im Sibas PN-System eindeutig sein. Hierfür wird von der Siemens AG für jede Komponente ein eindeutiger Präfix definiert und hat folgenden Aufbau: [Herstellername]_[Gerätetyp]_.
Durch Anhängen von Zeichen an den Präfix erzeugt der Komponenten-hersteller in eigener Verantwortung seine unterschiedlichen Download-objekte. Die von ihm definierten Downloadobjekte müssen der Siemens AG mitgeteilt werden, damit sie vom zentralen Downloaddienst verarbeitet werden können. Das Strukturelement enthält wiederum zwei Elemente:
o TLen: Länge des nachfolgenden Typtexts (TText). Darstellung als 2 Bytes in binärer Codierung.
o TText: Typdefinition in ASCII-Codierung. Der Text enthält keine Nullterminierung. TText enthält als nur die Anzahl der Zeichen der Typdefinition. Die Typtextbestandteile können Buchstaben und Zahlen enthalten. Für den Vergleich von Typtexten wird Groß-/Kleinschreibung nicht berücksichtigt.
• DO Checksum: MD5-Prüfsumme über den Container (ohne Header). Die Darstellung erfolgt immer als 32-stelliger ASCII-Text.
Abbildung 2-23: Beispiel Header Sibas PN Downloadobjekt
Die Abbildung 2-23: Beispiel Header Sibas PN Downloadobjekt zeigt beispielhaft den Aufbau eines DOs. Der dunkel markierte Bereich ist dabei der Header des Downloadobjekts.
2.5.2.1.3 Container Wie schon in Kapitel 2.5.2.1.1 ausgeführt, ist der Container für den Downloaddienst transparent und wird durch ihn nur binär transportiert. Die Struktur des Containers ist nur dem Komponentenhersteller bekannt. Er muss den Container korrekt generieren und sicherstellen, dass er von seiner Komponente gelesen und interpretiert werden kann.
Der Container wird auch verwendet, um mehrere Objekte in einem Downloadobjekt zu übertragen. Hierfür wird als Objekt meistens eine Archivdatei im Format tar oder zip verwendet. Das Packen und Entpacken erfolgt jedoch unter Verantwortung des Komponentenherstellers.
2.5.2.1.3.1 DO-Tool
Zum einfachen Erzeugen eines Downloadobjekts stellt die Siemens AG dem Gerätehersteller ein kommandozeilenbasiertes Programm, das DO-Tool, zur Verfügung. Es generiert aus den Kommandozeilenparametern den Header und stellt ihn dem Container in einer Datei voran. Die korrekte Erzeugung des Downloadobjekts obliegt dem Subsystemhersteller.
2.5.2.1.3.2 Control File
Wie in Kapitel 2.5.2.1.1 beschrieben, löst das Übertragen eines Downloadobjekts noch keine Aktivitäten auf der Sibas PN-Komponente aus. Die Bearbeitung des Downloadobjekts erfolgt erst mit der erfolgreichen Übertragung des Control Files. Der Dateiname des Control Files lautet immer control.dfs.
Das Control File enthält jetzt die Operationen, welche mit dem Downloadobjekt durchgeführt werden. Die Datei enthält die Kommandos als ASCII-Zeichen. Leerzeilen und Zeichen nach der #eof-Markierung werden ignoriert. Kommando und Parameter sind durch ein Leerzeichen getrennt.
Kommando Parameter Beschreibung :update Filename Dateiname des Download-
objekts. Es können mehrere DOs mit einer Kommandodatei verarbeitet werden.
Führt einen Softwarereset aus. Sec ist ein optionaler Parameter und gibt die Zeit zwischen dem Schreiben des Status-Files und der Ausführung des Reset in Sekunden an. Somit hat der Anwender die Möglichkeit noch vor dem Reset den Status der Gültigkeitsüberprüfung zu erhalten.
:special (optional)
args (optional)
Spezielles Kommando für Subsysteme. Hier können beliebige Informationen subsystemspezifisch mitgegeben werden. Diese speziellen Kommandos sind in den Subsystem-spezifikationen zu beschreiben. Die Argumente dürfen nur einzeilig sein.
Die Tabelle 2 enthält das Format und Tabelle 3 ein Beispiel eines Control Files. Dort erfolgt in einem Control File das Update von zwei Downloadobjekten (sxrt_software.do und sxrt_parameter.do). Es ist zulässig, mit einem Control File kein Update sondern nur einen Reset auszuführen; das Control File enthält dann auch keine update-Befehle.
Der Sibas PN Systemdienst Update unterscheidet nicht zwischen den in den Komponenten eventuell implementierten sequenziellen Algorithmen zur Realisierung eines Updates (z.B. Flash löschen, Flash programmieren, neues Programm gültig erklären). Die konkrete Realisierung des Updates obliegt der Verantwortung der Komponente. Diese muss nur sicherstellen, dass nach einem erfolgreichen Update beim nächsten Systemstart (entweder über das :reset-Kommando oder einem manuellen Reset) das System mit den neuen Objekten startet.
Enthält das Control File mehrere Updateobjekte, so können diese nacheinander aktualisiert werden. Dabei kann es vorkommen, dass das Update des ersten Updateobjekts erfolgreich ist und das Update des zweiten Updateobjekts fehlschlägt. In diesem Fall kann die Komponente nach Durchlauf des Control Files
einen inkonsistenten Zustand haben (siehe Kapitel 2.5.2.3.3). Ein Resetbefehl am Ende des Control Files wird unabhängig vom Erfolg des vorherigen Downloads ausgeführt.
Nach der Bearbeitung des Control Files muss dieses, unabhängig ob die Bearbeitung erfolgreich war oder nicht, zusammen durch die Komponente gelöscht werden. Das Downloadobjekt muss spätestens mit dem nachfolgenden Systemstart gelöscht werden.
2.5.2.2 Status File
Das Statusfile enthält das Ergebnis der Ausführung eines Control Files (siehe Kapitel 2.5.2.1.3.2). Es muss immer nach der Ausführung eines Control Files in das lokale Dateisystem (ftp root Verzeichnis) der Komponente geschrieben werden. Das Status File ist nur von der Ausführung des Control Files bis zum nächsten Reset gültig. Nach einem Neustart einer Komponente darf das Status File nicht mehr im lokalen Dateisystem vorhanden sein; bei Flash-Filesystemen muss es nach dem Hochlauf aktiv gelöscht werden.
Das Status File hat einen Aufbau (siehe Tabelle 4) identisch des Control Files aus „Tabelle 3 Beispiel Control File“ mit dem Zusatz, dass jede aktive Zeile des Control Files mit dem Ergebnis der Ausführung ergänzt wird.
(optional) Aktion erfolgreich. Optional kann noch eine Information dazu geschrieben werden. Texte müssen in englischer Sprache sein. Die Beschreibung darf nur einzeilig sein.
=fail description (optional)
Aktion gescheitert. Optional kann noch eine Information dazu geschrieben werden. Texte müssen in englischer Sprache sein. Die Beschreibung darf nur einzeilig sein.
#eof Ende Markierung des Status Files
Tabelle 5 Format Status File
Der Status =ok bei update kennzeichnet, dass das Downloadobjekt gespeichert ist und nach dem Reset zur Ausführung kommt. Ein vollständig erfolgreiches Update ist dadurch gekennzeichnet, dass alle Downloadobjekte den Status =ok aufweisen.
2.5.2.3 Downloadverfahren
2.5.2.3.1 Dateitransfer Der Dateitransfer vom Initiator des Downloads zur Komponente erfolgt über FTP, wobei der Initiator der FTP-Client und die Komponente der FTP-Server ist. Der Zugriff auf die Komponente über FTP erfolgt mit anonymous login, d.h. ohne Login und Passwort. Die Komponente muss sicherstellen, dass ein Dateitransfer im normalen Betrieb zu keiner Beeinträchtigung des Betriebs führt.
Die Standardimplementierung von FTP sieht keine Verriegelung von gegenseitigem Dateizugriff vor, d.h. sowohl die Komponente als auch FTP (der Initiator eines Downloads) können gleichzeitig auf eine Datei zugreifen. Aus diesem Grund muss vor der Ausführung oder Auswertung einer Datei immer die Vollständigkeit einer Datei überprüft werden. Die Dateien verfügen dazu über entsprechende Endemarkierungen (#eof)
Alle im Rahmen des Downloads von und zur Komponente transferierten Dateien befinden sich im root-Verzeichnis des FTP (Downloadverzeichnis), dieses bildet sich auf ein Laufwerk oder einen Verzeichnis¬baum im Dateisystem der Komponente ab. Das Downloadverzeichnis kann sich dabei in einem RAM- oder Flash-Filesystem befinden.
Der erste Schritt beim Download ist der Transfer der Downloadobjekte (siehe Kapitel 2.5.2.1). Mit dem Transfer von Downloadobjekten wird noch keine Aktion ausgelöst.
Das Schreiben des Control Files (siehe Kapitel 2.5.2.1.3.2) löst dann den Downloadvorgang aus. Dazu überprüft jede Komponente zyklisch das Vorhandensein eines Control Files. Der Zeitraum vom Schreiben bis zum Erkennen der Datei durch die Komponente sollte kleiner 5 Sekunden sein. Nach erfolgter Ausführung des Commmand Files wird es von der Komponente selbsttätig gelöscht.
Anschließend schreibt die Komponente das Status File (Kapitel 2.5.2.2). Es bleibt bis zum nächsten Neustart der Komponente verfügbar, danach muss es gelöscht sein. Enthält das Control File einen sofortigen Resetbefehl, so erfolgt beim Resetparameter 0 Sekunden unmittelbar nach einem erfolgreichen Update ein Reset. In diesem Fall kann kein Status File geschrieben werden, der zentrale Downloaddienst muss mit diese Situation beherrschen.
Soll das Status File sicher gelesen werden, so sollte das erste Control File keinen Resetbefehl enthalten. In diesem Fall wird das aktuelle Status File nicht durch den nachfolgenden Systemneustart überschrieben. Anschließend kann dann durch ein Control File nur mit dem Resetbefehl ein Neustart ausgelöst werden.
Das Command File darf nicht ausgeführt werden, wenn sich die Fahrzeugsteuerung SPCS im Zustand RUN befindet; diese Information wird vom PROFINET-Device-Stack bereitgestellt. Ein Downloadversuch in diesem Fahrzeugzustand wird mit einem negativen Ergebnis im Status File beendet.
Das Durchführen des Downloads ist unabhängig von der einer PROFINET-Verbindung. Voraussetzung für den Download ist nur eine vorhandene (und von der PROFINET-Konfiguration unabhängige) IP-Adresse.
2.5.2.3.2 Speicherort Wie schon in den vorherigen Kapiteln beschrieben kann sich das ftp root-Verzeichnis in einem RAM oder Flash-Dateisystem befinden. Das Verhalten wenn welche Dateien zu löschen sind, ist in den Kapiteln 2.5.2.1.3.2 und 2.5.2.2 beschrieben.
2.5.2.3.3 Inkonsistente Zustände Beim Update einer Komponente können inkonsistente Zustände auftreten wenn
• Bei einem SW-Download fehlerhafte Downloadobjekte übertragen werden oder
• Bei einem SW Download zueinander inkonsistente Downloadobjekte übertragen werden.
Der Komponentenlieferant muss sicherstellen, dass solche inkonsistenten Zustände erkannt bzw. beherrscht werden und die Komponente in der Lage ist, einen neuen Download entgegenzunehmen. Sie kann dafür entweder vor der Ausführung des Control Files eine Konsistenzprüfung vornehmen oder bei der Ausführung sicherstellen, dass nicht konsistente Konfigurationen erkannt und beherrscht werden.
Die Sibas PN Komponenten stellen in den meisten Fällen komplexe Gerät mit mehreren Baugruppen und Mikroprozessoren dar. Um ein fahrzeugübergreifendes Konfigurationsmanagement und automatisierten Download effektiv realisieren zu können, ist es notwendig, zur Laufzeit maschinell die aktuelle Hard- und Softwarekonfiguration einer Komponente ermitteln zu können.
Der Sibas PN Identifikationsdienst ermöglicht es, über das Kommunikationsnetzwerk des Fahrzeugs (PROFINET) jederzeit die aktuelle Konfiguration einer Komponente auslesen zu können. Aktuell bezieht sich das dabei auf die aktuell vorhandene Hardware und die aktuell ausgeführte Software.
2.5.3.2 Erzeugung
Wegen der Verwendung beim automatisierten Konfigurationsmanagement (z.B. Download) ist unbedingt sicherzustellen, dass die gelieferten Informationen mit der aktuellen Konfiguration übereinstimmen. Für die Software wird bevorzugt, dass die Softwareversion der Komponenten direkt in den Komponenten gespeichert ist und zur Laufzeit von diesen bereitgestellt werden. Die Hardwarekonfiguration sollte in einem Konfigurationsspeicher abgelegt sein und zur Laufzeit dort ausgelesen werden.
Die Konfigurationsinformation wird nach dem Hochlauf als Identdatei ins lokale Dateisystem (ftp root – Verzeichnis) geschrieben. Es ist dabei prinzipiell unerheblich, ob sich das lokale Dateisystem im RAM oder Flash befindet. Bei Verwendung eines Flash-Dateisystems ist sicherzustellen, dass alte Kopien zu einem möglichst frühen Zeitpunkt (direkt nach Erzeugen des Dateisystems) gelöscht werden.
Erzeugt eine Komponente eine Identdatei (sollte der Regelfall sein), so hat diese den Namen description.xml. Schreibt eine Komponente mehrere Identdateien, so haben diese die Namen description1.xml, description2.xml etc., in diesem Fall existiert keine Datei description.xml.
Die Identdatei muss spätestens zu dem Zeitpunkt geschrieben sein, bei dem die Komponente bereit zur Verbindungsaufnahme mit dem PROFINET ist; dies wird in der Regel durch das Kommando pn_open an den PROFINET-Stack signalisiert. Hierbei ist zu beachten, dass es unerheblich ist, ob eine PROFINET-Verbindung aufgebaut werden kann oder nicht, maßgeblich ist der Zeitpunkt ab dem dies aus Sicht der Komponente möglicht wäre. Die Identdatei muss erzeugt und kann gelesen werden auch wenn keine PROFINET-Verbindung besteht. Voraussetzung für den Download ist nur eine vorhandene (und von der PROFINET-Konfiguration unabhängige) IP-Adresse.
Bei komplexen Systemen können zwei Sonderfälle auftreten, welche wie folgt behandelt werden:
• Beim Hochlauf ist die Existenz einer Komponente, jedoch nicht ihre Konfiguration (Versionen) bekannt. In diesem Fall wird die Komponente in der Identdatei aufgeführt, ihre Konfiguration jedoch als unknown bezeichnet. Sobald die Versionen der Komponenten beim Hochlauf oder im Betrieb
bekannt werden, wird die Identdatei mit der erweiterten Konfiguration aktualisiert.
• Beim Hochlauf ist die Existenz von Komponenten noch nicht bekannt. Diese Komponenten können natürlich noch nicht in die Identdatei geschrieben. Werden diese Komponenten beim Hochlauf oder im Betrieb bekannt, so wird die Identdatei mit der erweiterten Konfiguration aktualisiert.
Bei diesen Sonderfällen werden während des Hochlaufs oder im Betrieb mehrere Stände der XML-Datei erzeugt. Nach dem Erzeugen eines Standes der XML-Datei (Datei wurde vom erzeugenden System wieder geschlossen), muss diese der Dateistruktur aus Kapitel , entsprechen.
Fällt ein Teil einer Komponente während des Betriebs aus, welcher in der Identdatei aufgeführt ist (z.B. ein Modul einer dezentralen Peripherie), muss keine neue Identdatei erzeugt werden.
Die Identdatei muss alle Objekte eines Gerätes enthalten,
• bei welchen Software im Betrieb nachgeladen werden kann und
• bei welchen eine Abhängigkeit zur nachladbaren Software besteht (z.B. Hardwareversion einer Baugruppe da nachladbare Software u.U. nicht auf allen Hardwareversionen läuft).
Software- oder Hardwareobjekte, welche für einen Download nicht relevant sind, sollte ebenfalls zur Ermittlung der aktuellen Fahrzeugkonfiguration in der Identdatei enthalten sein soweit diese Informationen verfügbar sind.
2.5.3.3 Dateitransfer
Auf die Identdatei kann jederzeit über FTP zugegriffen werden. Die Standardimplementierung von FTP sieht keine Verriegelung von gegenseitigem Dateizugriff vor, d.h. sowohl die Komponente als auch FTP können gleichzeitig auf eine Datei zugreifen. Aus diesem Grund muss vor der Auswertung einer Datei immer die Vollständigkeit einer Datei überprüft werden. Die Dateien verfügen dazu über entsprechende Endemarkierungen (</ISO15745Profile>).
2.5.3.4.1 Aufbau Bei der Identifikationsdatei ist zu beachten, dass lediglich das GSD-Format gewählt wurde um es mit einem GSD-Checker prüfen zu können. Die Inhalte der Identifikationsdatei haben keinerlei Bezug zu deren Bedeutung in einer Profinet-GSD-Datei. Die Aufgabe der Identifikationsdatei ist es, dem auslesenden Gerät die Hardware- und Softwarestruktur des mitzuteilen, d.h. welche Hardware- und Softwarekomponenten befinden sich in dem Gerät. Die Profinet-Struktur eines Gerätes, d.h. die gesteckten Slots und Subslots sind dabei irrelevant.
Die vorliegende Struktur stellt beispielhaft die Identdatei für ein Subsystem Bremse dar. Es besteht aus dem „PC104 Board“ und einer subsystemspezifischen Baugruppe „Knorr BSG102“. Beide Baugruppen sind eigenständige Komponenten, das Gerät verfügt über keine Subkomponenten. Die grauen Textpassagen sind konstante Texte und fest vorgegeben. Können einzelne Parameter nicht angegeben werden, so wird immer ein Leerstring "" gedruckt werden.
Die Identdatei unterstützt eine einfache Hierarchiestruktur:
• Komponenten, diese sind in der Regel identisch mit der Hardwarebaugruppe (es könnte aber auch eine Hauptsoftware sein). Komponenten können (müssen aber nicht) Subkomponenten enthalten. Komponenten können gleichzeitig eine Hardware und eine Software enthalten. Bei einer Komponente erhöht sich immer die ModuleIdentNumber. Die Unterscheidung, ob eine Komponente Software und/oder Hardware enthält, hängt von der Belegung der Parameter HardwareRelease und SoftwareRelease ab.
• Subkomponenten, diese enthalten in der Regel eine Software. Subkomponenten sind immer Teil einer Komponente. Sie werden in der Identdatei unmittelbar nach der Komponente übertragen. Die Zuordnung zur Komponente erfolgt, indem der Wert der ModuleIdentNumber identisch dem der Komponente ist. Die Subkomponenten werden verwendet, wenn eine Hardware mehrere Softwareobjekte enthält.
2.5.3.4.2 ProductFamily Die variable Beschreibung beginnt mit dem Schlüsselwort ProductFamily. Sie ist in jeder Identifikationsdatei genau einmal vorhanden.
Der Eintrag ProductFamily beschreibt den Gerätenamen. Die Kennung muss den Inhalt des Eintrags ProductFamily aus der GSD-Datei des Gerätes enthalten.
2.5.3.4.3 DeviceAccessPointList Die DeviceAccessPointList enthält genau ein DeviceAccessPointItem, dieses beschreibt immer die Komponente, welche das Dateisystem für die Identifikationsdatei bereitstellt. Sie ist pro Identifikationsdatei genau einmal vorhanden. Die Parameter haben die nachfolgende Bedeutung:
• ID: Die Kennung muss den Namen (DO Type, siehe Kapitel 2.5.2.1.2) des zugehörigen Downloadobjektes als Prefix enthalten. Weitere notwendige Unterscheidungen sind an dem Prefix mit dem Trennzeichen „_“ anzuhängen.
• PhysicalSlots: Anzahl von Komponenten, d.h. unabhängige Hardwarebaugruppen, aus welchen das Gerät besteht und in der Identdatei aufgeführt sind. Nicht in der Identdatei aufgeführte Komponenten werden nicht berücksichtigt.
• ModuleIdentNumber: Nummer der Komponente, beginnend mit 0. Subkomponenten haben immer die gleiche ModuleIdentNumber wie ihre Komponenten.
Die weitere Beschreibung der Komponente befindet sich beim Parameter ModuleInfo in Kapitel 2.5.3.4.4
2.5.3.4.4 ModuleList Die ModuleList enthält jetzt alle weiteren Komponenten oder Subkomponenten des Gerätes. Sie besteht aus keinem, einem oder mehreren ModuleItems.
Die Parameter haben die nachfolgende Bedeutung:
• ID: Die Kennung muss den Namen (DO Type, siehe Kapitel 2.5.2.1.2) des zugehörigen Downloadobjektes als Prefix enthalten. Weitere notwendige Unterscheidungen sind an dem Prefix mit dem Trennzeichen „_“ anzuhängen.
• ModuleIdentNumber: Nummer der Komponente, beginnend mit 1. Jede Komponente muss sich durch ihre ModuleIdentNumber unterscheiden, Subkomponenten haben immer die gleiche ModuleIdentNumber wie ihre Komponenten. Die ModuleIdentNumber muss bei einem modularen Gerät mit der topologischen Reihenfolge übereinstimmen, hierfür gilt von links nach rechts oder von oben nach unten.
Die weitere Beschreibung der Komponente befindet sich beim Parameter ModuleInfo in Kapitel 2.5.3.4.5.
2.5.3.4.5 ModuleInfo Der Eintrag ModuleInfo beschreibt jetzt die Komponente genauer und enthält die nachfolgenden Einträge:
• Name: Textbeschreibung der Komponente, kann vom Hersteller frei gewählt werden. Der Text darf nur aus Ziffern, Buchstaben sowie dem Sonderzeichen _ bestehen.
• InfoText: Enthält die Seriennummer der Komponente im herstellerspezifischen Format. Die Seriennummer darf nur aus Ziffern, Buchstaben sowie dem Sonderzeichen _ bestehen. Kann keine Seriennummer angegeben werden, so ist dies mit der Siemens AG vorab abzuklären.
• VendorName: Name des Herstellers, muss mit dem Herstellernamen des Downloadobjekts (siehe DO Type Kapitel 2.5.2.1.2) übereinstimmen.
• OrderNumber: Enthält die Bestellnummer oder Artikelnummer, kann vom Hersteller frei vorgegeben werden. Sie muss mit der Bestell- oder Artikelnummer übereinstimmen, unter welcher die Komponente vom Hersteller bestellt werden kann.
• HardwareRelease: Hardwareversion der Komponente, das Format kann vom Hersteller frei vorgegeben werden; es darf lediglich nicht die Zeichen [ und ] enthalten. Die Hardwareversion muss den entwicklungstechnischen Erzeugnisstand enthalten. Fertigungstechnische Erzeugnisstände müssen sich unterscheiden, wenn sich die Funktion ändert oder Rückwirkung auf die auf der Hardware lauffähigen Software hat. Wird zusätzlich noch informativ der fertigungstechnische Erzeugnisstand angegeben, so muss dieser durch die Zeichen [ und ] geklammert werden.
• SoftwareRelease: Softwareversion der Komponente, kann vom Hersteller frei vorgegeben werden. Sie sollte sich am Format Va.b.c.d orientieren, wobei a die Majorversion, b die Minorversion, c die Bugfixversion und d die eindeutige Build-Nummer ist. A,b unc c sollten sich im Bereich 0-255 bewegen, der Wert d im Bereich 0-65535. Andere Formate für die Softwareversion sind vorher mit der Siemens AG abzustimmen.
2.5.3.4.6 ExternalTextList Die ExternalTextList wird nur benötigt, wenn die Parameter ihren Wert mit TextId anstatt mit Value zugewiesen bekommen. Dies ist bei bisherigen Softwareversionen der Fall, deshalb ist dieses Verfahren hier nur informativ aufgenommen. In neuen Softwareversionen sollte die Zuweisung von Werte zu Parametern ausschließlich über Value erfolgen. Bei einer Zuweisung über TextId muss dieser ein Text
zugewiesen werden, dieser sollte jedoch identisch mit der eigentlichen TextId sein. Die untere XML-Sequenz muss dann zwischen den Zeilen </ModuleList> und </ApplicationProcess> in die Identdatei eingefügt werden.
Die Uhrzeitsynchronisation sorgt für einen mit dem Ablauf der Zeit fortschreitenden und möglichst stetigen Abgleich der verschiedenen lokalen Uhren in den verschiedenen per Kommunikation erreichbaren Geräten zugweit. Die Uhrzeitsynchronisation ist für alle Geräte obligatorisch, die Uhrzeiten verwenden, z.B. auf Uhrzeiten/Differenzen reagieren, Zeitstempel bilden oder auswerten.
Für die Uhrzeitsynchronisation werden als Protokoll NTP (RFC 1305) und SNTP (RFC 2030) eingesetzt werden. Als Quelle für die Uhrzeit steht am Fahrzugbus PROFINET ein NTP-Server zur Verfügung.
Folgende Strukturelemente für die Zeitdarstellung sind in Sibas PN definiert:
• UTC-Zeit in einer Darstellung mit der kleinsten Auflösung 1 ms.
• Qualität der Zeit in der Granularität: „Noch nie synchronisiert“ (0x00), „Synchronisation verloren“ (0x01), „Synchronisiert“ (0x02) und „Unbekannt“ (0x03).
• Offset UTC zu lokaler Zeit in der Auflösung Minuten wegen der Zeitzone.
• Offset UTC zu lokaler Zeit in der Auflösung Minuten wegen Sommer-/Winterzeit.
Die Zeitsynchronisation der Komponenten erfolgt bei Sibas PN über das bestehende PROFINET / Ethernet Netzwerk und SNTP bzw. NTP. Sibas PN stellt einen NTP Uhrzeitserver mit der erforderlichen Genauigkeit und Funksynchronisation bereit. Bietet das Betriebssystem auf den Komponenten einen NTP Client, so ist dieser zu verwenden. Die Verwendung von SNTP ist erlaubt, wenn das Betriebssystem keinen NTP Client zur Verfügung stellt.
2.5.4.1 Synchronisation
Die NTP / SNTP Zeitsynchronisation erfolgt mittels UTC-Zeit. Die Komponente muss über ihren Client zyklisch mindestens 1 mal pro Minute die Zeit mit dem Server synchronisieren. Hierfür benötigt die Komponente die IP-Adresse von NTP-Servern. Sibas PN sieht die Verwendung von insgesamt 4 NTP-Servern (Nummer 1 – 4) vor. Die Behandlung der IP-Adressen hängt von dem verwendeten Verfahren NTP oder SNTP ab.
• SNTP: Die Nummerierung der NTP-Server erfolgt anhand ihrer Genauigkeit, NTP1 ist der genaueste und NTP4 der ungenaueste NTP-Server im System. Die Komponente muss immer versuchen, sich mit dem genauesten NTP-Server zu synchronisieren. Fäll die Synchronisierung mit dem aktuellen NTP-Server aus, so muss sie auf den nächsten ungenaueren NTP-Server zurückfallen.
• NTP: Der NTP-Client auf der Komponente hält gleichzeitig die Verbindung zu allen NTP-Servern und wählt selbstständig den besten NTP-Server aus.
Die Komponente muss es ermöglichen, die 4 NTP-Adressen im Rahmen der Projektierung vorzugeben. Bei Komponenten mit der Eigenschaft PROFINET-Device ist eine Vorgabe der IP-Adressen der NTP-Server über die Anlaufparametrierung von Profinet des Device Access Points (Slot 0) zu
bevorzugen; Ausnahmen sind zu begründen. Die zu verwendende Notation ist „a.b.c.d“ mit a-d dezimal von 0-255. Nicht verwendete NTP-Serveradressen werden mit 0.0.0.0 angegeben.
Die Information über die Zeitqualität steht aufgrund des Synchronisationsstatus mit dem NTP-Server auf den Komponenten ebenfalls zur Verfügung. Die Zeitqualität sollte mindestens 1 mal pro Minute ermittelt werden.
Der Offset UTC zu lokaler Zeit wird durch den Profinet-Datensatz Nr. 11 für Slot 0 (Device Access Point DAP) wie folgt übertragen, es gilt Big Endian-Darstellung. Ein übertragener Wert muss auf der Komponente lokal gespeichert und verwendet werden bis eine Aktualisierung erfolgt. Der Datensatz kann von der Steuerung gelesen werden.
Byte Element Funktion 0-1 Version Versionskennung (aktuell 1) 2-3
TimeZone
Offset lokale Winterzeit zu UTC aufgrund der Zeitzone in Minute (+/-720 Minuten)
4-5
SummerTime
Aktueller Offset lokale Zeit (z.B. MESZ) zu lokaler Winterzeit (MEZ) in Minuten (+/-127 Minuten).
Tabelle 6 Datensatz TimeZone und SummerTime
typedef struct SPN_Record_TimeZone { u16 version; ///< Version of record structure u16 timeZone; ///< Time zone offset in min u16 summerTime; ///< Summer time offset in min } SPN_Record_TimeZone_s;
Abbildung 2-24: Struktur Datensatz TimeZone und SummerTime
Solange der Offset lokaler Zeit zu UTC über den Datensatz noch nicht übertragen wurde, geht die Komponente von einem Offset 0 Minuten aus.
Bei Sibas PN wird die lokale Zeit direkt und ohne gleitenden Übergang gestellt.
Die Abbildung 2-27: Ablauf Authentifizierung zeigt rot den Verlauf der Netzwerkzeit. Zum Zeitpunkt Sync loss verliert die Komponente die Synchronisation und läuft mit ihrer lokalen Zeit (blauer Verlauf) weiter. Aufgrund des Synchronisationsverlusts ändert sich jedoch auch der Zeitstatus auf „Synchronisation verloren“. Nach der Widerherstellung der Synchronisation wird die lokale Zeit (schwarzer Verlauf) wieder auf die Netzwerkzeit gestellt und läuft dann synchron weiter.
Das Problem von doppelten Zeitstempeln (grüne Linie) beim Zurückstellen der Uhr wird dadurch gelöst, dass die beiden Zeitstempel unterschiedliche Zeitqualität (QoT) haben und Zeitstempel mit QoT = „Synchronisation verloren“ ohnehin nicht mit synchronisierten Zeitstempeln verglichen werden können. Bei dem häufig verwendeten Verfahren einer langsamen Angleichung der lokalen Zeit an die Netzwerkzeit (blauer Verlauf gestrichelt) besteht der Nachteil, dass die lokale Uhr lange unsynchronisiert bleibt und auch der genaue Zeitpunkt der erfolgten Angleichung nicht bestimmt werden kann.
Die Abbildung 2-26 zeigt den Algorithmus zum Bilden der Zeitqualität. Nach dem Systemstart muss jede Komponente mit einer definierten Uhrzeit starten, welche vor dem 1.1.2000 steht; normalerweise die Startzeit des verwendeten Betriebssystems. Der Status der Uhrzeit ist beim Systemstart „Noch nie synchronisiert“.
Die Komponente muss die Uhrzeit nach dem Systemstart mit ihrem lokalen Takt weiterführen bis eine Synchronisation mit dem NTP-Server (NTP sync) mit dem Status „Synchronisiert“ erfolgt. Nach einer Synchronisierung wird immer diese Zeit weitergeführt, bei einem Verlust (NTP loss) der Synchronisation (Status „Synchronisation verloren“) wird die Uhrzeit mit dem lokalen Takt weitergeführt bis wieder eine erfolgreiche Synchronisation erfolgt.
Bei der Wiederkehr der Synchronisation (NTP sync) wird wieder der Zustand „Synchronisiert“ angenommen. Die Ereignisse NTP sync und NTP loss signalisieren nur das Zustandekommen und den Verlust mit dem NTP-Server und macht keine Aussage über die Qualität der Zeit des NTP-Servers (Stratum).
Der Status 0x00 (Unbekannt) wird von der Komponente nur dann verwendet, wenn er den aktuellen Synchronisationsstatus von NTP nicht ermitteln kann.
2.5.4.2 Format
Für das System Sibas PN sind systemweit zwei Zeitformate definiert. Diese Formate müssen an den Schnittstellen zwischen Systemkomponenten verwendet werden. Innerhalb eines Gerätes oder auch zum Export an den Benutzer sind individuelle Zeitformate zulässig (z.B. lokale Zeit).
2.5.4.2.1 I64 – Format Das I64-Zeitformat ist ein vorzeichenbehafteter 64-Bit Integer, bei Binärübertragung codiert im big-endian 2-er-Komplement und zählt die Millisekunden seit "1970-01-01 00:00:00 UTC"(in kurzen Worten: UTC in Millisekunden). Aufgrund des großen Wertebereichs von 63 Bits (plus Vorzeichen) ist mit keinem Überlauf während der Betriebsdauer von Sibas PN zu rechnen.
2.5.4.2.2 SIMATIC – Format Zur Darstellung der Zeit in Format, wo die einzelnen Zeitbestandteile (Jahr, Monat, Tag etc) einzeln dargestellt sind, wird das SIMATIC Format Date_Time verwendet. Es wird bei Sibas PN als Format DateTimeS7 bezeichnet. Sie enthält die einzelnen Bestandteile von Datum und Zeit in einer BCD-Codierung. Das SIMATIC Format ermöglicht es, eine Zeit im unteren Bereich mit einer Auflösung von 1 ms darzustellen.
• 1990-1-1-0:0:0.0 bis 2089-12-31-23:59:59.999
Die folgende Tabelle enthält ein Beispiel für Donnerstag, den 5. August 2004, 8:12 Uhr und 5.259 Sekunden. Es sind die Inhalte der Bytes dargestellt, die die Informationen von Datum und Uhrzeit enthalten.
2.5.4.2.3 Export-Format (ASCII) Die Ausgabe von Zeitinformationen in menschenlesbaren Dateien (z.B. CSV-Datei mit Diagnoseeinträgen) erfolgt im nachfolgenden Format:
YYYY-MM-DD-HH:NN:SS.LLL mit
• YYYY: Jahresangabe, immer 4-stellig.
• MM: Monatsangabe 1-12, 1- oder 2-stellig.
• DD: Tagesangabe 1-31, 1- oder 2-stellig.
• HH. Stunden 0-23, 1- oder 2-stellig.
• NN: Minuten 0-59, 2-stellig.
• SS: Sekunden 0-59, 1- oder 2-stellig.
• LLL: Millisekunden 0-999, 1-, 2- oder 3-stellig.
Beispiele sind 1990-1-1-0:00:00.0 oder 2089-12-31-23:59:59.999.
Die Ausgabe vom Offset UTC auf lokale Winterzeit aufgrund der Zeitzone erfolgt immer im nachfolgenden Format:
2.5.5 Web-Server für gerätespezifische Diagnose und Service
Teilnehmer am Fahrzeugbus müssen einen lokalen Web-Server zur Verfügung stellen, z.B. zur Erleichterung des gerätespezifischen Service, Unterstützung einer Diagnose zur Instandhaltung, Monitoring und Parametrierung.
Das Vorhandensein eines solchen Web-Servers ersetzt nicht die vorher als obligatorisch beschriebenen Dienste.
Durch den Einsatz der Siemens PN PC/104 (siehe Kap. 2.2.8.4) ist eine Unterstützung der notwendigen Funktionen für den Unterlieferanten weitgehend gegeben.
So stellt die PN PC/104 z.B. einen Webserver mit Java-Applet und die Möglichkeit einer Kommunikaton zwischen Webapplikation und Subsystemhost über TCP/IP zur Verfügung. Alternativ können außer Java-Applets auch andere Web-Objekte geladen werden, welche auf dem Browser dann zur Anzeige gebracht, bzw. ausgeführt werden.
2.5.5.1 Webinhalte
Folgende Anzeige-, Eingabemöglichkeiten und Funktionen müsse durch die Web-Applikation des Subsystems (z.B. Door Unit, Brake usw.) unterstützt werden:
• Auslesen und Auswerten aller Diagnosespeicher des Subsystems (siehe Kap. 2.6) incl. Betriebs- und Protokollspeicher
• Anzeige der anstehenden Werkstattdiagnosemeldung und Prozesswerte (z.B. Ein- / Ausgange, Spannungen, Strome, Temperaturen, Geschwindigkeit, etc.).
• Eingabe von instandhaltungs- oder servicerelevanten Parameter
• Anstoßen von Prüfläufen
• Gezieltes Zurücksetzen von anstehenden Werkstattdiagnosemeldungen
• Anzeige der Informationen aus dem Identifikationsdienst (siehe Kap. 2.5.3)
• Sprachumschaltung der Webseiten (Unterstützung der vom Fahrzeugprojekt definierten Sprachen, jedoch min. deutsch und englisch)
• Ablage und Bereitstellung von Dateiinhalten (z.B. Gerätedokumentation…)
• Die Java-Applets sollten signiert werden, um die Vertrauenswürdigkeit der Quelle (Datenintegrität) sicherzustellen.
2.5.5.2 Anforderungen bzgl. funktionaler Sicherheit an die Webapplikation
Generell trägt der Subsystemlieferant die Verantwortung für die von den Funktionen seines Subsystems geforderte Sicherheitsintegrität (siehe Kap. 2.3.4), auch bei der Verwendung von Webapplikationen.
Der Zugriff ohne Authentifizierung des Users auf die Informationen / Funktionen (siehe Kap. 2.5.5.1), die der HTTP-Server des Subsystems liefert ist nicht zulässig.
Aus diesem Grund ist eine Basic-HTTP-Authentication, welches einen Benutzernamen und ein Passwort für die Authentifizierung verwendet auf der Kommunikationsanschaltung des Subsystems zu realisieren. Der Ablauf (siehe Abb. Abbildung 2-27: Ablauf Authentifizierung) der Authentifizierung muss mit einem normalen HTTP-Request durch den HTTP-Client (Web Browser auf z.B. HMI oder Service PC) beginnen. Ist der Zugriff auf das angefragte Verzeichnis durch HTTP-Authentication beschränkt, sendet der HTTP-Server (Subsystem) den HTTP-Response mit einem WWW-Authentication-Header-Feld.
Der HTTP-Client wird damit zum Senden von Benutzernamen und Passwort aufgefordert.
Der HTTP-Client öffnet dann ein Eingabefenster, das den User zur Eingabe von Benutzername und Passwort auffordert. Nach abgeschlossener Eingabe schickt der HTTP-Client die Zugangsdaten an den Server. Sind die Daten korrekt, wird der Zugriff auf die angeforderten Inhalte freigegeben und vom Server ausgeliefert. Bei jedem erneuten HTTP-Request werden die Anmeldedaten erneut vom Client an den Server übermittelt. Sind die Zugangsdaten inkorrekt, hat der Benutzer noch zwei mal die Möglichkeit für eine korrekte Eingabe zu sorgen. Werden drei mal hinter einander die falschen Zugangsdaten eingegeben, so wird ein Fehler „Nicht autorisiert“ und eine entsprechende HTML-Datei vom Server geschickt, die den Besucher auf den fehlerhaften Zugriff des passwortgeschützten Bereich hinweißt.
Abbildung 2-27: Ablauf Authentifizierung
Die Authentifizierung kann als „Basic Authentication“ erfolgen, da zwischen dem Service-PC, bzw. dem HMI und dem Subsystem nur eine Fahrzeuginterne Verbindung aufgebaut wird.
Ein Zugriffsschutz, deren Authentifizierung und Verschlüsselung über eine DFÜ-Schnittstelle wird hier nicht betrachtet und wird über separate Mechanismen gewährleistet.
2.6 Diagnose Als Diagnose wird ein Verfahren oder Tätigkeit bezeichnet, bei dem/der aus den Symptomen (Anzeichen) auf die Natur eines Fehlzustandes geschlossen wird.
Die Diagnose umfasst die jeweils notwendigen Aktivitäten zur Inspektion, zum Aufzeichnen, Aufbewahren und ggf. Versenden bzw. Melden von Diagnosedaten. Damit sollen die unterschiedlichsten Tätigkeitsfelder und Personen unterstützt werden wie z. B.:
• Das Zugpersonal, indem dieses über Einschränkungen des Betriebs (z. B. reduzierte Traktionsleistung, usw.) informiert und ggf. mit Abhilfemaßnahmen versorgt wird.
• Die Instandhaltung, indem diese mit Fehlerinformationen versorgt wird, die z. B. zur Analyse von Problemen herangezogen werden kann.
• Die Wartungsdisposition, indem diese vorab (d. h. bevor das Schienenfahrzeug in das Depot zur Wartung einfährt) mit Fehlerinformationen versorgt wird. Dadurch wird die Planung der Wartungsarbeiten ermöglicht bzw. unterstützt (Unterstützung der Corrective Maintenance).
• Die Wartungsdisposition, indem diese mit Daten versorgt wird, die Rückschluss über den Verschleiß von Komponenten (Hardware) gibt (u. a. durch sogenannte Betriebsdaten).
Aus Sicht der Subsystemdiagnose sind folgende Verfahren relevant:
2.6.1 Betriebliches Melden Das betriebliche Melden (auch: Diagnose für das Betriebspersonal) bezeichnet die Feststellung von Fehlerzuständen bzw. Funktions- oder Betriebseinschränkungen, die für das Betriebspersonal relevant sind.
Durch das betriebliche Melden wird das Zugpersonal (z. B. der Triebfahrzeugführer oder der Zugbegleiter) beim Betrieb des Fahrzeuges unterstützt. Das betriebliche Melden ist funktional aufgebaut und orientiert sich an Funktionseinschränkungen. Das Zugpersonal wird über Funktionseinschränkungen des Fahrzeuges informiert und erhält Hilfestellungen (Abhilfemaßnahmen), um Betriebseinschränkungen (Einschränkungen für den Fahrgastbetrieb) zu minimieren.
2.6.2 Werkstattdiagnose Die Werkstattdiagnose (auch: Diagnose für Wartungspersonal) bezeichnet die Feststellung von Zuständen, die für die Wartung oder Instandsetzung durch das Wartungspersonal relevant sind. Diagnose umfasst dabei jeweils die nötigen Aktivitäten zur Inspektion (ggf. auch remote), zum Aufzeichnen, Aufbewahren und ggf. Versenden der Daten.
Die Werkstattdiagnose unterstützt damit das Instandhaltungspersonal bei der Behebung technischer Defekte (Instandsetzung), die sich im Betrieb ergeben haben. In diesem Fall hat die Werkstattdiagnose die KTE (kleinste tauschbare Einheit) im Fokus. Die Werkstattdiagnose unterstützt das Instandhaltungspersonal bei der Fehlersuche, falls die Ursache einer Funktionseinschränkung nicht eindeutig lokalisierbar ist. Daneben liefert die Werkstattdiagnose Betriebsdaten, die zur Planung von präventiven Wartungsaktivitäten genutzt werden können.
2.6.3 Betriebs- und Funktionsstatus Der Betriebsstatus einer Funktion / Teilfunktion informiert über die generelle Fähigkeit eines Funktionsträgers, die entsprechende Aufgabe erfüllen zu können. Das Statusmodell ist im Sibas PN System für alle (Teil-)Funktionen normiert (Beispielstatus sind NORMAL, FAILURE, usw.).
Auf einem Display (HMI) wird durch Anzeigeobjekte (Piktogramme) über die generelle Fähigkeit einzelner Funktionen zur Durchführung einer Aufgabe informiert. Die Anzeigeobjekte werden – je nach Verfügbarkeit der Funktion – mit einer entsprechenden Farbe hinterlegt (projektspezifische Festlegung). Dieser Mechanismus wird in nachfolgender Abbildung informell und beispielhaft dargestellt:
Abbildung 28 Betriebsstatus und Visualisierung
Jede Funktion/Teilfunktion eines Subsystems muss entsprechende Informationen mit folgenden Status liefern:
• Funktionsstatus einer (Teil-)Funktion, der den Status der Durchführung einer Aufgabe darstellt. Der Wertebereich des Funktionsstatus ist (teil)funktionsspezifisch, d. h. die Statusmodelle werden sich im Regelfall von (Teil-)Funktion zu (Teil)Funktion unterscheiden.
• Betriebsstatus einer (Teil-)Funktion, der über die generelle Fähigkeit eines Funktionsträgers informiert, die entsprechende Aufgabe erfüllen zu können. Der Wertebereich des Betriebsstatus ist nicht (teil-)funktionsspezifisch. Das zugrunde liegende Statusmodell wird in Kapitel 2.6.3.1 definiert.
Unter einem Funktionsträger wird dabei die technische Realisierung einer oder mehrere Funktionen verstanden. In der nachfolgenden Abbildung sind die Zusammenhänge in folgendem UML-Klassendiagramm dargestellt:
Abbildung 2-29: Zusammenhang zwischen Funktion und Betriebsstatus
Als Funktion wird die Realisierung einer Fähigkeit eines Systems oder eines Subsystems bezeichnet, welches die Aufgabe oder eine Menge von Aufgaben löst.
Eine Funktion kann sich wieder in Teilfunktionen aufteilen. Typischerweise realisiert ein System / Subsystem seine Funktionalität in mehreren verschiedenen Teilfunktionen.
Jede realisierte Funktion / Teilfunktion muss über den Grad seiner Verfügbarkeit Informieren.
2.6.3.1 Definition des Funktionsstatus
Der Funktionsstatus ist abhängig von der betrachteten (Teil-)Funktion und wird im Rahmen der Systemarchitekturbeschreibungen zu den einzelnen Funktionen, z. B. Systemarchitektur der Türsteuerung festgelegt. Der Funktionsstatus ist Bestandteil der dort definierten Schnittstellen.
Die Ausprägung der Betriebsstatus sind im Sibas PN System normiert und in der nachfolgenden Abbildung definiert. Diese Betriebsstatus werden über die im Kapitel 2.6.8 beschriebene Schnittstelle als Unsigned8-Werte übertragen.
Abbildung 2-30: Betriebsstatus Funktionsträger
2.6.3.2.1 General System Mode In der Folgenden Tabelle werden die einzelnen Zustände des „General System Mode“ beschrieben (Klammer deutschen Begriffe).
Name des Betriebsstatus Beschreibung Aktuelle Realisierung
OFF
(AUSGESCHALTET)
Funktionsträger ist ausgeschaltet. Ja
NORMAL
(NORMAL)
Funktionsträger ist betriebsbereit. Ja
DEGRADED
(TEILGESTÖRT)
Der Funktionsträger ist teilgestört, d. h. es liegen ein oder mehrere Funktionseinschränkungen vor.
Der Funktionsträger ist ausgefallen, die Kommunikation mit diesem ist jedoch noch möglich.
Ja
INITIALISATION
(INITIALISIERUNG)
Der Funktionsträger befindet sich im Hochlauf. Ja
READY_FOR_SHUTDOWN
(BEREIT FÜR DEN SHUTDOWN)
Der Funktionsträger kann ausgeschaltet werde Ja
SHUTDOWN
(HERUNTERFAHREN)
Der Funktionsträger ist ausgeschaltet. Ja
ISOLATED
(AUSGRUPPIERT)
Der Funktionsträger ist ausgruppiert und wartet auf die Eingruppierung. Diese ist im Regelfall nur durch das Wartungspersonal möglich.
Ja
STANDBY
(BEREIT)
Zustand für einen nicht aktiven, redundanten Funktionsträger. Ja
SW_DOWNLOAD
Dieser Zustand wird eingenommen, falls auf dem Funktionsträger ein SW-Download durchgeführt wird.
Nein
RESET
Dieser Zustand wird eingenommen, falls auf dem Funktionsträger ein Systemreset durchgeführt wird.
Nein
MISSING_PRECONDITION
(VORBEDINGUNG FEHLT)
Eine Vorbedingung für den ordnungsgemäßen Betrieb des Funktionsträgers ist nicht vorhanden.
Ja
UNKNOWN
(UNBEKANNT)
Dieser Zustand wird eingenommen wenn von außen nicht feststellbar ist, welchen Betriebsstatus sich ein Funktionsträger eingenommen hat. Dies ist z. B. bei einem Kommunikationsausfall gegeben.
2.6.3.2.4 Zustandsautomat Übergänge zwischen den Funktionsstatus werden durch Transitionen realisiert, die beim Eintreten von Ereignissen oder Bedingungen schalten. Der zugehörige Automat ist in nachfolgendem Zustandsdiagramm dargestellt:
Abbildung 2-31:: Zustandsdiagramm Betriebsstatus
Hinweis: Bei der Umsetzung des Automaten und bei der Konzeptionierung der zugehörigen Schnittstellen ist zu beachten, dass in späteren Ausbaustufen weitere Zustände hinzukommen können.
Im Betriebsstatusautomat wird über die beiden Regionen des UND-verfeinerten Zustands Betriebsstatus eine externe und eine interne Sicht unterschieden. Über die externe Sicht wird dargestellt, ob der Betriebsstatus des Funktionsträgers von außen (z. B. ein Betriebsstatus eines Funktionsträgers durch das SP CS) feststellbar ist , d. h.:
• Ist der Betriebszustand des Funktionsträgers feststellbar, so wird der Zustand KNOWN eingenommen.
• Ist der Betriebszustand des Funktionsträgers nicht feststellbar, so wird der Zustand UNKNOWN eingenommen (z. B. dann, wenn die Kommunikation zum Funktionsträger gestört ist).
Im Rahmen der Diagnose sind vor allem die Unterzustände der internen Sicht interessant, sofern sie bekannt sind (Zustand KNOWN). Der UND-verfeinerte Zustand ON zerfällt dabei in drei orthogonale Regionen:
• In der ersten orthogonalen Region wird der allgemeine Status der Durchführung der Aufgabe dargestellt.
• Über die Zustände in der zweiten orthogonalen Region wird informiert, ob ein Test abläuft oder ob sich der Funktionsträger im normalen Betrieb befindet.
• Über die Zustände in der dritten orthogonalen Region wird angezeigt, ob der Funktionsträger aktiv oder passiv ist, sofern dieser redundant ausgelegt ist.
Vermittels der Zustände dieser Regionen wird für einen Funktionsträger zum Ausdruck gebracht, ob dieser ohne Einschränkungen funktioniert (NORMAL), ob eine Vorbedingung für den ordnungsgemäßen Betrieb fehlt (MISSING_PRECONDITION), usw. Der Zustand MISSING_PRECONDITION wird für die Folgefehlerunterdrückung eingesetzt, weitere Informationen können hierzu den Kapiteln zum betrieblichen Melden (siehe Kapitel 2.6.1) und zur Werkstattdiagnose (siehe Kapitel 2.6.8.4) entnommen werden.
Hinweis: Ein Funktionsträger muss nicht zwingend alle genannten Betriebsstatus einnehmen, z. B. wird ein nicht redundant ausgelegter Funktionsträger niemals in den Zustand PASSIVE eintreten.
Im Rahmen dieser Beschreibung wird nicht definiert, unter welchen Bedingungen Funktionsträger einen bestimmten Zustand einnehmen.
Dies ist Aufgabe der subsystemspezifischen Systemarchitekturbeschreibungen der einzelnen Funktionen.
Die Ereignisse und Bedingungen, die zum Schalten von Transitionen führen, werden daher im Rahmen der Systemarchitekturbeschreibungen funktionsspezifisch festgelegt
2.6.4 Diagnosebeispiel In diesem Abschnitt wird der Einsatz von Funktions- und Betriebsstatus informell am Beispiel der Funktion Türsteuerung dargestellt.
Hinweis: Die hier dargestellten Szenarios dienen der Veranschaulichung des Konzepts; für die Funktion Türsteuerung ist grundsätzlich ausschließlich die Systemarchitekturbeschreibung Türsteuerung verbindlich.
Für die nachfolgenden Szenarios wird von folgender Aufteilung in Funktionsträger und Funktionen ausgegangen (Ausschnitt):
• Funktionsträger der Funktion Türsteuerung ist das Türsteuergerät. Diesem wird ein Betriebsstatus zugeordnet.
• Eine Funktion, die sich für das Öffnen und Schließen der Fahrgasttür verantwortlich ist.
• Eine Funktion, die für das Ein- und Ausfahren der Spaltüberbrückung verantwortlich ist.
Für die Funktionen werden die folgenden Funktionsstatus definiert:
• der Funktionsstatus Fahrgasttür (GESCHLOSSEN UND VERRIEGELT, IN BEWEGUNG, OFFEN, ABGESPERRT, usw.).
• der Funktionsstatus Spaltüberbrückung (EINGEFAHREN, NICHT VORHANDEN, AUSGEFAHREN, ABGESPERRT, usw.).
In der nachfolgenden Abbildung sind die Zusammenhänge nochmals auf Instanzebene dargestellt:
Abbildung 2-32: Funktionen, Funktionsträger, Betriebsstatus und Funktionsstatus am Beispiel der
2.6.4.1 Szenario 1 – Betriebs- und Funktionsstatus für eine offene Tür
Der Zug ist auf einer Haltestelle eingefahren. Für eine Tür eines Wagens, die bereits geöffnet wurde, stellen sich die Status der beiden Teilfunktionen (nach Öffnung dieser durch die Passagiere) wie folgt dar (es wird davon ausgegangen, dass an dieser Haltestelle ein Ausfahren der Trittstufen erforderlich ist):
• Funktionsstatus Fahrgasttür: OFFEN
• Funktionsstatus Spaltüberbrückung: AUSGEFAHREN
• Betriebsstatus Funktion Türsteuerung: NORMAL
2.6.4.2 Szenario 2 – Betriebs- und Funktionsstatus für eine defekte Tür
Szenario 2: Betriebs- und Funktionsstatus für eine defekte Tür
Der Zug ist auf einer Haltestelle eingefahren und die Tür öffnet sich, lässt sich danach jedoch aufgrund eines technischen Defekts nicht mehr schließen. Der Funktions- und Betriebsstatus der Tür stellt sich dann wie folgt dar:
2.6.4.3 Szenario 3 – Betriebs- und Funktionsstatus für eine ausgruppierte Tür
Eine Tür wurde nach dem Auftreten eines technischen Defekts manuell abgesperrt und verriegelt. Betriebs- und Funktionsstatus für die Tür sind dann wie folgt belegt:
• Funktionsstatus Fahrgasttür: GESCHLOSSEN
• Funktionsstatus Spaltüberbrückung: EINGEFAHREN
• Betriebsstatus Funktion Türsteuerung: ISOLATED
2.6.5 Betriebs- und Parameterdaten Betriebsdaten sind Informationen über den Zustand des Subsystems, z.B. Zählerstände.
Die Betriebsdaten eines Moduls werden über einen Datensatz (siehe Kapitel 2.6.8.4.11.2) gelesen. Betriebsdaten werden immer komplett pro Modul gelesen, bzw. geschrieben.
Für die Beeinflussung des Betriebsverhaltens eines Gerätes während des Betriebs verfügen Subsysteme über Parameter. Der SP CS kann durch Datensatz schreiben diese Parameter setzen / lesen (siehe Kapitel 2.6.8.4.11.1). Parameterdaten werden immer komplett pro Modul gelesen, bzw. geschrieben.
2.6.6 Diagnosewahrheit Das System muss die Qualitätsmerkmale, nach UIC 557 (entsprechend IEC 60706-5), bei der Entwicklung zugrunde legen, und an den gelieferten Produketn (System) nachweisen.
Im Vordergrund steht dabei die Fehleroffenbarung oder auch erkennbarer Fehleranteil genannt von 98% für nicht Sicherheitsrelevante Fehler.
Sicherheitsrelevante Fehler müssen sich nach o.g. Norm alle offenbaren!
Erkennbare Fehler umfassen sowohl Fehler, die über die Systemdiagnose automatisch diagnostiziert als auch Fehler die im Betrieb oder im Rahmen der Instandhaltung vom Personal erkannt werden, z.B. bei Sichtkontrollen, Funktionskontrollen, Prüfläufen.
Um den Nachweis für das Erreichen der geforderten Fehleroffenbarung zu führen, ist eine Ausfallanalyse über das zu liefernde System zu erstellen und dem AG zum DF vorzulegen.
Bei der Ausfallanalyse muss der AN folgende Schritte durchführen und tabellarisch übersichtlich darstellen:
1. Im Sinne einer FMEA Komponenten (LRU am Fahrzeug) und Einzelfunktionen
des Systems auflisten und die jeweiligen Fehlermöglichkeiten und Auswirkungen darstellen.
2. Die Art der Fehleroffenbarung analysieren und konkret beschreiben:
• Fehleroffenbarung durch Diagnose; Diese Diagnoseereignisse stellen die Basis für die Diagnoseprojektierung dar.
• Fehleroffenbarung im Rahmen des Betriebs oder der Instandhaltung durch festgelegte Kontrollen und Prüfungen. Diese Kontrollen und Prüfungen muss der AN in die Betriebs- und Instandhaltungsdokumentation übernehmen.
• Keine Fehleroffenbarung; Fehler wird nicht erkannt.
2.6.7 Generierung und Übertragung von Diagnoseereignissen
2.6.8 Diagnosegenerierung im Subsystem
Funktionsstatus
Werkstattdiagnose
CSV-Datei
Zyklisches Prozessabbild
Eintrag Funktionsstatus
Eintrag Betriebsstatus
Betriebsstatus
Status „Vormeldungen“
vorhanden
Funktionsschnittstelle Subsystem
PROFINET
azyklischer Datenabrufüber die FTP-Schnitstelle
StatusPuffer Vormeldung Werkstattdiagnose
Melden voll
Vormeldungen(Werkstattdiagnose)
azyklischer Datenabrufüber die Record-Schnitstelle
Vormelderelevant
Werkstattdiagnose
Vormelderelevant
Diagnosespeicherverwaltung
Werkstattdiagnose
Eintrag „betriebliche Melungen“
Betriebliche Meldungen
ParameterfileWerkstattdiagnose-
vormaledungen
CSV-Datei
Parametrierung mit denVormelderelevanten
Werkstattdiagnosemeldungs-nummern
Information obVormelderelevant
Abbildung 2-33:: Diagnosegenerierung
Hinweis: Analog zu den Werkstattdiagnosemeldungen werden über den gleichen Mechanismus, bzw. den gleichen Datensatz die Protokolldaten des Subsystems übergeben. Hierzu werden eigene CSV-Dateien für Protokolldaten, Vormeldungen (Protokolldaten) und das entsprechende Parameterfile „Protokollvormeldungen“ verwendet.
2.6.8.1 Funktionsstatus
Der Funktionsstatus wird mittels Bitschnittstelle über die zyklischen Daten entsprechen der jeweiligen Funktionsschnittstelle übertragen.
2.6.8.2 Betriebsstatus
Die Zustände des Betriebsstatus (General System Mode, Redundancy Mode, Test Service Mode) werden über die zyklischen Daten entsprechen der Definition in Kapitel 2.6.3.2 jeweils als Unsigned8-Werte übertragen.
2.6.8.3 Betriebliches Melden
Ereignisse für das „betriebliche Melden“ werden mittels Bitschnittstelle über die zyklischen Daten übertragen.
Für jedes Subsystem werden maximal 32 Einzelmeldungen pro (Teil-)Funktion eines Funktionsträgers (= u. A. Subsystem) entsprechend deren Funktionsschnittstelle festgelegt.
2.6.8.4 Werkstattdiagnosemeldungen
Werkstattdiagnosemeldungen werden in einen persistenten Umlaufpuffer auf dem Subsystem gespeichert. Ist das Ende des Datenpuffers erreicht, wird wieder von vorne begonnen und der bestehende Inhalt überschrieben (Ringspeicher), wobei ein Datensatz mit einer Kennung „Datensätze überschrieben“ eingefügt wird. Der Datenpuffer muss so ausgelegt sein, das eine Pufferung von min. 200 Werkstattdiagnosemeldungen möglich ist.
Ist die Werkstattdiagnosemeldung „vormelderelevant“, so wird diese auch in den Datenpuffer für die Vormeldungen eingetragen. Der Aufbau dieses Diagnosespeichers und der Datensätze ist analog zum Werkstattdiagnosepuffer. Die Pufferung von 50 vormelderelevanten Werkstattdiagnosemeldungen muss möglich sein.
Alle Werkstattdiagnosedaten verwenden die einheitliche Datenstruktur SP104_API_diagmessage_s beschrieben. Der Aufbau der Datenstruktur ist in Kapitel 2.6.8.4.12 enthalten.
Die Werkstattdiagnosemeldungen werden nichtflüchtig in zwei Ringpuffern gespeichert, einen für die Werkstattdaten und einen für die Protokolldaten. Die Unterscheidung zwischen beiden Typen erfolgt durch das Feld DiagnosticType der Diagnosestruktur (Kapitel 2.6.8.4.5) mit seinen Auswahlmöglichkeiten Werkstatt (0x3) und Protokoll (0x4).
Bestimmte Werkstattdiagnosemeldungen können in einer Konfigurationsdatei (DCF-Datei , siehe Kapitel 2.6.8.4.6) als vormelderelevant definiert werden. Dabei können sowohl Werkstattdaten und die Protokolldaten als vormelderelevant klassifiziert werden. Vormelderelevante Werkstattmeldungen müssen bereits während des Betriebs an den Betreiber des Fahrzeugs übertragen werden.
Sie werden parallel zu dem Ringpuffer noch in einen nichtflüchtigen FIFO-Speicher geschrieben. Bei neuen Vormeldedaten informiert das Subsystem die Steuerung (SP CS) über zyklische Daten darüber. Die Steuerung kann dann über einen Datensatz die vormelderelevanten Werkstattdiagnosemeldungen auslesen.
Nach dem Lesen durch die Steuerung wird die Meldung aus dem FIFO-Speicher entfernt.
Die Abbildung 2-34: Verarbeitung Werkstattdiagnose veranschaulicht den Workflow bei der Bearbeitung einer Werkstattdiagnosemeldung “newDiag“ nach der Übergabe durch die virtuelle Funktion newDiag.
2.6.8.4.1 Ringpuffer Ein Zugriff auf den Inhalt der zwei Ringpuffer (Werkstattdaten und Protokolldaten) ist über FTP möglich. Hierzu muss in das root-Verzeichnis des FTP eine Datei updatediag.dfs geschrieben werden; der Inhalt der Datei ist irrelevant. Als Folge davon werden die beiden Ringpuffer in getrennten Werkstattdiagnosedateien in das root-Verzeichnis des FTP geschrieben. Die Steuerdatei updatediag.dfs wird nach dem Ausführen der Kopieroperation von der Komponente gelöscht.
Die Werkstattdiagnosedateien (Diagnostic Log File Kapitel 2.6.8.4.7) weisen die Dateinamen
• Sibaspn_pc104_shop.dlf für die Werkstattdaten und
• Sibaspn_pc104_protocol.dlf für die Protokolldaten
Auf die Werkstattdiagnosedateien kann prinzipiell jederzeit über FTP zugegriffen werden. Die Standardimplementierung von FTP sieht keine Verriegelung von gegenseitigem Dateizugriff vor, d.h. sowohl die Komponente als auch FTP können gleichzeitig auf eine Datei zugreifen. Um unvollständige Daten durch den gleichzeitigen Zugriff zu vermeiden, darf über FTP auf die Werkstattdiagnose-dateien erst zugegriffen werden, wenn die Steuerdatei wieder gelöscht ist. Befindet sich im root-Verzeichnis des FTP die Steuerdatei, so darf nur die Komponente auf die Werkstattdiagnosedateien zugreifen.
Der Komponentenhersteller muss einen Mechanismus bereitstellen, um den Inhalt der Ringpuffer ohne Öffnen des Gerätes wieder zurückzusetzen.
2.6.8.4.2 Vormeldepuffer Ist eine Werkstattdiagnosemeldung als vormelderelevant klassifiziert, so wird eine Kopie davon in den Vormeldepuffer geschrieben.
Über das Bit „Vormeldedaten vorhanden“ in den zyklischen Daten (siehe Kapitel 2.6.8.4.4) wird dem Control System mitgeteilt, dass Meldungen im Vormeldepuffer vorhanden sind; es wird gesetzt sobald eine Meldung gespeichert wird und gelöscht wenn die letzte Meldung über die Record Data ausgelesen wurde. Der Vormeldepuffer kann ausschließlich über PROFINET Record Data ausgelesen werden.
Vom Vormeldepuffer existiert kein Abbild als über FTP auslesbare Datei. Durch seine nichtflüchtige Speicherung überdauert der Vormeldepuffer auch Spannungsausfälle der Baugruppe. Im Normalbetrieb werden die Vormeldedaten zeitnah vom Control System ausgelesen.
Werden mehr Meldungen in den Vormeldepuffer geschrieben als ausgelesen, so kommt es zum Überlauf (Overflow). Bei einem Overflow des Vormeldepuffers wird in der letzten gespeicherten Meldung das Strukturelement Message State auf den Wert 0x10 Overflow gesetzt. Zusätzlich wird das Bit „Vormeldedaten Überlauf“ in den zyklischen Daten (siehe Kapitel 2.6.8.4.4) gesetzt. Es bleibt solange gesetzt, bis vom Vormeldepuffer wieder Meldungen ausgelesen werden.
Nach einem Überlauf und dem Leeren des Vormeldepuffers muss das Control System einen Abgleich (siehe Kapitel 2.6.8.4.3) durchführen. Durch den Abgleich erhält es vom Subsystem alle aktuell anstehenden Fehler. Die zwischen dem Überlauf und dem Abgleich aufgetretenen Fehler sind bezüglich der Vormeldungen verloren; sie sind jedoch noch in den Ringpuffern für Werkstattdaten und Protokolldaten gespeichert.
2.6.8.4.3 Abgleich Beim Start des Subsystems oder dem Start des Diagnosesystems des Fahrzeugs wird die Information benötigt, welche Fehler aktuell in der Komponente noch anstehen. Durch den Neustart eines der beiden Systeme ist die inkrementelle Fehlerfortschreibung (kommend, gehend) fehlerhaft.
Aus diesem Grund muss die Komponente nach dem Systemstart und der Beendigung des Selbsttests einen Abgleich durchführen und die aktuell anstehenden Fehler als Werkstattdiagnosemeldungen übergeben. Zusätzlich verfügt das Control System über die Möglichkeit, mittels eines Datensatzes einen Abgleich auf der Komponente im Betrieb zu veranlassen. Die Komponente übergibt in diesem Fall alle aktuell anstehenden Werkstatt¬diagnosemeldungen.
Da mit einem Schreibvorgang nur eine Werkstattdiagnosemeldung übergeben werden kann, sind für die Übertragung der Abgleichdaten mehrere Schreibvorgänge auf den Ringpuffer notwendig. Dabei ist zu beachten, dass der Abgleich unterbrechungsfrei durchgeführt werden muss, d.h. die zu dem Abgleichzeitpunkt anstehenden Werkstattdiagnosemeldungen ohne Unterbrechung durch neuere Meldungen übertragen werden müssen. Erst nach der Beendigung
des Abgleichs dürfen Meldungen geschrieben werden, welche nach dem Abgleichzeitpunkt aufgetreten sind.
Um Abgleichmeldungen erkennen zu können, weisen sie eine charakteristische Codierung im Strukturelement Message State auf:
• AbgleichStart (01h) zeigt an, dass es sich bei dieser Meldung um die erste Abgleichmeldung handelt und dass mindestens noch eine Abgleichmeldung folgt.
• AbgleichSingle (04h) wird anstatt AbgleichStart als erste Abgleichmeldung geschrieben, wenn der Abgleich aus nur einer Meldung besteht. Es ist zwingend erforderlich, dass beim Abgleich mindestens eine Meldung geschrieben wird. Existiert keine reale Meldung, so muss vom Subsystem eine „Dummy-Meldung“ erzeugt werden.
• AbgleichRun (02h) zeigt an, dass es sich um eine Abgleichmeldung handelt, jedoch noch weitere Abgleichmeldungen folgen. Existieren nur 2 Abgleichmeldungen, so folgt auf die Meldung mit dem State AbgleichStart unmittelbar die Meldung mit dem State AbgleichEnd.
• AbgleichEnd (03h) zeigt an, dass es sich um die letzte Abgleichmeldung handelt, die nachfolgenden Meldungen enthalten den State Betrieb.
Meldungen nach dem Abgleich weisen den Message State Betrieb (00h) auf. Eine Besonderheit ist der Fall eines Überlaufs des Vormeldepuffers während des Abgleichs. Wie im normalen Betrieb wird dabei der Message State von der Sibas PN PC/104-Baugruppe, unabhängig vom übergebenen Wert, auf Overflow (10h) gesetzt. Da keine weiteren Meldungen gespeichert werden können, ist damit auch automatisch der Abgleich beendet. Tritt der Overflow während eines Abgleichvorgangs auf, so muss die Steuerung den Abgleichvorgang als vorzeitig beendet einstufen, wenn sie nach dem Start und vor dem Ende des Abgleichvorgangs einen Overflow erkennt. Zum Aufsynchronisieren muss das Control System nach dem Leeren des Vormeldepuffers einen neuen Abgleich über die Schnittstelle zum Subsystem anstoßen.
Die Software der Sibas PN PC/104-Baugruppe leitet den Abgleichwunsch über einen Aufruf der API des PROFINET Gateway Drivers an das Subsystem weiter. Das Ergebnis des API-Aufrufs wird dazu verwendet, das Schreiben des Datensatzes positiv oder negativ zu quittieren.
2.6.8.4.4 Schnittstelle Steuerung Bei neuen Vormeldedaten (siehe Kapitel 2.6.8.4.2) informiert die Komponente die Steuerung SPCS über die zyklischen Daten in Slot 13 und Subslot 1 an der Position Byte 0, Bit 0. Die Steuerung kann die Vormeldedaten d dann durch das Lesen der Record Data dieses Slots die Informationen auslesen. Ein Lesezugriff auf die Datensatznummer 100 von Slot 13 und Subslot 1 liefert den ältesten Werkstattdiagnoseeintrag zurück; befinden sich keine Werkstattdiagnoseeinträge mehr im Vormeldepuffer wird der Lesewunsch negativ quittiert.
Bei einem Überlauf des Vormeldepuffers wird das Bit „Vormeldedaten Überlauf“ in den zyklischen Daten von Slot 13, Subslot 1 an der Position Byte 0, Bit 1 gesetzt.
Die Aufforderung an die Komponente zum Durchführen des Abgleichs erfolgt durch das Schreiben des Record Data 102 von Slot 13 und Subslot 1. Dieser enthält 4 Bytes mit der Codierung 0x6789CDEF für das Durchführen eines Abgleich.
2.6.8.4.5 Speicherung Jeder der 2 Diagnosetypen (Werkstattdaten und Protokolldaten) verfügt über einen eigenen nichtflüchtigen Ringpuffer. Die Größe der Ringpuffer und der FIFO für die Vormeldedaten erfolgt durch Definitionen in der Software und ist im Betrieb nicht änderbar. Die Aufteilung wird vom Gerätehersteller mit der Siemens AG abzustimmen.
Bei der Diagnosestruktur ist zu beachten, dass die letzten Einträge (occ…) eine variable Länge aufweisen. Das Strukturelement OccDataType gibt an, ob Umfelddaten folgen oder nicht; wenn ja gibt das Strukturelement OccDataLen deren Länge an.
Die Diagnoseelemente werden in chronologischer Reihenfolge in die Ringpuffer geschrieben. Das Einsynchronisieren nach dem Systemstart auf das Ende des Ringpuffers erfolgt durch die Auswertung des Strukturelements SequenceNo der Diagnosestruktur. Nach einem Systemstart muss jedes Subsystem mit der Sequenznummer 0 beginnen. Befinden sich im Ringpuffer mehrere Einträge mit der Sequenznummer 0 so ist mit Hilfe des Strukturelements DateTime der älteste Diagnosedatensatz zu bestimmen.
2.6.8.4.6 Diagnostic Control File (DCF) Das DCF dient dazu, die Verarbeitung von Diagnoseeinträgen zu steuern, siehe hierzu Kapitel 2.6.8.4.2. Der Primärschlüssel dazu ist der DiagnosticCode, dieser ist Bestandteil einer jeden Diagnosestruktur aus Tabelle 17. Die Datei befindet sich im Flash-File-System (ftp root)der Komponente und wird von der Software nur gelesen. Durch ein Update mit FTP kann sie bei Änderungen an der Steuerung der Diagnosedaten einfach geändert werden.
#Sibas PN PC/104 Interface board #Diagnostic Control File Style:1 /Info data like /version, release, author ><DiagnosticCode>,<Operation> /Door problem >140,ADHOC /Cooler to hot >132,ADHOC #End DCF
Abbildung 2-35: Dateiformat DCF
Die Abbildung 2-35: Dateiformat DCF stellt das Dateiformat der DCF-Datei dar. Es besteht aus den drei nachfolgenden Bestandteilen:
• Konstante Texte, sind rot dargestellt. Sie beginnen immer mit einem # als erstes Zeichen einer Zeile. Die konstanten Elemente müssen beim Auswerten
der Datei überprüft werden. Die Datei darf nur akzeptiert werden wenn die Überprüfung eine Übereinstimmung ergibt.
• Informative Texte, sind grün dargestellt und beginnen als erstes Zeichen immer mit einem /. Die informativen Elemente werden nicht ausgewertet und können an jeder Stelle in der Datei stehen.
• Kommandos, sind blau dargestellt. Sie beginnen immer mit einem > als erstes Zeichen einer Zeile. Dahinter folgt immer der DiagnosticCode in dezimaler Schreibweise. Dahinter folgt, getrennt durch ein , das Kommando. Momentan ist nur das Kommando ADHOC definiert; es legt fest dass die Werkstattdiagnosemeldung vormelderelevant ist, d.h. während des Betriebs an das Control System übertragen werden muss. Die Struktur ermöglicht das spätere Hinzufügen weiterer Kommandos.
Zwischen den einzelnen Strukturelementen sind Leerzeichen erlaubt. Die dargestellten Zeilen können durch das Hinzufügen von Leerzeilen strukturiert werden. Das Kriterium für ein Zeilenende ist das Zeichen [LF].
2.6.8.4.7 Diagnostic Log File (DLF) Die DLF enthält alle Diagnoseeinträge der jeweiligen Diagnoseklasse aus den jeweiligen Ringpuffern (siehe Kapitel 2.6.8.4.1 und 2.6.8.4.5). Die Dateien können über FTP gelesen werden.
• Konstante Texte, sind rot dargestellt. Sie beginnen immer mit einem # als erstes Zeichen einer Zeile. Die konstanten Elemente werden beim Erzeugen der Datei geschrieben und sollten von der Auswertesoftware überprüft werden bevor sie die Datei akzeptiert.
• Informative Texte, sind grün dargestellt und beginnen als erstes Zeichen immer mit einem /. Als informatives Element werden der Datei immer die Artikelnummer, die Seriennummer und die Softwareversion der Sibas PN PC/104-Baugruppe hinzugefügt. Sie erleichtern bei Problemen eine Analyse.
• CSV-Liste, ist blau dargestellt. Der Aufbau der CSV-Liste und das verwendete Format ist im Kapitel 2.6.8.5.2 beschrieben. Hierfür werden die Strukturelemente eines Diagnoseeintrags, getrennt durch Kommas, in eine Zeile geschrieben. Bei der Ausgabe ist keine besondere Formatierung notwendig, da die Datei nur maschinell verarbeitet (z.B. Aufbereitung in Excel) und nicht durch Anwender (als Textdatei) interpretiert wird.
Die Datei verfügt sie über keine Endekennung, der Zugriff wird über die Steuerdatei updatediag.dfs (siehe Kapitel 6.2) verriegelt.
2.6.8.4.8 Diagnosespeicher für Protokolldaten
Protokolldaten werden analog zu dem im Kapitel 2.6.8.4 beschriebenem Mechanismus für Werkstattdiagnosemeldungen übergeben.
2.6.8.4.9 Initialisierungsdaten für Diagnosemeldungen Um die Datensätze von Werkstattdiagnosemeldungen mit den notwendigen Informationen versehen zu können ist es notwendig, das Subsystem mit diesen zu versorgen.
Diese Informationen gelangen über verschiedene Mechanismen, bzw. zu unterschiedlichen Zeitpunkten (über zyklische Daten, bzw. bei der Initialisierung des PROFINET IO Devices) und von unterschiedlichen Quellen zum Subsystem.
Im der folgenden Tabelle wird dargestellt, welche Information dem Subsystem hierfür bereitgestellt werden (Definition siehe Tabelle 17).
Datenquelle Datenübertragung
zyklisch azyklisch
Fahrzeugsteuerung (SP CS)
Anlauf Nach „Anlauf“
MissingPrecondition X X
TrainOperationID X
CarNo X X
GeneralTrainMode X X
TrainMode X X
TrainSubMode X X
OtherTrainModes X X
NameOfStation X X
NTP-Client-Parameter (Serveradressen)
X X
Time-Information (Zone und Sommer- Winterzeit)
X X
Tabelle 11 Initialisierungsdaten für Diagnosemeldungen
2.6.8.4.10 Nummernbänder für Subsystemunabhängige Record-Datensätze Für „normale Record Datensätze“ die Subsystemunabhängig sind, wird das Nummernband wie folgt definiert:
Nummern Datensatz 10 bis Datensatz 19 Datensatznummer: Datensatzbeschreibung: Slot Sub-Slot
Tabelle 12 Nummernband für Subsystemunabhängige Record-Datensätze
2.6.8.4.10.1 Aufbau Datensatz 10 „TrainOperationID und CarNo“
Der Datensatz wird zur Laufzeit an das Subsystem übermittelt und ist dort persistent abzulegen. Ein erneutes Senden des Datensatzes führt zum Überschreiben des „alten“ Datensatzes. Die Inhalte des Datensatzes werden zum Erzeugen von Diagnoseeinträgen benötigt (siehe Kapitel 2.6.8.4.12),
Für Vergleichszwecke ist es zulässig den Datensatz zur Laufzeit auch vom SP CS aus zu lesen, d.h. bei einem lesenden Zugriff ist der aktuell vorhandene Datensatz vom Subsystem zu melden.
• Die „TrainOperationID“ wird bei Sibas PN auf max. 16 Zeichen festgelegt.
• Die „CarNo“ wird bei Sibas PN auf max. 12 Zeichen (UIC-konforme Wagennummer) festgelegt.
Nicht verwendete Zeichen sind immer mit „“ (Leerzeichen) zu füllen. Byte Elemente Funktion 0-1 Version Versionskennung (aktuell 1)
2 MaxLenTrainOpId Länge Textfeld Train Operation ID (konstant 16)
3 Reserved 4-19 TextTrainOpId Text Train Operation ID (max. 16 Zeichen) 20 MaxLenCarNo Länge Textfeld Car Number (konstant 12) 21 Reserved 22-33 TextCarNo Text Car Number (max. 12 Zeichen)
Tabelle 13 Datensatz „TrainOperationID“ und „CarNo“
typedef struct SPN_Record_TrainOpID_CarNo { u16 version; ///< Version of record structure u08 maxLenTrainOpId; ///< Maximum len of string train operation id u08 reserved1; ///< reserved byte u08 textTrainOpId[16]; ///< text for train operation id u08 maxLenCarNo; ///< Maximum len of string car number u08 reserved2; ///< reserved byte u08 textCarNo[12]; ///< text for car number } SPN_Record_TrainOpID_CarNo_s;
Abbildung 2-37:: Struktur Datensatz „TrainOperationID“ und „CarNo“
2.6.8.4.10.2 Aufbau Datensatz 11 „TimeZone und SummerTime“
Der Datensatz wird zur Laufzeit an das Subsystem übermittelt und ist dort persistent abzulegen. Ein erneutes Senden des Datensatzes führt zum Überschreiben des „alten“ Datensatzes.
Der Aufbau des Datensatzes und die dazu gehörige Struktur für die „TimeZone und SummerTime“ ist im Kapitel 2.5.4.1 beschrieben.
2.6.8.4.11 Nummernbänder für subsystemspezifische Record-Datensätze Für „normale Record Datensätze“ die subsystemabhängig sind, wird das Nummernband wie folgt definiert:
Nummern Datensatz 20 bis Datensatz 99 Datensatznummer: Datensatzbeschreibung: Slot Sub-Slot 20 Parameterdaten 1 bis 25 1 21 Betriebsdaten 1 bis 25 1 22 23 … 99
Tabelle 14 Nummernbänder für subsystemspezifische Record-Datensätze
2.6.8.4.11.1 Aufbau Datensatz 20 „Parameterdaten“
Alle Parameter eines Subsystems, die sich zur Laufzeit ändern können oder aus dem Subsystem ausgelesen werden sollen, sind in diesem Datensatz zu spezifizieren.
Der Nutzdateninhalt des Datensatzes 20 kann für jedes Modul, das einem Slot zugeordnet wird anders aussehen.
Beim Schreiben und Lesen des Datensatzes wird immer der komplette Datensatz übertragen, d.h. auch beim Ändern eines Parameters werden die nicht geänderten Parameterdaten mit übertragen.
Beispiel eines Parameterdatensatzes der Klimaanlage:
Byte Elemente Funktion 0-1 Version Versionskennung (aktuell 1) 2-3 Kennlinie Auswahl der Kennlinie 4-5 Schlummerbetrieb Angabe in Minute ab 0.00 Uhr als Integer16 6-7 Kälteanlage Kälteanlage sperren / freigeben usw.
Tabelle 15 Datensatz Parameterdaten typedef struct SPN_Record_Parameter_Klima { u16 version; ///< Version of record structure u16 kennlinie; ///< kennlinie u16 schlummer; ///< schlummer u16 kaelteanlage; ///< sperren_freigabe } SPN_Record_Parameter_Klima_s;
Abbildung 2-38:Struktur Datensatz Parameterdaten
2.6.8.4.11.2 Aufbau Datensatz 21 „Betriebsdaten“
• Azyklischer Anteil
Alle Betriebsdaten (siehe Kap. 2.6) eines Subsystems, die sich zur Laufzeit ändern können oder aus dem Subsystem ausgelesen werden sollen, sind in diesem Datensatz zu spezifizieren.
Der Nutzdateninhalt des Datensatzes 21 kann für jedes Modul, das einem Slot zugeordnet wird anders aussehen.
Beim Schreiben und Lesen des Datensatzes wird immer der komplette Datensatz übertragen, d.h. auch beim Ändern eines Betriebsdatums werden die nicht geänderten Betriebsdaten mit übertragen.
Wichtig: Bei der Übertragung vom Subsystem an das überlagerte Leitsystem sind die absoluten Zählerstände zu übertragen.
Bei der Übertragung an das Subsystem werden relative Werte für Änderungen übertragen, d.h.:
o Betriebsdaten die geändert werden sollen, werden mit relativen Werten versorgt
o Betriebsdaten die nicht geändert werden sollen, werden mit „0“ gesendet.
Somit sind im Subsystem die aktuellen Werte mit den gesendeten Werten zu addieren.
Beispiel.: Im Betriebsdatensatz sind drei Betriebsdaten wie folgt spezifiziert: 1. Betriebsstundenzähler ( Datentyp INT aktueller Stand 10) 2. Schaltspiele der Komponente x ( Datentyp INT aktueller Stand 200) 3. Schaltspiele der Komponente y ( Datentyp INT aktueller Stand 350) 4. usw. Datensatz der aus dem Subsystem ausgelesen wird: „10;200;350“ Soll jetzt der Zähler der Schaltspiele für Komponente x auf „0“ zurückgesetzt werden, sieht der gesendete Datensatz wie folgt aus: „0;-200;0“
Beispiel eines Betriebsdatensatzes der Klimaanlage:
DB1.DBW 0 Version INT // Versionskennung DB1.DBW 2 Betriebsstunden Verdichter 1 INT // Betriebsstundenzähler des Verdichter 1 DB1.DBW 4 Betriebsstunden Verdichter 2 INT // Betriebsstundenzähler des Verdichter 2 DB1.DBW 6 Betriebsstunden Zulüfter OS INT // Betriebsstundenzähler des Zulüfters 1 DB1.DBW 8 Betriebsstunden Zulüfter US INT // Betriebsstundenzähler des Zulüfters 2 Usw.
Tabelle 16 Datensatz Betriebsdaten typedef struct SPN_Record_Betriebsdaten_Klima { u16 version; ///< Version of record structure u16 operation_hour1; ///< operation hour 1 u16 operation_hour2; ///< operation hour 2 } SPN_Record_Betriebsdaten_Klima_s;
Abbildung 2-39: Struktur Betriebsdaten Parameterdaten
• Zyklischer Anteil
Nachdem gleiche Subsysteme in unterschiedlichen Projekten verschieden ausgeprägt sein können, unterscheiden sich auch deren Funktionalitäten. Damit die Gesamtfunktionalität in einem Projekt entsprechend konfiguriert werden kann, wird das Subsystem in Module aufgeteilt.
Beispiel:
1. Im Projekt A hat die Tür eine Trittstufe 2. Im Projekt B hat die Tür keine Trittstufe Durch die Modulaufteilung kann dann im Projekt B das Funktionsmodul „Trittstufe“ weggelassen werden.
Im zyklischen Abbild des jeweiligen Funktionsmoduls ist ein Bit vorzusehen, welches bekannt gibt ob der Datensatz sich seit dem letzten auslesen geändert hat.
Das Bit ist einem Funktionsmodul zuzuordnen und in der GSD zu integrieren.
Bei jedem Auslesen des Datensatzes wird das Bit auf „0“ gesetzt. Ändert sich jetzt ein Betriebsdatum, z.B. der Türschließzähler erhöht sich um eins, wird das Bit wieder auf „1“ gesetzt.
Wenn der geänderte Wert jetzt vom überlagerten System benötigt wird und diesem durch das Bit mitgeteilt wird, dass es nicht mehr den aktuellen Stand hat, wird der Datensatz erneut ausgelesen.
Nach erfolgreicher Übermittlung des Datensatzes ist das Bit wieder auf „0“ zu setzen.
2.6.8.4.12 Aufbau der Werkstattdiagnosemeldungen (Datensatz) Die Tabelle 17 Aufbau Werkstattdiagnosemeldungen zeigt die Elemente der Diagnosestruktur samt der Beschreibung. Die Struktur ist so aufgebaut dass sich mit #pragma pack 1 bei einem C-Compiler eine identische Abbildung im Speicher ergibt und außerdem das Speicherabbild identisch mit demjenigen in einer SIMATIC-Steuerung (Datentypen entsprechen der Profile Guidelines für PROFINET [7]) ist. Alle Werte im Format Signed16, Unsigned16 und Unsigned32 sind im Big-endian-Format anzugeben, d.h. an der niedrigsten Adresse (Offset) steht das höherwertigste Bit. Die Darstellung des Elements DateTimeS7 ist identisch dem SIMATIC-Format aus Kapitel 2.5.4.2.2. Der Defaultwert gibt die Belegung des Wertes an, wenn er der Komponente nicht bekannt ist. Elemente ohne Defaultwert (---) müssen korrekt gesetzt werden.
Analog zu den Werkstattdiagnosemeldungen werden über den gleichen Mechanismus (siehe Kapitel 2.6.8), bzw. den gleichen Datensatz die Protokolldaten des Subsystems übergeben.
Datenfeld Beschreibung Format Länge Offest Default
VersionID Version der Header-Datenstruktur 1. Byte / 2. Byte Major / Minor Die hier definierte Diagoseheader-Datenstruktur hat die Version 1.0
Unsigned16 2 Byte +0 1.0
DiagnosticClass 0 = Korrektiv 1 = Preventiv
Unsigned8 1 Byte +2 ---
Reserved1 Reserved Byte für zukünfige Verwendung und Aufrechterhaltung des Alignments
Unsigned8 1 Byte +3 0
DateTimeS7.year Jahr in BCD-Codierung von 1990 (Codierung 90) bis 2089 (Codierung 89) Unsigned8 1 Byte +4 --- DateTimeS7.month Monat in BCD-Codierung von 01 bis 12 Unsigned8 1 Byte +5 ---
DateTimeS7.day Tag in BCD-Codierung von 01-31 Unsigned8 1 Byte +6 --- DateTimeS7.hour Stunde in BCD-Codierung von 01-12 Unsigned8 1 Byte +7 ---
DateTimeS7.minute Minute in BCD-Codierung von 00-59 Unsigned8 1 Byte +8 --- DateTimeS7.second Sekunde in BCD-Codierung von 00-59 Unsigned8 1 Byte +9 ---
DateTimeS7.ms Millisekunde höherwertigen 2 Digits in BCD-Codierung von 00-99 Unsigned8 1 Byte +10 --- DateTimeS7.ms_dow Bit 7..4: Millisekunde niederstes Digit in BCD-Codierung, Bit 3..0: Wochentag
Datenfeld Beschreibung Format Länge Offest Default DateTimeAI.timequality Zeitqualität: 0x00: Unsynchronisiert, noch nie Verbindung zum Server, 0x01:
Seit Start mindestens einmal Verbindung zum Server, aktuell jedoch keine Verbindung zum Server, 0x02: Synchronisiert durch Server, 0x03: Synchronisationsstatus des Servers unbekannt.
Unsigned8 1 Byte +15 3
SequenceNo Laufende Nr. des Diagnosesatzes. Nach jedem Systemstart muss jedes Subsystem mit der Sequenznummer 0 beginnen. Ist das Wertebereichsende erreicht, beginnt die SequenceNo. wieder mit 0.
Unsigned16 2 Byte +16 ---
HeaderLength Länge des Diagnoseheader in Byte (Start bis Datenfeld “OtherTrainModes“) Unsigned8 1 Byte +18 --- DataLength Länge der Umfelddaten in Byte (Start von Datenfeld „OccVersionID“ bis Ende
“OccData“). Unsigned8 1 Byte +19 ---
VendorID Die VendorID ist eine 16-Bit-Kennung, welche eine eindeutige Referenz zur Herstellerfirma (siehe Herstellerkennung, Abbildung 2-10) darstellt. Diese wird von der PNO für jeden Hersteller vergeben. Eine Herstellerfirma braucht diese ID also nur einmal. (Information erfolgt aus GSD)
Unsigned16 2 Byte +20 ---
DeviceID Die Device_ID (siehe Gerätekennung, Abbildung 2-10) dient der detaillierten Unterscheidung der Geräte-Typen. Sie kann herstellerspezifisch festgelegt werden (Information erfolgt aus GSD)
Unsigned16 2 Byte +22 ---
DeviceSerialNo Seriennummer des Gerätes (Subsystem, nicht Kommunikationsanschaltung) VisibleString 26 Byte +24 0 NameOfStation Eindeutiger Name des Gerätes. PROFINET Gerätename aus dem Sibas PN
n“ ModulName Name des fehlerhaften Modules. (Information erfolgt aus der GSD). Kann der
Fehler nicht eindeutig einem Modul zugeordnet werden, erfolgt hier kein Eintrag.
VisibleString
26 Byte +76 „unknown“
ModulSerialNo Seriennummer des Modul (falls vorhanden) VisibleString
26 Byte +102 „unknown“
HardwareRelease Hardwarestand des Modul VisibleString
4 Byte +128 „unknown“
SoftwareRelease Softwarestand des Modul VisibleString
4 Byte +132 „unknown“
ApplID Version der Subsystemapplikation (falls zusätzlich zur Software_Release vorhanden) 1. Byte / 2. Byte / 3. Byte Major / Minor / Patch Kann der Fehler nicht eindeutig einer Applikation zugeordnet werden, wird hier der Defaultwert eingetragen.
Unsigned32
4 Byte +136 „unknown“
DiagnosticCode Diagnoseereignis-Nr. des Subsystemes Unsigned16 2 Byte +140 --- EventState Meldung kommt / geht Unsigned8 1 Byte +142 ---
Message State Status der Meldung 00h Betriebliche Meldung 01h Erste Abgleichmeldung, weitere folgen 02h Abgleichmeldung, weitere folgen 03h Letzte Abgleichmeldung, es wurden schon Abgleichmeldungen geschrieben 04h Erste und einzige Abgleichmeldung, es folgen keine weiteren Abgleichmeldungen 10h Überlauf Vormeldepuffer, evtl. laufender Abgleich ist beendet.
Unsigned8 1 Byte +144 ---
MissingPrecondition 0 = Precondition vorhanden 1 = Precondition nicht vorhanden
Unsigned8 1 Byte +145 ---
TrainOperationID Fahrzeug-Nr., z.B. Zuglaufnummer (ICE745) oder betreiberspezifische Festlegung.
VisibleString 16 Byte +146 „unknown“
CarNo UIC-ID des Wagens nach UIC 438, ggf. betreiberspezifische Festlegung. Bei Verwendung der UIC:
wichtigste techn. Merkmale (4 Ziffern) Nummer in der Baureihe (3 Ziffern) Prüfziffer (2 Ziffern)
VisibleString
12 Byte +162 „unknown“
GeneralTrainMode Allgemeiner Zustand des Zuges (Normaler Betrieb, Service, Wartung). Dieser Zustand wirkt auf Berechtigungen, Veränderungen an der Anlage vornehmen zu können (Laden von SW-erlaubt/verboten, Forcen von Signalen erlaubt/verboten). Er gilt übergeordnet für den Zug.
Unsigned8 1 Byte +174 ---
TrainMode Betrieblicher Zustand des Zuges. Dies stellt die Hauptzustände des Zuges aus Betreibersicht dar.
Unsigned8 1 Byte +175 ---
TrainSubMode Betriebliche Subzustände des Zuges aus Betreibersicht. Unsigned8 1 Byte +176 --- OtherTrainModes Weitere Zustände, die unabhängig vom Betriebszustand Zug aktiv sein
können. Unsigned8 1 Byte +177 0
Reserved2 Reserved Byte für zukünfige Verwendung und Aufrechterhaltung des Alignments
Unsigned16 2 Byte +178 0
Reserved3 Reserved Byte für zukünfige Verwendung und Aufrechterhaltung des Alignments
Unsigned8 1 Byte +180 0
Reserved4 Reserved Byte für zukünfige Verwendung und Aufrechterhaltung des Unsigned8 1 Byte +181 0
Die nachfolgenden Definitionen bilden die Struktur aus Tabelle 18 in eine C-Struktur ab. /// Length of version informaiton #define SP104_API_DIAGMSG_VERS_END 2 /// Length of diag string element, 25 characters plus 0 or #define SP104_API_DIAGMSG_STRLEN 26 /// Length of diag info element, 3 characters plus 0 or 4 characters #define SP104_API_DIAGMSG_INFOLEN 4 /// Length of carNo uic element, 12 characters #define SP104_API_DIAGMSG_CARNOLEN 12 /// Length of trainOperationID element, 16 characters #define SP104_API_DIAGMSG_TRAINOPLEN 16 /// Max Length of environment data, 100 bytes #define SP104_API_DIAGMSG_OCCLEN 100 /// Diagnostic type shop data #define SP104_API_DIAGMSG_SHOPDATA 3 /// Diagnostic type protocol data #define SP104_API_DIAGMSG_PROTDATA 4
/// Structure S7 Time Format typedef struct SP104_API_datetimeS7 { u08 year; ///< Year in BCD Coding: 1990 (coding 90) to 2089 (coding 89) u08 month; ///< Month in BCD Coding: 01 to 12 u08 day; ///< Day in BCD Coding: 01 to 31 u08 hour; ///< Hour in BCD Coding: 01 to 24 u08 minute; ///< Minute in BCD Coding: 00 to 59 u08 second; ///< Second in BCD Coding: 00 to 59 u08 ms; ///< Miliseconds higher to digits in BCD Coding: 00 to 99 u08 ms_dow; ///< Bit 7..4: Miliseconds lower to digit (0..9), Bit 3..0: 1: Sunday, 2: Monday, 3: Tuesday…. } SP104_API_datetimeS7_s; /// Structure Additional time Information typedef struct SP104_API_datetimeAI { s16 timezone; ///< Offset UTC to local wintertime due timezone in minutes s08 dst; ///< Offset local wintertime to local time due daylight saving time in minutes u08 timequality; ///< Synchronisation status 0: never synchronized 1: sync lost, 2: synchronized, 3: unknown } SP104_API_datetimeAI_s; /// Diagnostic message typedef struct SP104_API_diagmessage { u08 nHeaderVersion[SP104_API_DIAGMSG_VERS_END]; ///< Version Headerstruktur u08 nDiagnosticClass; ///< Diagnostic class u08 nReserved1; ///< Reserved byte 1, inserted for alignment SP104_API_datetimeS7_s datetime; ///< Date and time SP104_API_datetimeAI_s timeinfo; ///< Additional time information u16 nSequenceNumber; ///< Sequence number of message, must be incremented by subsystem u08 nHeaderLength; ///< Length of header until included element software release u08 nUserDataLength; ///< Length of user data u16 nVendorID; ///< Vendor ID of subsystem manufactory; given by Siemens u16 nDeviceID; ///< Device ID, given by subsystem manufactory u08 szDevSerialNumber[SP104_API_DIAGMSG_STRLEN]; ///< String with serial number of device u08 szStationName[SP104_API_DIAGMSG_STRLEN]; ///< String with station name u08 szModuleName[SP104_API_DIAGMSG_STRLEN]; ///< String with name of defective module u08 szModSerialNumber[SP104_API_DIAGMSG_STRLEN]; ///< String with serial number of module u08 szModHWRelease[SP104_API_DIAGMSG_INFOLEN]; ///< String with hardware release u08 szModSWRelease[SP104_API_DIAGMSG_INFOLEN]; ///< String with software release u08 nApplID[SP104_API_DIAGMSG_VERL_END]; ///< Version of subsystem application u16 nDiagnosticCode; ///< Identifier of diagnostic event u08 nEventState; ///< Event state (appears, disappears) u08 nDiagnosticType; ///< Diagnostic type, coding with SP104_API_DIAGMSG_SHOPDATA or _PROTDATA u08 nMessageState; ///< Message type, includes alignment and overflow info
u08 nMissingPrecondition; ///< 0: Precondition available, 1: not available. u08 nTrainOperationID[SP104_API_DIAGMSG_TRAINOPLEN]; ///< Name of train u08 nCarNo[SP104_API_DIAGMSG_CARNOLEN]; ///< UIC438 coded car number u08 nGeneralTrainMode; ///< General state of train (operation, service, maintenance...) u08 nTrainMode; ///< Operational state of train u08 nSubTrainMode; ///< Operational substate of train u08 nOtherTrainMode; ///< Additional state of train u16 nReserved4; ///< Reserved byte 4, inserted for alignment u08 nReserved2; ///< Reserved byte 2, inserted for alignment u08 nReserved3; ///< Reserved byte 3, inserted for alignment u08 nOccVersionId[SP104_API_DIAGMSG_VERS_END]; ///< Version of environment data structure u08 nOccDataType; ///< Info if environment data are available or not u08 nOccDataLen; ///< Len of attached environment data u08 nOccData[SP104_API_DIAGMSG_OCCLEN]; ///< Data field for environment data } SP104_API_diagmessage_s;
Abbildung 2-41: Strukturdefinition Diagnosedaten
2.6.8.4.13 Druckformat Die Umsetzung der Strukturelemente der Diagnosestruktur Tabelle 6 1 in den ASCII-Text der CSV-Liste erfolgt anhand der nachfolgenden Vorschrift:
• „N“: Dezimalzahl
• „X“: Hexadezimalzahl (0x…)
• „0N“: Dezimalzahl mit konstanter Textlänge (fehlende Stellen durch 0 aufgefüllt)
• „Text“: Ausgabe des Strings als Text
• „-„:Datenfeld nicht drucken
Das generelle Format des Diagnostic Log Files ist in den Kapiteln 2.6.8.4.7 und 2.6.8.5 beschrieben)
Datenfeld Beschreibung Format VersionID Version der Header-Datenstruktur
1. Byte / 2. Byte Major / Minor
N.N
DiagnosticClass 0 = Korrektiv 1 = Preventiv
N
Reserved1 Reserved Byte für zukünfige Verwendung und Aufrechterhaltung des Alignments - DateTimeS7.year Jahr in BCD-Codierung von 1990 (Codierung 90) bis 2089 (Codierung 89) DateTimeS7.month Monat in BCD-Codierung von 01 bis 12 DateTimeS7.day Tag in BCD-Codierung von 01-31 DateTimeS7.hour Stunde in BCD-Codierung von 01-12 DateTimeS7.minute Minute in BCD-Codierung von 00-59 DateTimeS7.second Sekunde in BCD-Codierung von 00-59 DateTimeS7.ms Millisekunde höherwertigen 2 Digits in BCD-Codierung von 00-99 DateTimeS7.ms_dow Bit 7..4: Millisekunde niederstes Digit in BCD-Codierung, Bit 3..0: Wochentag
(1:Sonntag, 2: Montag, 3: Dienstag….) DateTimeAI.timezone Inkrement lokale Winterzeit auf UTC in Minuten (aufgrund der Zeitzone) DateTimeAI.dst Inkrement lokale Winterzeit auf lokale Sommerzeit (aufgrund Sommer-
/Winterzeitumschaltung)
Siehe Kapitel 2.5.4.2.3
DateTimeAI.timequality Zeitqualität: 0x00: Unsynchronisiert, noch nie Verbindung zum Server, 0x01: Seit Start mindestens einmal Verbindung zum Server, aktuell jedoch keine Verbindung zum Server, 0x02: Synchronisiert durch Server, 0x03: Synchronisationsstatus des Servers unbekannt.
N
SequenceNo Laufende Nr. des Diagnosesatzes N HeaderLength Länge des Diagnoseheader in Byte (Start bis Datenfeld “OtherTrainModes“) N DataLength Länge der Umfelddaten in Byte (Start von Datenfeld „OccVersionID“ bis Ende
“OccData“). N
VendorID 16-Bit-Kennung, die eine eindeutige Referenz zur Herstellerfirma darstellt. Diese wird von der PNO für jeden Hersteller vergeben. Eine Herstellerfirma braucht diese ID also nur einmal. (Information erfolgt aus GSD)
N
DeviceID Die Device_ID dient der detaillierten Unterscheidung der Geräte-Typen. Sie kann herstellerspezifisch festgelegt werden (Information erfolgt aus GSD)
N
DeviceSerialNo Seriennummer des Gerätes Text NameOfStation Eindeutiger Name des Gerätes. PROFINET Gerätename aus dem Sibas PN
Projektierungstool (SIMATIC Manager). Text
ModulName Name des fehlerhaften Modules. Information erfolgt aus der GSD) Text
ModulSerialNo Seriennummer des Modul (falls vorhanden) Text
Message State Status der Meldung 00h Betriebliche Meldung 01h Erste Abgleichmeldung, weitere folgen 02h Abgleichmeldung, weitere folgen 03h Letzte Abgleichmeldung, es wurden schon Abgleichmeldungen geschrieben 04h Erste und einzige Abgleichmeldung, es folgen keine weiteren Abgleichmeldungen 10h Überlauf Vormeldepuffer, evtl. laufender Abgleich ist beendet.
N
MissingPrecondition 0 = Precondition vorhanden 1 = Precondition nicht vorhanden
N
TrainOperationID Fahrzeug-Nr., z.B. Zuglaufnummer (ICE745) oder betreiberspezifische Festlegung. Text CarNo UIC-ID des Wagens nach UIC 438, ggf. betreiberspezifische Festlegung.
Bei Verwendung der UIC: wichtigste techn. Merkmale (4 Ziffern) Nummer in der Baureihe (3 Ziffern) Prüfziffer (2 Ziffern)
Text
GeneralTrainMode Allgemeiner Zustand des Zuges (Normaler Betrieb, Service, Wartung). Dieser Zustand wirkt auf Berechtigungen, Veränderungen an der Anlage vornehmen zu können (Laden von SW-erlaubt/verboten, Forcen von Signalen erlaubt/verboten). Er gilt übergeordnet für den Zug.
N
TrainMode Betrieblicher Zustand des Zuges. Dies stellt die Hauptzustände des Zuges aus N
TrainSubMode Betriebliche Subzustände des Zuges aus Betreibersicht. N OtherTrainModes Weitere Zustände, die unabhängig vom Betriebszustand Zug aktiv sein können. N Reserved4 Reserved Byte für zukünfige Verwendung und Aufrechterhaltung des Alignments - Reserved2 Reserved Byte für zukünfige Verwendung und Aufrechterhaltung des Alignments - Reserved3 Reserved Byte für zukünfige Verwendung und Aufrechterhaltung des Alignments - OccVersionID Version der Umfeld-Datenstruktur
1. Byte / 2. Byte Major / Minor
N.N
OccDataType Typ der Umfeld-Datenstruktur 0 = Es werden keine Umfelddaten übertragen > 0 = Typ der Umfeldstruktur
N
OccDataLen Länge Umfeld-Datenstruktur in Byte (max. 100) N OccData Gerätespezifische Umfelddaten, Länge siehe OccDataLen X,X,X,X,X,X (X = 1 Byte)
2.6.8.4.14 Beschreibungsdatei Umfelddaten Die Diagnosestruktur aus Kapitel 2.6.8.4.12 enthält Umfelddaten (OccData) mit welchen das Subsystem einem Diagnoseeintrag weitere Informationen anhängen kann. Diese Informationen dienen einer besseren Fehleraufklärung.
Da diese Umfelddaten subsystemspezifisch definiert werden, ist ihr Format und ihre Länge in diesem Dokument nicht spezifiziert, dies erfolgt durch den Subsystemhersteller. Die einzelnen Elemente der Umfelddaten werden im Diagnoseeintrag binär aneinandergereiht.
Datentypen, die größer als ein Byte sind, sind im big endian Format abzulegen.
Es ist dem Subsystem-Lieferanten überlassen ein Alignment der Daten in seinen Strukturen einzuführen. Es wird empfohlen, Daten, die größer als ein Byte sind, an geraden Adressen auszurichten.
Die Definition der Elemente der Umfelddaten und der Meldetexte erfolgt durch den Subsystemhersteller anhand zweier Excel-Dateien.
Die Templates sind von der Siemens AG erhältlich. Die Umsetzung der Excel-Datei in ein maschinenlesbares Format erfolgt durch die Siemens AG.
2.6.8.5 CSV-Datei
Die Werkstattdiagnosemeldungen werden in einer CSV-Datei gemäß Datenstruktur (Kapitel 2.6.8.4.9) abgelegt.
2.6.8.5.1 Einführung In diesem Kapitel wird das Dateiformat für den Export von Diagnosedaten definiert. Die Formatvorgaben müssen eingehalten werden, um die Weiterverarbeitung (z. B. Konvertierung der exportierten Daten in andere Formate) im Rahmen nachgelagerter Verarbeitungsschritte zu ermöglichen.
Zur Strukturierung der Dateien wird ein CSV-Format (Comma Separated Value) eingesetzt, dessen Details in den folgenden Kapiteln definiert wird. Der Einsatz von XML-Dateien wurde aufgrund der daraus resultierenden Dateigröße verworfen (Vorgabe).
2.6.8.5.2 CSV-Format Eine CSV-Datei gliedert sich – wie eine Tabelle – in Zeilen und Spalten. Als Zelle wird dabei ein Eintrag genau einer ausgewählten Zeile und Spalte bezeichnet, d. h. jeder Zelle sind genau eine Zeile und eine Spalte zugeordnet. Nachfolgende Abbildung veranschaulicht die Zusammenhänge:
Abbildung 2-42: Struktur einer CSV-Datei (Zeilen, Spalten, Zellen)
Bei einer (für den Export von Diagnosedaten vorgesehenen) CSV-Datei handelt es sich im Sibas PN System in erster Linie um eine Textdatei, die aus Unicode-Zeichen besteht. Zur Kodierung dieser Zeichen wird UTF-8 eingesetzt, wobei die folgenden beiden Regeln gelten:
• Zur Beschreibung der Struktur bestehend aus Zeilen, Spalten und Zellen kommt lediglich eine Untermenge des in UTF-8 kodierten Zeichenvorrats (Unicode) zum Einsatz, der kompatibel zum ASCII-Zeichensatz ist (dabei handelt es sich um die Unicode-Zeichen U+0000 – U+007F)
• Der Inhalt einer Zelle besteht aus einer Zeichenkette, die UTF-8 kodiert ist. Hierbei kann auf den vollen Unicode-Zeichenvorrat zurückgegriffen werden.
Die Struktur einer CSV-Datei (Zeilen, Spalten und Zellen) wird unter Verwendung der folgenden Regeln definiert:
• Zeilen werden durch einen Zeilenumbruch (im Folgenden mit LF abgekürzt) abgeschlossen.
• Die letzte Zeile einer Datei kann, muss jedoch nicht mit einem Zeilenumbruch abgeschlossen werden.
• Jede Zeile besteht aus einer beliebigen, jedoch pro Datei fixen Anzahl von Zellen. Daraus folgt unmittelbar, dass alle Zeilen einer Datei die gleiche Anzahl von Zellen besitzt.
• Zellen einer Zeile werden durch das Trennzeichen Komma voneinander getrennt.
• Jede Zelle enthält eine beliebige Anzahl von UTF-8 kodierten Zeichen und wird durch das Trennzeichen Komma abgeschlossen. Lediglich am Anfang (vor der ersten Zelle) und am Ende einer Zeile (nach der letzten Zelle) steht kein Trennzeichen
• Beispiel: aaa,bbb,cccLF
• Der Inhalt einzelner Zellen kann in doppelte Anführungszeichen gesetzt werden:
• Beispiel: “aaa“,“bbb“,“ccc“LF
• Jede Zelle muss in doppelte Anführungszeichen ““ gesetzt werden, wenn der Inhalt ein Trennzeichen setzen. Doppelte Anführungszeichen, die Bestandteil des Inhalts einer enthält.
• Jede Zelle, deren Inhalt ein doppeltes Anführungszeichen enthält, ist in doppelte Anführungszeichen zu Zelle sind, müssen verdoppelt werden (Escape-Sequenz). Damit wird angezeigt, dass es sich nicht um das Ende einer Zeichenkette einer Zelle handelt.
• Beispiel: aaa,“b““bb“,cccLF“d“,“e“,“f
• Jede Zelle, deren Inhalt einen Zeilenumbruch enthält, ist in doppelte Anführungszeichen zu setzen.
• Beispiel: aaa,“bLFBb“,cccLF“d“,“e“,“f
Die Struktur der CSV-Dateien (Formalisierung der in natürlicher Sprache verfassten Regeln, s.o.) wird durch nachfolgende EBNF-Grammatik definiert, wobei die in <VERWEIS3> standardisierte Notation eingesetzt wird. Gültige Terminalsymbole sind UTF-8 kodierte Zeichen in der Standardschreibweise (z. B. U+0022 für das doppelte Anführungszeichen “):
UTFCHARACTER_NO_DQOUTE bezeichnet ein UTF-8 kodiertes Unicode-Zeichen mit Ausnahme des doppelten Anführungszeichens (dieses ist unter Umständen zu verdoppeln, siehe dazu auch Aufgliederung der Regeln in ESCAPED und UNESCAPED). Hinweis: Leerzeichen (sogenannte white spaces) sind grundsätzlich Bestandteil einer Zelle (FIELD in der Grammatik). Hinweis: Dieses Format ist verbindlich, andere CSV-Formate (Derivate) werden nicht unterstützt.
3.1 PROFINET-Konformität Für IO-Devices ist in einem PNO-Prüflabor die PROFINET-Konformität festzustellen und eine Device-Ident-Nummer zu beantragen. Bei erfolgreicher Durchführung kann ein Prüfzertifikat beantragt werden.
Kunde entwickelt ein Feldgerät und erstellt eine GSD-Datei
Kunde beantragt bei der PNO eineHerstellerkennung
Test des Feldgerätes
Test erfolgreich?Testbericht
Kunde kann bei derPNO ein Zertifikat
beantragen
Test nichterfolgreich
Kunde meldet sich bei einemPrüflabor zum Test an.
Abbildung 3-1: PNO-Zertifizierung für ein PROFINET IO-Device
Für weitere Informationen zu PNO und zu Prüflaboren, siehe
4.1 Testplattform Zur Inbetriebnahme und zum Test eines Subsystems mit PROFINET-Anschaltung (z.B. PN PC/104) kann als Gegenstation eine Simatic S7 Baugruppe genutzt werden. Mit dieser Simatic S7 Baugruppe kann ein IO-Controller realisiert werden, der mit einem IO-Device (Subsystem) kommuniziert.
Damit kann eine PROFINET Verbindung zum Test-PC (Windows XP) aufgebaut werden und die GSDML des Steuergerätes (IO-Device) getestet werden.
PN PC/04
PC Plattform
Engineeringstation
Abbildung 4-1: Testaufbau mit Simatic S7 und IO-Device mit PN PC/104
Zusammen mit der Simatic S7 ist die benötigte Software und Dokumentation verfügbar.
Weitere Informationen hierzu erhalten Sie über:
http://www.siemens-edm.de/pn_pc104.0.html
Siemens AG I IS MS EDM Mail: [email protected] Frauenauracher Str. 98 91056 Erlangen
SIEMENS I IA http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&caller=view&lang=de&siteid=csius&aktprim=0&extranet=standard&objid=18881571&DataKey=18881571&treeLang=de
PROFINET Technologie-komponenten
PN IO Open Source Device Stack (für NETARM)
SIEMENS I IA http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&nodeID0=10805868&foldersopen0=%2D1062%2D&lang=de&siteid=csius&aktprim=0&extranet=standard&objid=18977512&DataKey=18977512&basisview=4000002&viewLevel=5&wttree=cs&treeLang=de
