AP1: Anforderungen und Referenzanwendungen · 14.10.2013 Seite 2 itsowl-IV/AP1/AP1.1/1.0 Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster Executive Summary

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



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.



Ä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



Ä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



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



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



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



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



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.



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


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.



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.



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/



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.



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.



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



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



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



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



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.



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


R01 Funktional itsowl-IV Höchste GE/SK


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




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




07/2013



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


R04 Funktional itsowl-IV Hoch SK


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


R05 Funktional itsowl-IV/ Interview Goldbeck

Hoch SK/SD/EN


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


R06 Funktional itsowl-IV Hoch SK/SD/EN


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


R.07 Funktional itsowl-IV Hoch SD


07/2013



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.


RN.01 Nicht-funktional

itsowl-IV Normal SK/EN


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.



Interview Lenze

Normal GE


07/2013



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


Abnahmekriterium

Die Geräte verfügen über Methoden zur Verschlüsselung und Authentifizierung.



Interview Weidmüller/Wincor-Nixdorf

Normal SE


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


Abnahmekriterium

Eine Anwendung lässt sich ohne Portierungsaufwand mit verschiedenen Netzwerktechnologien betreiben.



Interview Wago

Normal GE


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


Abnahmekriterium

Eine Hardware lässt sich in verschiedenen Netzwerken, die auf unterschiedlichen Techniken basieren, betreiben.



Interview Wago

Normal SK


07/2013



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


Abnahmekriterium

Ein Geräte- bzw. Netzwerkfehler beeinträchtigt nicht die Funktionalität des Gesamtprozesses.



Interview Wago

Hoch SK/SD


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.


RM.01 Nicht-funktional



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.





07/2013



Anforderung

Homogene Kommunikation

Beschreibung

Es soll eine homogene Kommunikation über alle Prozessschichten möglich sein. Dazu muss eine geeignete Middleware eingesetzt werden.

Zielsetzung


Abnahmekriterium

Auf der untersten Ebene (z.B. Sensoren) und der höchsten (z.B. Prozessleitsystem) müssen dieselben Kommunikationsprotokolle eingesetzt werden.



Interview Lenze

Hohe GE


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


Abnahmekriterium

Unterstützung der SOA-Dienste auf allen Geräten.



Interview Weidmüller

Hohe GE


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


Abnahmekriterium

Die Geräte müssen in der Lage sein, die spezifizierte Echtzeitanforderung zu erfüllen.


RA.01 Nicht-funktional

Interview Lenze

Normal GE


07/2013



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



itsowl-IV Hoch SA, EN


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


RA.03 Funktional itsowl-IV Hoch SA


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


RA.04 Funktional itsowl-IV Hoch SA


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


RA.05 Funktional itsowl-IV Hoch EN


07/2013



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


RA.06 Funktional itsowl-IV Hoch EN


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



itsowl-IV Mittel SK


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


RA.08 Nicht-funktional - Portierbarkeit

itsowl-IV Hoch GE


07/2013

3.2.4 Anforderungen: Sensor- und Informationsfusion



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


Abnahmekriterium

Das System meldet die Notwendigkeit einer tatsächlich benötigten Wartung.


RSI.01 Nicht-funktional

Interview Gildemeister

Normal SD/EN


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


Abnahmekriterium

Fehlerursachen werden automatisch lokalisiert bzw. Fehler werden bereits vor ihrem Auftreten prognostiziert.


RSI.02 Nicht-funktional

Interview Phoenix/Wago

Normal SD/EN


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

-


RSI.03 Nicht-funktional - Nutzbarkeit

itsowl-InverSa Hoch SD


08/2013 RSI.04, RM.01



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.


RSI.04 Nicht-funktional – Nutzbarkeit, Zuverlässigkeit

itsowl-InverSa Höchste SD/EN


08/2013 RSI.03



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.



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



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



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



Anhang C – Strukturierter Leitfaden für die IP Interviews







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.

Documents

AP1: Anforderungen und Referenzanwendungen · 14.10.2013 Seite 2 itsowl-IV/AP1/AP1.1/1.0 Kategorie: Dokument Status: Final Verfügbarkeit: itsowl Spitzencluster Executive Summary