AP1: Anforderungen und Referenzanwendungen
14.10.2013 Seite 1 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
it´s OWL – Intelligente Technische Systeme OstWestfalenLippe
CQP 3 – Intelligente Vernetzung (itsowl-IV)
AP 1 – ANFORDERUNGEN UND REFERENZANWENDUNGEN
AP1.1/AP1.2 – Anforderungsspezifikation
Referenz: itsowl-IV/WP1/AP1.1/1.0
Kategorie: Dokument
Verantwortlich: inIT
Autoren: H. Trsek, U. Mönks, L. Dürkop (inIT)
J. Ax, C. Wördehoff (CITEC-KS)
U. Pohlmann (IPT-EM)
Abgabedatum: M6
Datum: 14.10.2013
Projektstart: 01.07.2012
Projektdauer: 60 Monate
Status: Final
Verfügbarkeit: itsowl Spitzencluster
14.10.2013 Seite 2 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Executive Summary
Dieses Dokument ist das Ergebnis der im Rahmen des AP 1 “Anforderungen und Referenzanwendungen” im Querschnittsprojekt “Intelligente Vernetzung” (QP IV) durchgeführten Anforderungsanalyse, die zur Ermittlung von Referenzanwendungen und der funktionalen und nicht-funktionalen Anforderungen an die intelligente Vernetzung von Intelligenten Technischen Systemen diente. Die Architektur und die funktionalen Spezifikationen der weiteren Arbeitspakete AP 2, AP 3, AP 4 und AP 5 des QP IV basieren weitestgehend auf den Ergebnissen der Anforderungsanalyse. Die Anforderungsspezifikation bildet in den weiteren Arbeitspaketen die Grundlage, an der die Forschungsarbeiten kontinuierlich ausgerichtet und durchgeführt werden. Durch dieses Vorgehen wird unter anderem beabsichtigt, dass die im QP IV erzielten Forschungsergebnisse die für die Innovationsprojekte relevanten Forschungsfragestellungen adressieren.
Diese erste Iteration hat das Ziel, die zentralen Bestandteile und kritischen Aspekte der intelligenten Vernetzung aus Sicht der Clusterpartner zu erfassen und zu dokumentieren. Im Rahmen der Analyse konnten die vier nachfolgend aufgeführten wesentlichen Referenzanwendungsfälle definiert werden:
Selbstkonfiguration der Kommunikation
Verteilte Steuerung von autonomen Fahrzeugen
Signalselbstbeschreibung und die Konfiguration eines Sensor- und Informa-tionsfusionssystems
Multistandard Echtzeit Ethernet Knoten
Die Referenzanwendungsfälle werden zur Ableitung der Anforderungen an die intelligente Vernetzung herangezogen und werden in Kapitel 2 detailliert beschrieben. Die Definition der Referenzanwendungen dient zusätzlich zur Kategorisierung der identifizierten Bedarfe der Innovationsprojekte und zur Priorisierung der Anforderungen. Außerdem werden die Referenzanwendungsfälle zur Festlegung der Validierungsszenarien und entsprechender Leistungsindikatoren für das AP 5 genutzt.
Die aus den Anwendungen abgeleiteten Anforderungen sind in allgemeine und spezifische Anforderungen aufgeteilt. Die Klassifizierung der spezifischen Anforderungen ist nach der jeweiligen architekturellen Zugehörigkeit vorgenommen, d.h. Konnektivität, Middleware, Anwendungen und Sensor- und Informationsfusion. Die Anforderungen werden in Kapitel 3 aufgeführt.
Dieses Dokument wird im weiteren Verlauf des Projekts fortlaufend aktualisiert, sodass neue Anforderungen erfasst werden können, die durch die Kooperation mit den laufenden IPs bzw. durch neu gestartete IPs und Transferprojekte entstehen.
14.10.2013 Seite 3 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Änderungsnachweis
Versionen
Version Status Datum Autor(en)
0.1 Entwurf 02.11.2012 H. Trsek, U. Mönks
0.2 Entwurf 11.07.2013 L. Dürkop, U. Mönks
0.3 Entwurf 02.08.2013 J. Ax, C. Wördehoff
0.31 Entwurf 02.08.2013 U. Pohlmann
0.32 Entwurf 07.08.2013 U. Mönks
0.4 Entwurf 02.09.2013 U. Mönks
0.5 Entwurf 04.09.2013 H. Trsek
0.6 Entwurf 30.09.2013 J. Ax, L. Dürkop, U. Mönks, H. Trsek
1.0 Final 14.10.2013 H. Trsek
14.10.2013 Seite 4 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Änderungen
Version Kapitel Zusammenfassung der Änderungen
0.1 Erste Gliederung und Struktur der Anforderungen
Dokumentstruktur
0.2 Anforderungsanalyse Referenzanwendungen “Selbstkonfiguration eines zentral gesteuerten Automatisierungs-prozesses“ und „Signalselbstbeschreibung und Selbstkonfiguration der Fusion“ hinzugefügt. Anforderungen hinzugefügt.
0.3 Referenzanwendungen Beschreibung der Referenzanwendung „Intelligenter Multistandard RTE Knoten“ hinzugefügt.
0.31 Referenzanwendungen Beschreibung der Referenzanwendung „Entwicklung eines verteilt gesteuerten Automatisierungsprozesses mit autonomen Fahrzeugen“ hinzugefügt
0.32 Anforderungen Kleinere Verbesserungen, Kommentare
Abschnitt „Sensorik“ auf Grund des Inhalts in „Sensor- und Informationsfusion“ umbenannt
0.4 Referenzanwendungen und Anforderungen
Anwendungsfall "Signalselbstbeschreibung und Selbstkonfiguration der Fusion" weiter detailliert, Anforderungen abgeleitet
0.5 Alle Kapitelstruktur geändert, Executive summary und Einleitung hinzugefügt, editiorielle Änderungen
0.6 Alle Review Kommentare integriert
1.0 Alle Finale Version
14.10.2013 Seite 5 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Inhaltsverzeichnis
1 Einleitung.................................................................................................. 8
1.1 Aufgaben des AP 1 ...................................................................................... 8
1.2 Gesamtprozess der Anforderungsanalyse und Struktur des Dokuments ...... 8
2 Referenzanwendungen .......................................................................... 10
2.1 Selbstkonfiguration eines zentral gesteuerten Automatisierungsprozesses 10
2.2 Entwicklung eines verteilt gesteuerten Automatisierungsprozesses mit autonomen Fahrzeugen ....................................................................................... 13
2.3 Signalselbstbeschreibung und Selbstkonfiguration der Fusion ................... 14
2.4 Intelligenter Multistandard Real-time Ethernet Knoten ................................ 15
3 Anforderungen ....................................................................................... 17
3.1 Allgemeine Anforderungen ......................................................................... 20
3.2 Spezifische Anforderungen......................................................................... 22 3.2.1 Anforderungen: Konnektivität .......................................................................... 22 3.2.2 Anforderungen: Middleware ............................................................................ 24 3.2.3 Anforderungen: Anwendung ........................................................................... 25 3.2.4 Anforderungen: Sensor- und Informationsfusion ............................................. 27
4 Zusammenfassung und nächste Schritte ............................................ 30
Anhang A – Liste der allgemeinen Anforderungen ................................... 31
Anhang B – Liste der spezifischen Anforderungen .................................. 32
Anhang C – Strukturierter Leitfaden für die IP Interviews ....................... 34
Literaturverzeichnis ..................................................................................... 37
14.10.2013 Seite 6 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Abbildungsverzeichnis
Abbildung 1: Gesamtprozess der itsowl-IV Anforderungsanalyse .............................. 8
Abbildung 2: Schematischer Aufbau einer Automatisierungsanlage ........................ 10
Abbildung 3: Schichtmodell ..................................................................................... 11
Abbildung 4: Erweiterter Profinet IO-Controller als selbstkonfigurationsfähige SPS. 12
Abbildung 5: Real time Autokonfiguration ................................................................ 13
Abbildung 7: Logische Softwarestruktur mit Koordinationsprotokoll ......................... 14
Abbildung 8: Mehrschichtfusionsmodell mit beispielhaften Fusionsalgorithmen auf Attributs- (µBalTLCS) und Systemebene. ................................................................ 15
Abbildung 9: Systemarchitektur des rekonfigurierbaren RTE-Moduls ...................... 16
14.10.2013 Seite 7 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Tabellenverzeichnis
Tabelle 1: Vorlage für die itsowl-IV Anforderungen .................................................. 17
Tabelle 2: Mögliche IDs für allgemeine und spezifische Anforderungen .................. 17
Tabelle 3: Verschiedene Kategorien ........................................................................ 19
Tabelle 4: Allgemeine Anforderungen ..................................................................... 31
Tabelle 5: Anforderungen an die Middleware .......................................................... 32
Tabelle 6: Anforderungen an die Konnektivität ........................................................ 32
Tabelle 7: Anwendungsanforderungen .................................................................... 32
Tabelle 8: Anforderungen an die SEFU/IFU ............................................................ 33
14.10.2013 Seite 8 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
1 Einleitung
1.1 Aufgaben des AP 1
Das Arbeitspaket 1 “Anforderungen und Referenzanwendungen” ermittelt
Anforderungen an die intelligente Vernetzung, insbesondere hinsichtlich der Projektziele der Innovationsprojekte. Diese bilden in den folgenden Arbeitspaketen (AP) die Grundlage, an der die Forschungsarbeiten ausgerichtet und durchgeführt werden. Dadurch ist sichergestellt, dass die erzielten Forschungsergebnisse Anwendung in den Innovationsprojekten finden. Die in AP 5 realisierte Evaluationsumgebung wird für ausgewählte relevante Anwendungsfälle entworfen, die in diesem Arbeitspaket ebenfalls festgelegt werden.
1.2 Gesamtprozess der Anforderungsanalyse und Struktur des Dokuments
Als Querschnittsprojekt soll itsowl-IV den anderen Projektpartnern Technologieplattformen für die intelligente Vernetzung zur Verfügung stellen. Um dieses Ziel zu verwirklichen, werden strukturierte Interviews mit den Innovationsprojekten mit Bezug zur intelligenten Vernetzung durchgeführt, um herauszuarbeiten, welches Verständnis diese vom Begriff „intelligente Vernetzung“ haben und welche Anforderungen sie an dessen Realisierung stellen. Basierend auf diesen Interviews werden Referenzanwendungen in diesem Dokument beschrieben, die möglichst viele Einsatzfälle bei den Projektpartnern abdecken sollen und von denen die in Kapitel 3 beschriebenen definierten Anforderungen abgeleitet sind.
Der Gesamtprozess für die Anforderungsanalyse wird in Abbildung 1 dargestellt [4]. Er umfasst im Wesentlichen die drei Aspekte Erfassung, Analyse und Anforderungsmanagement.
Abbildung 1: Gesamtprozess der itsowl-IV Anforderungsanalyse
Während der Erfassung werden zunächst mögliche Stakeholder identifiziert, welche in unserem Fall die relevanten Innovationsprojekte (IPs) sind. Im Anschluss daran wurde der im „Anhang C – Strukturierter Leitfaden für die IP Interviews“ dokumentierte Leitfaden für die IP Interviews konzipiert und die Interviews durchgeführt. Darüber hinaus wird das bereits im Konsortium vorhandene Expertenwissen aufgenommen und dokumentiert. In der Analyse Phase werden unter Verwendung der Interviewergebnisse repräsentative Anwendungsfälle
14.10.2013 Seite 9 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
beschrieben (siehe Kapitel 2), die zur Ableitung der in Kapitel 3 strukturiert beschriebenen Anforderungen herangezogen werden. Im weiteren Verlauf des Projektes wird eine kontinuierliche Überprüfung, Anpassung und ggf. Änderung der Anforderungen erfolgen, welche sich zusammenfassend als Anforderungsmanagement beschreiben lässt.
Die Anforderungsanalyse stellt die Grundlage für die Referenzarchitektur des QP „Intelligente Vernetzung“ dar, die in AP 2 und AP 3 erarbeitet wird. Dieses Dokument wird im Laufe des Projektes in weiteren Versionen erscheinen. Hierbei werden neue Anforderungen ergänzt und die Referenzanwendungen verfeinert.
14.10.2013 Seite 10 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
2 Referenzanwendungen
In dem Querschnittsprojekt „Intelligente Vernetzung“ sollen Methoden entwickelt werden, die die Selbstkonfiguration von Intelligenten Technischen Systemen auf den Ebenen Anwendung, Middleware und Konnektivität ermöglichen. Im Arbeitspaket „Festlegung von Anwendungsfällen“ sollen relevante Anwendungsfälle und -szenarien, die eine Rekonfiguration und Selbstbeschreibungsfähigkeit der Vernetzung sowie den Einsatz von Sensor- und Informationsfusion erfordern, erarbeitet werden. Im weiteren Projektverlauf werden diese außerdem zur Spezifikation der Evaluationsumgebung in AP 5 herangezogen. Die in diesem Kapitel beschriebenen Referenzanwendungen dienen zur Ableitung der Anforderungen, die in Kapitel 3 ausgeführt werden.
2.1 Selbstkonfiguration eines zentral gesteuerten Automatisierungsprozesses
Im Folgenden wird ein Anwendungsfall beschrieben, der aufzeigt, wie eine Selbstkonfiguration am Beispiel eines Steuerungsprozesses aus der industriellen Automatisierungstechnik aussieht. Der schematische Aufbau ist in Abbildung 2 dargestellt.
Steuerungsprogramm(IEC 61131)
Kommunikations-schnittstelle
SPS
Kommunikations-schnittstelle
Sensoren/Aktoren,IOs, ...
Kommunikations-schnittstelle
Sensoren/Aktoren,IOs, ...
Kommunikations-schnittstelle
Sensoren/Aktoren,IOs, ...
Feldgeräte
Netzwerktechnologie
Abbildung 2: Schematischer Aufbau einer Automatisierungsanlage
In diesem Szenario gibt es pro Fertigungszelle eine zentrale Steuerung. Dies ist typischerweise eine speicherprogrammierbare Steuerung (SPS), die ein Steuerungsprogramm gemäß IEC 61131 enthält. Die Ansteuerung von Sensoren und Aktoren wird durch die Feldgeräte vorgenommen. Zwischen den Feldgeräten und der zentralen Steuerung müssen z.B. Messwerte und Statusinformation (Prozessdaten) über eine bestimmte Netzwerktechnologie ausgetauscht werden. Diese Technologie basiert zunehmend auf Echtzeit-Ethernet Systemen (realtime Ethernet, RTE), die den bestehenden Ethernet-Standard um Methoden zur Einhaltung von Echtzeit-Anforderungen erweitern. Standard-Ethernet und RTEs sind insofern kompatibel, dass beide gleichzeitig über dieselbe Kommunikationsinfrastruktur betrieben werden können. Alle Protokolle, die über Standard-Ethernet betrieben werden können wie TCP/IP, können ohne weiteres auch in einem RTE eingesetzt werden. Dies führt zu einer Vereinfachung der Kommunikation zwischen dem Bereich der Automatisierungstechnik und der restlichen IT-Welt, in welcher die Ethernet-Kommunikation bereits etabliert ist.
14.10.2013 Seite 11 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Die Inbetriebnahme eines solchen Systems erfordert mehrere manuelle Konfigurationsschritte, die in der Regel in einem Werkzeug des SPS-Herstellers durchgeführt werden:
1. Das eigentliche Steuerungsprogramm muss erstellt werden. Daten, die mit den Feldgeräten ausgetauscht werden, werden dabei als Variablen deklariert.
2. Alle im Prozess vorhandenen Feldgeräte müssen dem Werkzeug bekanntgemacht werden. Dazu wählt der Nutzer die entsprechenden Feldgeräte aus einer Gerätebibliothek aus und fügt sie dem Werkzeug hinzu. Weiterhin müssen für jedes Feldgerät je nach verwendeter Netzwerktechnologie spezifische Einstellungen durchgeführt werden.
3. Der Nutzer teilt dem Werkzeug mit, welche Variablen des Steuerungsprogrammes auf die Ein- und Ausgänge der Feldgeräte abgebildet werden.
Diese Konfigurationsschritte sollen durch die im Projekt it’s OWL IV zu entwickelnden Methoden zur Selbstkonfiguration vereinfacht werden. Zur Einordnung der erforderlichen Schritte wird das im itsowl-IV Rahmenplan [1] beschriebene 3-Schicht-Modell angewendet (siehe Abbildung 3).
Anwendung
Steuerungsprogramm – definiert die auszutauschenden Informationen
Schichten
Middleware
Automatische Variablen-Zuordnung Konfiguration der Konnektivität
Konnektivität
Stellt die physikalischen Methoden zum Datenaustausch bereit
Abbildung 3: Schichtmodell
Das eigentliche Steuerungsprogramm ist in der Anwendungsschicht anzusiedeln. Eine geeignete Middleware soll ein automatisches Mapping der Steuerungsvariablen auf die entsprechenden Feldgeräte durchführen. Dies führt zu drei wesentlichen Anforderungen:
Auf der Anwendungsschicht muss ein geeigneter Formalismus entwickelt werden, der es erlaubt, die Variablen des Steuerungsprogrammes semantisch zu beschreiben. Die Semantik soll die Bedeutung Variablen der Variablen näher beschreiben. Ein einfach Beispiel wäre: Bei Variable A handelt es sich um einen Temperaturwert.
Dazu kompatibel müssen die Ein- und Ausgänge der Feldgeräte ebenfalls semantisch beschrieben werden.
Die Middleware stellt auf Basis dieser Beschreibungen die Verbindungen zwischen den Variablen der Anwendungsschicht und den Feldgeräten her.
14.10.2013 Seite 12 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Sind die Variablen-Zuordnungen getroffen, müssen die Daten über die Konnektivitäts-Schicht transportiert werden. Die Konfiguration dieser Schicht soll durch die Middleware ebenfalls automatisch erfolgen. Die dazu notwendigen Schritte sind abhängig von der verwendeten Netzwerk-Technologie. Für das RTE Profinet IO wurden bereits erste Methoden zur Selbstkonfiguration entwickelt [5]. Wie eine konkrete Realisierung eines sich selbst konfigurierenden Gerätes auf Profinet-Basis aussehen könnte, zeigt Abbildung 4.
IO-Controller (PC basierend)
Ethernet
IO-Controller Stack
Mapping Service
IEC 61131 Steuerung
Profinet Autokonfiguration
Abbildung 4: Erweiterter Profinet IO-Controller als selbstkonfigurationsfähige SPS
In Profinet werden die am Datenaustausch beteiligten Geräte als IO-Controller und IO-Devices bezeichnet. Der IO-Controller übernimmt dabei die Rolle der SPS und die IO-Devices die der Feldgeräte. Das Steuerungsprogramm läuft hier auf dem IO-Controller, der um einige Komponenten zur Selbstkonfiguration erweitert wurde (Mapping Service, Profinet Autokonfiguration). Der Mapping Service empfängt die semantischen Beschreibungen der Feldgeräte und stellt die Verbindung der Feldgerätdaten zu den Steuerungsvariablen her. Die automatische Inbetriebnahme des Profinet-Netzwerkes wird durch die Komponente „Profinet Autokonfiguration“ durchgeführt. Der Ablauf dieser Autokonfiguration ist in Abbildung 5 dargestellt. Wenn ein IO-Device an das Netzwerk angeschlossen wird, benötigt es in Phase 1 zuerst IP-Konnektivität. Dies kann durch Verfahren wie DHCP1 erreicht werden. Anschließend muss der IO-Controller das neue Device erkennen, dies passiert in Phase 2. Technisch kann diese durch Implementierung von service-orientierten Architekturen (SOA) wie DPWS2 oder OPC UA3 realisiert werden. In Phase 3 erhält der Controller ebenfalls über die eingesetzte SOA-Lösung eine Gerätebeschreibungsdatei. In dieser Datei sind alle Profinet-spezifischen Eigenschaften des IO-Devices gespeichert. Anhand dieser Dateien kann das Autokonfigurations-Modul des IO-Controllers anschließend das Profinet-Netzwerk konfigurieren und der Prozessdatenaustausch starten.
1 Dynamic Host Configuration Protocol, http://www.ietf.org/rfc/rfc2131.txt
2 Devices Profile for Web Services, http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01
3 OPC Unified Architecture, http://www.opcfoundation.org/UA/
14.10.2013 Seite 13 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
IO-DeviceIP-Zuweisungsdienst
IO-Device verbunden
Fragt IP-Adress an
Weist IP-Adresse zu
IO-Controller setzt Parameter der IO-Devices und konfiguriert das RTE
Erkennung neuer Geräte
IO-Controller analysiert Geräte-beschreibungsdatei
IO-Controller
1
2
4
GBD Server
IO-Controller erhält Gerätebeschreibungsdatei 3
Phasen
Abbildung 5: Real time Autokonfiguration
2.2 Entwicklung eines verteilt gesteuerten Automatisierungsprozesses mit autonomen Fahrzeugen
Im Folgenden wird ein Anwendungsfall beschrieben, der aufzeigt, wie eine Vernetzung eines Intelligenten Technischen Systems am Beispiel eines Steuerungsprozesses aus der industriellen Automatisierungstechnik aussehen könnte. Im zugrunde liegenden Szenario werden Waren durch autonome Transporteinheiten zu den jeweiligen Stationen befördert. Sie bewegen sich auf gekennzeichneten Wegen. Es soll möglich sein, dynamisch Transporteinheiten und Stationen hinzuzufügen und zu entfernen, um so möglichst ressourcensparend zu arbeiten. So können Transporteinheiten für Ladevorgänge und Wartungen autonom aus dem Netzwerk austreten und für den Einsatz wieder eintreten. Das Ziel ist es, dass Stationen und Transporteinheiten autonom interagieren und miteinander kommunizieren. Eine zentrale Steuerung wird aus Gründen von Flexibilität, Erweiterbarkeit und Robustheit nicht verwendet. Es wird das in Abbildung 3 dargestellte Schichtenmodell verwendet.
In dem System gibt es pro Systemeinheit (Anlage, Transporteinheit) eine Steuerung. Diese Steuerungen sind miteinander vernetzt und können durch Koordinationsprotokolle nachrichtenbasiert miteinander kommunizieren (siehe Abbildung 6). Zum Beispiel kann eine Anlage eine Transporteinheit anfordern, wenn sie ihre eine Ware benötigt oder wenn sie eine Ware fertig bearbeitet hat.
14.10.2013 Seite 14 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Station Transporter
Transportation
_Request
Abbildung 6: Logische Softwarestruktur mit Koordinationsprotokoll
Wenn eine neue Systemeinheit hinzugefügt wird, muss sich die Software rekonfigurieren. Hierbei muss zum Beispiel eine neue Verbindung zur hinzugefügten Systemeinheit hergestellt werden. Wenn dies auf Konnektivitätsebene durchgeführt wurde, soll die Middleware diese Information an die Anwendung weiterleiten. Daraufhin soll die Schnittstelle zur neuen Komponente und das Verhalten des zu verwendenden Koordinationsprotokolls instanziiert werden. Die Kommunikation muss trotz Rekonfiguration weiter bestimmte Eigenschaften wie zum Beispiel Deadlock-Freiheit aufweisen. Das Routing und die benötigten Echtzeiteigenschaften des Netzwerks sollte durch die Middleware sichergestellt werden.
2.3 Signalselbstbeschreibung und Selbstkonfiguration der Fusion
Bei Anwendungen, in denen eine Diagnose notwendig ist (bspw. Selbstdiagnose eines Intelligenten Technischen Systems oder Condition Monitoring einer Produktionsanlage), müssen Informationen, die aus Signalen möglicherweise unterschiedlichster Art und Herkunft gewonnen werden, zusammengeführt (fusioniert) und ausgewertet werden. Eine Möglichkeit die Informationsfusion auszuführen, ist in Abbildung 7 dargestellt. Dieses Fusionsmodell ist dabei in der Lage, Signalquellen unterschiedlichster Art einzubeziehen und zu verarbeiten, Konflikte zwischen ihnen zu berücksichtigen und die physikalische Struktur des überwachten Systems durch die Aufteilung auf mehrere Schichten abzubilden. So werden Teilkomponenten des Systems (bspw. verschiedene Module eines Produktionssystems) oder Prozessschritte mit Hilfe von Attributen modelliert. Zur Einschätzung des Gesamtsystemzustands werden die den Attributen zugeordneten Überwachungsergebnisse auf der über den Attributen liegenden Fusionsschicht zusammengeführt.
Bei Anwendung dieses Fusionsmodells ist es notwendig, dass die verwendeten Attribute bei Veränderungen des überwachten Systems angepasst werden. So werden bspw. Signalquellen beim Entfernen eines Moduls aus einem überwachten Prozess zwangsläufig ebenfalls entfernt. Die fehlenden Signale führen bei Nichtberücksichtigung dieser Änderung dazu, dass der Zustand des überwachten Prozesses falsch eingeschätzt wird, da Signale aus der nun fehlenden Quelle erwartet werden, aber nicht erfasst werden können. Alle mit diesen fehlenden Signalquellen ausgestatteten Attribute sind hiervon betroffen.
14.10.2013 Seite 15 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Abbildung 7: Mehrschichtfusionsmodell mit beispielhaften Fusionsalgorithmen auf Attributs- (µBalTLCS) und Systemebene.
Abhilfe schafft hier die Überwachung der Signalquellen auf Vorhandensein und Lieferung plausibler Signale. Bei Entfernen einer Signalquelle wird dies registriert und das Signal bei den betroffenen Attributen entfernt. Ist eine Signalquelle vorhanden, liefert aber unplausible Signale, wird dies ebenfalls detektiert. Infolge dessen erfolgt eine weitere Verarbeitung, wie bspw. durch Meldung, Alarmierung oder Entfernen der Signalquelle. Die Ausprägung der weiteren Verarbeitung ist dabei applikationsspezifisch.
Auch im Fall der Erweiterung des überwachten Systems muss automatisch reagiert werden, um Fehleinschätzungen des Systemzustands zu vermeiden. Mit der Erweiterung hinzukommende Signalquellen müssen dem Fusionssystem mitteilen, woher ihre gelieferten Signale stammen und wie sie zu interpretieren sind. Hierüber wird das Fusionssystem in die Lage versetzt, die bestehenden Attribute mit den neu hinzugekommenen Signalen zu erweitern bzw. neue Attribute selbständig zu bilden. Dabei sind der genaue Ablauf dieser Erweiterungen des Fusionssystems sowie die ausgetauschten Daten und deren Interpretation zu definieren.
2.4 Intelligenter Multistandard Real-time Ethernet Knoten
In modernen industriellen Automatisierungsanlagen kommunizieren die verschiedenen Komponenten mit Hilfe von echtzeitfähigen Bus- oder Netzwerksystemen. Durch die große Anzahl von Herstellern dieser Komponenten, haben sich viele verschiedene Netzwerkstandards etabliert, die auf unterschiedliche Anforderungen des Informationsaustauschs optimiert sind. Das Ziel dieser Referenzanwendung besteht in der Entwicklung intelligenter Automatisierungs-komponenten, die für unterschiedliche Netzwerkstandards einsetzbar sind und bei Bedarf selbstständig das eigene Verhalten durch Rekonfiguration von Hard- und Software ändern. Dieser sog. intelligente Multistandard RTE (Real Time Ethernet) Knoten, soll in unterschiedlichen RTE Netzwerken betrieben werden können.
Abbildung 8 zeigt die Systemarchitektur des intelligenten Multistandard RTE Knotens, bestehend aus einem statischen Bereich (grün) und einem rekonfigurierbaren Bereich (blau).
Der statische Bereich des Knotens besteht aus einem Applikationskern, der die spezielle Anwendung der Komponente beinhaltet, und dem Rekonfigurations-Manager. Im dynamisch rekonfigurierbaren Bereich des Systems befindet sich der
14.10.2013 Seite 16 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
entsprechende Kommunikationskern (RTE Standard). Dieser partiell rekonfigurierbare Bereich ermöglicht ein dynamisches Austauschen von RTE Standards unter Einsparung von Logikressourcen (Reduzierung der Logikeinheiten durch Zeitmultiplexen).
Die Systemarchitektur soll eine automatische Konfiguration ermöglichen, sodass der manuelle Konfigurationsaufwand zum Hinzufügen, Entfernen oder Ändern von Geräten möglichst gering gehalten werden kann. Dies reduziert Zeit und Kosten bei der Inbetriebnahme von Anlagen. Als weiterer Vorteil des rekonfigurierbaren Systems ist die Verlängerung des Lebenszyklus einer Produktreihe zu nennen. So soll durch Soft- und Hardwareupdates (Rekonfiguration) auf Protokollerweiterungen reagiert werden.
Abbildung 8: Systemarchitektur des rekonfigurierbaren RTE-Moduls
Der rekonfigurierbare Bereich kann beispielsweise durch ein Field Programmable Gate Array (FPGA) oder ein Real-time Multi Processor System on Chip (RT-MPSoC) realisiert werden.
100 Mbit/s
(Fast-Ethernet)
100BASE TX/FX
Port 1
(RJ45)
Port 2
(RJ45)
PHY
Port n
(RJ45)
MII Schnittstellen
Anwendungs Schnittstelle
Hardware
CPU
Rekonfigu-
rations
Manager
Echtzeit
Ethernet
Kanal 1
Applikationskern
Echtzeit
Ethernet
Kanal N
Kommunikationskern
14.10.2013 Seite 17 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
3 Anforderungen
Die in Tabelle 1 gezeigte Vorlage wird in itsowl-IV verwendet, um alle identifizierten Anforderungen zu erfassen. Eine detaillierte Beschreibung der einzelnen Felder erfolgt im Anschluss an die Vorlage.
Tabelle 1: Vorlage für die itsowl-IV Anforderungen
Anforderung
Beschreibung
Zielsetzung
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
Datum Historie Referenz
Anforderung
Aussagekräftiger Titel der Anforderung
Beschreibung
Detaillierte Beschreibung der Anforderung, die dennoch kurz und prägnant sein sollte
Zielsetzung
Beschreibt einerseits das die Anforderung verursachende Problem und kann andererseits bei den spezifischen Anforderungen genutzt werden, um existierende Abhängigkeiten zu allgemeinen Anforderungen zu beschreiben.
Abnahmekriterium
Dieses Feld beschreibt eine Metrik oder eine Bedingung, die zur späteren Überprüfung der Anforderung dient. In dem Feld kann außerdem eine erforderliche Testprozedur erläutert werden.
ID
Eindeutige Identifizierung der Anforderung, die aus zwei Teilen besteht. Mögliche IDs sind in Tabelle 2 aufgeführt. Der erste Teil besteht aus einem Buchstaben für die allgemeinen Anforderungen (R) und aus ein bis zwei weiteren Buchstaben für die spezifischen Anforderungen. Der erste Buchstabe ist hierbei immer ein „R“ für Requirement. Die beiden nächsten Buchstaben repräsentieren die spezifische
Funktionalität des Systems, für die die Anforderung aufgestellt wurde. Der zweite Teil besteht aus einer fortlaufenden Nummerierung beginnend mit 01. Beide Teile werden mit einem Punkt voneinander getrennt.
Tabelle 2: Mögliche IDs für allgemeine und spezifische Anforderungen
14.10.2013 Seite 18 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Allgemeine Anforderungen
ID Funktionalität
R.xx Allgemeine Anforderung Spezifische Anforderungen
ID Funktionalität
RA.xx Anwendung
RM.xx Middleware
RN.xx Netzwerk
RSI.xx Sensor- und Informationsfusion
RS.xx Sensorik
Typ
Der Anforderungstyp kann entweder funktional oder nicht-funktional sein. Funktionale Anforderungen beinhalten präzise Verhaltensaussagen (“das itsowl-IV System soll …
tun.”), d.h. was das System tun soll. Sie definieren extern zu beobachtende Funktionalitäten und Dienste des Systems. Nicht-funktionale Anforderungen legen
die qualitativen Eigenschaften des Systems fest und beinhalten häufig Randbedingungen für die funktionalen Anforderungen. Die nicht-funktionalen Anforderungen können nach [3] wie folgt beschrieben werden:
- Größe/Skalierbarkeit
o RAM Mbytes
o Anzahl ROM chips
- Nutzbarkeit
o Bedienbarkeit
o …
- Portabilität
o Austauschbarkeit
o Anpassungsfähigkeit
- Leistung
o Geschwindigkeit
o Antwortzeiten
- Zuverlässigkeit
o Verfügbarkeit (Mean time to failure - MTTF)
o Fehlerhäufigkeit
- Sicherheit
o Daten
o Funktional
Quelle
Die Quelle gibt den Ursprung der Anforderung an. Dies kann beispielsweise ein intern identifizierter Anwendungsfall (itsowl-IV) sein oder ein Interview mit einem der
14.10.2013 Seite 19 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
IPs sein. Der Eintrag muss die Herkunft der Anforderungen beschreiben, z.B. Interview mit IP Wago. Priorität
Dieses Feld enthält eine Aussage, ob die Anforderung kritisch für itsowl-IV ist (höchste), weniger kritisch (hoch) oder nur eine wünschenswerte zusätzliche Eigenschaft des itsowl-IV-Systems bietet (normal). Die verschiedenen Prioritäten
können während des Projekts angepasst werden. Kategorie
Die Liste möglicher Anforderungskategorien und eine kurze Beschreibung der Kategorie ist in Tabelle 3 definiert. Die Liste kann und sollte bei Bedarf erweitert werden.
Tabelle 3: Verschiedene Kategorien
Kategorie Kurzform Beschreibung
Selbstkonfiguration SK Anforderung aus dem Bereich Selbstkonfiguration
Selbstdiagnose SD Anforderung aus dem Bereich Selbstdiagnose
Generisch GE Generische Anforderung an itsowl-IV
Security SE Anforderung an die Datensicherheit
Safety SA Anforderung an die funktionale Sicherheit
Engineering EN Anforderung zur Interaktion mit Engineering Werkzeugen und Prozessen
Datum Monat und Jahr in dem die Anforderung erstmalig erfasst wurde, Format: MM/JJJJ (z.B.: 10/2012) Historie Änderungshistorie aller wesentlichen Änderungen und Anpassungen der Anforderung inkl. der Gründe für die Änderung. Für aufeinanderfolgende Änderungen müssen verschiedene Zeilen verwendet werden und das Änderungsdatum muss vorangestellt werden. Referenz
In diesem Feld werden die Referenzen, falls vorhanden, zu bereits bestehenden Anforderungen (allgemein oder speziell) aufgeführt.
14.10.2013 Seite 20 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
3.1 Allgemeine Anforderungen
Die allgemeinen Anforderungen wurden aus den in Kapitel 2 spezifizierten Referenzanwendungen abgeleitet.
Anforderung
Erweiterbarkeit
Beschreibung
Das System soll Erweiterungen und Änderungen zur Laufzeit zulassen, während die Produktivität anderer Teilsysteme nicht beeinträchtigt wird. Mögliche Änderungen sind: Hinzufügen von neuen Geräten, Netzwerkrekonfigurationen, Softwareupdates. Es soll einfach möglich sein, neue Services, Technologien, Systeme oder Geräte hinzuzufügen.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
R01 Funktional itsowl-IV Höchste GE/SK
Datum Historie Referenz
07/2013
Anforderung
Schnelle Neuinitialisierung
Beschreibung
Das System soll in der Lage sein, nach Erweiterungen oder Änderungen im ausgeschalteten Zustand schnell eine Neuinitialisierung durchzuführen.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
R02 Funktional itsowl-IV Höchste GE/SK
Datum Historie Referenz
07/2013
Anforderung
Autokonfiguration
Beschreibung
Der durch das Hinzufügen, Entfernen oder Ändern von Geräten und Netzwerkkomponenten verursachte manuelle Konfigurationsaufwand soll möglichst gering gehalten werden. Dazu ist es notwendig Verfahren zu entwickeln, die eine automatische Konfiguration sicherstellen bzw. den Konfigurationsaufwand minimieren.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
R03 Funktional itsowl-IV Höchste GE/SK
Datum Historie Referenz
07/2013
14.10.2013 Seite 21 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anforderung
Dynamische Pfadrekonfiguration
Beschreibung
Im Falle des Ausfalls eines Netzwerkpfades soll das System eine Rekonfiguration der Pfade vornehmen. Diese Redundanz kann durch das Vorhalten von Ersatzpfaden oder durch Protokolle zur Pfadsuche umgesetzt werden.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
R04 Funktional itsowl-IV Hoch SK
Datum Historie Referenz
07/2013
Anforderung
Einfach zu bedienende Konfigurationstools
Beschreibung
Die Konfiguration eines Kommunikationssystems erfordert häufig wiederkehrende, komplexe und fehleranfällige Schritte. Dieser Aufwand soll durch einfache Tools mit grafischer Oberfläche erleichtert werden.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
R05 Funktional itsowl-IV/ Interview Goldbeck
Hoch SK/SD/EN
Datum Historie Referenz
07/2013
Anforderung
Semantische Namensvergabe/Adressierung von Geräten
Beschreibung
Eine schnelle und nachvollziehbare Namensvergabe und Adressierung von Geräten soll möglich sein. Dadurch soll ein Gerät z.B. bei Fehlern schnell und zuverlässig identifizierbar sein.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
R06 Funktional itsowl-IV Hoch SK/SD/EN
Datum Historie Referenz
07/2013
Anforderung
Automatische Systemdiagnose
Beschreibung
Der aktuelle Systemzustand soll gegenüber dem Sollzustand automatisch geprüft werden. Dabei soll die Vorhersagbarkeit, Lokalisation und Detektierbarkeit von Fehlern unterstützt werden.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
R.07 Funktional itsowl-IV Hoch SD
Datum Historie Referenz
07/2013
14.10.2013 Seite 22 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
3.2 Spezifische Anforderungen
Die spezifischen Anforderungen an itsowl-IV werden in einem iterativen Prozess definiert. Dazu soll ein regelmäßiger Austausch mit den anderen Clusterprojekten erfolgen.
3.2.1 Anforderungen: Konnektivität
Anforderung
Standardisierte Vorkonfiguration von Geräten
Beschreibung
Geräte müssen in der Lage sein, im Auslieferungszustand in das Gesamtsystem integriert zu werden. Z.B. müssen sie ihre für den spezifischen Einsatzzweck notwendige Konfiguration von den entwickelten Konfigurationstools erhalten können. Weiterhin müssen sie kompatibel mit den Autokonfigurationsmechanismen sein.
Zielsetzung
Die Anforderung beruht auf den generellen Anforderungen R03 (Autokonfiguration) und R05 (einfach zu bedienende Konfigurationstools).
Abnahmekriterium
Alle Geräte senden im Auslieferungszustand die gleichen Nachrichten und reagieren identisch auf Testnachrichten.
ID Typ Quelle Priorität Kategorie
RN.01 Nicht-funktional
itsowl-IV Normal SK/EN
Datum Historie Referenz
07/2013
Anforderung
Echtzeitgarantie (Netzwerk)
Beschreibung
Die verwendeten Netzwerktechnologien müssen geeignet sein, um die Echtzeitanforderungen der Anwendungen zu erfüllen. Dies erfordert u.a. den Einsatz von Echtzeit-Ethernet.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Die Netzwerktechnologien müssen in der Lage sein, die spezifizierte Echtzeitanforderung zu erfüllen.
ID Typ Quelle Priorität Kategorie
RN.02 Nicht-funktional
Interview Lenze
Normal GE
Datum Historie Referenz
07/2013
14.10.2013 Seite 23 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anforderung
Gewährung der Datensicherheit
Beschreibung
Innerhalb eines Produktionsprozesses können sicherheitsrelevante Daten ausgetauscht werden. Ein Angreifer könnte sich Zugang zum Netzwerk verschaffen und diese Daten mitlesen oder den Prozess durch manipulierte Daten stören. Um dies zu verhindern, können zwei Anforderungen an die Datensicherheit gestellt werden:
Verschlüsselung: Die Daten zwischen Geräten müssen so verschlüsselt werden, dass ein Angreifer mit Netzwerkzugriff diese nicht lesen kann.
Authentifizierung: Es muss Möglichkeiten geben, um zu überprüfen, ob die Daten von berechtigten Endgeräten versendet wurden.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Die Geräte verfügen über Methoden zur Verschlüsselung und Authentifizierung.
ID Typ Quelle Priorität Kategorie
RN.03 Nicht-funktional
Interview Weidmüller/Wincor-Nixdorf
Normal SE
Datum Historie Referenz
07/2013
Anforderung
Entkoppelung Anwendung/Netzwerk
Beschreibung
Eine flexible Anwendungsentwicklung im Hinblick auf die unterliegende Netzwerkschicht soll ermöglicht werden. Dazu ist eine Trennung Anwendung/Netzwerk durch Einsatz einer geeigneten Middleware erforderlich. Durch diese Trennung soll es möglich werden, die Netzwerktechnologie ohne bzw. nur mit geringen Änderungen in der eigentlichen Anwendung zu wechseln.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Eine Anwendung lässt sich ohne Portierungsaufwand mit verschiedenen Netzwerktechnologien betreiben.
ID Typ Quelle Priorität Kategorie
RN.04 Nicht-funktional
Interview Wago
Normal GE
Datum Historie Referenz
07/2013
Anforderung
Rekonfigurierbare Hardware für den Kommunikationskanal
Beschreibung
Anwendungen haben verschiedene Anforderungen an den Kommunikationskanal. Die Hardware soll diesen Anforderungen entsprechend konfigurierbar sein und der Anwendung die optimale Netzwerktechnologie zur Verfügung stellen. Weiterhin können neue Geräte einfach in ein bestehendes Netzwerk integriert werden, wenn sich deren Hardware adaptiv der vorhandenen Technologie anpasst.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Eine Hardware lässt sich in verschiedenen Netzwerken, die auf unterschiedlichen Techniken basieren, betreiben.
ID Typ Quelle Priorität Kategorie
RN.05 Nicht-funktional
Interview Wago
Normal SK
Datum Historie Referenz
07/2013
14.10.2013 Seite 24 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anforderung
Redundanz
Beschreibung
Der Ausfall von Netzwerktechnik soll nicht zu Störungen im Prozessablauf sorgen. Dies beinhaltet zum einen Techniken zur Rekonfiguration von Netzwerkpfaden. Andererseits sollen die Funktionen von ausgefallenen Geräten möglichst automatisch von anderen Geräten übernommen werden.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Ein Geräte- bzw. Netzwerkfehler beeinträchtigt nicht die Funktionalität des Gesamtprozesses.
ID Typ Quelle Priorität Kategorie
RN.06 Nicht-funktional
Interview Wago
Hoch SK/SD
Datum Historie Referenz
07/2013 R04
3.2.2 Anforderungen: Middleware
Anforderung
Bereitstellung von semantischen Informationen über Geräte
Beschreibung
Das System soll sowohl von menschlichen Benutzern als auch von Software lesbare semantische Informationen über die Geräte im Produktionsumfeld liefern.
Zielsetzung
Die Anforderung beruht auf den generellen Anforderungen R03 (Autokonfiguration), R05 (einfach zu bedienende Konfigurationstools) und R07 (automatische Systemdiagnose).
Abnahmekriterium
a) Das System soll geeignete Mechanismen bereitstellen, um Gerätebeschreibungen mit semantischen Informationen zu erweitern.
b) Das System soll den Zugang zu und das Abfragen aus einer Datenbank von semantischen Gerätebeschreibungen erlauben.
ID Typ Quelle Priorität Kategorie
RM.01 Nicht-funktional
itsowl-IV Normal SK/EN
Datum Historie Referenz
07/2013
Anforderung
Standardisierung von Gerätesemantiken
Beschreibung
Die semantische Beschreibung von Geräten soll auf bestehenden Standards basieren.
Zielsetzung
Die Anforderung beruht auf den generellen Anforderungen R03 (Autokonfiguration), R05 (einfach zu bedienende Konfigurationstools) und R07 (automatische Systemdiagnose).
Abnahmekriterium
Benutzung eines verbreiteten Standards zur semantischen Beschreibung.
ID Typ Quelle Priorität Kategorie
RM.02 Nicht-funktional
itsowl-IV Normal SK/EN
Datum Historie Referenz
07/2013
14.10.2013 Seite 25 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anforderung
Homogene Kommunikation
Beschreibung
Es soll eine homogene Kommunikation über alle Prozessschichten möglich sein. Dazu muss eine geeignete Middleware eingesetzt werden.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Auf der untersten Ebene (z.B. Sensoren) und der höchsten (z.B. Prozessleitsystem) müssen dieselben Kommunikationsprotokolle eingesetzt werden.
ID Typ Quelle Priorität Kategorie
RM.03 Nicht-funktional
Interview Lenze
Hohe GE
Datum Historie Referenz
07/2013
Anforderung
Einsatz einer service-orientierten Architektur (SOA)
Beschreibung
Zur Ermöglichung einer vertikalen Integration des Gesamtsystems soll auf allen Ebenen eine service-orientierte Architektur eingesetzt werden.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Unterstützung der SOA-Dienste auf allen Geräten.
ID Typ Quelle Priorität Kategorie
RM.04 Nicht-funktional
Interview Weidmüller
Hohe GE
Datum Historie Referenz
07/2013
3.2.3 Anforderungen: Anwendung
Anforderung
Echtzeitgarantie (Geräte)
Beschreibung
Geräte müssen bestimmte Echtzeitklassen einhalten. So erfordern manche Anwendungen Zyklen bis zu 1ms.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Die Geräte müssen in der Lage sein, die spezifizierte Echtzeitanforderung zu erfüllen.
ID Typ Quelle Priorität Kategorie
RA.01 Nicht-funktional
Interview Lenze
Normal GE
Datum Historie Referenz
07/2013
14.10.2013 Seite 26 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anforderung
Wiederverwendung von Lösungswissen zur Kommunikation
Beschreibung
Beim Entwickeln der Kommunikation zwischen Systemen soll bewährtes Lösungswissen wiederverwendet werden. Hierdurch lassen sich Fehler vermeiden und die Entwicklungsgeschwindigkeit erhöht werden.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
RA.02 Nicht-funktional
itsowl-IV Hoch SA, EN
Datum Historie Referenz
07/2013
Anforderung
Formale Analyse von Sicherheitseigenschaften bei der Kommunikation
Beschreibung
Die Kommunikation zwischen Systemen soll für sicherheitskritische Anwendungen bzgl. Sicherheitseigenschaften analysiert werden können. Es soll beweisbar sein, dass während der Kommunikation z.B. kein Deadlock auftritt.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
RA.03 Funktional itsowl-IV Hoch SA
Datum Historie Referenz
07/2013
Anforderung
Bereitstellung von minimalen und maximalen Kommunikationszeiten
Beschreibung
Die Anwendung stellt Zeitanforderungen an die minimale und maximale Zeit zur Übertragung einer Nachricht. Diese Information muss der Middleware beim Versand bereitgestellt werden. Die Middleware stellt diese Anforderung dann sicher.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
RA.04 Funktional itsowl-IV Hoch SA
Datum Historie Referenz
07/2013
Anforderung
Anwendung soll verteilt auf verschiedenen Hardware-Einheiten ausgeführt werden
Beschreibung
Eine Anwendung lässt sich in Softwarekomponenten aufteilen. Diese Softwarekomponenten können verteilt auf mehreren Hardware-Einheiten ausgeführt werden. Hierzu muss eine Zuteilung von Softwarekomponenten zu Hardware-Einheiten berechnet oder spezifiziert werden. Es soll möglich sein, dass die Softwarekomponenten miteinander kommunizieren.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
RA.05 Funktional itsowl-IV Hoch EN
Datum Historie Referenz
07/2013
14.10.2013 Seite 27 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anforderung
Kooperatives Verhalten zwischen Anwendungen
Beschreibung
Anwendungen sollen miteinander interagieren, um gemeinsam zu kooperieren und ein gemeinsames Ziel zu erreichen. Anwendungen von verschiedenen Anlagen tauschen lokal vorliegende Informationen aus, um das Gesamtverhalten einer Anlage zu verbessern.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
RA.06 Funktional itsowl-IV Hoch EN
Datum Historie Referenz
07/2013
Anforderung
Lokale Steuerungen ersetzen Gesamtsteuerung
Beschreibung
Eine Steuerung kann mit anderen Steuerungen kommunizieren. Gemeinsam wird eine Strategie ausgehandelt. Es gibt keine Gesamtsteuerung mehr. Hierdurch kann ein System einfach um eine Anlage erweitert werden. Es sind keine Anpassungen notwendig, da jede Anlage nur für sich selbst verantwortlich ist und das Gesamtsystem sich selbst organisiert.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
RA.07 Nicht-funktional
itsowl-IV Mittel SK
Datum Historie Referenz
07/2013
Anforderung
Anwendungen werden plattformunabhängig beschrieben und lassen sich auf verschiedene Plattformen portieren
Beschreibung
Das Verhalten der Anwendung wird als plattformunabhängiges Modell unabhängig von plattformspezifischen Eigenschaften beschrieben. Es lässt sich auf verschiedenen Plattformen portieren, ohne dass die das plattformunabhängige Modell angepasst werden muss.
Zielsetzung
-
Abnahmekriterium
ID Typ Quelle Priorität Kategorie
RA.08 Nicht-funktional - Portierbarkeit
itsowl-IV Hoch GE
Datum Historie Referenz
07/2013
3.2.4 Anforderungen: Sensor- und Informationsfusion
14.10.2013 Seite 28 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anforderung
Prognose für notwendige Wartungen erstellen
Beschreibung
Die Wartungsintervalle für Maschinen sind in der Regel vorbestimmt und berücksichtigen nicht den tatsächlichen Zustand und Verschleiß einer Maschine. Dies kann zu unnötigen oder verspäteten Wartungen führen. Durch die Einbeziehung von Sensordaten in ein intelligentes Überwachungssystem können verbesserte Prognosen für den notwendigen Zeitpunkt von Wartungsarbeiten getroffen werden. Die Prognosen können auf der Überwachung der Parameter der produzierten Güter oder der Maschine selbst beruhen.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Das System meldet die Notwendigkeit einer tatsächlich benötigten Wartung.
ID Typ Quelle Priorität Kategorie
RSI.01 Nicht-funktional
Interview Gildemeister
Normal SD/EN
Datum Historie Referenz
07/2013
Anforderung
Selbsterkennung der Ursache von Fehlern
Beschreibung
Sobald ein Fehler im Prozess vorliegt, soll die Ursache möglichst automatisch erkannt werden. Dazu ist eine Verknüpfung mit einer Expertenwissen-Datenbank notwendig. Diese Datenbank soll um die Prozessdaten erweitert werden, die die mit dem Prozess verknüpften Sensoren liefern. So soll aus eventuellen Abweichungen bei den Prozessdaten auf die Fehlerursache geschlossen werden können. In einem weiteren Schritt lassen sich Fehler dann auch schon vor ihrem Auftreten prognostizieren.
Zielsetzung
Die Anforderung beruht auf den Anwendungen diverser IPs.
Abnahmekriterium
Fehlerursachen werden automatisch lokalisiert bzw. Fehler werden bereits vor ihrem Auftreten prognostiziert.
ID Typ Quelle Priorität Kategorie
RSI.02 Nicht-funktional
Interview Phoenix/Wago
Normal SD/EN
Datum Historie Referenz
07/2013
Anforderung
Signalselbstschreibung
Beschreibung
Im Prozess erfasste Signale zu Diagnosezwecken besitzen neben den enthaltenen Daten zuzüglich eine semantische Beschreibung ihrer Herkunft und des Signalinhalts. Des Weiteren wird mit jedem Signaldatum dessen Zeitpunkt des Empfangs bzw. der Erzeugung, insbesondere zu Synchronisationszwecken, festgehalten. Für die Signalbeschreibung werden die zur Erfüllung von RM.01 (Bereitstellung von semantischen Informationen über Geräte) erarbeiteten Konzepte als Basis verwendet bzw. mitgenutzt.
Zielsetzung
Diese Anforderung ist Grundlage zur Erfüllung der Anforderung RSI.04 (Selbstkonfiguration der Informationsfusion).
Abnahmekriterium
-
ID Typ Quelle Priorität Kategorie
RSI.03 Nicht-funktional - Nutzbarkeit
itsowl-InverSa Hoch SD
Datum Historie Referenz
08/2013 RSI.04, RM.01
14.10.2013 Seite 29 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anforderung
Selbstkonfiguration der Fusions-Attribute
Beschreibung
Die im Fusionssystem verarbeiteten Signale sind mit hinreichend vielen Informationen angereichert, sodass die überwachten Attribute automatisch vom Fusionssystem generiert, aktualisiert oder zerstört werden.
Zielsetzung
Über Fusions-Attribute, die sich adaptiv an die im System aktuell vorzufindenden Begebenheiten anpassen, ist eine im Vergleich zu statischen Systemen robustere und zuverlässigere Zustandsüberwachung möglich.
Abnahmekriterium
Bei Systemerweiterungen, -wartungen oder sonstigen Änderungen werden die überwachten Attribute selbständig vom Fusionssystem angepasst.
ID Typ Quelle Priorität Kategorie
RSI.04 Nicht-funktional – Nutzbarkeit, Zuverlässigkeit
itsowl-InverSa Höchste SD/EN
Datum Historie Referenz
08/2013 RSI.03
14.10.2013 Seite 30 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
4 Zusammenfassung und nächste Schritte
Dieses Dokument beschreibt die für das Querschnittsprojekt „Intelligente Vernetzung“ identifizierten Referenzanwendungen und Anforderungen, die aus Interviews mit insgesamt 11 IPs und durch QP interne Befragungen definiert wurden. Die weitere intensive Zusammenarbeit mit den befragten IPs stellt überdies sicher, dass neue Anforderungen bzw. interessante Anwendungsfälle umgehend erfasst und in die Anforderungsspezifikation integriert werden können.
Im weiteren Verlauf des Projekts werden die Anforderungen für die Spezifikation der Referenzarchitektur herangezogen und die notwendigen Architekturkomponenten unmittelbar daraus abgeleitet. Die definierten Referenzanwendungsfälle werden in der in AP 5 entwickelten modularen Evaluationsumgebung umgesetzt, um anschließend die festgelegten Anforderungen zu validieren.
Zu Beginn der zweiten Förderphase wird ein aktualisierter Leitfaden für die Interviews erstellt. Dieser wird zu weiteren Interviews mit den bis dahin neu gestarteten, relevanten IPs verwendet, um anschließend eine erneute Analyse durchzuführen und die Anforderungsspezifikation entsprechend zu ergänzen.
14.10.2013 Seite 31 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anhang A – Liste der allgemeinen Anforderungen
Appendix A fasst die allgemeinen Anforderungen aus Kapitel 3.1 zusammen und listet ihre ID zusammen mit dem Anforderungsnamen.
Tabelle 4: Allgemeine Anforderungen
ID Name
R01 Erweiterbarkeit
R02 Schnelle Neuinitialisierung
R03 Autokonfiguration
R04 Dynamische Pfadrekonfiguration
R05 Einfach zu bedienende Konfigurationstools
R06 Semantische Namensvergabe/Adressierung von Geräten
R07 Automatische Systemdiagnose
14.10.2013 Seite 32 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anhang B – Liste der spezifischen Anforderungen
Appendix B fasst alle spezifischen Anforderungen aus Kapitel 3.2 zusammen und listet ihre ID zusammen mit dem Anforderungsnamen.
Middleware
Tabelle 5: Anforderungen an die Middleware
ID Name
RM.01 Bereitstellung von semantischen Informationen über Geräte
RM.02 Standardisierung von Gerätesemantiken
RM.03 Homogene Kommunikation
RM.04 Einsatz einer service-orientierten Architektur (SOA)
Konnektivität
Tabelle 6: Anforderungen an die Konnektivität
ID Name
RK.01 Standardisierte Vorkonfiguration von Geräten
RK.02 Echtzeitgarantie (Netzwerk)
RK.03 Gewährung der Datensicherheit
RK.04 Entkoppelung Anwendung/Netzwerk
RN.05 Rekonfigurierbare Hardware für den Kommunikationskanal
RN.06 Redundanz
Anwendung
Tabelle 7: Anwendungsanforderungen
ID Name
RA.01 Echtzeitgarantie (Geräte)
RA.02 Wiederverwendung von Lösungswissen zur Kommunikation
RA.03 Formale Analyse von Sicherheitseigenschaften bei der Kommunikation
RA.04 Bereitstellung von minimalen und maximalen Kommunikationszeiten.
RA.05 Anwendung soll verteilt auf verschiedenen Hardware-Einheiten ausgeführt werden
RA.06 Kooperatives Verhalten zwischen Anwendungen
RA.07 Lokale Steuerungen ersetzen Gesamtsteuerung
RA.08 Anwendungen werden plattformunabhängig beschrieben und lassen sich auf verschiedene Plattformen portieren
14.10.2013 Seite 33 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Sensor-/Informationsfusion
Tabelle 8: Anforderungen an die SEFU/IFU
ID Name
RSI.01 Prognose für notwendige Wartungen erstellen
RSI.02 Selbsterkennung der Ursache von Fehlern
RSI.03 Signalselbstschreibung
RSI.04 Selbstkonfiguration der Fusions-Attribute
14.10.2013 Seite 34 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Anhang C – Strukturierter Leitfaden für die IP Interviews
14.10.2013 Seite 35 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
14.10.2013 Seite 36 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
14.10.2013 Seite 37 itsowl-IV/AP1/AP1.1/1.0
Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster
Literaturverzeichnis
[1] itsowl-IV Konsortium, „Rahmenplan zum Verbundprojekt itsowl-IV – CQP3 Intelligente Vernetzung“, Mai 2012.
[2] itsowl-IV Konsortium, „Fragenkatalog zur Anforderungsanalyse“, Internes Arbeitsdokument des Konsortiums, August 2012.
[3] I. Sommerville, Software Engineering, 9th Edition, Addison-Wesley, 2011.
[4] Ian Sommerville and Pete Sawyer. Requirements Engineering: A Good Practice Guide, 1st Edition, John Wiley & Sons, Inc., New York, NY, USA,
1997.
[5] L. Dürkop, H. Trsek, J. Jasperneite, L. Wisniewski, „Towards autoconfiguration of industrial automation systems: A case study using Profinet IO“, IEEE 17th Conference on Emerging Technologies & Factory Automation (ETFA), 2012.