Gerätebezogene Modellierung von Funkkomponenten zur ... · Gerätebezogene Modellierung von Funkkomponenten zur Berücksichtigung im Lebenszyklus industrieller Automatisierungsanlagen

Gerätebezogene Modellierung von Funkkomponenten zur

Berücksichtigung im Lebenszyklus industrieller Automatisierungsanlagen

(FiLiA)

Abschlussbericht

Autor(en): Prof. Dr.-Ing. habil. Martin Wollschlaeger (TUD), Dr.-Ing. Lutz Rauchhaupt, André Schimschar, David Hasler (ifak);Robert Lehmann (TUD),

ifak e.V. Magdeburg, TU Dresden

Version: 1.0 (28.02.2013)

© ifak e.V. Magdeburg, TU Dresden Abschlussbericht_FiLiA.docx Version 1.0 (28.02.2013)

Die dieser Abhandlung zugrunde liegenden Arbeiten sind im Rahmen des IGF-Vorhabens 16734 BR/1 entstanden. Das IGF-Vorhaben 16734 BR/1 der Forschungsvereinigung Elektrotechnik beim ZVEI e.V. - FE, Lyoner Straße 9, 60528 Frankfurt am Main wurde über die AiF im Rahmen des Programms zur Förderung der industriellen Gemeinschaftsforschung und -entwicklung (IGF) vom Bundesministerium für Wirtschaft und Technologie aufgrund eines Beschlusses des Deutschen Bundestages gefördert.

Inhaltsverzeichnis 3 / 89


Inhaltsverzeichnis

1 Einleitung ..................................................................................................................................................... 9

2 Arbeitsschritte / Ablauf .............................................................................................................................. 11

3 Anforderungsanalyse ................................................................................................................................ 13

3.1 Einordnung in das Projekt ................................................................................................................. 13

3.2 Industrielle Automatisierungsanlagen als Betrachtungsraum des Projektes .................................... 13

3.3 Methodische Vorgehensweise .......................................................................................................... 16

3.4 Anforderungsermittlung für das Modell ............................................................................................. 20

3.5 Zusammenfassung ............................................................................................................................ 22

4 Klassifikation der relevanten Informationen .............................................................................................. 23

5 Einflussgrößen........................................................................................................................................... 29

5.1 Allgemein ........................................................................................................................................... 29

5.2 Kenngrößen ....................................................................................................................................... 29

5.3 Einflussgrößen ................................................................................................................................... 30

5.4 Testdurchführung .............................................................................................................................. 31

5.5 Ergebnisdarstellung ........................................................................................................................... 33


6 Modellbildung ............................................................................................................................................ 39

6.1 Grundlagen und Werkzeuge ............................................................................................................. 39

6.2 Modellierungskonzept........................................................................................................................ 39

6.3 Kernelemente des FiLiA-Modells ...................................................................................................... 40

6.4 Datentechnische Repräsentation des Modells .................................................................................. 51

7 Frequenzmanagement-Prozess ................................................................................................................ 59

7.1 Allgemein ........................................................................................................................................... 59

7.2 Parameter .......................................................................................................................................... 59

7.3 Phasen des Koexistenzmanagementprozesses ............................................................................... 61


8 Umsetzung in Zielformate ......................................................................................................................... 64

8.1 Sichtenbildung ................................................................................................................................... 64

8.2 General Station Description Markup Language (GSDML) ................................................................ 65

8.3 Electronic Device Description Language........................................................................................... 68

8.4 Abbildung nach FDCML .................................................................................................................... 71

8.5 Abbildung in andere Formate ............................................................................................................ 74

9 Validierung ................................................................................................................................................. 75

9.1 Konzept ............................................................................................................................................. 75

9.2 Validierung des Modells und der Instanzdateien .............................................................................. 75

9.3 Validierung der GSDML-Abbildung ................................................................................................... 75

9.4 Validierung der EDDL-Abbildung ...................................................................................................... 79

10 Zusammenfassung .................................................................................................................................... 82

11 Darstellung des wissenschaftlich-technischen und wirtschaftlichen Nutzens der erzielten Ergebnisse ... 84

11.1 Wirtschaftsbereiche ........................................................................................................................... 84

11.2 Nutzen der angestrebten Forschungsergebnisse ............................................................................. 84

11.3 Möglicher Beitrag zur Steigerung der Leistungs- und Wettbewerbsfähigkeit der KMU .................... 85

12 Verwertung ................................................................................................................................................ 86

13 Referenzen ................................................................................................................................................ 87

Abbildungsverzeichnis 4 / 89


Abbildungsverzeichnis

Abbildung 1: Funklösungen als integrale Bestandteile im Lebenszyklus einer Anlage 9

Abbildung 2: Ebenenmodell der Automation 13

Abbildung 3: Dimensionen der Integration (Integrationsprozesse) 15

Abbildung 4: Phasen der Produkt- und Anwendungssicht im Lebenszyklus 16

Abbildung 5: Generisches Lebenszyklus-Modell eines Produktes (Typ) 17

Abbildung 6: Lebenszeit einer Produktinstanz 18

Abbildung 7: Hierarchische Systemstruktur 19

Abbildung 8: Sicht als Filter des Datenbestands 20

Abbildung 9: Ausgewählte Phasen und Use Cases im Anlagenlebenszyklus 21

Abbildung 10: Kategorisierung von Parametern bzgl. Funkgeräten in Automatisierungsanlagen 23

Abbildung 11: Testaufbau für die Untersuchung von Bluetooth-Komponenten 32

Abbildung 12: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Abstand 60-95 dB 33

Abbildung 13: Statistische Kenngrößen der Aktualisierungszeit in Abhängigkeit vom Abstand 60-95 dB 33

Abbildung 14: Paketverlustrate in Abhängigkeit vom Sendezeitabstand 34

Abbildung 15: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand 5-20 ms 34

Abbildung 16: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand 30-50 ms 35

Abbildung 17: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (IEEE 802.11b) 35

Abbildung 18: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (IEEE 802.11a) 36

Abbildung 19: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (IEEE 802.11g) 36

Abbildung 20: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (Infrastructure Modus) 37

Abbildung 21: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (Ad-hoc) 37

Abbildung 22: Kernelemente des FiLiA-Modells 41

Abbildung 23: Klassen TypeInformation (links) und InstanceInformation (rechts) 42

Abbildung 24: Klassendiagramm des Modellelements Device 43

Abbildung 25: Klassendiagramm des Modellelements NetworkComponent 44

Abbildung 26: Vererbungshierarchie der Klasse NetworkComponentType 44

Abbildung 27: Vererbungshierarchie der Klasse NetworkComponentInstance 45

Abbildung 28: Detaildarstellung der Eigenschaft DataRate 46

Abbildung 29: Vererbungshierarchie der Klasse WirelessComponentType 46

Abbildung 30: Vererbungshierarchie der Klasse WirelessComponentInstance 47

Abbildung 31: Klassendiagramm des Modellelements PowerSupply 47

Abbildung 32: Relation zwischen Spannungsversorgung, Gerät und Komponente 48

Abbildung 33: Klassendiagramm des Modellelements Antenna 48

Abbildung 34: Relation zwischen Antenne und Funkkomponente 49

Abbildung 35: Klassendiagramm des Modellelements Network 50

Abbildung 36: Klassendiagramm und Relationen des Modellelements Application 51

Abbildungsverzeichnis 5 / 89


Abbildung 37: Schemadarstellung des Basiselements 52

Abbildung 38: Schemadarstellung der Typ- und Instanzinformation 52

Abbildung 39: Schemadarstellung der Typklasse DeviceType 53

Abbildung 40: Schemadarstellung der Instanzklasse DeviceTypeInformation 54

Abbildung 41: Schemadarstellung der Typklasse WirelessComponentType 55

Abbildung 42: Schemadarstellung der Typklasse IEEE_11ComponentType 56

Abbildung 43: Fragment einer Beispieldatei 57

Abbildung 44: Schemadarstellung der Frequenzbänder und Kanäle 58

Abbildung 45: Fragment der Instanzdatei der Frequenzbänder und Kanäle 58

Abbildung 46: Zuordnung von Parametern zu Phasen des Lebenszyklus 64

Abbildung 47: Transformation von Modellbestandteilen in Zielformate für spezifische Use Cases 65

Abbildung 48: Strukturbild GSD-Nutzung 66

Abbildung 49: Gerätestruktur eines PROFINET IO-Devices 66

Abbildung 50: Fragment einer GSD 67

Abbildung 51: Prinzip der Erstellung der Transformationen zwischen FiLiA-Modell und GSDML 68

Abbildung 52: Strukturbild Geräteinbetriebnahme 69

Abbildung 53: Kanalauswahldialog einer Parametrierung mittels EDD 71

Abbildung 54: EDD-Quelltext Kanalauswahl 71

Abbildung 55: Basiselemente des Gerätemodells nach ISO 15745 72

Abbildung 56: Schemadarstellung des FDCML-Elements DeviceManager 73

Abbildung 57: Prinzip der Erstellung der Transformation zwischen FiLiA-Modell und FDCML 74

Abbildung 58: Screenshot der Instanziierung des FiLiA-Beispielgerätes in Step7 77

Abbildung 59: Eigenschaftsdialog im Step7 78

Abbildung 60: Dialog zur Kanalauswahl im Step7 79

Abbildung 61: Dialog zur Geräteintegration 80

Abbildung 62: PDM Gerätekatalog 80

Abbildung 63: Geräteinformationen 81

Abbildung 64: Kanalauswahldialog einer Parametrierung mittels EDD in PDM 81

Tabellenverzeichnis 6 / 89


Tabellenverzeichnis

Tabelle 1: Zuordnung ausgewählter Aktivitäten von Akteuren zu den Sichten 21

Tabelle 2: Definition und Zuordnung funkspezifischer Parameter 24

Tabelle 3: Relevante Parameter für das Koexistenzmanagement 60

Tabelle 4: eingeschränkte Nutzung von Kanälen in Funkgeräten 70

Tabelle 5: Veröffentlichungen im Rahmen des FiLiA-Projektes 86

Abkürzungsverzeichnis 7 / 89


Abkürzungsverzeichnis

B&B Bedienen und Beobachten

EAM Enterprise Asset Management

EDD Electronic Device Description

EDDL Electronic Device Description Language

EMV Elektromagnetische Verträglichkeit

ERP Enterprise Ressource Planning

FDA Food and Drug Administration

FDCML Field Device Configuration Markup Language

FDI Field Device Integration

GSD General Station Description

GSDML General Station Description Markup Language

KPI Key Performance Indicator

LAN Local Area Network

MES Manufacturing Execution System

NC Numerischer Controller

OLE Object Linking and Embedding

OPC OLE for Process Control

PDM Process Device Manager

XML Extensible Markup Language

Zusammenfassung 8 / 89


Zusammenfassung

Im Forschungsvorhaben „Gerätebezogene Modellierung von Funkkomponenten zur Berück-sichtigung im Lebenszyklus industrieller Automatisierungsanlagen“ – „FiLiA“ ist ein Modell zur Darstellung und weitergehenden Nutzung von funkrelevanten Informationen in der Automation erarbeitet worden. Hierzu wurden eingangs umfangreiche Analysen durchgeführt. Dabei stand im Fokus, in welchen Lebenszyklusphasen funkrelevante Informationen anfallen bzw. erfor-derlich sind. Anhand des Aufbaus von industriellen Automatisierungsanlagen wurde eine Zu-ordnung der funktionalen Elemente zu den verschiedenen logischen Ebenen in den Lebens-zyklen vorgenommen.

Die Identifikation von Schnittmengen zu existierenden Geräteinformationen war ein weiterer Teilaspekt des Vorhabens. Identifizierte funktionale Elemente und bestehende Geräte-informationen sind herangezogen worden, um eine universelle Klassenhierarchie aufzubauen, die allgemeine Geräteinformationen, technologieabhängige Geräteinformationen und lösungs-bezogene Geräteinformationen detailliert beschreibt.

Anschließend wurde untersucht, welche anwendungs- und technologie- oder umgebungs-bezogenen Einflussgrößen sowie deren Wertebereiche relevante Änderungen von Funkkenn-größenwerten nach sich ziehen. Diese Einflussgrößen sind zunächst kategorisiert worden. Ihre Rückwirkung auf Kenngrößen wurde exemplarisch anhand ausgewählter konkreter Technologien untersucht. Dafür war es notwendig, aussagekräftige Testszenarien in einer Laborumgebung aufzubauen. Details zur Kenngrößenuntersuchung (Vorbetrachtung, Aufbau, Durchführung, Ergebnisdarstellung) sind in Abschnitt 5 dargestellt. Aus den Resultaten der Laboruntersuchung konnten zusätzliche Informationen identifiziert werden, die im Modell repräsentiert werden mussten.

Auf Basis der umfangreichen Eingangsanalysen wurde ein Modell entwickelt und metasprachlich beschrieben, das die Belange der funkgestützten Komponenten abbildet. Die Modellierung der funkbezogenen Eigenschaften erfolgte im Kontext ihres Einsatzes in der Automation. Existierende Modelle wurden nicht verworfen sondern auf informationeller Ebene integriert, bspw. Modelle zur Geräte Identifikation (IEC 15745 [1]). Ein wesentlicher Anspruch an das Modell ist die zukünftige Erweiterbarkeit, diesem Anspruch konnte durch die strikte Trennung von Typ- und Instanzinformationen nachgekommen werden. Die Modellbildung selbst erfolgte objektorientiert mittels Unified Modeling Language. Alle Modellteile sind in Abschnitt 6 ausführlich beschrieben und dargestellt. Zur datentechnischen Repräsentation wurde das Modell zusätzlich auf XML-Schema umgesetzt. Basierend auf der XML-Schema-Repräsentation sind Transformationen und Transformationsvorschriften erarbeitet worden, um Modellinhalte aus dem FiLiA-Schema auf automatisierungsrelevante Beschreibung(-en/-s-sprachen) (GSDML, EDD, etc.) abzubilden.

Um die Leistungsfähigkeit des Modells nachzuweisen, wurden Instanzen für ausgewählte Anwendungsfälle umgesetzt. Die erstellten exemplarischen Umsetzungen des Modells wur-den validiert. Auf Basis von ausgewählten Szenarien fand eine Identifizierung typischer Werk-zeugketten statt, in denen verschiedene Umsetzungen des Modells, z.B. in EDDL, FDCML und GSDML, systematisch getestet wurden.

Es wurde im GMA-Fachausschuss "Funkgestützte Kommunikation" an einer Richtlinie zur Gewährleistung der Koexistenz industrieller Funklösungen mitgewirkt (DIN EN 62657). Ziel der Bemühungen war es, den Frequenzmanagement-Prozess als Bestandteil des Lebens-zyklus zu etablieren.

Hersteller von Funkkomponenten können die Ergebnisse des Projektes nutzen, um ihren Markt in Richtung Automatisierungstechnik zu erweitern bzw. zu festigen. Systemintegratoren kann freigestellt werden, welche Funktechnologie oder Komponenten welchen Herstellers sie einsetzen. Software-Werkzeug-Herstellern wird ermöglicht, mit ihren Produkten ein größeres Spektrum an Geräten und somit von Anwendungen abzudecken.

Das Ziel des Forschungsvorhabens wurde erreicht.

Einleitung 9 / 89


1 Einleitung

Funkgestützte industrielle Kommunikation entwickelt sich vom Problemlöser für Nischen-anwendungen zum integralen Bestandteil industrieller Kommunikationssysteme. Die Aus-stellungsschwerpunkte zum Thema "Wireless Automation" auf Messen, wie der Hannover Messe, der ISA EXPO oder der SPS/IPC/Drives, die Jahrestagung "Wireless Automation" der VDI/VDE-Gesellschaft für Mess- und Automatisierungstechnik [2] sowie Forschungsprojekte [3], [4], [5] sind sichtbarer Ausdruck für diese Entwicklung. Es zeigt sich hier aber auch, dass bisher nahezu ausschließlich die gerätetechnische Integration von Funkkomponenten im Fokus der Forschung und Entwicklung steht. Dabei geht es um die Erhöhung der Zuverlässig-keit, die Verbesserung des Zeitverhaltens oder die Berücksichtigung von Funklösungen in funktional sicheren Anlagen (Safety). Bisher wenig beachtet bleibt hingegen die Integration der Funklösungen in den Lebenszyklus automatisierungstechnischer Anlagen.

Derzeit fehlt ein durchgängiges Konzept für das Handling von Geräte- und Projektinfor-mationen. So bietet beispielsweise die Firma Siemens ein Standalone-Tool an, mit dem eine Abschätzung der Funkausbreitungsbedingungen sowie die Konfiguration der Siemens-WLAN-Komponenten vorgenommen werden kann. Eine durchgängige Integration in den Lebens-zyklus fehlt jedoch auch hier. Die Spezifikation für WirelessHART sieht eine Beschreibung der Funkkomponenten mit der für HART-Geräte obligatorischen EDD vor, neue Aspekte, die durch das neue Übertragungsmedium von Bedeutung werden, wie das Frequenzmanage-ment, sind bisher nicht berücksichtigt. Auf der anderen Seite gibt es Ansätze zur Planung von Funksystemen und zum Frequenzmanagement, deren Bezug zum Automatisierungssystem wurde jedoch noch nicht hergestellt.

Bei der Bewertung der Ausgangssituation war zu berücksichtigen, dass die vielfältigen Anfor-derungen unterschiedlicher Anwendungsbereiche der Automation verschiedene Funk-lösungen erfordern. So sind heute industrielle Funklösungen basierend auf Bluetooth, WLAN, ZigBee, IEEE 802.15.1 (WISA), IEEE 820.15.4 (WirelessHART) verfügbar sowie Lösungen, die keine Funkstandards nutzen. Die Konfiguration und Diagnose all dieser Lösungen über private serielle Protokolle, Werkzeuge oder spezifische Web-Server wird mittelfristig einen Hemmschuh bei der Weiterverbreitung der Funkkommunikation darstellen.

Abbildung 1: Funklösungen als integrale Bestandteile im Lebenszyklus einer Anlage

Es fehlen also ein Konzept und eine Methodik, um die vielfältigen Funklösungen einheitlich in den verschiedenen Phasen des Lebenszyklus einer Automatisierungsanlage zu berücksich-tigen und dabei neue Aspekte der Funkkommunikation, wie die Funkausbreitung im industri-

Planung Konfiguration Inbetriebnahme Betrieb DiagnosePlanung Konfiguration Inbetriebnahme Betrieb Diagnose

Einleitung 10 / 89


ellen Umfeld, das Frequenzmanagement, ein geändertes Netzwerk- und Security-Manage-ment, aufzunehmen. Die Entwicklung eines so umfassenden Ansatzes zur methodenorien-tierten Integration der Funkkommunikation in den Lebenszyklus der Automation (Abbildung 1) war bisher nicht Gegenstand der Forschung.

Das Forschungsziel des Projektes war daher die Entwicklung eines Modells und einer Metho-dik zur Integration von Funklösungen in den Lebenszyklus von automatisierungstechnischen Geräten und Anlagen. Weiterhin sollte die Integration der Handhabung von Funklösungen in die zum Einsatz gebrachten Werkzeugen durch die methodische Aufbereitung der relevanten Daten und Prozesse, die zur Berücksichtigung von Funklösungen als integrale Bestandteile im Lebenszyklus der Automation erforderlich sind, erleichtert werden. Das heißt, primärer For-schungsgegenstand in diesem Vorhaben war die Modellierung und Aufbereitung der Eigen-schaften industrieller Funklösungen, eine Verbesserung der funktechnischen Übertragungs-eigenschaften selbst stand nicht im Fokus.

Dabei wurde im Projekt auf die heute in industriellen Automatisierungslösungen zur Anwen-dung kommenden Funktechnologien aufgesetzt, jedoch Erweiterungsmöglichkeiten für zu-künftige Entwicklungen vorgesehen.

Die wesentlichen wirtschaftlichen Ergebnisse und der Nutzen des Vorhabens bestehen aus Sicht der Projektpartner in der Schaffung von durchgängigen modellbasierten Automati-sierungskonzepten unter Einbeziehung von Funklösungen. Die Kohärenz des Modells zu den aktuell laufenden Standardisierungsarbeiten zur Beschreibung von Geräten und deren Inte-gration in Leitsysteme, welche ebenso einen explizit Lebenszyklus-orientierten Ansatz haben, aber die Funktechnologien bisher nicht weiter betrachten, ist wesentliche Voraussetzung für die Reduzierung der Aufwendungen und letztlich der Kosten bei der Planung und Inbetrieb-nahme, aber auch beim Betrieb und Service von Automatisierungslösungen mit funkgestütz-ten Bestandteilen.

In den Geschäftsfeldern Prüf- und Fertigungsautomatisierung sowie mittelfristig in der Pro-zessautomation wird die konfektionierte Einbindung von funkgestützten Systemen in die Feld-ebene von Automatisierungssystemen zur Überwachung von Anlagenkomponenten zu Kostenreduktionen durch kürzere Rüstzeiten führen. Weiterhin liefert das Vorhaben auch einen Beitrag zur Verlängerung der Instandhaltungszeiträume (Asset-Management) und zur optimierten Betriebsführung sowie zur Anbindung von vor- und nachgelagerten Prozessen (z. B. Eingangs- und Ausgangslogistik) durch Integration von funkgestützten Lösungen und eröff-net ebenfalls neue bzw. erweiterte Anwendungsszenarien durch die Nutzung funktypischer Eigenschaften wie zum Beispiel Mobilität und Flexibilität (weitgehend ortsunabhängiger Informationszugriff).

Arbeitsschritte / Ablauf 11 / 89


2 Arbeitsschritte / Ablauf

Grundlage der Arbeiten im Projekt waren die im Projektantrag definierten Arbeitspakete. Folgende inhaltlichen Schwerpunkte waren dabei Gegenstand der einzelnen Aktivitäten:

AP 1 Anforderungsanalyse

Bevor mit der Aufbereitung der Daten und Prozesse begonnen werden konnte, wurde zunächst identifiziert, in welchen Phasen des Lebenszyklus welche Informationen über die Funklösungen erforderlich sind. Dazu wurden einerseits die funktionale Struktur von Automa-tisierungslösungen, der Lebenszyklus der automatisierungstechnischen Anlage sowie ausge-wählte Spezifika von Funkübertragungen im industriellen Umfeld analysiert. Neue Prozesse betreffen die Analyse der Funkausbreitungsbedingungen, das Frequenzmanagement über den gesamten Lebenszyklus sowie die Wartung von Geräten mit Primär- oder Sekundärzel-len. Ein weiterer Aspekt, der zu berücksichtigen war, betrifft die unterschiedlichen Anwen-dungsbereiche Fertigungsautomation und Prozessautomation.

AP 2 Klassifizierung der Geräteinformationen

Für die Beschreibung von Eigenschaften von Funklösungen ist es erforderlich, diese in Bezug auf ihre Relevanz für Geräte und Gerätekomponenten, für Netzwerke und für die Applikation zu klassifizieren. Dabei wurden Schnittmengen zu existierenden Geräteinformationen identifi-ziert. In diesem Arbeitspaket wurde eine universelle Klassenhierarchie aufgebaut, die allge-meine Geräteinformationen, technologieabhängige Geräteinformationen und lösungsbezo-gene Geräteinformationen beschreibt. Die Geräteinformationen sind bedeutend für die Konfi-guration und Diagnose. Sie können ebenso für Plug-und-Play-Konzepte, Security-Strategien und Frequenzmanagement-Konzepte herangezogen werden.

AP 3 Analyse von Einflussgrößen

Die Kenngrößenwerte werden mehr oder weniger von Einflussgrößen wie Übertragungsent-fernung, Datenlänge bzw. Umgebungsbedingungen beeinflusst. Im Rahmen dieses Arbeits-paketes wurde untersucht, welche der anwendungs- und technologiebezogenen oder umge-bungsbezogenen Einflussgrößen und deren Wertebereiche tatsächlich relevante Änderungen der Kenngrößenwerte nach sich ziehen. Dazu wurde eine Reihe von Tests unter Beachtung des industriellen Anwendungsbereiches durchgeführt.

AP 4 Modellbildung und metasprachliche Beschreibung der Geräteinformationen

Ausgehend von den Klassifikationen der funkrelevanten Informationen, der Geräte- und Netz-werkeigenschaften und der Anwendungsaspekte wurden Zuordnungen dieser Informationen zu einer generalisierten Werkzeugkette entlang des Lebenszyklus vorgenommen. Die in den Werkzeugen vorhandenen – zumeist nicht explizit repräsentierten – Modelle wurden analy-siert. Auf dieser Basis wurde ein Modell entwickelt und metasprachlich beschrieben, das die Belange der funkgestützten Komponenten abbildet.

AP 5 Spezifikation eines Frequenzmanagement-Prozesses

Es wurde unter verantwortlicher Mitwirkung des ifak im GMA-Fachausschuss "Funkgestützte Kommunikation" eine Richtlinie zur Gewährleistung der Koexistenz industrieller Funklösungen erarbeitet (DIN EN 62657). Zentraler Inhalt dieses Dokumentes ist ein Frequenzmanagement-Prozess. Die formale Beschreibung dieses Prozesses und dessen Einordnung in den Lebens-zyklus von Automatisierungssystemen ist wesentlich für die effektive Nutzung von Funklösun-gen in der Automation. Ziel war es, den Frequenzmanagement-Prozess zum Bestandteil des Lebenszyklus zu machen, die modelltechnischen Grundlagen für eine Verbindung zu den da-

Arbeitsschritte / Ablauf 12 / 89


für erforderlichen Werkzeugen aufzubereiten und in den GMA-Fachausschuss einzubringen. Wesentliche Aspekte der Richtlinie fanden bei der Modellbildung im Projekt „FiLiA“ Berück-sichtigung.

AP 6 Umsetzung des Modells mit geeigneten Beschreibungsmitteln

Auf der Grundlage der durchgeführten Untersuchungen und der Modellbildung wurden für ausgewählte Sichten und für ausgewählte Funklösungen Konzepte zur Transformation der Modellinhalte in spezifische Zielformate erarbeitet. Dazu wurden geeignete Zielformate identi-fiziert und untersucht. Neben der Repräsentation des Modells in XML bildeten Beschreibungs-mittel wie EDDL einen Schwerpunkt. Damit können die funkbezogenen Daten in typische Werkzeuge des Lebenszyklus industrieller Automatisierungsanlagen integriert werden.

AP 7 Validierung

Die erstellten exemplarischen Umsetzungen des Modells wurden validiert. Auf Basis von aus-gewählten Szenarien wurden typische Werkzeugketten identifiziert, in denen verschiedene Umsetzungen des Modells, z.B. in EDDL, FDCML und GSDML, systematisch getestet wurden.

AP 8 Abschlussbericht

Die Ergebnisse aller Arbeitspakete, die gewonnenen Erkenntnisse sowie Anregungen zu deren Anwendung und Weiterverwendung wurden im Abschlussbericht zusammengefasst.

Anforderungsanalyse 13 / 89


3 Anforderungsanalyse

3.1 Einordnung in das Projekt

Im Rahmen der Anforderungsanalyse wurde zunächst der methodische Ansatz zum Vorgehen in diesem Vorhaben entwickelt. Wesentliche Kategorien wie Produkttyp, Lebenszyklus, Pro-duktinstanz und Lebenszeit wurden für die Nutzung in diesem Vorhaben spezifiziert. Anschlie-ßend wurden die Anforderungen an die Modellbildung zusammengetragen. Es wurde dabei zwischen der Komponentensicht auf Funkgeräte, der Systemsicht auf das Funknetzwerk und der Anlagensicht auf Funknetzwerke unterschieden.

3.2 Industrielle Automatisierungsanlagen als Betrachtungsraum des Projektes

Eine industrielle Automatisierungsanlage stellt ein komplexes System aus einer Vielzahl von Einzelkomponenten dar. Für die Beschreibung eines solchen Systems hat sich die Automati-sierungspyramide (Abbildung 2) etabliert, die eine Zuordnung von funktionalen Elementen zu verschiedenen logischen Ebenen vornimmt. In den Ebenen werden somit spezifische Aufga-ben aus dem Gesamtkomplex einer fertigungs- oder verfahrenstechnischen Automatisierungs-lösung ausgeführt [6].

Abbildung 2: Ebenenmodell der Automation



In der Unternehmensleitebene werden Funktionen implementiert, die der Beeinflussung der Automatisierungslösung nach unternehmerischen Kriterien (Ziele, Markt- und Kunden-situation, Auslastungskenngrößen etc.) dienen.

Die Betriebsleitebene stellt Funktionen für die operative Umsetzung der strategischen Ziele durch technische Systeme der Automation zur Verfügung. Eine zentrale Position nimmt das Manufacturing Execution System (MES) ein, das die Steuerung unterlagerter Automatisie-rungskomponenten in einer solchen Form koordiniert, dass betriebliche und logistische Prozesse der Produktion koordiniert werden.

Diese beiden oberen Ebenen gehören der „Bürowelt“ an. Die eigentliche technische Automati-sierung beginnt in der Leitebene. Angesiedelt in dieser Ebene sind Funktionen zur Prozess-führung durch das zentrale Bedienen und Beobachten, das (zentrale) Engineering, das (zentrale) Diagnosesystem und das Archiv. Auch (komplexe) automatisierungstechnische Funktionen werden dieser Ebene zugeordnet.

Um den gesamten Prozess von einem Ort (Warte) führen und überwachen zu können, ist es notwendig, dass die verwendete Hard- und Software in der Lage ist, die vom Prozess ver-langten Reaktionszeiten zu gewährleisten.

Es stehen einerseits Funktionen zur Darstellung der Prozesszustände durch dynamische Prozessbilder zur Verfügung und andererseits Funktionen, welche zum Eingriff (Bedienung) in den Prozess und in die Automatisierungsanlage selbst dienen.

Produktionsausfälle sind kostenaufwändig und müssen auf ein ökonomisch vertretbares Niveau reduziert werden. Diagnosesysteme sollen in Fehlerfällen schnelle Fehlersuche und rasche Fehlerbeseitigung ermöglichen. Ein Fehler rührt entweder vom automatisierten Prozess oder von einem eingesetzten Gerät zur Prozessautomatisierung her. Die Diagnose des Netzwerkes beinhaltet das Überprüfen der Netzwerkeigenschaften auf Einhaltung von Vorgabeparametern. Diese Parameter werden typisch dem Netzwerkmanagement zugeordnet und beinhalten Konfigurationsparameter, Performanceparameter, Fehlerzustände und Sicher-heitsparameter. Von geringerer Bedeutung sind Abrechnungsparameter.

Die Komponenten der Leitebene sind zumeist durch Ethernet-basierte Strukturen vernetzt, wobei häufig hier auch TCP/IP-basierte Protokolle eingesetzt werden.

Die Funktionen dieser Ebene sind für das Gesamtsystem von erheblicher Relevanz und deshalb werden Maßnahmen zur Erhöhung der Zuverlässigkeit und Verfügbarkeit u. a. redun-dante Kommunikationsverbindungen (Bussysteme) zum Prozess, redundante Bildschirme usw. vorgenommen.

In der Automatisierungsebene werden die typischen Automatisierungsfunktionen wie Ablauf-steuerungen, Regelungen, komplexe Messwertverarbeitung sowie die Funktionen zum lokalen Bedienen und Beobachten implementiert. Als typische Kommunikationsprotokolle kommen hier Ethernet-basierte zum Einsatz.

Für die Automatisierungsgeräte ist ihr Echtzeitverhalten von entscheidender Bedeutung. Traditionell besitzen deshalb die Automation Controller Feldbusschnittstellen zur Kommunika-tion mit den Geräten der Feldebene.

In der Feldebene sind Funktionen wie Messen (Messwertaufnahme) und Stellen (Stellwert-ausgabe), Überwachungsfunktionen sowie dezentrale Verarbeitung (dezentrale Automatisie-rungsfunktionen wie Regelungen usw.) einzuordnen. Zunehmend werden dieser Ebene auch komplexere Funktionen der Signalverarbeitung zugeordnet.

Als Kommunikationssystem kommen wegen ihres deterministischen Verhaltens ein oder mehrere Feldbusse zum Einsatz. Die Auswahl der eingesetzten Feldbussysteme erfolgt unter Berücksichtigung der Applikationsanforderungen (Datenrate, Abstände, Protokoll, Kommuni-kationsparadigma, Kosten). Das zur Zeit viel diskutierte Echtzeit-Ethernet mit den unterschied-lichen standardisierten wie firmenspezifischen Lösungen wird künftig die herkömmlichen Feld-busse ergänzen und teilweise auch ersetzen.



Die Funktionen der Sensor-/Aktor-Ebene sind mit denen der Feldebene vergleichbar, wobei einfache Mess- und Stellaufgaben dominieren. Komplexere Verarbeitungsfunktionen sind, be-dingt durch die geringere Leistungsfähigkeit der Komponenten, nur sehr selten anzutreffen. Vielfach werden Sensor-/Aktor-Ebene und Feldebene nicht unterschieden.

Die Durchgängigkeit der Informationsflüsse zwischen den Komponenten und den Ebenen wird durch die Integrationsprozesse gewährleistet. Dabei können gemäß Abbildung 3 drei Dimensionen unterschieden werden.

Die horizontale Dimension repräsentiert die Integration der verschiedenen Systeme und Komponenten innerhalb einer Ebene, die zur Erfüllung der zugehörigen Funktion miteinander verbunden sind. Hierfür werden in den Ebenen verschiedenste Schnittstellen eingesetzt. Von besonderer Bedeutung im Kontext des Projektes sind die Funklösungen in der Sensor-/Aktor-, Feld- und Automatisierungsebene, transportieren sie doch die Prozessdaten sowie Para-meter- und Diagnosedaten. Weiterhin ist innerhalb eines Kommunikationssystems der Wech-sel des Übertragungsmediums (Kabel - Funk, Schichten 1 und 2 des OSI-Modells) ebenfalls denkbar, z. B. PROFINET IO über WLAN oder Bluetooth in einem Netz. Auch in der Leitebene sind relevante Anforderungen und Lösungen zu finden (spezifische Funkanbindungen). In den oberen Ebenen werden Funklösungen typisch als Bestandteil lokaler Netze angewandt (Infrastruktur).

Die vertikale Dimension repräsentiert die Kopplung an den funktionalen Schnittstellen zwischen Elementen verschiedener Ebenen. Hier sind Gateway-Lösungen oder Integrations-lösungen typisch, etwa die Integration von WirelessHART in PROFIBUS. Damit wird ein koordinierter Durchgriff auf ausgewählte Daten einer jeweiligen Schicht ermöglicht. Die Vor-gabe von produktionsrelevanten Daten (Auftragsdaten, Batches usw.) stellt die typische Kom-munikation nach unten dar, die Rückmeldungen aus unterlagerten Ebenen (Fertigstellung, Diagnosen, Alarme) oder die aggregierten Kenngrößen (Key Performance Indicator (KPI)) werden nach oben kommuniziert.

Die dritte Dimension der Integration erfolgt über die Zeit und soll den Datenaustausch über die Phasen des Lebenszyklus von Automatisierungssystemen gewährleisten. In dieser Ebene entsteht ein spezifischer Informationsfluss – d. h. in den einzelnen Phasen werden in den Komponenten Daten entstehen und es werden Daten konsumiert.

Pla

nung

Serv

ice &

Inst

andhaltu

ng

Betrie

bInbetr

iebse

tzung

Err

ichtu

ng

Recyc

ling

Unternehmens-

leitebene

Betriebs-

leitebene

Automatisierungsebene

Feldebene

Sensor-/Aktor-Ebene

Leitebene

Integration überdie Lebenszeit horizontale

Integration

vertikaleIntegration

Abbildung 3: Dimensionen der Integration (Integrationsprozesse)

Im Kontext des Projektes wurden insbesondere die Ebenen unterhalb der Leitebene betrach-tet. Der Fokus lag dabei auf Feldebene und Steuerungsebene. Die durch Funksysteme über-



tragenen Daten selbst waren nur insoweit relevant, als dass ihre Übertragung die geforderten Eigenschaften der Daten wie z. B. Echtzeitanforderungen einhalten müssen.

Hingegen wurden funkbezogene Daten untersucht, welche die Eigenschaften der Funksyste-me abbilden und als Eingangs- oder Ausgangsdaten für Integrationsprozesse dienen. Hierzu gehören u. a. Angaben zum Zeitverhalten, die genutzten Frequenzbänder etc..

Von besonderer Relevanz sind übergreifende Prozesse wie das Koexistenzmanagement der Funklösungen, das derzeit dem Facilitymanagement bzw. der IT zugeordnet ist. Zukünftig ist nicht ausgeschlossen, dass einzelne Funktionen bis in die Feldebene reichen (als Bestandteil der Geräte, die in ein (eher zentralisiertes) Managementsystem eingebunden werden). Das Koexistenzmanagement betrifft damit alle Funkgeräte, übergreifend über die Ebenen und unabhängig von deren Funktion.

3.3 Methodische Vorgehensweise

3.3.1 Übersicht

Die Betrachtung von Funklösungen (Funkgeräten und -netzwerken) ist in zwei wesentliche Perspektiven zu untergliedern. Einerseits ist die Herstellung von Funklösungen zu betrachten, andererseits ihre Nutzung als Bestandteil einer industriellen Automatisierungsanlage. Wäh-rend erstere im Verantwortungsbereich des Herstellers liegt, ist letztere als Anwendungssicht dem Verantwortungsbereich des Anwenders (Endkunde) zuzuordnen. In Abbildung 4 ist diese Trennung durch die vertikale rote Linie dargestellt. Beiden Betrachtungen liegt ein Produkt-begriff zugrunde, der nach [7] ein Wirtschaftsgut mit definierten Eigenschaften (Typ) bezeich-net, das in einem Wertschöpfungsprozess in reproduzierbarer Qualität erzeugt wird (Instanz). Der Wertschöpfungsprozess kann ein Prozess sein, der Komponenten zu einem System integriert (Integrationsprozess). Produkte können Hardware, Software, Dienstleistungen oder beliebige Kombinationen daraus sein.

Im Kontext dieses Projektes waren daher sowohl die Funklösungen als Produkte zu betrach-ten, als auch die industrielle Automatisierungsanlage.

Sensor/Aktor-Ebene

Automatisierungsebene

Feldebene

Entwicklung

Unternehmensleitebene

Betriebsleitebene

Produktion

Planung

Beschaffung

Applikations-

entwicklung.

Integration

Betrieb

Service & Instandhaltung

Recycling

Hersteller der

Funklösung

Integration über

die Lebenszeit

Ve

rtika

le In

teg

ratio

n

Leitebene

Nutzer der

Funklösung

Abbildung 4: Phasen der Produkt- und Anwendungssicht im Lebenszyklus



Die Betrachtung von Eigenschaften des Produktlebenszyklus unterscheidet sich daher. In [7] sind wesentliche Modelle für das Life-Cycle-Management für Produkte und Systeme der Automation beschrieben. Dabei wird zunächst eine Sicht auf die Erstellung von Produkten definiert (Hersteller der Funklösung), anschließend eine Integrationssicht auf Komponenten (Nutzer der Funklösung). Dabei ist zu beachten, dass aus den von den Herstellern angebo-tenen Produkttypen „Funklösung“ Instanzen gebildet werden – die einzelnen Funkgeräte und Funknetzwerke – die im Produkttyp „Automatisierungsanlage“ und in den davon realisierten Instanzen genutzt werden. Es ist möglich, dass für einen Typ „Automatisierungsanlage“ nur eine einzige Instanz implementiert wird.

3.3.2 Produkttyp - Lebenszyklus

Ein Typ ist nach [7] gekennzeichnet durch eine eindeutige Produkt-ID (z. B. die Bestell-nummer), einen Satz von Entwicklungsdokumenten, Fertigungs- und Prüfbeschreibungen und einer technischen Dokumentation. Für die Zulassung eines Typs für Anwendungen können Zertifikate gefordert und ausgestellt werden. Alle Tätigkeiten, die im Rahmen der Entwicklung, Pflege und Betreuung eines Produktes geleistet werden – unabhängig davon, wie oft es gefer-tigt wird – beziehen sich auf den Produkttyp. Zur Verwaltung von Änderungen am Typ, ausge-prägt als Versionen und Ausgabestände, ist ein Management der Dokumente, Programme und Werkzeuge für Entwicklung, Test, Fertigung und Service inklusive Archivierung erforder-lich.

Entstehung Vermarktung Nachsorge

Service

Fertigung

Pflege und BetreuungEntwicklung

1

2

3

6

4

5

1

3

5

2

4

Vertriebsfreigabe

Vermarktungsende Produkt

Vermarktungsende Service-Leistungen

Lieferfreigabe

Fertigungsende

6 Abkündigung

Abbildung 5: Generisches Lebenszyklus-Modell eines Produktes (Typ)

Der typische Lebenszyklus eines Produktes (Typ) kann nach Abbildung 5 in verschiedene Phasen (Lebensphasen) gegliedert werden. Er beginnt mit der Entstehungsphase, in der das Produkt als Typ entwickelt wird. Die Entwicklung schließt Testaktivitäten, die Einführung in Fertigung und Vermarktung sowie die Erprobung (Pilotierung) im Systemumfeld ein. Beim Erreichen der spezifizierten technischen und kommerziellen Kriterien wird das Produkt zum Vertrieb freigegeben (Meilenstein 1: Vertriebsfreigabe). Nach Abschluss der erfolgreichen Erprobung und nach Abschluss der Fertigungseinführung sowie der Vorbereitung des Service erfolgt die Lieferfreigabe (Meilenstein 2) und damit die Fertigung des Produkts, d. h. – im Sinne der eingeführten Terminologie – die Instanziierung des Typs.

An die Entstehungsphase schließt sich die Vermarktungsphase an. In dieser Phase erfolgt das operative Geschäft mit dem Produkt. Sie endet mit dem Vermarktungsende des Pro-duktes (Meilenstein 3 – Typstreichung). Das Fertigungsende (Meilenstein 4) eines Produkts liegt in der Regel zeitlich nach dem Ende der aktiven Vermarktungsphase und wird von techni-schen und wirtschaftlichen Randbedingungen abhängig gemacht. Die Pflege der Hardware endet in der Regel mit dem Fertigungsende. Die Betreuung von Software (inklusive Firmware) kann über das Fertigungsende hinaus durchgeführt werden.



Die Nachsorgephase beginnt mit dem Vermarktungsende des Produktes und endet mit der Abkündigung des Produktes (Meilenstein 6). Der mit der Lieferfreigabe beginnende Service für das Produkt endet ebenfalls mit der Abkündigung des Produktes. Das Vermarktungsende von Services (Meilenstein 5) liegt in der Nachsorgephase zeitlich vor der Abkündigung des Produktes. Mit der Abkündigung des Produktes enden somit alle vom Hersteller standard-mäßig vorgehaltenen produktbezogenen Lieferungen und Leistungen.

Die Summe der Lebensphasen eines Typs wird als Lebenszyklus des Produkts (Product Life-Cycle) bezeichnet.

3.3.3 Produktinstanz - Lebenszeit

Jede gefertigte Einheit eines Typs bildet nach [7] eine Instanz dieses Typs. Die Instanz ist immer ein individuelles Exemplar und sollte durch eine eineindeutige Kennung (z. B. Seriennummer) identifizierbar sein. Das Nutzungsrecht von Instanzen von Softwareprodukten wird über Lizenzscheine geregelt. Alle Tätigkeiten, die mit der Fertigung und dem Service während des Einsatzes des Produktes in einer Anlage geleistet werden, beziehen sich auf die Produktinstanz.

Jede Instanz eines Produktes besitzt eine Lebenszeit (Product Life Time), die vom Zeitpunkt ihrer Erzeugung (Meilenstein a) – z. B. Fertigung der Hardware – bis zur Entsorgung (Meilen-stein f) – z. B. Verschrottung – reicht. Sie kann deutlich über das Ende des Lebenszyklus des Produkttyps (Meilenstein 6) hinaus gehen (Abbildung 6). Der wesentliche Abschnitt der Lebenszeit ist die Nutzzeit, die bei Meilenstein c beginnt – z. B. mit Installation/Aktivierung von Software – und mit der Außerbetriebsetzung (Meilenstein e) – z. B. Deinstallation, irreparabler Defekt – endet.

Zeit

Produkt (Instanz)

Lebenszeit

Gewährleistungszeit

c e

„Standard-Service“Service durch

Sondervereinbarungen

b d

Nutzzeit

f

Entsorgung

†

Produkt (Typ) 6

Vermarktung Nachsorge

a

Ende der Erzeugung

Beginn der Gewährleistungszeit für den Kunden

Beginn der Nutzzeit Ende der Lebenszeit (Ende Entsorgung)

Abkündigung des Produkttypsa

b

c

e

d

f

6

Ende der Gewährleistungszeit

Ende der Nutzzeit (Außerbetriebsetzung)

Abbildung 6: Lebenszeit einer Produktinstanz

3.3.4 Integrationsmodell

Ein wesentlicher Anteil des Produkt Lebenszyklus Management Prozesses (PLM-Prozesses) ist die Integration von Komponenten Dritter (nicht selbst entwickelter Komponenten) in ein System [7]. Ein System kann als eine abgegrenzte, geordnete Gesamtheit von Elementen (Komponenten) verstanden werden, die zur Erfüllung einer Funktion (Systemfunktion) aufeinander einwirken oder miteinander in Beziehung stehen (Abbildung 7). Systeme können hierarchisch aufgebaut sein, d. h. sie können aus unterlagerten Systemen (die dann selbst Komponenten darstellen) bestehen.

Ein System „Messumformer“ besteht beispielsweise aus Hardwarekomponenten, wie z. B. Gehäuse, Antenne, Funkkomponente (die wiederum ein System aus Komponenten wie Kon-densatoren, Widerständen, Prozessor, Basisbandcontroller etc. darstellt), und aus Software-



komponenten, wie z. B. Firmware, Betriebssystem, Systemsoftware, Applikationssoftware. Das System „Messumformer“ ist seinerseits Komponente im System „Leittechnik“.

System (n+1)

System n

System (n-1)Komponente (n-1).1

Syste

mfu

nktion

Komponente n.3

Komponente (n+1).1

Komponente (n-1).2

Komponente n.1Komponente n.2

Komponente (n-1).3

…

…

…Beispiele:

(n+1) Leittechnik(n+1).1 Leitsystem(n+1).2 Messumformer

n Messumformern.1 Gehäusen.2 Antennen.3 Funkkomponente

(n-1) Funkkomponente(n-1).1 Prozessor(n-1).2 Basisbandcontroller(n-1).3 Firmware

Komponente (n+1).2

Abbildung 7: Hierarchische Systemstruktur

In diesem Forschungsvorhaben standen die Integration von Funkkomponenten in Funkgeräte, die Integration von Funkgeräten in Funknetzwerke sowie die Integration von Funklösungen in Automatisierungsanlagen im Fokus.

3.3.5 Definition der Lebenszyklus-Phasen

Abgeleitet aus den Betrachtungen des Produktes in Bezug auf seine Herstellung und in Bezug auf seine Verwendung lassen sich Phasen definieren, denen wesentliche Aktivitäten zugeord-net werden können. Dabei ist zu beachten, dass in den einzelnen Anwendungsdomänen ggf. verschiedene Begriffe etabliert sind.

Der Produktlebenszyklus beginnt mit dem Entwurf und der Entwicklung des Produktes. Durch die Produktion wird der Betrieb des Produktes ermöglicht, in welcher eine Service/ Instandhaltungsphase stattfinden kann. Der Lebenszyklus endet mit dem Recycling des Produktes.

Ein Anlagenlebenszyklus startet mit der Basisplanung und der folgenden Detailplanung, in welcher die Automatisierungsfunktion bzw. das Automatisierungssystem festgelegt werden. Durch die Errichtung und Inbetriebsetzung der Anlage wird der Betrieb ermöglicht. Service/ Instandhaltungsmaßnahmen gewährleisten den Betrieb und Anlagenoptimierungen. Der Lebenszyklus endet mit dem Recycling der Anlage.

3.3.6 Sichten

In den jeweiligen Lebenszyklusphasen werden in den Use Cases Daten von Funklösungen bearbeitet oder erzeugt. Dabei bestimmen die Use Cases und die Akteure die Eingangsdaten (benötigte Daten) und die Ausgangsdaten (entstehende Daten). Die Menge der dem Use Case zugeordneten Daten ist eine Untermenge des gesamten Datenbestandes und stellt eine Sicht dar. Eine Sicht repräsentiert somit eine spezifische Clusterung von Eigenschaften und entspricht einer Filterung des Datenbestandes für die jeweilige Anwendung (Abbildung 8). Sichten helfen bei der Verbesserung der Handhabbarkeit der Datenmenge.



Funknetzwerk

Funkgerät Funkgerät Funkgerät

Funkkomponente Funkkomponente

Akteur Use Case

Sicht

Datenbestand

Eingangs-

daten

Ausgangs-

daten

Abbildung 8: Sicht als Filter des Datenbestands

Wesentliche Sichten sind die Betrachtung von Funktionen, von Geräten bzw. Ressourcen und vom Ort, an dem sich ein Gerät befindet. Je nach Use Case bzw. Akteur sind ggf. nur einzelne Sichten relevant. So ist z. B. in der Basisplanung meist nur eine Funktionssicht in den Werk-zeugen realisiert.

Die für dieses Projekt relevanten Eigenschaften wurden Sichten zugeordnet. Sie beschreiben eine Funkkomponente, ein Funkgerät oder ein Funknetzwerk.

3.3.7 Akteure

In dem Projekt wurden folgende Akteure unterschieden:

Funkkomponentenhersteller (ACT_01) Hersteller der Funkkomponente

Gerätehersteller (ACT_02) Hersteller von Geräten mit Funkkomponenten

Systemhersteller (ACT_03) Hersteller, welcher Funksysteme inkl. der Geräte anbietet

Anlagenersteller (ACT_04) plant und erstellt Automatisierungsanlagen

Netzwerkbetreiber (ACT_05) sichert den Betrieb von Funklösungen

Betreiber (ACT_06) setzt Funklösungen ein, um eine Automatisierungsaufgabe zu erfüllen

3.4 Anforderungsermittlung für das Modell

3.4.1 Übersicht

Den Phasen sind Use Cases zugeordnet, die verschiedene Aktionen beinhalten, in denen Informationen über Funklösungen entstehen, verarbeitet oder verändert werden (Abbildung 9). Für verschiedene Sichten werden ausgewählte relevante Aktivitäten (Funktionen) und die daran beteiligten Akteure aufgelistet.

Diese Phasen haben grundsätzlich eine bestimmte Reihenfolge, da die einzelnen Schritte aufeinander aufbauen. Bei der Veränderung von betriebstechnischen Gegebenheiten (Um-planung, Anlagenerweiterung etc.) können diese Phasen jedoch wiederholt werden. Diese Wiederholungen können zyklisch auftreten und beschreiben dann eine kontinuierliche Weiter-entwicklung der Anlage.



Basis-

Planung

Detail-

Planung

Errichtung Betrieb Recycling

Application

Engineering

Device

Engineering

Aufbau

Program-mierung

OngoingEngineering

Service /Instand-haltung

Automati-

sierungs-

funktionNetwork

Engineering

Inbetrieb-

setzung

Konfigu-

ration

Parametrie-rung

Geräte-

Herstellung

Geräte-

entwurf

Produktion

Geräte-

entwicklung

Auswahl/

Beschaffung

Demontage

Abbildung 9: Ausgewählte Phasen und Use Cases im Anlagenlebenszyklus

Beispielhaft sollen für einige Sichten relevante Aktivitäten und die beteiligten Akteure aufge-listet werden.

Tabelle 1: Zuordnung ausgewählter Aktivitäten von Akteuren zu den Sichten

Anwendungsfälle Akteur

Komponentensicht auf Funkgeräte

Entwurf Festlegung der Zielfunktionalität (drahtlose Kommunikation soll realisiert werden)

Gerätehersteller

Entwicklung Entwickeln der Funkkomponente Funkkomponentenhersteller

Integration einer Funkkomponente Gerätehersteller

Produktion Festlegung von Instanzparametern (Seriennummer etc.)

Gerätehersteller

Betrieb, Service/Instandhaltung

Batteriewechsel Netzwerkbetreiber, Betreiber

Systemsicht auf Funknetzwerke

Entwurf Festlegung von Kommunikations-anforderungen der Anwendung

Systemhersteller

Entwicklung Erstellung der Netzwerktypdokumentation

Systemhersteller

Anlagensicht auf Funknetzwerke

Detailplanung Entscheidung und Auswahl eines Funknetzwerktyps

Systemhersteller, Anlagenersteller, Betreiber

Errichtung Bau- und Montagearbeiten (Antennenposition und -ausrichtung)

Systemhersteller, Anlagenersteller

Inbetriebsetzung Konfigurierung der Funknetzwerke Systemhersteller, Anlagenersteller

Betrieb, Service/ Instandhaltung

Bedienung und Beobachtung der Anlage

Betreiber



3.5 Zusammenfassung

Die Anforderungsanalyse gab die Struktur vor für:

Analyse der Daten, die für die Anwendungsfälle in den einzelnen Lebenszyklus-Phasen benötigt werden,

Analyse der relevanten Einflussgrößen auf das Verhalten von Funklösungen,

Modellbildung sowie für die

Spezifikation eines Koexistenzmanagements.

Anhand des Aufbaus von industriellen Automatisierungsanlagen und der Erläuterung der Ebenen wurde eine Zuordnung der funktionalen Elemente zu den verschiedenen logischen Ebenen vorgenommen. Auf dieser Grundlage wurden die für das Projekt relevanten Ebenen herausgearbeitet.

Im Weiteren wurde das Wissen über die wesentlichen zu betrachtenden Kategorien wie Produkttyp - Lebenszyklus und Produktinstanz - Lebenszeit aufgearbeitet und die verschiede-nen Lebenszyklus-Phasen, die zu betrachtenden Sichten und Akteure definiert.

Auf dieser Grundlage erfolgte die Ausarbeitung der Anforderungen an das Modell, wobei eine Unterscheidung der Komponentensicht auf Funkgeräte, der Systemsicht auf Funknetzwerke und der Anlagensicht auf Funknetzwerke unterschieden wurde.

Klassifikation der relevanten Informationen 23 / 89


4 Klassifikation der relevanten Informationen

Wie der vorangegangene Abschnitt angedeutet hat, werden von zahlreichen Akteuren und Datenflüssen entlang des Lebenszyklus Informationen bereitgestellt. Davon kann eine Reihe an Informationen generalisiert werden, es gibt aber auch eine große Menge spezifischer Details.

Funkkomponente(Chipsatz) Antenne

Spannungs-versorgung

Funkgerät

Funknetzwerk

Anlage

Abbildung 10: Kategorisierung von Parametern bzgl. Funkgeräten in Automatisierungsanlagen

Den Ansatz zur Kategorisierung veranschaulicht Abbildung 10. Die Grafik stellt dar, dass Funkgeräte eine oder mehrere Funkkomponenten, eine oder mehrere Antennen und Span-nungsversorgungen beinhalten können. Die Funkkomponente umfasst sämtliche funkrelevan-ten Parameter, welche die Kommunikation auf dem drahtlosen Medium bestimmen. Beispiele sind das Frequenzband, die Bandbreite, aber auch die verwendete Funktechnologie. Die Kategorie Antenne beinhaltet Parameter, welche die Antenne charakterisieren. Beispiele sind die Antennencharakteristik oder der -gewinn. Der Bereich Spannungsversorgung beschreibt die Art und Weise der Energieversorgung. An dieser Stelle wird auch festgelegt, ob das Gerät mit Energy Harvesting, Batterien oder über ein Kabel mit Energie versorgt wird. Das Funk-gerät, welches die bereits beschriebenen Klassen umfasst, beinhaltet zusätzliche Parameter, wie zum Beispiel den Status des Gerätes oder eine Fehleranzeige. Einige Parameter können auch für mehrere Klassen relevant sein. Beispielsweise besitzen nicht nur das Funkgerät, sondern auch die Antenne und die Funkkomponente einen Produkttyp und -namen. Zwei oder mehrere Funkgeräte bilden ein Netzwerk. An dieser Stelle ist z. B. die Topologie oder die Po-sition der Geräte von Interesse. Ein oder mehrere Netzwerke realisieren die Kommunikation, die zur Automatisierung der Anlage notwendig ist. Auch hier existieren charakterisierende Parameter. Beispiele sind hierfür die Kommunikationslast oder die Umgebungsbedingungen.

Die Informationen, die bereits für verschiedene Funktechnologien verfügbar sind, lieferten einen guten Ausgangspunkt für die Modellierung. Als ein erster Schritt mussten diese exis-tierenden Informationen bewertet und kategorisiert werden. Tabelle 2 fasst die Ergebnisse der umfassenden Analyse von Funklösungen und Standards zusammen. Dabei handelt es sich um Informationen, die während des Lebenszyklus von Interesse sind. Aus Platzgründen werden in Tabelle 2 nur Parameter aufgeführt, die für das weitere Verständnis erforderlich sind. Deshalb wurden die spezifischen Informationen für die drahtlosen Technologien WLAN, Bluetooth, IEEE 802.15.4, WSAN-FA und WirelessHART gesammelt. Sie wurden anschlie-ßend den oben genannten Kategorien zugeordnet.



Weitere Informationsquellen waren Gerätemodelle und ihre Repräsentation als Beschrei-bungssprachen. Diese Gerätemodelle werden insbesondere in der Detailplanung und Inbe-triebsetzung genutzt und stellen die Vorgaben für die Konfiguration dar. In den Geräte-modellen werden vornehmlich Informationen hinterlegt, die einen Gerätetyp kennzeichnen. Für instanzbezogene Informationen sind aber zumindest Platzhalter vorgesehen, die dann die Abbildung der Realwerte aus den Instanzen aufnehmen. Für den Zugriff zur Laufzeit bein-halten die Geräteinstanzen vielfach Datenstrukturen mit aktuellen Instanzdaten, die über das Kommunikationssystem protokollspezifisch auslesbar und ggf. schreibbar sind. Die protokoll-technische Abbildung ist für die Ermittlung relevanter Informationen für das FiLiA-Modell nicht von Bedeutung, wohl aber der Aufbau der Datenstrukturen. Ein Beispiel für derartige Struktu-ren sind die Identification and Maintenance-Informationen, die für PROFIBUS und PROFI-NET IO in [8] beschrieben sind. Hier sind typbezogene und instanzbezogene Informationen in einer gemeinsamen Struktur abgelegt.

Für den Anwendungsfall der Gerätebeschaffung in der Detailplanung werden zunehmend Gerätemerkmale definiert und Merkmalsleisten zugeordnet. Derartige Merkmalsleisten kenn-zeichnen einerseits Anforderungen an die Geräte, die aus applikativer Sicht entstehen (z.B. stoffliche Eigenschaften oder Arbeitsbereiche bei Mess- und Stellfunktionen und -geräten), aber auch Betriebseigenschaften der Geräte, die diese Funktionen in der Anlage realisieren. Diese Betriebsmerkmalsleisten und Gerätemerkmalsleisten sind nach IEC 61987 [9] aufge-baut. Die relevanten Merkmale, die derzeit verfügbar sind, wurden bei der Analyse berück-sichtigt.

Als weitere Literaturquellen dienten folgende Standards: IEC 61804-3 [10], ISO 15745 [1], IEC 62390 [11], IEC 62541 (OPC UA) [12], IEC 62453 (FDT) [13], IEC 62769 (FDI) [14], IEC 62657 [15], WSAN-FA Spezifikation [16], [17].

Tabelle 2: Definition und Zuordnung funkspezifischer Parameter

Kategorie Parameter Definition

Fun

kkom

pon

ente

Product Name Produktname der Funkkomponente

Product Type Produkttyp der Funkkomponente

Product Code Strichcode, Bestellcode

Hardware Version Hardwareversion der Funkkomponente

Software Version Softwareversion der Funkkomponente

Serial Number Seriennummer der Funkkomponente

Production Date Produktionsdatum der Funkkomponente

Vendor Information Herstellerinformation

Contact Data Kontaktdaten des Herstellers (Adresse, Telefonnummer)

Static Address Statische Adresse, z.B. MAC-Adresse

Dynamic Address Dynamische Adresse, z.B. IP-Adresse

Radio Technology or Standard

Eine Reihe von Eigenschaften werden durch die ausgewählte Funktechnologie oder den -standard vordefiniert: z.B. die Modulation und das Coding.

Media Access Mode Medienzugriffsverfahren (z.B. TDMA/CSMA)

Frequency Bands Verschiedene Frequenzbänder können zur drahtlosen Kommunikation verwendet werden. Beispiele sind das 2.4 GHz und 5 GHz Band.




Modulation Ein Signal bekommt sein Informationsgehalt durch Änderung der Amplitude, Frequenz oder der Phase einer Welle. Dies erfolgt durch die Modulation der Welle

Coding Beschreibt die verwendete Codierung für ein Symbol während der Funkübertragung

Frequency/Radio Channels Bei manchen Technologien werden Kanäle anstelle von Centerfrequenz und Bandbreite definiert, um einen bestimmten Frequenzbereich im Band zu beschreiben.

Data Rate Dieses Attribut beschreibt die Datenrate, welche auf der Luftschnittstelle verwendet wird.

Transmit Power Beschreibt die Sendeleistung, die im Gerät konfiguriert werden kann.

Receiver Sensitivity Die Empfängerempfindlichkeit beschreibt, wie gut der Receiver das gewollte Signal bei Abwesenheit von Interferenzen akzeptieren kann.

Maximum number of retransmissions

Dieses Attribut definiert, wie oft eine Übertragung im Falle von erkannten Fehlern wiederholt wird.

Transmission Time Übertragungszeit, siehe VDI/VDE-Richtlinie 2185

Update Time Aktualisierungszeit, siehe VDI/VDE-Richtlinie 2185

Packet Loss Rate Paketverlustrate, siehe VDI/VDE-Richtlinie 2185

Data Throughput Datendurchsatz, siehe VDI/VDE-Richtlinie 2185

Response Time Antwortzeit, siehe VDI/VDE-Richtlinie 2185

An

ten

ne

Product Name Produktname der Antenne

Product Type Produkttyp der Antenne


Hardware Version Hardwareversion der Antenne

Software Version Softwareversion der Antenne

Serial Number Seriennummer der Antenne

Production Date Produktionsdatum der Antenne



Antenna Type Art der Antenne, z.B. omni-direktional, direktional, Antennenarrays, PCB




Antenna Characteristic Die Antennencharakteristik wird in Form von Diagrammen dargestellt

Antenna Gain Da reale Antennen nicht ideal omni-direktional sind, wird hier die Richtwirkung beschrieben

Antenna Architecture Neben einfachen Antennen sind auch diversitäre oder Antennenarrays (MIMO) möglich

Antenna Radiation Pattern Veränderung der Feldintensität einer Antenne als eine Winkelfunktion bezogen auf die Achsen

Antenna Position Antennenposition

Po

we

r

Su

pp

ly

Power Sources Energiequelle der Funkkomponente: Leitungs-gebunden / Autark

Power Supply Related Attributes

Attribute, die beschreiben, wie das Gerät mit Energie versorgt wird und welche Energiesparmethoden zur Verfügung stehen.

Fun

kge

rät

Product Name Produktname des Funkgerätes

Product Type Produkttyp des Funkgerätes


Hardware Version Hardwareversion des Funkgerätes

Software Version Softwareversion des Funkgerätes

Serial Number Seriennummer des Funkgerätes

Production Date Produktionsdatum des Funkgerätes



Network Device Type Netzwerkgerätetyp: In Abhängigkeit von der Technologie oder Implementierung kann ein Gerät unterschiedliche Rollen in einem Netzwerk annehmen.

Static Address Statische Adresse, z.B. MAC-Adresse

Dynamic Address Dynamische Adresse, z.B. IP-Adresse

RF Output Power (EIRP/ERP) (Equivalent Isotropically Radiated Power, Effective Radiated Power

Diese Leistung ist die Leistung, die der Antenne übergeben wird, multipliziert mit der Antennenverstärkung durch Richtcharakteristik

Power Spectral Density Signalleistung durch definierte Bandbreite

Relative Movement Beides, die relative Geschwindigkeit zwischen Funkkomponenten und die Trajektorie, kann das Fehlerverhalten der Funkübertragung beeinflussen und könnten deshalb ungünstige Voraussetzungen für die Koexistenz sein.









Ne

tzw

erk

Network Identifier Eindeutiger Bezeichner des gesamten Netzwerks

Topology Die Topologie beschreibt die Struktur und den Aufbau eines drahtlosen Systems (Punkt-zu-Punkt, Stern, Baum, Mesh)

Number of Wireless Devices Anzahl an drahtlosen Geräten, dabei wird die Anzahl gemeint, die zur Erfüllung der Automatisierungsapplikation notwendig ist.

Infrastructure Components Infrastrukturkomponenten sind Geräte wie Router oder Basisstationen, ohne direkte Verbindung zur Automatisierungsanwendung.

Positions of Wireless Devices and Distances between them

Die Positionen aller drahtlosen Geräte einer verteilten Automatisierungsanwendung sollten in einer Skizze des Applikationsbereiches ein-getragen werden. Die Distanz kann im Falle von mobilen Funkkomponenten dynamisch variieren.

Physical Links Die Anzahl an physikalischen Verbindungen beinhaltet alle physikalischen Kommunika-tionsbeziehungen zwischen 2 drahtlosen Geräten eines drahtlosen Systems. Zwischen 2 drahtlosen Geräten existiert nur ein physikalischer Link.

Spatial Coverage of the Wireless Communication Network

ist abhängig von den Kommunikationsanforde-rungen der Anwendung. Es ist allerdings aus-schlaggebend für die Realisierbarkeit einer räumlichen Trennung von drahtlosen Systemen.









An

we

nd

un

g

Application Fields Anwendungsfelder: Wireless HMI, Wireless Control, M2M, Wireless failsafe, Mono track rail, AGV, Cranes, VoIP,…

Communication Load Anforderung der Automatisierungsanwendung eine bestimmte Menge von Nutzdaten innerhalb einer bestimmten Zeitspanne zu übertragen.

Characteristic of the Area of Operation

Folgende Einsatzgebiete werden betrachtet: Indoor, Outdoor, Indoor und Outdoor

Initiation of Data Transmission

Dieser Parameter spezifiziert, wie die Anwendung den Datentransfer initiiert: Periodisch, aperiodisch oder stochastisch.

Transmission Interval ist der Zyklus der Nutzdatenpakete am Communication Interface

Other Frequency Users Dieser Parameter beschreibt andere Frequenznutzer, die im selben Bereich Funkwellen ohne die Versendung von Daten ausstrahlen. Ein Beispiel sind Mikrowellen.

Radio Propagation Conditions

Die Ausbreitungsbedingungen beeinflussen die Robustheit eines drahtlosen Systems sowie die Interferenz von anderen drahtlosen Systemen. Sie hängen von der benutzten Frequenz, den Ausmaß und der Charakteristik des Einsatzgebietes, den natürlichen Umgebungsbedingungen und dem Sichtkontakt ab.

Beschreibungen, Datenblätter und Dokumentationen von typischen Funkgeräten und -kompo-nenten wurden ebenfalls analysiert und bei der Bildung der Kategorien berücksichtigt.

Einflussgrößen 29 / 89


5 Einflussgrößen

5.1 Allgemein

Im Vorhaben "FiLiA" wurde das Ziel verfolgt, die Relevanz von Einflussgrößen auf die Kenn-größen industrieller Funklösungen zu untersuchen. Dabei wurde ermittelt, innerhalb welcher Grenzen signifikante Änderungen im Verhalten von Funklösungen festzustellen sind. Außer-dem wurden Einflussgrößen ausgeschlossen, bei denen keine Beziehung zu den definierten Kenngrößen nachgewiesen werden konnte.

Innerhalb dieses Forschungsvorhabens haben sich die Untersuchungen auf folgende Einfluss-größen beschränkt:

Abstand der Teilnehmer

Sendezeitabstand

WLAN Radio Mode

Topologie

Die Tests wurden für ausgewählte Funktechnologien (Bluetooth, WLAN) durchgeführt. Zwischen zwei Teilnehmern einer Technologie wurde dabei lediglich eine Punkt-zu-Punkt-Verbindung aufgebaut. Damit wurde auch die Systemgröße auf zwei Teilnehmer begrenzt. Eine Ausnahme bildete die Untersuchung unterschiedlicher Topologien. In diesem Testszena-rio wurde die Kommunikation zwischen zwei Clients über einen gemeinsamen Access Point hergestellt. Ziel der Untersuchung der ausgewählten Funktechnologien war es, Messergeb-nisse zu liefern, mit welchen die Wirkung von Einflussgrößen auf das Übertragungsverhalten nachgewiesen werden kann.

Die Tests wurden für die zu untersuchende Einflussgröße im Labor durchgeführt. Für die Labortests wurden Messboxen zur Schirmung der Funkgeräte genutzt. Die Entfernung zwi-schen den Funkkomponenten wurde mit Hilfe von Dämpfungsgliedern realisiert, da dadurch unterschiedliche Entfernungen auf diese Weise schnell einstellbar sind. Die Einflussgröße Sendezeitabstand wurde ebenfalls im Labor untersucht. In diesem Testszenario wurden die Entfernung und damit die Dämpfung auf einem konstanten Wert belassen. Beim WLAN Radio Mode wurde das Übertragungsverhalten bei IEEE 802.11a, IEEE 802.11b und IEEE 802.11g untersucht. Bei der Betrachtung der Topologie wurde sich auf den Ad-hoc und den Infra-structure Modus beschränkt. Die einzelnen Testgruppen setzten sich aus mehreren Testfällen zusammen, die sich bezüglich dem Wert der relevanten Einflussgröße unterschieden. Falls erforderlich und sinnvoll, wurden für einen Testfall zunächst Einrichtungstests durchgeführt, um die Wirkung von Einflussgrößenwerten zu ermitteln. Die Einrichtungstests waren durch kleine Stichproben gekennzeichnet (Messdauer: einige Minuten). Ausgewählte Testfälle wur-den mit signifikanten Stichproben durchgeführt (Messdauer: mehrere Stunden).

5.2 Kenngrößen

Für die einheitliche Bewertung der Wirkung unterschiedlicher Einflussgrößen auf das Zeit- und Fehlerverhalten von Funklösungen kamen folgende Kenngrößen zum Einsatz:

Übertragungszeit (Transmission Time): Die Übertragungszeit ist eine Kenngröße zur Bewertung einer Kommunikationsverbindung zwischen zwei Kommunikations-endpunkten. Sie wird nach dem Producer-Consumer-Model ermittelt und ist der Zeit-abschnitt vom Beginn der Übergabe des ersten Nutzdatenbytes eines Paketes an die Kommunikationsschnittstelle eines Test-Producers bis zur Übergabe des letzten Nutz-datenbytes desselben Paketes an die Kommunikationsschnittstelle eines Test-Consumers.

Aktualisierungszeit (Update Time): Die Aktualisierungszeit ist eine Kenngröße zur Bewertung einer Kommunikationsverbindung zwischen zwei Kommunikationsend-punkten. Sie wird nach dem Producer-Consumer-Model ermittelt. Sie ist der Zeitab-schnitt von der Übergabe des letzten Nutzdatenbytes des Paketes eines Test-Produ-cers von der Kommunikationsschnittstelle eines Test-Consumers an die Anwendung



bis zur Übergabe des letzten Nutzdatenbytes des folgenden Paketes vom gleichen Test-Producer.

Paketverlustrate (Packet Loss Rate): Die Paketverlustrate wird nach dem Producer-Consumer-Model ermittelt. Sie drückt aus, wie viele der von der Anwendung im Producer an die Kommunikationsstelle übergebenen Pakete im Consumer von der Kommunikationsschnittstelle an die Anwendung übergeben werden.

Verfügbarkeit (Availability): Die Verfügbarkeit ist ein Maß für die Fähigkeit einer Ein-heit, während eines gegebenen Zeitintervalls eine geforderte Funktion zu erfüllen.

5.3 Einflussgrößen

In diesem Abschnitt wird eine Reihe von Einflussgrößen aufgelistet, bei denen Auswirkungen auf das Kommunikationsverhalten von Funklösungen in Betracht gezogen werden müssen. Diese werden in anwendungsbezogene, geräte- und systemspezifische sowie umgebungs-bezogene Einflussgrößen unterteilt.

Anwendungsbezogene Einflussgrößen: Dies sind Festlegungen, die von der auto-matisierungstechnischen Anwendung bestimmt werden. Mit anwendungsbezogenen Einflussgrößen werden Kommunikationsanforderungen aus Anwendungssicht definiert, zeitliche Randbedingungen der Übertragung festgelegt und die Empfangsbedingungen durch Übertragungsentfernung, Knotendichte und Mediennutzung vorbestimmt.

o Kommunikationssystem Anzahl Kommunikationsgeräte Anzahl logischer Verbindungen Räumliche Ausdehnung des Kommunikationssystems Security-Funktionalität

o Logische Kommunikationsverbindung Endpunkte Abstand zwischen Kommunikationsgeräten Safety-Funktionalität

o Kommunikationsgeräte Position des Kommunikationsgerätes Bewegung des Kommunikationsgerätes Rolle des Geräts im Netzwerk

o Kommunikationslast Nutzdatenlänge Initiierung der Datenübertragung Sendezeitabstand

Geräte- und Systemspezifische Einflussgrößen: Durch eine gezielte Auswahl bzw. Implementierung der Funksysteme lässt sich das Zeit- und Fehlerverhalten der Über-tragung und damit die Zuverlässigkeit und Verfügbarkeit des Kommunikationssystems optimal gestalten.

o Anzahl Funksysteme o Funksystem

Funktechnologie oder -standard Topologie Anzahl Funkgeräte Anzahl der Infrastrukturkomponenten Anzahl physikalischer Funkverbindungen Modulation Bitrate des Funkkanals Medienzugriffssteuerung Security-Mechanismen

o Funkverbindung Funkkomponenten der Funkverbindung Abstand zwischen Funkgeräten Relative Bewegung zwischen den Funkgeräten



Sichtverbindung Anzahl Frequenzkanäle Frequenzband

o Funkgerät Netzwerkgerätetyp Position Anzahl der Antennen Sendeleistung Empfängerempfindlichkeit Maximale Anzahl Paketwiederholungen Zeitliche Mediennutzung Verbindungswechsel Kommunikationszyklus

o Antenne Antennentyp Richtdiagramm Antennengewinn Polarisation Antennenleitung Antennenausrichtung

o Kommunikationsschnittstelle Art der Kommunikationsschnittstelle

Umgebungsbezogene Einflussgrößen: Neben den Anforderungen der Anwendung und den Eigenschaften des Kommunikationssystems und dessen Komponenten beein-flussen die Umgebungsbedingungen die Kenngrößen einer Funklösung. Dabei sind diese Einflussgrößen meist wenig oder gar nicht planbar.

o Anzahl anderer Funksysteme o Anzahl anderer Frequenznutzer o Einsatzbereich

Charakterisierung des Einsatzbereiches Abmessungen des Einsatzbereiches Natürliche Umgebungsbedingungen Signal-Stör-Verhältnis (SIR)

5.4 Testdurchführung

5.4.1 Allgemein

Aus der Vielzahl an zu berücksichtigenden Einflussgrößen wurden einige ausgewählt und mit Hilfe von Messungen überprüft, ob eine Abhängigkeit zwischen Einfluss- und Kenngröße festzustellen ist. Dabei handelte es sich um die Einflussgrößen Distanz, Sendezeitabstand, WLAN Radio Mode und Topologie. Im Folgenden werden die einzelnen Testreihen im Detail erläutert.

5.4.2 Testreihe „Distanz“

Die Testreihe „Distanz“ wurde unter Laborbedingungen durchgeführt. Die Funkkomponenten befanden sich in separaten Messkammern, die eine Dämpfung von 90 dB zur Umgebung aufwiesen. Die Geräte waren über Koaxialkabel miteinander verbunden. Zwischengeschaltet war ein dynamisches Dämpfungsglied zur Nachbildung der Entfernung. Untersucht wurde bei dieser Testreihe die Bluetooth Technologie. Der genutzte Testaufbau ist in Abbildung 11 dar-gestellt. Es wurde jeweils die Ethernet-Schnittstelle der Geräte verwendet. Der Sendezeit-abstand wurde auf 32 ms fest eingestellt. Zur Generierung und Auswertung der Ethernet-Testpakete wurde der Ethernet-Netzwerkanalysator der Firma Anritsu verwendet.



P C

dAB

Anritsu

ConsumerProducer

PC

Abbildung 11: Testaufbau für die Untersuchung von Bluetooth-Komponenten

5.4.3 Testreihe „Sendezeitabstand“

Die Testreihe „Sendezeitabstand“ wurde unter Laborbedingungen durchgeführt. Die Funk-komponenten befanden sich in separaten Messkammern, die eine Dämpfung von 90 dB zur Umgebung aufwiesen. Die Geräte waren über Koaxialkabel miteinander verbunden. Zwischengeschaltet war ein statisches Dämpfungsglied mit einer Dämpfung von 60 dB. Die Testreihe unterteilte sich in zwei Testgruppen entsprechend den Technologien Bluetooth und WLAN. Der Testaufbau zur Untersuchung der beiden Systeme entspricht ebenfalls der Abbildung 11. Bei Bluetooth und WLAN wurden die Ethernet-Schnittstellen der Geräte zur Übergabe der Testpakete verwendet. Zur Generierung und Auswertung der Ethernet-Testpakete wurde der Ethernet-Netzwerkanalysator der Firma Anritsu verwendet.

5.4.4 Testreihe „WLAN Radio Mode“

Die Testreihe „WLAN Radio Mode“ wurde ebenfalls unter Laborbedingungen durchgeführt. Die Funkkomponenten befanden sich in separaten Messkammern, die eine Dämpfung von 90 dB zur Umgebung aufwiesen. Die Geräte waren über Koaxialkabel miteinander verbunden, um störende Beeinflussungen auszuschließen. Zwischengeschaltet war ein statisches Dämpfungsglied mit einer Dämpfung von 60 dB. Die Testreihe unterteilte sich in drei Test-gruppen entsprechend den Radio Modi IEEE 802.11 b, IEEE 802.11 a und IEEE 802.11 g. Entsprechend dem ausgewählten Radio Mode sind unterschiedliche Bitraten zulässig. Durch die Konfiguration des Bitraten-Parameters mit „Auto“ übernahmen die Geräte eine geeignete Auswahl. Die Untersuchung der einzelnen Radio Modi erfolgte jeweils für die Sendezeit-abstände 10 ms, 20 ms und 30 ms. Bei WLAN wurden die Ethernet-Schnittstellen der Geräte zur Übergabe der Testpakete verwendet. Zur Generierung und Auswertung der Ethernet-Testpakete wurde ebenfalls der Ethernet-Netzwerkanalysator der Firma Anritsu eingesetzt.

5.4.5 Testreihe “Topologie”

Die Testreihe „Topologie“ wurde ebenso unter Laborbedingungen durchgeführt. Die Funk-komponenten befanden sich in separaten Messkammern, die eine Dämpfung von 90 dB zur Umgebung aufwiesen. Die Geräte waren über Koaxialkabel miteinander verbunden, um störende Beeinflussungen auszuschließen. Bei der Untersuchung des Infrastructure Modus waren statische Dämpfungsglieder und ein Power Splitter zwischengeschaltet. Die Dämpfung der Clients zum Access Point betrug je 60 dB. Beim Ad-hoc Modus war nur ein statisches Dämpfungsglied von 60 dB zwischen den Geräten angeordnet. Die Testreihe unterteilte sich in zwei Testgruppen entsprechend den Topologien Infrastructure und Ad-hoc. Beim Infrastruc-ture Modus wurde IEEE 802.11 g und beim Ad-hoc Modus IEEE 802.11 b genutzt. Dies wirkte sich auch auf die automatisch ausgewählten Bitraten aus. Bei WLAN wurden die Ethernet-Schnittstellen der Geräte verwendet. Zur Generierung und Auswertung der Ethernet-Test-pakete wurde der Ethernet-Netzwerkanalysator der Firma Anritsu eingesetzt. Die Topologien wurden für unterschiedliche Sendezeitabstände untersucht.



5.5 Ergebnisdarstellung

5.5.1 Überblick

Im folgenden Abschnitt werden die Ergebnisse der beschriebenen Testreihen präsentiert. Die Darstellung erfolgt grafisch in Form von Liniendiagrammen. Als Kenngrößen werden über-wiegend die Übertragungszeit, aber auch die Aktualisierungszeit und Paketverlustrate ver-wendet. Übertragungs- und Aktualisierungszeit entsprechen einer empirischen Verteilung. Um einen besseren Eindruck über die Form der Verteilungen zu erhalten, werden jeweils das Maximum, das Minimum, das Perzentil 95 und der Median in Abhängigkeit von der ent-sprechenden Einflussgröße aufgezeigt.

5.5.2 Distanz

Abbildung 12: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Abstand 60-95 dB

Abbildung 12 zeigt die statistischen Kenngrößen der Übertragungszeit in Abhängigkeit von der Dämpfung. Bis 90 dB weisen Minima, P95 und Median ein relativ konstantes Verhalten auf. Das Maxima steigt bereits etwas eher an.

Abbildung 13: Statistische Kenngrößen der Aktualisierungszeit in Abhängigkeit vom Abstand 60-95 dB

1

10

100

1000

10000

100000

60 65 70 75 80 85 90 95

Tran

smis

sio

n T

ime

[m

s]

Attenuation [dB]

Min

P95

Max

Median

1

10

100

1000

10000

100000

60 65 70 75 80 85 90 95

Up

dat

e T

ime

[m

s]

Attenuation [dB]

Min

P95

Max

Median



Abbildung 13 zeigt das Verhalten der Aktualisierungszeit bei unterschiedlichen Sendezeit-abständen. Wie bei der Übertragungszeit steigen auch die statistischen Kennwerte der Aktua-lisierungszeit ab einer Dämpfung von 90 dB an. Lediglich das Minima fällt ab. Aber auch der Median sinkt zunächst leicht, bevor ein Anstieg erfolgt.

Abbildung 14: Paketverlustrate in Abhängigkeit vom Sendezeitabstand

Abbildung 14 zeigt den Zusammenhang zwischen Paketverlustrate und Sendezeitabstand. Bei einer Dämpfung von 93 dB treten erste Paketverluste auf. Diese steigen mit größer wer-dender Dämpfung stark an. Bei 96 dB werden keine Pakete mehr übertragen.

5.5.3 Sendezeitabstand

Zur Untersuchung des Einflusses des Sendezeitabstandes auf das Übertragungsverhalten der Bluetooth-Komponenten wurden die Testfälle in zwei Teile aufgegliedert. Bei einem Sende-zeitabstand von 5-20 ms wurde das System in einem „gestressten“ Zustand betrieben und bis an dessen Leistungsgrenzen geführt. Im zweiten Abschnitt wurde der Fokus auf den Einfluss der Asynchronität zwischen Kommunikationssystem und -anforderung gelegt.

Abbildung 15: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand 5-20 ms

Die statistischen Kennwerte der Übertragungszeit zeigen kein typisches Verhalten, welches bei einem gestressten System erwartet wird (siehe Abbildung 15). Der Minimalwert bleibt über den gesamten Betrachtungszeitraum konstant. Die Maximalwerte von Maxima und Median

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

60 65 70 75 80 85 90 95 100

PLR

Dämpfung [dB]

0

10

20

30

40

50

60

5 10 15 20

Tran

smis

sio

n T

ime

[m

s]

Transmission Interval [ms]

Min

P95

Max

Median



werden bei 13 ms erreicht. Die Minimalwerte von Maxima, Median und P95 liegen beim kleinsten Sendezeitabstand von 5 ms vor.

Abbildung 16: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand 30-50 ms

Abbildung 16 zeigt den Verlauf der statistischen Kenngrößen bei einem ungestressten Über-tragungssystem. Der Minimalwert ist auch in diesem Bereich konstant. Bei einem Sende-zeitabstand von etwa 38 ms steigen P95 und Maximalwert schlagartig an und verbleiben anschließend auf konstantem Niveau.

Das Diagramm in Abbildung 16 stellt bei einem Sendezeitabstand von 51 ms die Ergebnisse für einen zufälligen Sendezeitabstand zwischen 30 und 50 ms dar. Eine zufällige Anregung des Bluetooth-Systems hat jedoch keine Auswirkung auf das Übertragungsverhalten.

5.5.4 WLAN Radio Mode

Abbildung 17: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (IEEE 802.11b)

Abbildung 17 zeigt das Verhalten des WLAN Systems für unterschiedliche Sendezeitab-stände, wenn das System im Modus IEEE 802.11b betrieben wird. Das Perzentil 95 befindet sich bei etwa 600 µs und der Minimalwert pendelt etwas um 450 µs. Die statistischen Kenn-größen sind von dem Sendezeitabstand unabhängig.

0

10

20

30

40

50

60

30 35 40 45 50

Tran

smis

sio

n T

ime

[m

s]


Min

P95

Max

Median

0,1

1

10

10 15 20 25 30

Tran

smis

sio

n T

ime

[m

s]


Min

P95

Max

Median



Abbildung 18: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (IEEE 802.11a)

Abbildung 18 zeigt die statistischen Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand entsprechend IEEE 802.11a. Es ist zu erkennen, dass die Übertragungs-zeiten des IEEE 802.11a Standards wesentlich geringer als die des IEEE 802.11b Standards sind. Das Perzentil 95 befindet sich bei etwa 420 µs und der Minimalwert pendelt etwas um 320 µs.

Abbildung 19: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (IEEE 802.11g)

Abbildung 19 zeigt die statistischen Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand entsprechend IEEE 802.11g. Im Vergleich zeigt sich, dass die Minimalwer-te der Übertragungszeit von a und g Standard gleich sind. Das Perzentil 95 des IEEE 802.11g Standards weist allerdings einen um etwa 40 µs höheren Wert auf.

0,1

1

10 15 20 25 30

Tran

smis

sio

n T

ime

[m

s]


Min

P95

Max

Median

0,1

1

10

10 15 20 25 30

Tran

smis

sio

n T

ime

[m

s]


Min

P95

Max

Median



5.5.5 Topologie

Abbildung 20: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (Infrastructure Modus)

Abbildung 20 zeigt die statistischen Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (Infrastructure Modus). Das System wurde im Infrastructure Modus betrie-ben. Die Übertragung erfolgte von einem Client zu einem anderen. Die Kommunikation fand mit Hilfe eines Access Points statt. Als Radio Mode wurde IEEE 802.11g verwendet. Die sta-tistischen Kenngrößen der Übertragungszeit sind relativ unabhängig vom Sendezeitabstand. Eine Erhöhung ist lediglich bei 1 ms festzustellen. Der Minimalwert befindet sich bei 1 ms und das Perzentil 95 bei etwa 1,43 ms.

Abbildung 21: Statistische Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (Ad-hoc)

Abbildung 21 zeigt die statistischen Kenngrößen der Übertragungszeit in Abhängigkeit vom Sendezeitabstand (Ad-hoc). Im Ad-hoc Modus erfolgt keine Übertragung über den Access Point. Allerdings erlaubt der Ad-hoc Modus nur den IEEE 802.11b Standard. Minima und P95 mit 0,89 und 1,05 ms liegen unter den Werten des Infrastructure Modus. Die statistischen Kennwerte steigen bei einem zu niedrigem Sendezeitabstand stark an.

5.6 Zusammenfassung

Die Ergebnisse haben gezeigt, dass bei den untersuchten Einflussgrößen eine starke Beein-flussung der Kenngrößen vorhanden ist. Es existieren Bereiche der Einflussgrößen, z.B. bei

0,1

1

10

0 2 4 6 8 10

Tran

smis

sio

n T

ime

[m

s]


Min

P95

Max

0,1

1

10

0 2 4 6 8 10

Tran

smis

sio

n T

ime

[m

s]


MinP95MaxMedian



der Distanz, in denen kein Einfluss auf das Übertragungsverhalten auszumachen ist. In ande-ren Regionen, zum Beispiel in bestimmten Grenzbereichen, kommt der Einfluss der unter-suchten Größen sehr stark zum Tragen. Aus diesem Grund muss eine Vielzahl der Einfluss-größen auch Bestandteil des Modells werden.

Modellbildung 39 / 89


6 Modellbildung

6.1 Grundlagen und Werkzeuge

Die Modellierung der funkbezogenen Eigenschaften erfolgte im Kontext ihres Einsatzes in der Automation. Daraus resultierte einerseits, dass existierende Modelle zu berücksichtigen waren, und andererseits, dass die funkbezogenen Eigenschaften auf Modellelemente abzu-bilden waren, die für den Automatisierungskontext typisch sind.

Um die Allgemeingültigkeit der Modellierung zu gewährleisten, wurde die Modellbildung auf Basis objektorientierter Konzepte durchgeführt, das als Standardparadigma in der Software-entwicklung angesehen werden kann. Die Notation der Modellelemente erfolgte mittels der Sprache UML (Unified Modeling Language). Modellierungskonzept und Notation erlauben damit die Wiederverwendbarkeit der Modellelemente bis hin zur Code-Generierung für Soft-warekomponenten. Die Modellierung erfolgte mit dem Werkzeug IBM Rational Software Architect in der Version 8.5.

Nachfolgend werden ausgewählte Modellierungskonzepte sowie die Kernelemente des Modells vorgestellt, bevor auf ausgewählte Einzelkomponenten des Modells eingegangen wird.

6.2 Modellierungskonzept

Die in den AP 1 und 2 durchgeführte Analyse der einzelnen Informationen hat ergeben, dass verschiedene Akteure die Modellinhalte festlegen. Hier sind insbesondere nach 3.3.7 die Her-steller- und die Betreiber-Aspekte relevant. Die Hersteller definieren im Herstellungsprozess (Produktlebenszyklus) Eigenschaften von Typen, die Betreiber legen im Anwendungslebens-zyklus konkrete Werte für Instanzen fest. Gemäß dem in 3.3.4 beschriebenen Integrationsmo-dell lässt sich diese Grundstruktur für Elemente auf unterschiedlicher Hierarchie anwenden.

Daraus ergaben sich folgende wesentliche Modellhierarchien mit den zugehörigen Typen und Instanzen:

NetworkComponent

Device

Antenna

PowerSupply

Network

Application (nur Instanzsicht).

Die Modellelemente bilden damit die in Abbildung 10 dargestellten Kategorien ab. Sie werden jeweils als Klassen in UML modelliert und bezüglich ihrer Eigenschaften und ihrer Zusam-menhänge weiter detailliert. Durch diesen Modellierungsschritt entsteht das FiLiA-Modell.

Grundsätzlich wurden in das FiLiA-Modell nur diejenigen Eigenschaften aufgenommen, die funkbezogene Aspekte abbilden. Sie sind in der Tabelle 2 aufgeführt. Um den Gesamtzusam-menhang der funkbezogenen Eigenschaften zu denen weiterer Aspekte (z.B. drahtgebundene Komponenten und Netzwerke) herstellen zu können, wurden letztere konzeptionell mit in das Modell aufgenommen, wenngleich nicht weiter detailliert. Somit konnten Abstraktionen bei der Modellbildung gefunden und eingefügt werden, die eine spätere Nachnutzung oder Erweite-rung des Modells ermöglichen.

Die Zuordnung der Modellelemente zu bestehenden Modellen (z. B. zum Gerätemodell nach ISO 15745) ist immer sichtenspezifisch, da es kein allgemeines, übergreifendes Modell gibt oder zumindest keines in der Automation als relevant identifiziert werden konnte. Im Rahmen der Modellierungsarbeiten wurde daher entschieden, bestehende Modelle als Pakete zu nutzen und ggf. Assoziationen zwischen den Elementen des FiLiA-Modells und denen der existierenden Modelle zu definieren. Diese Assoziationen bilden später die Basis für Trans-formationen, mit denen Modellinhalte in die Zielmodelle überführt werden können. Dieses



Vorgehen stellt sicher, dass das FiLiA-Modell in sich konsistent gehalten werden kann und die relevanten Informationen konzentriert dargestellt werden können.

6.3 Kernelemente des FiLiA-Modells

Das FiLiA-Modell (Abbildung 22) enthält zunächst die Klassen, die die Typinformationen und die Instanzinformationen für die Modellhierarchie abbilden. Zwischen den Typklassen und den Instanzklassen besteht immer einer Instanziierungsrelation. So ist z.B. eine Geräteinstanz (DeviceInstance) immer mit einer zugehörigen Typklasse (DeviceType) verbunden, im Bei-spiel durch die Relation isInstanceOfDeviceType dargestellt.

Neben der Instanziierungsrelation sind die grundlegenden Zusammenhänge zwischen den Modellelementen durch Assoziationen modelliert. Diese Zusammenhänge existieren auf der Typebene und der Instanzebene. So können z.B. einem DeviceType mehrere NetworkCom-ponentTypes zugeordnet werden. Hier liegt die Idee eines Kataloges zu Grunde, der alle mög-lichen NetworkComponentTypes aufführt. Eine Teilmenge davon kann in einem DeviceType enthalten sein. Diese Teilmenge wird über die Relation hasComponentType abgebildet. Ähn-liche Assoziationen beschreiben die Zusammenhänge zu Spannungsversorgungen (Power-SupplyType) oder zu Antennen (AntennaType).

Zu einem Typ einer beliebigen Klasse können mehrere Instanzen in einem Modell existieren. Die Verbindung zwischen der Typklasse und den zughörigen Instanzklassen erfolgt über die Instanziierungsrelation. Die Zusammenhänge zwischen den verschiedenen Typklassen besit-zen daher Entsprechungen auf der Instanzebene. So existiert eine Assoziation zwischen der Instanzklasse DeviceTypeInstance und NetworkComponentInstance. Für alle Instanzen von NetworkComponentInstance, die einer Instanz von DeviceInstance tatsächlich zugeordnet sind (z.B. in diese verbaut, gesteckt oder angeschlossen), wird die Relation hasNetwork-ComponentInstances gesetzt.



Abbildung 22: Kernelemente des FiLiA-Modells



6.3.1 Identifikationsdaten

Die in Abschnitt 3.3.7 und 6.2 erwähnten unterschiedlichen Rollen von Herstellern und An-wendern führten zur getrennten Modellierung von Identifikationsdaten aus Hersteller- und An-wendersicht sowie aus Typ- und Instanzsicht. Die Klasse TypeInformation enthält diejenigen Eigenschaften, die typischerweise durch die Hersteller für einen Typ festgelegt werden. Sie bildet daher die folgenden Eigenschaften ab:

ProductName

ProductCode

HardwareVersion

SoftwareVersion

VendorInformation

ContactData

Ein Hersteller legt diese Informationen bei der Planung und Entwicklung des Produktes fest. Die Klasse InstanceInformation beschreibt die instanzbezogenen Informationen

SerialNumber

ProductionDate

Auch diese Informationen werden vom Hersteller definiert, allerdings nicht für ein Produkt als Typ, sondern spezifisch für jedes gefertigte Exemplar (Instanz) dieses Typs.

Abbildung 23 zeigt die Klassen für diese Informationen.

Abbildung 23: Klassen TypeInformation (links) und InstanceInformation (rechts)

Die Datentypen der Eigenschaften können in der Umsetzung noch weiter verfeinert werden. Aus der Analyse bestehender Modelle konnten keine übergreifend festgelegten Datentypen gefunden werden. Bei der Umsetzung des Modells sind demzufolge ggf. Transformationen zur Typkonvertierung erforderlich.

Die beschriebenen Klassen werden von den verschiedenen Modellelementen (Device, Net-workComponent, PowerSupply, Antenna) jeweils über Assoziationen eingebunden. Damit ist die Gleichartigkeit dieser Informationen sichergestellt.

Die durch die Anwender festlegbaren Informationen zur Identifikation sind z.B. in Form von Namen an verschiedenen Stellen in die Instanzklassen integriert.

6.3.2 Das Modellelement Device

Das Modellelement DeviceType stellt die Typklasse für ein Gerät dar. Ein Gerätetyp ist immer durch eine eineindeutige Kennzeichnung (DeviceID) identifizierbar. Die weiteren Identifika-tionsdaten sind in der Klasse TypeInformation (6.3.1) abgelegt, die durch die Relation DeviceTypeInformation erreichbar ist.

Eine Geräteinstanz wird durch die Instanzklasse DeviceInstance repräsentiert, die über die Instanziierungsrelation isInstanceOfDeviceType mit der Typklasse verbunden ist. Die Geräte-instanz kann ebenfalls durch eine eineindeutige Kennzeichnung (DeviceInstanceID) im Modell



identifiziert werden. Über die Relation DeviceInstanceInformation kann auf die weiteren instanzbezogenen Identifikationsinformationen zugegriffen werden.

Die restlichen Eigenschaften der Instanzklasse beinhalten die in Tabelle 2 für die Komponente Funkgerät definierten Eigenschaften, soweit diese nicht in unterlagerten Modellteilen (z.B. NetworkComponent) abgebildet sind.

In Abbildung 24 sind die beschriebenen Klassen und ihre Zusammenhänge als Klassen-diagramm dargestellt.

Abbildung 24: Klassendiagramm des Modellelements Device

6.3.3 Das Modellelement NetworkComponent

Das Klassendiagramm in Abbildung 25 stellt die Typ- und Instanzklasse für Network-Component sowie deren Beziehungen zu den Identifikationsinformationen dar. Die Klassen für dieses Modellelement wurden eingefügt, um grundsätzlich drahtlose und drahtgebundene Baugruppen und deren Eigenschaften modellieren zu können. Von diesen Klassen werden nur abgeleitete Klassen tatsächlich im Modell benötigt. Daher sind beide Klassen als abstrakte Klassen definiert. Sie beinhalten übergreifende Informationen, die durch Generalisierung aus den Informationen in Tabelle 2 entstanden sind. So kann z.B. die StaticAddress die (fest eingeprägte) Schicht-2-Adresse nach OSI-Modell sein (entspricht der MAC-Adresse bei Ether-net), wohingegen DynamicAddress eine dynamisch zugewiesene Adresse wie die IP-Adresse sein kann. Typ- und Instanzrelationen sind gemäß 6.2 aufgebaut.



Abbildung 25: Klassendiagramm des Modellelements NetworkComponent

6.3.4 Das Modellelement WirelessComponent

Von den abstrakten Klassen NetworkComponentType und NetworkComponentInstance wer-den Spezialisierungen für drahtgebundene Komponenten (WiredComponent) und für draht-lose Komponenten (WirelessComponent) abgeleitet. Es existiert eine echte Vererbungsbezie-hung, jeweils für die Typklassen (Abbildung 26) und für die Instanzklassen (Abbildung 27).

Abbildung 26: Vererbungshierarchie der Klasse NetworkComponentType



Abbildung 27: Vererbungshierarchie der Klasse NetworkComponentInstance

Die Klassen WiredComponentType und WiredComponentInstance wurden im Kontext des Projektes nicht weiter betrachtet. Sie sind für künftige Erweiterungen vorgesehen und können entsprechend weiter detailliert werden.

Die Klasse WirelessComponentType fasst im Sinne einer Generalisierung die funkbezogenen Eigenschaften aus Tabelle 2 zusammen. Hier wurden vergleichbare Eigenschaften durch Analyse der Kenngrößen (APs 2 und 3) zusammengetragen. In der Typklasse werden wiede-rum diejenigen dieser Eigenschaften abgelegt, die für einen Komponententyp stehen. So ist z.B. im Attribut DataRates hinterlegt, welche Datenraten durch den Typ unterstützt werden. Da diese Datenraten von anderen Eigenschaften wie Modulation abhängen, werden die Eigenschaften als Bestandteil einer komplexen Datenstruktur (DataRateType) abgebildet, die wiederum als Modellelemente verfügbar sind. In Abbildung 28 ist dies als Klassendiagramm dargestellt. Über die Kardinalität ist eine Zuweisung einer Liste von Elementen des Typs DataRateType möglich, dies stellt den Wertebereich der unterstützten Datenraten dar.

In einem Werkzeug zur Konfiguration oder zur Anzeige, welches das FiLiA-Modell nutzt, kann für eine einzelne Instanz festgelegt bzw. angezeigt werden, welche Datenrate aktuell in dieser Instanz genutzt wird. Das Attribut DataRate ist hier ebenfalls enthalten, allerdings mit einer Kardinalität von 1. Der Wertebereich der Instanz wird aus dem Wertebereich des Typs gebil-det, der Typ kann über die Instanziierungsrelation der Oberklasse (NetworkComponent) er-reicht werden.



Abbildung 28: Detaildarstellung der Eigenschaft DataRate

Für weitere Eigenschaften wurden entsprechende Detailabbildungen definiert, die jedoch aus Gründen der Übersichtlichkeit hier nicht ausführlich beschrieben werden. Eine Dokumentation des Modells existiert, in der diese Details enthalten sind.

Wie erwähnt, stellen die Klassen WirelessComponentType und WirelessComponentInstance Generalisierungen dar, die für einzelne Technologien oder Lösungen weiter detailliert werden müssen. Hierzu wurden für die betrachteten Technologien IEEE 802.11 (WLAN), IEEE 802. 15.1, IEEE 802.15.4 und WirelessHART spezifische Klassen abgeleitet. Diese Vererbungs-relation ist in Abbildung 29 für die Typklassen und in Abbildung 30 für die Instanzklassen dar-gestellt. Die Modellierung der einzelnen Detailinformationen ist in der Dokumentation ent-halten.

Abbildung 29: Vererbungshierarchie der Klasse WirelessComponentType



Abbildung 30: Vererbungshierarchie der Klasse WirelessComponentInstance

6.3.5 Das Modellelement PowerSupply

Die Spannungsversorgung für Geräte und ihre Komponenten wird durch das Modellelement PowerSupply abgebildet. Das Klassendiagramm dafür ist in Abbildung 31 dargestellt. Die Typklasse, die Instanzklasse sowie die modelltypischen Relationen sind darin erkennbar.

Weitergehende Eigenschaften des Typs beziehen sich zum Beispiel auf die maximale Leis-tung der Spannungsversorgung. Eigenschaften der Instanz sind demgegenüber die noch ak-tuell zur Verfügung stehende Restkapazität sowie das Installationsdatum. Letzteres ist insbe-sondere für Szenarien wie Batteriewechsel relevant, da ein Werkzeug über diese Eigenschaft die Zeiten bestimmen kann, zu welcher die Batterie gewechselt werden sollte.

Weitere Ergänzungen können herstellerspezifisch sein und stellen Erweiterungen des Modells dar.

Abbildung 31: Klassendiagramm des Modellelements PowerSupply

Komponenten zur Spannungsversorgung können durchaus mehrfach auftreten und ganzen Geräten wie auch explizit einzelnen Komponenten zugeordnet werden. Diese Zuordnung wird im Modell durch die Assoziation isConnectedToPowerSupplyInstance realisiert (Abbildung 32). In dieser Abbildung ist auch die Relation zwischen Komponenten und Geräten zu sehen.



Abbildung 32: Relation zwischen Spannungsversorgung, Gerät und Komponente

6.3.6 Das Modellelement Antenna

Antenneneigenschaften sind für die Auslegung und für das Management von funkbasierten Systemen von wesentlicher Bedeutung. Demzufolge ist im FiLiA-Modell mit dem Modell-element Antenna ein Konstrukt verfügbar, das Eigenschaften von Antennen abbildet. In Abbildung 33 ist das entsprechende Klassendiagramm abgebildet. Neben den modelltypischen Strukturierungen in Typklasse (AntennaType) und Instanzklasse (AntennaInstance) sind die Relationen zu den Identifikationsdaten erkennbar.

Abbildung 33: Klassendiagramm des Modellelements Antenna

Die Antenneninstanzen können von Instanzen des Modellelements WirelessComponent refe-renziert werden. Dies repräsentiert die physikalische Verbindung der Funkkomponente mit einer oder mehreren Antennen. Die Antenneneigenschaften (Eigenschaften der Typklasse) und die Einsatzbedingungen (Eigenschaften der Instanzklasse) können somit für das Mana-gement der Funkkomponente genutzt werden. Abbildung 34 verdeutlicht diesen Zusammen-hang.



Abbildung 34: Relation zwischen Antenne und Funkkomponente

6.3.7 Das Modellelement Network

Netzwerkbezogene Eigenschaften nach Tabelle 2 werden im Modellelement Network abge-bildet. Hier besteht wiederum eine Typsicht und eine Instanzsicht, so dass die entsprechen-den Klassen und ihre Instanziierungsrelation modelliert wurden (Abbildung 35). Weiterhin ist in dieser Abbildung ersichtlich, dass Network abstrakt ist und die abgeleiteten Klassen für WiredNetwork und WirelessNetwork erstellt wurden. Im Rahmen des FiLiA-Modells wurden nur die Klassen für WirelessNetwork weiter detailliert. Die Zuordnung von NetworkCompo-nentInstances zu einem Netzwerk erfolgt mittels Aggregation.



Abbildung 35: Klassendiagramm des Modellelements Network

Die Typklasse NetworkType beschreibt mögliche Topologien, die für dieses Netzwerk einsetz-bar sind. Eine solche Topologie ist für die Instanzklasse auszuwählen. Die Instanzklasse ent-hält weiterhin Informationen zur Servicequalität (TransmissionTime, UpdateTime, PacketLoss-Rate, DataThroughput, ResponseTime aus Tabelle 2) sowie zur physikalischen Verbindung (z.B. Datenrate und Teilnehmer – hier beginnt die Aggregation zu den NetworkComponent-Instances).

Für ein WirelessNetwork ist neben dem Namen des Netzes (z.B. SSID bei WLAN) die maxi-male Anzahl der Teilnehmer relevant, zusätzlich werden für eine Netzwerkinstanz auch die aktuell im Netzwerk verfügbaren Geräte, deren Positionen, die räumliche Abdeckung des Netzes sowie die Angaben zur netzwerkweiten Festlegung von Security-Eigenschaften abge-bildet.

6.3.8 Das Modellelement Application

Dieses Modellelement fasst letztlich die Anwendungsanforderungen zusammen und stellt diese im Modell mit der Klasse Application zur Verfügung, die streng genommen eine Instanz einer Applikation beschreibt. Hier wurde aus Aufwandsgründen auf eine explizite Modellierung einer Typklasse verzichtet. Über eine Aggregationsbeziehung lässt sich der Zusammenhang zwischen der Applikation und den bei ihrer Realisierung genutzten Netzwerkinstanzen ab-bilden.



Abbildung 36: Klassendiagramm und Relationen des Modellelements Application

In der Klasse Application können neben übergreifenden Eigenschaften wie Anwendungsfeld, globale Kommunikationslast und Zyklus, Einsatzgebiet (Indoor, Outdoor), Ausbreitungsbedin-gungen auch Informationen zu weiteren Frequenznutzern (Tabelle 2) hinterlegt werden und u.a. für Planungs- und Managementprozesse genutzt werden.

6.4 Datentechnische Repräsentation des Modells

Die in UML modellierten Zusammenhänge der Modellelemente sollen durch Werkzeuge ent-lang des Lebenszyklus genutzt werden. Dies erfordert den sichtenspezifischen Zugriff auf die Modellteile und die in ihnen abgebildeten Informationen.

Ein globales Austauschformat für die in Funknetzwerken verwendeten Daten existiert bisher nicht. Es ist auch nicht abzusehen, dass dies entwickelt wird. Grund hierfür ist die Spezifik der Sichten. Es ist hingegen sinnvoll, eine Lösung zu entwickeln, die eine leichte Überführbarkeit der für eine Sicht relevanten Daten erlaubt.

Durch eine Umsetzung des Modells auf eine XML-Repräsentation kann diese aufwandsarme Überführung in verschiedene Zielformate realisiert werden. Daher wurde das Modell auf ein XML-Schema abgebildet. Das Schema wurde so entwickelt, dass es die Beziehungen zwischen den Modellelementen (Vererbung, Aggregationen und Assoziationen) abbildet und selbst erweiterbar ist (z.B. durch ##any-Konstrukte).

In der XML-Schema-Sprache sind Vererbungsbeziehungen leicht abbildbar, die Assoziationen mussten hingegen explizit modelliert werden. Die Instanziierungsrelation wurde wie auch die Aggregation von Modellelementen über IDs und Referenzen realisiert, die über Constraints (z.B. Unique-Mechanismen) weiter eingeschränkt werden können. Die Referenzen müssen beim Erzeugen der Instanzdaten – also der .xml-Datei des Modells – angelegt werden. Dies kann durch Werkzeuge unterstützt werden bzw. bei der Transformation.

Die Entwicklung des Schemas erfolgte auf Basis des UML-Modells durch Transformation und Nachbearbeitung mit dem Werkzeug XMLSpy aus dem Altova MissionKit 2009.

6.4.1 Abbildung der Kernmodellelemente

Das Basiselement für das Modell ist das Element FiLiA_Model, das wie alle Elemente dem Namespace http://www.ifak.eu/FiLiA/2012/07/FiLiA_Model angehört. Dieses Element enthält Container für die einzelnen Klassen der Modellelemente aus 6.3. Die Kardinalitäten sind aus Flexibilitätsgründen weit gefasst (1..* für die Elemente, 0..* für die Applikation). Die Modell-elemente selbst wurden als ComplexTypes definiert und werden von den Containern genutzt. In Abbildung 37 ist das Basiselement in der grafischen Notation des XMLSpy dargestellt.



Abbildung 37: Schemadarstellung des Basiselements

Die Typ- und Instanzklassen der Modellelemente wurden in benannte komplexe Elemente überführt. Dadurch lassen sich diese Definitionen wiederverwenden. In Abbildung 38 ist die Definition der Identifikationsdaten dargestellt, wobei links die Typinformationen und rechts die Instanzinformationen zu sehen sind.

Abbildung 38: Schemadarstellung der Typ- und Instanzinformation

Die Wiederverwendung dieser Informationen erfolgt in den Modellelementen Device, Network-Component, PowerSupply und Antenna sowie in den abgeleiteten Elementen. Beispielhaft soll hier nur die Klasse Device dargestellt werden. In Abbildung 39 ist die Abbildung der Typklasse gezeigt. Das Element DeviceTypeInformation ist vom Typ TypeInformation und verwendet die in Abbildung 38 dargestellten Typinformationen wieder. Die gelbe Hinterlegung macht dies kenntlich.

Das Attribut DeviceID stellt die ID dar, über welche die Instanzen dieser Klasse im XML-Doku-ment identifiziert werden können. Dies entspricht der Identifikation der in einer Realisierung des Modells vorhandenen verschiedenen Gerätetypen. Diese ID wird in der Instanzklasse (Abbildung 40) genutzt, um die Instanziierungsrelation abzubilden. Dazu enthält die Instanz-klasse das Element isInstanceOfDeviceType, das eine DeviceID beinhaltet. Über die hier nicht dargestellten Constraints Unique wird sichergestellt, dass DeviceIDs eineindeutig sind, über



das Paar Key – Keyref wird festgelegt, dass nur IDs referenziert werden können, die existie-ren. Das Element hasNetworkComponentType ist ein Beispiel für die Realisierung der Aggre-gation, welche die Zuordnung von Typklassen des Elements NetworkComponent zur Typ-klasse des Elements Device abbildet.

Abbildung 39: Schemadarstellung der Typklasse DeviceType



Abbildung 40: Schemadarstellung der Instanzklasse DeviceTypeInformation

Eine weitere Aggregation ist in der Instanzklasse zu sehen, das Element isConnectedTo-PowerSupplyInstance enthält die Referenzen zu den Instanzen der Spannungsversorgungs-komponenten.

Für die Abbildung der Vererbungsbeziehungen wurde auf den Mechanismus der Vererbung durch Erweiterung (derivation by extension) der XML-Schema-Sprache zurückgegriffen. Dies soll exemplarisch am Modellelement WirelessNetworkComponent gezeigt werden. In Abbildung 41 ist ein Ausschnitt der Typklasse dargestellt. Die Vererbung von der (abstrakten) Oberklasse NetworkComponentType ist durch die gelbe Hinterlegung erkennbar.



Abbildung 41: Schemadarstellung der Typklasse WirelessComponentType

Die in Abbildung 42 dargestellte abgeleitete Typklasse IEEE_11ComponentType beschreibt einen Typ einer WLAN-Komponente und spezialisiert daher die Informationen der allgemeinen Klasse WirelessComponentType und ergänzt diese um WLAN-spezifische Eigenschaften.



Abbildung 42: Schemadarstellung der Typklasse IEEE_11ComponentType

Die Nutzung von Frequenzbändern und Kanälen ist per se allgemein für Funkkomponenten, die tatsächlich verwendbaren Bänder und Kanäle hängen natürlich vom Funkstandard ab und werden außerdem durch weitere Regularien eingeschränkt. Die von einem Typ einer Funk-komponente unterstützten Bänder und Kanäle werden in der Instanz der Typklasse einge-tragen. Dies erfolgt durch Referenzierung der festgelegten Bänder und Frequenzen, die in einem separaten Dokument (6.4.2) gepflegt werden. Die Referenz wird durch das Element FrequencyBands der Typklasse realisiert, das Referenzen auf Bänder (FrequencyBandRef) enthält. Die Bänder können noch separat benannt werden.

Die Bänder enthalten die Referenzen auf die zugehörigen Kanäle. Wenn ein Typ einer Funk-komponente einzelne Frequenzen nicht unterstützt, so wird die Referenz nicht gesetzt. In einer Instanz der Funkkomponente können die Referenzen als Initialwerte übernommen oder weiter eingeschränkt werden. Dies ist z.B. bei der applikationsspezifischen Festlegung der Kanalnutzung durch Konfigurationswerkzeuge oder durch das Frequenzmanagement möglich. Der aktuell eingestellte Kanal bei WLAN oder der aktuell genutzte Kanal bei Systemen mit Frequenzhopping ist über ein Element in der Instanz abbildbar.

Das im Abschnitt 6.3.4 beschriebene Detail DataRate (Abbildung 28) ist auf das Element DataRates abgebildet. Die Kombination aus den verschiedenen die Datenrate bestimmenden Eigenschaften ist durch den complexType DataRateType beschrieben. Dieser verwendet – in Analogie zur UML-Modellierung – einen Typ, der Werte und Einheiten kombiniert, und erwei-tert diesen um Angaben zu Modulation usw.

Eine XML-Datei, die dem Schema folgt, nach XML-Konventionen also durch einen Parser als gültig gekennzeichnet wird, enthält eine Realisierung des Modells. Ein Fragment einer Beispieldatei ist in Abbildung 43 dargestellt. Sie enthält einen Gerätetyp mit der ID „DT4“, von dem eine Instanz mit der ID „ID4“ existiert. Im Gerätetyp können zwei Komponententypen „EthernetID“ und „IEEE_11ComponentTypeID“ eingesetzt werden, von denen in der Instanz „ID4“ aber nur eine Instanz der WLAN-Komponente enthalten ist (NWComponentInstanceRef = "WLESS_WLAN_ID2").

Vererbung und Abstraktion der Modellelemente führen in der Instanzdatei dazu, dass die Basisklasse angegeben wird und eine explizite Typisierung der tatsächlich eingesetzten Klas-se nachfolgend spezifiziert wird. Im Beispiel ist das am Statement „<NetworkComponentType xsi:type="IEEE_11ComponentTypeT" NWComponentTypeID="IEEE_11ComponentTypeID"/>“ erkennbar, das die abgeleitete Klasse IEEE_11ComponentTypeT anstelle der abstrakten Basisklasse NetworkComponentType einsetzt. Anhand des xsi:type-Konstrukts weiß der Par-ser, welche Klasse hier eingesetzt wird und kann entsprechend prüfen.



Abbildung 43: Fragment einer Beispieldatei

6.4.2 Abbildung der Frequenzbänder und Kanäle

Während die in den bisher beschriebenen Modellelementen abgebildeten Informationen eher dynamisch über den Lebenszyklus verarbeitet und geändert werden, gibt es Zusammen-hänge, die weitestgehend statisch sind. Hierzu gehören z.B. durch physikalische Gesetzte oder auch durch Regularien festgelegte Informationen. Diese werden in der Umsetzung nach XML als separate Modellteile abgebildet und referenziert.

Die Abbildung der Kanäle und Frequenzbänder ist ein Beispiel für diese Kategorie. Demzu-folge wurde eine XML-Datei erzeugt, die diese Informationen enthält. Dazu existiert im XML-Schema des FiLiA-Modells ein Basiselement FrequencyBands, das in den unterlagerten Ele-menten die einzelnen Kanäle mit ihren Details beschreibt. Ein Band und ein Kanal hat jeweils eine ID, über die die Referenzierung aus dem Modell erfolgt. Die IDs müssen im jeweiligen Kontext (Band bzw. Kanal) eineindeutig sein, was durch die Constraints erreicht wird. Optional können Namen vergeben werden. In Abbildung 44 ist die Schemadarstellung aufgeführt.

In der Instanzdatei sind die einzelnen Kanäle mit ihren Kenngrößen wie Mittenfrequenz, Bandbreite, etc. entsprechend der Schema-Datei hinterlegt. Hierbei ist anzumerken, dass die Kanäle allgemeine Namen erhalten haben, die bei der Referenzierung aus dem Modell technologiespezifisch benannt werden können (z.B. WLAN_Channel_1 in einer Instanz der Typklasse IEEE_11ComponentType). Dieser technologiespezifische Name ist jedoch nur in der Typklasse hinterlegt, nicht in der Datei der Kanäle selbst. Ein Fragment der Instanzdatei ist in Abbildung 45 dargestellt.



Abbildung 44: Schemadarstellung der Frequenzbänder und Kanäle

Abbildung 45: Fragment der Instanzdatei der Frequenzbänder und Kanäle

Frequenzmanagement-Prozess 59 / 89


7 Frequenzmanagement-Prozess

7.1 Allgemein

Funkkommunikation in der Automatisierungstechnik trägt dazu bei, Fertigungsprozesse kos-tengünstiger, flexibler und zuverlässiger zu gestalten, und ermöglicht zudem die Umsetzung neuer Automatisierungskonzepte. Automatisierungsanwendungen stellen aber in der Regel höhere Anforderungen an Zuverlässigkeit und Echtzeitfähigkeit der Funkkommunikation als Anwendungen aus dem Heim- und Bürobereich.

Aufgrund dieser Anforderungen werden verschiedenste Funkkommunikationssysteme bereits eingesetzt. Es ist sehr wahrscheinlich, dass an einem Ort mehrere Funkkommunikations-systeme gleichzeitig betrieben werden. Da diese Funkkommunikationssysteme ein gemein-sames Medium nutzen, ist im Laufe des Lebenszyklus mit einer gegenseitigen Beeinflussung der Systeme zu rechnen. Dies kann sich auf die Zuverlässigkeit und die Echtzeitfähigkeit auswirken.

Bei richtigem Vorgehen ist für die meisten Anwendungsfälle, bei Berücksichtigung der jeweiligen Anforderungen und effizienten Umgang mit dem Frequenzspektrum als endliche Ressource, die Koexistenz mehrerer Funkkommunikationssysteme möglich. Um dies zu erreichen, ist ein Prozess erforderlich, in dem alle Aspekte der Koexistenz von Funkkommu-nikationssystemen während der Entwicklung, Inbetriebnahme und im Betrieb sowie bei der Instandhaltung berücksichtigt werden. Dieser Prozess wird als Koexistenzmanagement von Funkkommunikationslösungen bezeichnet.

Abhängig von der Bedeutung der Funkkommunikation für die Anlage kann dieser Prozess mehr oder weniger aufwendig gestaltet werden. Hierbei sind die Anforderungen an die einge-setzten Funkkommunikationssysteme ausschlaggebend. Werden an das Funkkommunika-tionssystem keine oder nur geringe Anforderungen gestellt, so ist für die Koexistenz von Funk-kommunikationslösungen ein geringerer Aufwand erforderlich als für ein Funkkommunika-tionssystem, das z. B. Teil einer Steuerungsanwendung mit hohen Echtzeitanforderungen ist.

Der Zustand, in dem Koexistenz besteht, ist dadurch bestimmt, dass Grenzwerte relevanter Parameter für alle im betrachteten Bereich vorhandenen Funkanwendungen eingehalten werden. Dieser Zustand der Koexistenz ist durch geeignete Maßnahmen bei der Planung und im Betrieb herzustellen. Das macht deutlich, dass Koexistenz kein statisches Merkmal einer Funkkommunikationslösung ist, sondern ein Zustand innerhalb des Lebenszyklus einer Anlage. Es besteht die Möglichkeit, dass dieser Zustand durch bestimmte Ereignisse zeit-weilig oder dauerhaft verlassen wird. Die Grenzwerte der Parameter werden durch die Auto-matisierungsanwendung bestimmt, in der die Funkkommunikation abläuft. Das heißt auch, dass es nicht sinnvoll ist, die Koexistenz losgelöst von einer Automatisierungsanwendung bewerten oder sicherstellen zu wollen.

Die relevanten Parameter der einzelnen Lebenszyklusphasen des Koexistenzmanagements sind Bestandteil des in Abschnitt 6 eingeführten Modells. Je nach Phase und Notwendigkeit können einzelne Modellbestandteile herausgefiltert werden und durch die Integration in entsprechende Tools die Personen, die für das Koexistenzmanagement verantwortlich sind, unterstützen. Beispiele sind Koexistenzsimulationen, aber auch die Konfiguration der einge-setzten Funkkommunikationsgeräte und -systeme. Im günstigsten Fall kann dadurch der Ein-satz von Funkspezialisten vermieden werden. Die Aufgabe des Koexistenzmanagements kann stattdessen von einem Automatisierungsingenieur übernommen werden. Im folgenden Abschnitt werden Parameter, die beim Koexistenzmanagement in Betracht kommen, aufge-führt.

7.2 Parameter

Eine Auswahl der in Abschnitt 4 aufgelisteten und kategorisierten Parameter finden sich auch im Anwendungsfall des Koexistenzmanagements wieder. Die nachfolgend in Tabelle 3 in alphabetischer Reihenfolge aufgelisteten Parameter beschreiben Kommunikationsanforderun-



gen sowie Bedingungen innerhalb des Arbeitsbereiches und charakterisieren ebenfalls drahtlose Geräte und Netzwerke:

Tabelle 3: Relevante Parameter für das Koexistenzmanagement

Adjacent channel selectivity Physical links

Antenna gain Positions of wireless devices and distances between them

Antenna radiation pattern Power spectral density

Bandwidth Purpose of the automation application

Bit rate of physical link Radio channel

Center frequency Radio propagation conditions

Characteristic of the area of operation Receiver blocking

Communication load Receiver maximum input level

Cut-off frequency Receiver sensitivity

Data throughput Regional radio regulations

Duty cycle Relative movement

Effective radiated power (EIRP, ERP) Reliability required

Frequency hopping procedure Response time

Future expansion plan Security level required

Geographical dimension of the plant Spatial coverage of the wireless communication network

Infrastructure components Spurious response

Initiation of data transmission Topology

Length of user data per transmission interval

Total radiated power (TRP)

Limitation from neighbors of the plant Transmission gap

Maximum dwell time Transmission interval

Maximum number of retransmissions Transmission time

Maximum transmitter sequence Transmitter spectral mask

Mechanisms for adaptivity Type of antenna

Medium access control mechanism Update time

Modulation Used frequency bands

Natural environmental conditions Wireless devices

Organisational parameters Wireless networks

Other frequency users Wireless technology or standard

Packet loss rate



7.3 Phasen des Koexistenzmanagementprozesses

7.3.1 Allgemein

Zum Koexistenzmanagementprozess gehören technische und organisatorische Maßnahmen zur Herstellung und Wahrung des Zustands der Koexistenz sämtlicher Funklösungen in einer Anlage. Die aufgelisteten Parameter der Koexistenz werden in verschiedenen Phasen des Koexistenzmanagementprozesses angewendet. Dabei handelt es sich um folgende Phasen:

Untersuchungsphase: Die Untersuchungsphase soll ausgelöst werden, wenn Änderungen festgestellt werden oder ein neues Funksystem installiert wird.

Planungsphase: In der Planungsphase wird auf der Grundlage der Koexistenzpara-meterwerte der Ressourcenzuweisungsplan entwickelt oder ein bestehender Plan modifiziert.

Implementierungsphase: In der Implementierungsphase werden neue Funkkommuni-kationslösungen installiert und die Konfiguration bestehender Funkkommunikations-lösungen wird gemäß dem Ressourcenzuweisungsplan modifiziert.

Betriebsphase: In der Betriebsphase wird der Zustand der Funkkommunikationssys-teme überwacht mit dem Ziel, Probleme in Bezug auf die Koexistenz und Änderungen von Umgebungsbedingungen aufzudecken.

In allen Phasen sollen die lokalen und regionalen rechtlichen und behördlichen/regulato-rischen Aspekte berücksichtigt und eingehalten werden. Dies sind zum Beispiel in Europa die R&TTE-Richtlinien und die harmonisierten Normen wie ETSI EN 300 328.

Weiterhin werden für den Koexistenzmanagementprozess vier Parametersätze festgelegt. Mit diesen werden die folgenden Aspekte beschrieben:

die allgemeinen Eigenschaften einer Anlage, die für alle Funkkommunikationsnetz-werke gemeinsam gelten

die Kommunikationsanforderungen der Anwendung für jede Automatisierungsfunktion?

die Eigenschaften jedes Funkkommunikationssystems und jedes Gerätetyps

die Eigenschaften jeder Funkkommunikationslösung

7.3.2 Untersuchungsphase

Die Untersuchungsphase wird durch die folgenden Ereignisse ausgelöst:

es müssen neue Funkkommunikationssysteme installiert oder bestehende Lösungen sollen aktualisiert/modifiziert werden

die Umgebung eines Funkkommunikationssystems verändert sich

es treten Probleme in Bezug auf die Koexistenz auf

Die Untersuchung zielt ab auf:

die Ermittlung des gegenwärtigen Zustands in Bezug auf betriebene Funkanwendungen

die Bestimmung freier und belegter Frequenzressourcen

Die Untersuchung schafft eine Basis für das Koexistenzmanagement und ist ein sehr wichtiger Schritt zu dessen Implementierung. Die Vollständigkeit und Richtigkeit der Untersuchungs-ergebnisse sind wichtige Voraussetzungen für eine erfolgreiche Implementierung des Koexistenzmanagements.

Diese Untersuchung kann in Abhängigkeit von der Anwendung eine komplexe Aufgabe sein, für die eine Unterstützung durch erfahrene und qualifizierte Funkspezialisten empfohlen wird. Zur effizienten Durchführung sind die Befragung der Fachabteilungen (Betreiber und Planer



von Produktionsanlagen und Gebäudeeinrichtungen) und Funkmessungen erforderlich. Es müssen angemessene Hilfsmittel (z. B. geeignete Fragebögen) zur Verfügung gestellt werden, die eine Erfassung betriebener Funkkommunikationssystemen gestatten.

Abhängig von den Anwendungsanforderungen muss die Untersuchung durch Messungen unterstützt werden. Diese Messungen dienen der Plausibilitätsprüfung der Abfrageergebnisse und zusätzlich der Ermittlung unbekannter und externer Funkanwendungen (z. B. aus der Nachbarschaft oder von äußeren Quellen).

Zusätzliche Informationen können mithilfe automatischer Überwachungssysteme gewonnen werden. Einige moderne Funkkommunikationssysteme (z. B. Controller-basierte WLANs) ermöglichen die Aufnahme von Informationen über andere Funkkommunikationssysteme.

7.3.3 Planungsphase

7.3.3.1 Überblick

In der Planungsphase wird der Ressourcenzuweisungsplan auf der Basis der aktualisierten Bestandsaufnahme erstellt oder modifiziert. Der Ressourcenzuweisungsplan beschreibt, wie Funkressourcen zu den jeweiligen Funkkommunikationslösungen zugeordnet werden. Der Ressourcenzuweisungsplan muss entsprechend dokumentiert werden. Er muss von dem für das Koexistenzmanagement zuständigen Gremium überprüft und vom Koexistenzmanager freigegeben werden.

Auch wenn noch keine Funkanwendungen in Betrieb sind, sollte bei der Planung bereits berücksichtigt werden, dass später weitere Funkanwendungen hinzugefügt werden könnten. Werden bereits Funkanwendungen genutzt, ist festzustellen, ob diese alle der Kontrolle des Koexistenzmanagers unterstehen.

Einerseits besteht die Möglichkeit, dass Fremdsysteme einstrahlen; andererseits kann es sein, dass die Prioritäten so vergeben sind, dass z. B. bestehende Funkkommunikationslösun-gen oder Funkkommunikationslösungen kritischer Anwendungsklassen nicht geändert werden können. In diesen Fällen müssen die Gegebenheiten akzeptiert und die verbleibenden Frei-heitsgrade (Frequenz, Zeit, Raum usw.) genutzt werden, um die Koexistenz herzustellen.

7.3.3.2 Funkfeldplanung

Die Funkfeldplanung eines Funkkommunikationssystems sollte durch entsprechende Soft-wareprodukte unterstützt werden.

Des Weiteren sollte eine Planung durch Messungen und Simulationen untersetzt werden. Die Unterstützung der Planung durch Simulationen wird empfohlen, weil genaue großflächige Messungen sehr aufwendig sind und oft nur eine Momentaufnahme darstellen und nur bedingt eine Optimierung zulassen.

Die Simulationen sollten, soweit möglich, durch Messungen präzisiert werden. Eine reine simulationsgestützte Planung kann nur für die Umgebungen empfohlen werden, in denen Messungen nicht sinnvoll oder nicht möglich sind (z. B. für noch nicht erstellte oder nicht eingerichtete Gebäude). Bei der Funkfeldplanung müssen auch andere Funkanwendungen berücksichtigt werden.

Wenn keine zuverlässigen Informationen über die Frequenzbelegung im zutreffenden Bereich und in der näheren Umgebung vorliegen, sollte bei jeder Planung eine Umgebungsanalyse durchgeführt werden. Dafür können Spektrum- und Protokollanalysatoren verwendet werden.

7.3.4 Implementierungsphase

In der Implementierungsphase werden neue Funkkommunikationslösungen installiert und die Konfiguration bestehender Funkkommunikationslösungen wird an den erstellten Ressourcen-zuweisungsplan angepasst.

Die Zuteilung der Funkressource erfolgt durch die Konfiguration von Optionen und Parame-tern, welche sich auf die Belegung der Funkressource durch die Funkkommunikationssysteme beziehen.



Die Implementierung muss überprüft werden, um sicherzustellen, dass der Ressourcenzuwei-sungsplan entsprechend realisiert worden ist.

7.3.5 Betriebsphase

In der Betriebsphase muss der Zustand der Funkkommunikationslösungen überwacht werden, damit Probleme in Bezug auf die Koexistenz und Veränderungen der Umgebung ermittelt werden können.

Bestimmte Überwachungstätigkeiten zur Überprüfung des Zustands der Koexistenz müssen regelmäßig oder auch kontinuierlich durchgeführt werden. Ergebnisse sind entsprechend aufzuzeichnen.

Eine Untersuchungsphase muss eingeleitet werden, sobald eins von den nachfolgend aufge-führten Ereignissen eintritt:

Auftreten von Problemen in Verbindung mit der Koexistenz

neue Funkkommunikationssysteme installiert werden müssen

sich die Umgebung des Funkkommunikationssystems verändert

Wesentlicher Bestandteil des Koexistenzmanagements während des Betriebs ist die Einfüh-rung einer Meldepflicht für unternehmensinterne Funkanwendungen. Das betrifft sowohl die Meldung von Störungen als auch die Information, dass der Einsatz weiterer Funkanwen-dungen geplant ist. Sollen neue Funkkommunikationssysteme installiert werden, so ist der Auswahlprozess mit anschließender Planung und Bewertung einzuleiten. Treten Störungen auf, so sind die Ursachen durch Messungen und Analysen zu ergründen und das geforderte Verhalten wiederherzustellen.

7.4 Zusammenfassung

Wesentliche Teile der DIN EN 62657-2 wurden im Vorhaben „FiLiA“ berücksichtigt. So bilde-ten die für das Frequenzmanagement relevanten Parameter eine Grundlage für die Modell-bildung. Weiterhin wurde gezeigt, dass auch das Koexistenzmanagement, wie bereits bei der Automatisierungsanlage aufgezeigt, einen Lebenszyklus bestehend aus verschiedenen Pha-sen aufweist. In identischer Weise existiert eine Planungs-, Installations- und Betriebsphase. Die Untersuchungsphase, in welcher bestehende Funksysteme und die Funkbedingungen in der Automatisierungsanlage ermittelt werden, ist eine Besonderheit des Frequenzmanage-ments. Das Koexistenzmanagement ist nicht in jeder Phase des Lebenszyklus einer Anlage relevant. Es stellt damit aber auch einen besonderen Use Case für das erstellte Modell dar. Über eine geeignete Transformation können die in den einzelnen Phasen benötigten Para-meter herausgefiltert und beispielsweise Planungs-, Konfigurations- und Diagnosetools bereit-gestellt werden.

Umsetzung in Zielformate 64 / 89


8 Umsetzung in Zielformate

8.1 Sichtenbildung

Auf der Grundlage der durchgeführten Untersuchungen und der Modellbildung wurde eine Umsetzung in Zielformate, die für die industrielle Automation relevant sind, durchgeführt. Dazu wurde in einem ersten Schritt analysiert, welche der kategorisierten Parameter in welcher Phase des Lebenszyklus relevant sind. Einen Ausschnitt dieser Zuordnung zeigt Abbildung 46. Dabei wurde für jeden Parameter überprüft, ob dieser in einer Phase festgelegt (o – Output), angepasst (x – Change) oder genutzt (i – Input) wird. Weiterhin ist es auch erfor-derlich, dass einige Parameter in einzelnen Phasen elektronisch verfügbar gemacht werden (c – Create). Mit der Zuordnung der Parameter zu den Phasen werden auch die Informationsflüsse veranschaulicht. Es zeigt, an welcher Stelle Parameter generiert, weiterverarbeitet und genutzt werden.

Abbildung 46: Zuordnung von Parametern zu Phasen des Lebenszyklus

Beim Durchlaufen des Lebenszyklus werden in den einzelnen Phasen verschiedene Werk-zeuge bzw. Tools verwendet. Diese Tools haben unterschiedliche Formate, in denen Daten im- und exportiert sowie verarbeitet werden. Die Übersicht in Abbildung 46 hilft zu analysieren, welche Werkzeuge in den Informationsflüssen welche Zielformate nutzen.

Die genannten Zielformate stellen eine Sicht auf das gebildete Modell dar. Für eine einzelne Phase des Lebenszyklus werden nur bestimmte Parameter benötigt, welche zudem ein vom genutzten Tool festgelegtes Format aufweisen müssen. Dazu ist eine Transformation notwen-dig (siehe Abbildung 47), die unter Umständen sehr komplex sein kann.



Sicht

Datenbestand

Use Case

Transformation(en)

Spezifisches Format

Spezifisches Format

Modell

Abbildung 47: Transformation von Modellbestandteilen in Zielformate für spezifische Use Cases

Bei der Transformation wird in Abhängigkeit vom Anwendungsfall die dazugehörige Sicht auf das Modell in ein spezifisches Format überführt. Je nach Anwendungsfall kommt ein Tool zum Einsatz, das das spezifische Format benötigt und verwendet. Die Transformation ist in beide Richtungen möglich. Um eine Aussage treffen zu können, welche Zielformate benötigt werden, wurden die innerhalb des Lebenszyklus eingesetzten Tools analysiert.

Eine wesentliche Form der Umsetzung in Zielformate ist in der Automation die Erstellung von Gerätebeschreibungen. In Bezug auf „FiLiA“ sind das Gerätebeschreibungen von ausgewähl-ten Funklösungen. Für die Erstellung der Gerätebeschreibungen werden geeignete Beschrei-bungsmittel wie EDDL oder XML-basierte Sprachen wie GSDML und FDCML ausgewählt, die in dem in der Automation typischen Umfeld benutzt werden. Zu einem besseren Verständnis soll dies exemplarisch beschrieben werden.

8.2 General Station Description Markup Language (GSDML)

Für die Integration von Geräten in PROFINET IO-Systeme werden Eigenschaften des ent-sprechenden Gerätes mittels einer Gerätebeschreibungsdatei, der General Station Descrip-tion (GSD) spezifiziert. Die Notation der GSD erfolgt auf Basis der GSDML als Beschreibungs-sprache. Die GSD wird durch Werkzeuge verarbeitet, die die Initialkonfiguration für die Anlauf-parameter dieser Geräte festlegt. Die einzelnen Konfigurationen werden beim Systemanlauf durch die Steuerung an die jeweiligen Geräte übertragen. Die prinzipielle Vorgehensweise bei der Nutzung der GSD ist in Abbildung 48 dargestellt.



Abbildung 48: Strukturbild GSD-Nutzung

Der Abbildungsprozess auf GSDML erfordert zunächst die Definition, welche Informationen aus dem FiLiA-Modell überhaupt abgebildet werden sollen. Die wesentlichen Inhalte einer GSD sind der Aufbau des Gerätes entsprechend des Gerätemodells von PROFINET IO, die Spezifikation der Prozessdaten, die Festlegung von Diagnoseinformationen und die Spezi-fikation der Anlaufparameter. Die konzeptionelle Abbildung selbst erfolgt durch Zuordnung der Daten des FiLiA-Modells auf Elemente des Gerätemodells, das in Abbildung 49 dargestellt ist.

Abbildung 49: Gerätestruktur eines PROFINET IO-Devices

Entsprechend der in FiLiA verwendeten Modellstruktur (Abbildung 10) und deren Umsetzung (Abbildung 22) wird das Modellelement Device auf ein PROFINET IO-Device abgebildet. Da die GSD einen Gerätetyp beschreibt, sind primär die Informationen aus den Typklassen des FiLiA-Modells abbildungsrelevant. Für die Abbildung von Diagnoseinformationen können ggf. auch Informationen der Instanzklassen relevant sein und können z.B. als Platzhalter abge-bildet werden. Für den Zugriff auf Geräteparameter zur Laufzeit ist die GSD hingegen nicht vorgesehen. Hierfür kann z.B. die EDDL genutzt werden (8.3).

Die zugehörigen Informationen der Typklasse DeviceType, insbesondere die Identifikations-informationen, gelten für ein PROFINET IO-Device als Ganzes und werden dem Element DeviceIdentity zugeordnet. Bei der Abbildung ist zu beachten, dass Teile der Informationen



nicht in Textform sondern in codierter Form vorliegen. Dies ist z.B. für die Überführung der Daten aus dem Attribut VendorInformation relevant, die in einem PROFINET IO-Device als Zahl abgelegt ist. Die Zuordnung zwischen Herstellernamen und ihrer Zahlenrepräsentation wird durch die Nutzerorganisation PROFIBUS International (PI) festgelegt. Bei der Trans-formation ist hier ggf. eine manuelle Interaktion notwendig.

Das Modellelement NetworkComponent stellt im Sinne des PROFINET IO-Gerätemodells einen Device Access Point dar. Die entsprechenden Elemente einer WirelessNetwork-Component müssen demzufolge auf Unterelemente eines solchen Elements der GSD abgebil-det werden. Für die Identifikationsinformationen der Typklasse gelten die gleichen Aussagen wie beim Modellelement Device.

Das GSDML-Element DeviceAccessPointItem beschreibt ein WirelessNetworkComponent. Bei der Abbildung sind die von GSDML vorgegebenen Elemente wie ModuleIdentNumber etc. auszufüllen. Diese Werte werden durch den Hersteller der Komponente definiert. Modulinfor-mationen werden aus den Identifikationsdaten erzeugt. Die Definition der Prozessdaten selbst ist nicht relevant, da es sich um ein Modul handelt, das als Kommunikationsanschaltung verstanden wird, nicht um eines, das Ein- oder Ausgangsdaten aus dem Prozess liefert.

Die in der Typklasse des Modellelements WirelessNetworkComponent definierten Eigen-schaften können auf Einstellparameter in der GSDML abgebildet werden. Allerdings bleibt festzuhalten, dass diese Abbildung durch den Hersteller vorgenommen wird. Er entscheidet entsprechend seiner System- und Gerätephilosophie, welche Parameter beim Hochlauf an das Gerät übergeben werden, und welche über weitere Engineeringwerkzeuge eingestellt werden. Es ist geplant, die Ergebnisse des AP4 Modellbildung in die relevanten Arbeitskreise bei PROFIBUS International (PI) einzubringen, die sich mit der Definition von funkgestützten Systemen befassen. Deren Ziel sollte auch die Festlegung von GSD-relevanten Strukturen sein. Bislang sind allerdings durch PI noch keine solchen Festlegungen erfolgt.

Die GSDML definiert in der Liste SystemDefinedSubmodule das Element InterfaceSubmodul-eItem. Dies wird als Basis für das Funk-Interface genutzt. Die Einstellparameter werden auf einzelne RecordDataItem-Elemente abgebildet. Im Beispiel in Abbildung 50 ist dies exem-plarisch für ein WLAN-Modul gezeigt. Einstellparameter sind die Auswahl des Funkkanals, die Eingabemöglichkeit für die ist die Netzwerkkennung (SSID) sowie für Sicherheitseinstel-lungen.

Abbildung 50: Fragment einer GSD



Bei der Generierung der GSD ist zu beachten, dass die Zuordnungen von Texten und von Datenstrukturen mittels Marken (TextId bzw. ValueItemTarget) erfolgt. Es müssen daher die entsprechenden IDs für die Marken generiert und die Referenzen an den jeweiligen Stellen eingefügt werden. Das GSDML-Schema prüft auf Eineindeutigkeit der Marken, so dass keine Dopplungen auftreten können. Daher sind zur Erzeugung einer gültigen GSD diese IDs durch die Transformation aus dem FiLiA-Modell bereits eineindeutig zu erstellen. Die Listen der ValueItems stehen ebenso wie Grafiken (GraphicsItem) am Ende der Datei.

Relevante Eigenschaften der Antennentypen können über das Element PortSubmoduleItem und zugehörige RecordData abgebildet werden. Ports können „gesteckt“ werden, also bei der Geräteparametrierung eingesetzt werden. Dies erfordert zwingend die GSDML-Version 2.25 oder höher. Bei der Nutzung von Ports ist zu beachten, dass Identifikationsdaten für dieses Element nicht vorgesehen sind. Sie lassen sich also nicht abbilden. Ein Mapping dieser Informationen auf RecordDataItems ist möglich, allerdings nicht sinnvoll, da die RecordData beim Hochlauf in das Gerät geschrieben werden und dies für diese Klasse von Daten kein typischer Anwendungsfall ist.

Die zur Transformation der Modellelemente genutzten XSLT-Stylesheets wurden mittels Altova Mapforce generiert. Sie sind modular aufgebaut, so dass einzelne Teile wiederver-wendbar sind. Somit ist auch die Abbildung von Modellelementen mit Vererbungsstruktur realisierbar, indem für die Oberklasse eine Stylesheet zur Transformation ihrer Attribute ge-nutzt wird, während die Attribute der abgeleiteten Klassen die der Oberklasse ergänzen. Dies erfordert die Auswertung der expliziten Typangaben (xsi:type) in der Modellinstanzdatei, was für das genannte Werkzeug erst ab der Version 2013 unterstützt wird. Das Mapping erfolgt grafisch, eine Überblicksdarstellung hierzu ist in Abbildung 51 gegeben.

Abbildung 51: Prinzip der Erstellung der Transformationen zwischen FiLiA-Modell und GSDML

Das beschriebene Vorgehen der Abbildung auf InterfaceSubmoduleItems wurde hier exem-plarisch für WLAN beschrieben, es ist für andere Funktechnologien identisch.

8.3 Electronic Device Description Language

Mit der Electronic Device Description Language (EDDL) wurde eine sehr kompakte, problem-orientierte Beschreibungssprache definiert. Diese Sprache ist durch die Internationale Norm IEC 61804-3 [10] festgelegt. Die Norm unterstützt aktuell die drei Profile HART®, PROFIBUS/ PROFINET und FOUNDATIONTM Fieldbus. Der Hersteller definiert mit Mitteln der Sprache die für die Parametrierung des Gerätes notwendigen Parameter, deren Beziehungen untereinan-



der, die Kommunikationspfade und legt die Art und Struktur für die Bedienoberflächen fest. Ein universelles Bedien- und Parametrierprogramm (z.B. isEDD workbench – ifak) / SIMATIC PDM – SIEMENS) interpretiert die Gerätebeschreibungsdatei (EDD) und stellt dem Bediener die darin festgelegte Oberfläche zum Einstellen der Geräteparameter zur Verfügung. Abbildung 52 zeigt das Strukturbild für die Geräteinbetriebnahme mittels einer EDD.

PC

Feldbus

PLC

Gerätebeschreibung /

Treiber (EDD)

Communication

Device

isEDD workbench

Abbildung 52: Strukturbild Geräteinbetriebnahme

Der Vorteil liegt in der Betriebssystemunabhängigkeit der EDDL-Sprache, welche zudem nur sehr geringe Erfahrungen bei der Softwareentwicklung von den Geräteentwicklern erfordert. Als nachteilig könnte angesehen werden, dass nur ein fest definierter Umfang an Visualisie-rungsmitteln zur Verfügung steht.

Eine weitere und neue Variante, die Parametrierung über das vorhandene Bussystem durch-zuführen, bietet das Konzept „Field Device Integration“ (FDI – IEC 62769 [14]). Dieses befindet sich derzeit in der Entwicklungsphase bzw. in frühen Phasen der Normung. Ein aktu-eller Schritt ist dabei die Umsetzung der Spezifikation in Form von Prototypen und notwen-digen Komponenten.

Die Basis dieser Technologie bilden die vom Gerätehersteller zu erstellenden Device Packages. Diese Komponenten besitzen eine durch die Spezifikation festgelegte Schnittstelle (vorrangig basierend auf OPC UA – IEC 62541 [12]) für die Beschreibung der Gerätedaten, deren Abhängigkeiten und Regeln zur Darstellung für den Bediener. Ein Device Package wird speziell für einen Gerätetyp oder eine Gerätegruppe erstellt und stellt abgestimmte Ober-flächen zur Parametrierung und Diagnose bereit. Basis des FDI-Konzepts zur Beschreibung der Eigenschaften der Feldgeräte bildet die herstellerunabhängige und vom Konzept auch technologieunabhängige Gerätebeschreibungssprache EDDL. Optional können im Device Package neben der EDD ausprogrammierte Softwarekomponenten enthalten sein, um die mit EDDL ggf. nur sehr aufwändig zu beschreibenden speziellen Bedienelemente zu ergänzen. Daneben ist die Möglichkeit gegeben, Dokumentationen, Zertifikate oder Busprotokoll-spezifische Zusatzinformationen im Device Package zu hinterlegen.

Bei der Umsetzung des Modells in die Electronic Device Description Language (EDDL) wurden die Modellelemente nach Abbildung 46, welche für die Inbetriebnahme und dem eigentlichen Betrieb des Gerätes im Funknetzwerk von Bedeutung sind (Geräteinstanzdaten), betrachtet. Diese wurden in der EDD mittels Variablen definiert, die Kommunikationsobjekte



mittels COMMANDs festgelegt und in Menü-Definitionen für die Bedienung strukturiert. Dies erfolgte strukturiert für die Modellelemente Device, NetworkComponent, Antenna und PowerSupply.

Als Beispiel für die Umsetzung in eine EDD sei die Kanalauswahl eines WLAN-Gerätes genannt. Die in einem Gerät verbaute WLAN-Komponente unterstützt aufgrund Ihres Aufbaus/ Konfiguration eine Anzahl von Funkkanälen. Die Anzahl der nutzbaren Kanäle kann vom Gerätehersteller bei der Integration der Funkkomponente in sein Gerät weiter eingeschränkt werden. Ein Beispiel für IEEE 802.11 bg ist in Tabelle 4 dargestellt.

Tabelle 4: eingeschränkte Nutzung von Kanälen in Funkgeräten

Kanäle der Funkkomponente

genutzte Kanäle im Gerät

mögliche Einschränkung durch EDD-Parametrierung

CH. 1 2412 MHz X X

CH. 2 2417 MHz X X

CH. 3 2422 MHz X X

CH. 4 2427 MHz X X

CH. 5 2432 MHz X

CH. 6 2437 MHz X

CH. 7 2442 MHz

CH. 8 2447 MHz X

CH. 9 2452 MHz X

CH. 10 2457 MHz

CH. 11 2462 MHz X X

CH. 12 2467 MHz X X

Bei der Verwendung des Funkgerätes steht somit nur eine gewisse Anzahl von Kanälen zur Verfügung. Diese Auswahl von Kanälen kann bei der Parametrierung weiterhin eingeschränkt werden, dies kann notwendig sein damit beispielsweise bei der automatischen Kanalwahl weitere ausgeschlossen werden. Bei der manuellen Kanalwahl wirkt diese Einschränkung dann ebenfalls. Ein Parametrierdialog der isEDD workbench ist in Abbildung 53 dargestellt.



Abbildung 53: Kanalauswahldialog einer Parametrierung mittels EDD

Auf der linken Seite ist der Dialog mit der Einstellung „automatische Kanalauswahl“ darge-stellt. Dabei können Einschränkungen bei den zu nutzenden Kanälen vorgenommen werden. Das Bild auf der rechten Seite stellt denselben Dialog mit manueller Kanalauswahl dar. Die Auswahl eines aktiven Kanals ist aus dem Bereich der konfigurierten Kanäle möglich.

Abbildung 54: EDD-Quelltext Kanalauswahl

Abbildung 54 zeigt die Variablendefinitionen der in dem Dialog enthaltenen Parameter.

8.4 Abbildung nach FDCML

Die Field Device Configuration Markup Language (FDCML) ist eine XML-basierte Sprache zur systemunabhängigen Beschreibung von Automatisierungskomponenten und definiert keine vollständig modellierten Komponentenobjekte, sondern generische Strukturen zur Darstellung dieser Objekte. Dadurch ist es möglich, die Komponenten unabhängig vom verwendeten Automatisierungssystem zu beschreiben. Außerdem kann der Inhalt einer Beschreibung ohne



Änderung des Beschreibungsformats um beliebige Objekte erweitert werden. Im Gegensatz zu bekannten Gerätebeschreibungssprachen der Feldgerätekonfiguration verfolgt FDCML daher den Ansatz einer Metasprache. FDCML entspricht in ihrer Beschreibungsstruktur der ISO 15745-1. Demzufolge sind in FDCML die vier Basisobjekte DeviceIdentity, Device-Manager, DeviceFunction und ApplicationProcess für die Gerätebeschreibung vorgesehen (Abbildung 55).

Abbildung 55: Basiselemente des Gerätemodells nach ISO 15745

Das DeviceIdentity-Objekt beinhaltet allgemeine Informationen, z. B. Herstellername, Geräte-typ und Gerätebezeichnung zur Geräteidentifikation. In dieses Modellelement können die Identifikationsdaten des FiLiA-Modellelements DeviceType abgebildet werden. Ebenso lassen sich in diesem Element die Identifikationsdaten der Instanz (DeviceInstance) hinterlegen. Die Abbildung selbst erfolgt wiederum durch Transformation mittels XSLT.

FDCML bietet darüber hinaus die Möglichkeit der Gruppenbildung, sodass ein Gerät, das sich aus verschiedenen Komponenten, ggf. von verschiedenen Herstellern, zusammensetzt, im Detail beschrieben werden kann und sich als Einheit präsentiert. Dieses Konzept wird für die Abbildung der Relationen zwischen den FiLiA-Modellelementen Device und Network-Component, PowerSupply und Antenna genutzt.

Die Abbildung der Eigenschaften der NetworkComponent und der abgeleiteten Klassen erfolgt aus funktionaler Sicht auf das FDCML-Element DeviceManager. Dieses Element enthält ein Element communicationEntity, das für die Beschreibung von Kommunikationsanschlüssen genutzt wird (Abbildung 56). Hier können eigene, für diesen Anschluss spezifische Parameter definiert werden, die in den Elementen ParameterDescriptionList und cfgItemList hinterlegt sind. An diese Stellen lassen sich Informationen aus dem Element NetworkComponent einfü-gen. Es ist darüber hinaus möglich, Relationen zu Werkzeugen zu definieren. Eine Appli-kation, die FDCML-Beschreibungen verwertet, kann so z.B. spezifische andere Werkzeuge oder auch Transformationen ansprechen und aufgabenbezogen – mithin sichtenspezifisch – weitere Modellinhalte erzeugen.



Abbildung 56: Schemadarstellung des FDCML-Elements DeviceManager

FDCML bietet ein Erweiterungskonzept, das über die XML-Mechanismen ##any die Einbin-dung weiterer Schemata mit eigenen Namespaces erlaubt. Auch dieses Element (external-Schema in Abbildung 56) kann für die Abbildung von Elementen des FiLiA-Modells genutzt werden. Hier besteht eine deutlich losere Modellkopplung, da die so eingebundenen Schema-ta – meist aus Kompatibilitätsgründen gewollt – weniger strikt validiert werden (lax validation). Der Vorteil dieser Einbindung ist hingegen, dass die Transformation einfacher wird, da kom-plette Elemente aus dem XML-Schema des FiLiA-Modells einfach zugeordnet werden können und die Instanzdaten dann nur kopiert werden müssen.

Die Transformationen wurden wie bei GSDML mittels Altova Mapforce generiert. Die Rand-bedingungen wie z.B. abstrakte Elemente (xsi:type) sind ebenfalls die gleichen wie unter 8.2 beschrieben. Abbildung 57 zeigt das Prinzipbild der Transformationserstellung.



Abbildung 57: Prinzip der Erstellung der Transformation zwischen FiLiA-Modell und FDCML

8.5 Abbildung in andere Formate

Im Rahmen der Bearbeitung wurden weitere Anwendungen identifiziert, die auf Inhalte des FiLiA-Modells zugreifen. Diese Anwendungen realisieren Sichten der Anlagenplanung und der Gerätebeschaffung. In diesem Kontext sind Merkmalsleisten nach IEC 61987 zu nennen. Für diese Merkmalsbeschreibung existiert ein formales Modell, so dass in vergleichbarer Form wie zu Gerätebeschreibungen Modellabbildungen definiert werden können. Diese Abbildung wurde konzeptionell entworfen, jedoch nicht durch Transformationen umgesetzt. Der Grund hierfür ist das Fehlen von geeigneten Gerätemerkmalen, die explizit die Eigenschaften des Gerätetyps abbilden. Sofern hierfür in der Standardisierung passende Definitionen verab-schiedet werden, lassen sich die FiLiA-Modelle abbilden und es können Transformationen generiert werden.

Eine weitere Möglichkeit zur Abbildung wird künftig in AutomationML gesehen. Hier gilt prinzi-piell die gleiche Aussage. Sobald die Definitionen für Rollenklassen festliegen, können Ge-rätetypen (DeviceType) auf SystemUnitClasses erfolgen. Da AutomationML auf dem Format CAEX und damit auf XML basiert, sind wiederum Transformationsmechanismen einsetzbar, die den oben beschriebenen entsprechen.

Validierung 75 / 89


9 Validierung

9.1 Konzept

Wie es bei der Modellierung typisch ist und auch zur Reproduzierbarkeit von Resultaten verlangt wird, ist eine Validierung des gebildeten Metamodells zwingend notwendig. Dazu wurden auf Basis der Umsetzung in Zielformate Lösungen erarbeitet. Dies geschah für ausgewählte Aspekte des Lebenszyklus der Automation anhand einer Auswahl von typischen Werkzeugen. Die erarbeiteten Ergebnisse wurden anschließend einem Validierungsprozess unterzogen, bei dem die Lösung an den aufgestellten Anforderungen gespiegelt und diskutiert wurde. D. h. es wurde sichergestellt, dass das Modell und die darin abgebildeten Informationen den Anforderungen genügen. Auf Basis von ausgewählten Szenarien wurden typische Werkzeugketten identifiziert, in denen verschiedene Umsetzungen des Modells, z.B. in EDD oder als Erweiterungen XML-basierter Sprachen wie GSDML, validiert wurden.

Da einige Exportformate nicht zur Verfügung standen, wird nur ein ausgewählter Teil der typi-scherweise in der Automation verwendeten Sprachen anhand von Toolketten, die auf ausge-wählte Modellbereiche zurückgreifen, validiert. Die genutzten Sprachen und die jeweilige Art der Validierung sind im Folgenden kurz aufgelistet:

XML: Bildung einer Instanzdatei auf Grundlage des XML-Metamodells und Überprüfung von Export- und Importfunktionalitäten

GSDML: Validierung der Importmöglichkeiten in SIMATIC Step7

EDD: Integration von Modellbestandteilen (z. B. Frequenzkanäle) in SIMATIC PDM

9.2 Validierung des Modells und der Instanzdateien

Die Validierung des Modells erfolgte durch Analyse der im Modell hinterlegten Daten gegenüber den im AP2 erstellten Klassifikationen. Darüber hinaus wurden auf Ebene des UML-Modells Prüfungen durchgeführt. Diese stellen die Konsistenz des UML-Modells sicher (consistency checking), so dass alle Modellelemente gemäß den Konventionen der UML definiert sind.

Die Erstellung des Schemas wurde durch Generierungsprozesse unterstützt. Hierbei wurde eine Überführung des UML-Modells und der FiLiA-Modellelemente nach XML-Schema werkzeuggestützt durchgeführt. Dabei war zu beachten, dass die im Überführungstemplate vorhandene Abbildung bei der Repräsentation von Instanziierungsrelationen in UML nicht zu den gewünschten Strukturen im Schema (Elemente für Typklassen und Instanzklassen) füh-ren konnte. Dies ist naheliegend, da typisch in einem Schema eine Typsicht und in der XML-Datei eine Instanzsicht realisiert wird. Im Modellierungsansatz von FiLiA werden hingegen explizit Typklassen und Instanzklassen definiert, von denen dann in der XML-Datei Instanzen (Modellinstanz) gebildet werden.

Für ausgewählte Geräte wurden auf Basis von bestehenden Spezifikationen und Datenblät-tern Instanzdateien erzeugt, die als XML-Repräsentation nach dem FiLiA-Schema vorhanden sind. Auf XML-Ebene wurden Wohlgeformtheit und Gültigkeit durch verschiedene Parser ge-testet.

Soweit elektronisch verarbeitbare Quellen für die Geräte überhaupt verfügbar waren, wurden diese auf Äquivalenz gegenüber der XML-Datei geprüft. Hierzu wurden Import- und Export-funktionen, zumeist in Form von Transformationen, erstellt und angewandt.

9.3 Validierung der GSDML-Abbildung

Die Validierung der GSDML-Abbildung erfolgte in mehreren Schritten. Zunächst wurden die generierten GSD auf Korrektheit in Bezug auf die XML-Struktur geprüft. Dies betrifft die As-pekte der Wohlgeformtheit und der Gültigkeit. Die Wohlgeformtheit ist durch die Generierung der Transformation bereits gegeben und wurde durch das Werkzeug Altova Mapforce geprüft. Wenn derartige Transformationen händisch erstellt werden, so ist hier zusätzlicher Aufwand erforderlich.

Validierung 76 / 89


Die Prüfung auf Gültigkeit erfolgt gegen das GSDML-Schema. Dies erfolgte sowohl im Werk-zeug Altova XMLSpy, indem die Instanzdatei (GSD) durch den im Werkzeug eingebauten Parser geprüft wurde. Dies erfolgte für unterschiedliche GSDML-Versionen (2.25 und 2.3). Die Nutzerorganisation PROFIBUS International stellt mit dem GSDML-Viewer ein Werkzeug zur Verfügung, das neben der Schema-Prüfung – hierbei werden mehrere XML-Parser genutzt, um Implementierungsunterschiede der Parser auszugleichen – auch weitere, nicht im Schema hinterlegte Abhängigkeiten prüft. Eine derart getestete GSD sollte sich in Engineering-Werk-zeuge integrieren lassen.

Dies wurde für das Werkzeug SIMATIC Step7 durchgeführt. Hierbei war zu beobachten, dass die GSDML-Version 2.3 durch die vorhandene Werkzeugversion noch nicht unterstützt wurde. Es ist davon auszugehen, dass die künftigen Versionen diese Unterstützung bieten. Für die weitere Validierung wurde daher die GSDML-Version 2.25 genutzt.

Nach erfolgreichem Import der GSD steht das Beispielgerät im Katalog zur Verfügung und kann in ein PROFINET-Netzwerk integriert werden. Dazu wird das Gerät in das Projekt gezo-gen und über dem Symbol eines PROFINET-Netzes abgelegt. Damit wird eine Geräteinstanz des Typs (hier des Beispielgeräts) erstellt, die nun parametriert werden kann. Abbildung 58 zeigt dies beispielhaft.

Validierung 77 / 89


Abbildung 58: Screenshot der Instanziierung des FiLiA-Beispielgerätes in Step7

Die durch die GSD abgebildeten Eigenschaften des Interfaces können nun geändert werden. Dazu werden die Eigenschaftsdialoge durch Step7 auf Basis der GSD-Informationen erzeugt. In Abbildung 59 sind die im Beispielgerät durch RecordData hinterlegten Eigenschaften im Dialog dargestellt. Es ist erkennbar, dass es sich hierbei – wie bei der Definition der Record-DataItems festgelegt – sowohl um Eingabefelder (SSID), als auch um Auswahlfelder (Kanal-auswahl) handeln kann. In Abbildung 60 ist die Liste der möglichen Einträge aufgeklappt, deren Werte aus der GSD entnommen sind.

Validierung 78 / 89


Abbildung 59: Eigenschaftsdialog im Step7

Validierung 79 / 89


Abbildung 60: Dialog zur Kanalauswahl im Step7

Die Integration der Daten des FiLiA-Modells in GSDML war wie oben beschrieben möglich, der Zugriff auf echte Geräte jedoch nicht, da die in der GSDML definierten Daten nicht in der adäquaten Form in realen Geräten vorhanden sind. Hierzu müssten in den Geräten Daten-strukturen für den azyklischen Zugriff über PROFINET IO existieren, die genau die in der GSDML spezifizierten Slots, Subslots und Indices beschrieben werden können. Beim Hoch-lauf eines Gerätes wird genau eine solche Sequenz vom IO-Controller initiiert.

Mittels des an der TU Dresden entwickelten Generic Device [18] [19],, einer Softwarelösung für ein PROFINET IO-Device, das auf einem PC läuft und dessen Applikation als Software-komponente flexibel gestaltbar ist, konnte der Hochlauf getestet werden. Hierzu wurde eine Testapplikation erzeugt, die die Konfigurationsdaten entgegennahm und im Gerät ablegte. Die Hochlaufsequenz wurde damit fehlerfrei ausgeführt.

Auf Basis dieser Plattform lassen sich weitere Tests des FiLiA-Modells durchführen, die insbe-sondere auch ein absichtliches Fehlverhalten des Gerätes einschließen. Allerdings sind hier andere Szenarien als die Inbetriebnahmen mittels GSDML ergiebiger.

9.4 Validierung der EDDL-Abbildung

Die Validierung der EDD-Abbildung erfolgte durch die Integration der erstellten Geräte-beschreibung in SIMATIC PDM der Firma Siemens.

Zunächst wurde für die erstellte Gerätebeschreibung eine tool-spezifische Integrationsdatei erstellt (*.devices). Mit Hilfe dieser Datei wurde die Gerätebeschreibung über den Device

Validierung 80 / 89


Integration Manager in den Gerätekatalog von PDM integriert. Da PDM derzeitig nur die Protokolle PROFIBUS und HART unterstützt, war es leider nicht möglich, der Gerätebeschrei-bung die Kommunikation WLAN zuzuordnen. Für die Integration wurde daher PROFIBUS PA verwendet (Siehe Abbildung 61).

Abbildung 61: Dialog zur Geräteintegration

Nach erfolgreichem Import der EDD steht die Gerätebeschreibung im Gerätekatalog zur Ver-fügung (Abbildung 62) und sie kann einem Gerät eines Netzwerkes zugeordnet werden.

Abbildung 62: PDM Gerätekatalog

Durch das Hinzufügen eines Gerätes zu einem Netzwerk (z.B. WLAN-Netzwerk) und der Zu-ordnung eines Gerätetyps (Auswahl der Gerätebeschreibung) wird eine Geräteinstanz dieses Typs erstellt. Mit Hilfe von PDM kann dieses Gerät dann über die EDD parametriert werden. Dies erfolgt über die erstellte Menüstruktur und durch die definierten Dialogfenster.

Validierung 81 / 89


Abbildung 63 zeigt einen Bildschirmausschnitt von PDM, welcher für die WLAN-Geräteinstanz beispielhaft die Instanzdaten der allgemeinen Geräteinformationen und die der Netzwerk-komponente enthält.

Abbildung 63: Geräteinformationen

Ein weiterer Ausschnitt aus der Umsetzung, die Kanalauswahl eines WLAN-Gerätes, in eine EDD wurde bereits in Abschnitt 8.3 genannt. Auch an dieser Stelle soll dieser Ausschnitt der EDD zur Veranschaulichung der Validierung mittels PDM dienen.

Abbildung 64: Kanalauswahldialog einer Parametrierung mittels EDD in PDM

In Abbildung 64 ist auf der linken Seite der Dialog für die Kanalauswahl mit der Einstellung „automatische Kanalauswahl“ dargestellt. Dabei können Einschränkungen bei den nutzbaren Kanälen vorgenommen werden. Das Bild auf der rechten Seite stellt denselben Dialog mit manueller Kanalauswahl dar (die „automatische Kanalauswahl“ wurde deaktiviert). Bei dieser Konfiguration kann der Bediener die Auswahl eines aktiven Kanals aus dem Bereich der konfigurierten Kanäle vornehmen.

Die Integration der Daten des FiLiA-Modells in eine Geräte-EDD war wie oben beschrieben möglich, der Zugriff auf echte Geräte jedoch nicht, da PDM die Kommunikation über WLAN nicht unterstützt und die EDD Spezifikation [10] keine Kommunikationsobjekte für WLAN definiert. Dazu kommt noch, wie bereits erwähnt, dass die in der EDD definierten Daten nicht in adäquater Form in realen Geräten vorhanden sind. Hierzu müssten in den Geräten die Datenstrukturen existieren und zugreifbar sein.



10 Zusammenfassung

Im Projekt „FiLiA“ wurde ein Modell entwickelt, welches alle wesentlichen Parameter beinhal-tet, die für Funkkomponenten in den Phasen des Lebenszyklus der industriellen Automation relevant sind. Dabei wurden nicht nur die Phasen der Anlage, sondern des Produktes an sich berücksichtigt. Vor der eigentlichen Modellbildung war eine ausführliche Anforderungsanalyse erforderlich. In diesem ersten Schritt wurden die einzelnen Phasen des Lebenszyklus definiert und beschrieben. Auch Akteure wie z. B. System- oder Gerätehersteller wurden eingeführt. Anschließend wurden verschiedene Use Cases in Bezug auf Funkkomponenten benannt. Diese wurden dann den Phasen des Lebenszyklus zugewiesen. Den Use Cases wurden aber auch Akteure zugeordnet, die an deren Durchführung beteiligt sind. In der Anforderungs-analyse wurden ebenfalls die verschiedenen Ebenen der Automation betrachtet.

Nach Abschluss der Anforderungsanalyse wurde eine Reihe von Literaturquellen, die über-wiegend aus den verschiedensten Standards bestanden, gesichtet und die Parameter gesam-melt, die für Funkkomponenten im Bereich der industriellen Automation von Bedeutung sind. Dazu gehören neben Hardwareattributen auch Kenn- und Einflussgrößen. Weiterhin wurde versucht, Parameter, die für alle Funktechnologien identisch sind, zusammenzufassen und zu generalisieren. Nach Beendigung der Recherche wurde die Vielzahl an Informationen katego-risiert und den Klassen Funkkomponente, Funkgerät, Antenne, Spannungsversorgung, Netz-werk und Anwendung zugeordnet. Des Weiteren wurden auch Untersuchungen durchgeführt, die überprüft haben, welche Einflussgrößen tatsächlich Auswirkungen auf das Zeit- und Feh-lerverhalten aufweisen. Diese mussten dann im Modell berücksichtigt werden. Alle anderen, bei denen keine Abhängigkeiten festzustellen waren, konnten aus den Betrachtungen ausgeschlossen werden. Nach der Kategorisierung der Parameter war auch ein wichtiger Schritt zu analysieren, welche Parameter in welchen Phasen des Lebenszyklus generiert, angepasst oder genutzt werden. Anschließend folgte die eigentliche Modellbildung. Dies ge-schah auf Basis von UML als Metamodell und die Abbildung auf XML-Schema (XSD), wobei die XML-Spezifikation als Austauschformat für die Modellinstanzen und als Ausgangspunkt für Transformationen genutzt wurde.

Durch die verschiedenen Phasen des Lebenszyklus existieren nun unterschiedliche Sichten auf das erstellte Modell. Da in diesen Phasen auch unterschiedliche Zielformate zum Einsatz kommen, war eine Transformation notwendig, welche die in den Phasen relevanten Para-meter aus dem Gesamtmodell herausfiltert und in das jeweilige Zielformat überführt. Dabei wurde auch auf die bereits erstellte Übersicht zurückgegriffen, die darstellt, welche Parameter in welchen Phasen relevant sind. Das Koexistenzmanagement, als eine wichtige Phase beim Einsatz von Funkkomponenten in einer industriellen Automatisierungsanlage, wurde dabei tiefergehender betrachtet.

Beispielhaft wurden ausgewählte Modellteile in die Zielformate GSDML, EDD und FDCML überführt. Anschließend wurde mit Hilfe der erzeugten Dateien die Validierung des gebildeten Modells vorgenommen. Dabei wurden beispielsweise aus dem Modell XML-Instanzdateien für reale Funkgeräte für die Technologien WLAN, Bluetooth und WirelessHART erstellt und deren Import- und Export-Funktionalität überprüft. Zur Validierung des GSDML-Zielformates wurde die erzeugte Instanzdatei in den Programmteil „HWConfig“ der Software SIMATIC STEP 7 importiert. Mit Abschluss der Validierung konnte die Korrektheit des gebildeten Modells erfolg-reich nachgewiesen werden.

Im Projekt „FiLiA“ wurde die Grundlage gelegt, Funkkomponenten in den kompletten Lebens-zyklus der industriellen Automation zu integrieren. Es wurde die Basis geschaffen, die Be-standteile und Aspekte der drahtlosen Kommunikation in bestehende Werkzeuge, welche in den spezifischen Phasen relevant sind, zu implementieren. Damit kann erreicht werden, dass der Einsatz von Funk nicht mehr separat, sondern zusammen mit der Erstellung und Sicher-stellung der Automatisierungsfunktionalität betrachtet wird. Die Integration kann auch dabei helfen, dass die Automatisierungsingenieure ohne eine Beratung oder Unterstützung von Funkexperten die Funkkommunikation einsetzen, beherrschen und erweitern können.



Bei der Modellbildung wurde sich während der Projektlaufzeit auf die weitverbreitetsten Funk-technologien WLAN, Bluetooth und WirelessHART beschränkt. Andere Standards wie z. B. WIA-PA sowie proprietäre Funklösung verschiedenster Hersteller blieben unberücksichtigt. Das Modell von FiLiA ist als erweiterbar konzipiert. Die Parameter neuer Standards und Lö-sungen müssten eingepflegt werden. Weiterhin müsste im Modell eine Schnittstelle geschaf-fen werden, in welcher die Hersteller das Modell mit ihren spezifischen Parametern erweitern könnten.

Im Projektverlauf war es außerdem nur eingeschränkt möglich, Funklösungen mit ihrem Ver-halten und Attributen in bestehende Werkzeuge, die innerhalb des Lebenszyklus Anwendung finden, zu integrieren. Erste Versuche mit GSDML und EDD wurden unternommen. Diese waren in ihrer Funktionalität teilweise beschränkt, sodass nicht alle Parameter, die zur Umset-zung einer Modellsicht von Nöten gewesen wären, eingebunden werden konnten. Außerdem ist auch die Anwendung auf andere Tools und Standards wie FDI bisher noch offen.

Mit den erreichten Ergebnissen wurde ebenfalls offenbart, dass eine Standardisierung von funkrelevanten Parametern zwingend notwendig ist. Viele Parameter tragen unterschiedliche Bezeichnungen, obwohl sie dieselbe Bedeutung haben. Viele Hersteller stellen für dieselbe Funktechnologie unterschiedliche Parameter und Einstellungsmöglichkeiten zur Verfügung. Eine solche Standardisierung ist während des gesamten Lebenszyklus einer Automatisie-rungsanlage von Vorteil. Verantwortliche Ingenieure müssten sich nicht in jedes Gerät, wenn es von einem anderen Hersteller stammt, einarbeiten. Die Planung, Konfiguration und War-tung wären einfacher. Auch das Speichern bestehender Funksysteme und deren aktuellen Einstellungen in Datenbanken wären so besser möglich. Eine Standardisierung wäre für die Integration von Funklösungen in die Gesamtanlage von vorteilhaft.

Ein weiterer Punkt bezüglich einer notwendigen Standardisierung betrifft die Diagnose. Wenn Probleme bei der Funkkommunikation auftreten, müssen bisher die zur Störungsanalyse relevanten Parameter per Webinterface aus den Geräten gelesen werden. Auch das Web-interface ist von Hersteller zu Hersteller unterschiedlich. Dies führt zu einer Verzögerung der Ursachenforschung. Ein Fehler in der Funkkommunikation kann für Produktionsausfälle verantwortlich sein. Eine Verzögerung der Fehlerbehebung führt zu einer Erhöhung der ohne-hin schon erheblichen Kosten. Eine standardisierte Diagnoseschnittstelle kann die Zeit zur Lösung des Problems stark verkürzen. Es kann auch dabei helfen, dass Störungen in der Funkkommunikation schon im Vorfeld vermieden werden.

Mit dem in FiLiA geschaffenen Modell ist es möglich, ein Koexistenzmanagementtool zu ent-wickeln. Die eingesetzten Funkkommunikationssysteme und ihre Parameter werden in einer Datenbank gesammelt. Wichtig dabei ist auch das Festhalten der exakten Position der Geräte in der Anlage. Nicht außer Acht gelassen werden darf die Anforderung der Anwendung an die Funkübertragung einer Verbindung. Das Managementsystem muss Situationen erkennen, in denen die Einhaltung der Anforderungen nicht mehr gewährleistet werden kann und entspre-chende Maßnahmen ergreifen. Dies gilt auch für die Einbindung neuer Funksysteme in die bestehende Anlage. Der verantwortliche Ingenieur müsste bei Konflikten, z. B. durch die Nut-zung desselben Frequenzbereiches, auf eine möglicherweise falsche Konfiguration aufmerk-sam gemacht werden, um selbst Gegenmaßnahmen ergreifen zu können.

Darstellung des wissenschaftlich-technischen und wirtschaftlichen Nutzens der erzielten Ergebnisse 84 / 89


11 Darstellung des wissenschaftlich-technischen und wirtschaftlichen Nutzens der erzielten Ergebnisse

11.1 Wirtschaftsbereiche

Die Projektergebnisse sind vor allem für kleine und mittelständische Unternehmen (KMU) aus dem Bereich der Entwicklung und Fertigung funkbasierter Automatisierungskomponenten, -geräte und -lösungen (Mess-, Regel- und Automatisierungs- sowie Informations- und Kom-munikationstechnik) von Interesse. Eine Relevanz der Ergebnisse besteht allerdings auch für KMU, die als Planungsbüros/ Systemintegratoren für die Prozess- und Fertigungsindustrie, als Betreiber bzw. als Wartungsunternehmer solcher Anlagen sowohl in der chemischen Verfah-renstechnik, Pharmaindustrie, Grundstoffindustrie, Biochemie, Wasser-/Abwassertechnik und anderen prozesstechnisch orientierten Branchen als auch von Anlagen mit eher Stückgut orientierten Produktionsprozessen, wie sie z.B. im Fahrzeug- und Maschinenbau anzutreffen sind, am Markt auftreten. Es ist also eine erhebliche Anzahl von KMU von den Ergebnissen dieses Forschungsvorhabens betroffen. Im weiteren Verlauf dieses Abschnittes wird erläutert, welche wirtschaftliche Bedeutung für KMU von diesem Vorhaben ausgeht.

11.2 Nutzen der angestrebten Forschungsergebnisse

Bei dem hier vorgestellten Vorhaben wurde eine konsequente Weiterentwicklung und Erweite-rung bestehender Modelle im Lebenszyklus der Automation hin zu einem einheitlichen Modell und Konzept zu dessen durchgängiger Betrachtung vorgenommen. Die damit gewonnenen Ergebnisse führen in erster Linie zu einer Verringerung der Aufwendungen und somit der Kosten für die einzelnen beteiligten Akteure. Durch das Aufzeigen eines einheitlichen Kon-zeptes werden Impulse für neue Anwendungsszenarien beim Lifecycle-Management generiert und neue Anwendungsfelder (z. B. durch erhöhte Mobilität ohne höheren Managementauf-wand) erschlossen.

Die entstandenen Ergebnisse sind Grundlage für einheitliche und damit gleiche Sichtweisen auf verschiedene Funktechnologien in der Automation sowie deren gleiche Handhabung in den unterschiedlichen Anwendungsbereichen (Prozessautomation, Fertigungsautomation). Es wurde eine offene „Schnittstelle“ zum Lifecycle-Management-Prozess für Funkkomponenten unterschiedlichster Technologien und Hersteller geschaffen und somit die allgemeine Markt-anforderung nach einer herstellerunabhängigen Interoperabilität der Komponenten erfüllt. Den genannten Unternehmenstypen wird die Möglichkeit geboten, dem Kundenwunsch nach Flexi-bilität mit offenen Produkten zu entsprechen.

Die Hersteller von Funkkomponenten können diese Ergebnisse nutzen, um ihren Markt in Richtung Automatisierungstechnik zu erweitern bzw. zu festigen. Systemintegratoren kann freigestellt werden, welche Funktechnologie oder welchen Hersteller sie einsetzen. Software-Werkzeug-Hersteller wird ermöglicht, mit ihren Produkten ein größeres Spektrum an Geräten und somit von Anwendungen abzudecken.

Wesentliche Teile der Modellumsetzung in XML bzw. UML können direkt als Grundlage für die Entwicklung von Lösungspakten (Planer, Hersteller) oder als Basislösung beim Anwender (Betreiber/ Wartungsunternehmen) eingesetzt werden.

Die im Vorhaben „FiLiA“ durchgeführten Tests zur Ermittlung der Einflussfaktoren auf die Kenngrößen von Funksystemen sowie deren Klassifizierung können in den verschiedensten Phasen des Lebenszyklus zum einen durch Planer, Systemintegratoren und zum anderen durch Betreiber und Wartungsunternehmen / Instandhalter direkt als Entscheidungsgrundlage oder indirekt als Referenz genutzt werden.

Neben den genannten Formen der direkten Nutzung ergibt sich ein massiver indirekter Nutzen durch die mit diesem Forschungsvorhaben hervorgebrachte Funktionalität, u. a. bei der Unter-stützung von Herstellern, Systemintegratoren und Betreibern. Damit einhergehen:

die Verkürzung der Zeiten und die Verringerung des Aufwandes zur Integration von Funklösungen in den Lebenszyklus von Automatisierungssystemen

Darstellung des wissenschaftlich-technischen und wirtschaftlichen Nutzens der erzielten Ergebnisse 85 / 89


die Festigung von KMU als Anbieter für automatisierungstechnische Produkte und Lösungen. Beispielsweise ist es für KMU, die Feldgeräte produzieren, entscheidend, dass ihre Feldgeräte in ähnlich komfortabler Weise in das Gesamtsystem eingebunden werden können wie Feldgeräte der großen Hersteller. Dadurch kann die Gefahr redu-ziert werden, dass durch herstellerspezifisch optimierte Tools und eine unübersichtli-che Funktionsvielfalt die Erzeugnisse der KMU nicht optimal integriert werden können.

Für KMU als Systemanbieter/Integrator, Betreiber oder Instandhalter ergibt sich eine Senkung der Aufwendungen beim Erschließen weiterer Technologien und Anwen-dungsfelder. Dadurch kann deren Wettbewerbsfähigkeit massiv gesteigert werden.

Als Beispiele für die Nutzung der Ergebnisse in verschiedensten Bereichen der industriellen Automation seien die folgenden genannt:

Betriebsdatenerfassung für stationäre und mobile Anwendungen

Einsatz von Identifikationssystemen für die Prüfung und Fernüberwachung von Montageprozessen

Erkennen und Melden von kritischen Betriebszuständen (Condition Monitoring Systems, CMS)

Einsatz von Sensornetzwerken bei der Ferndiagnose bzw. Fernüberwachung von mobilen und stationären Systemen

Einsatz von Prüfständen mit dazugehöriger moderner Leit- und Steuerungstechnik

Weiterentwicklung moderner Antriebstechnik

11.3 Möglicher Beitrag zur Steigerung der Leistungs- und Wettbewerbsfähigkeit der KMU

Dieses Vorhaben erhob die funkgestützte Kommunikation zum integralen Bestandteil des Lifecycle-Management-Prozesses in der Automation. Es leistete damit einen weiteren Beitrag dazu, dass sich die funkgestützte Kommunikation in der industriellen Automatisierung weiter etabliert und somit Vorteile wie Mobilität und Flexibilität wirksam werden können.

Weiterhin wurde durch das im Projekt verfolgte Ziel, der Offenhaltung des Marktes in dem sich dynamisch entwickelnden Technologiebereich, unterstützt. Dies wurde besonders durch den generischen Charakter der entwickelten (hersteller- und plattformunabhängigen) Konzepte und Technologien ebenso wie durch das Einbringen der Ergebnisse in Standardisierungs-bestrebungen auf unterschiedlichen Ebenen belegt. Ohne Durchführung des Projektes be-stand die Gefahr, dass durch herstellerspezifisch optimierte Tools und eine unübersichtliche Funktionsvielfalt die Erzeugnisse der KMU nicht optimal integriert werden können und damit für die KMU ein erheblicher Wettbewerbsnachteil entsteht.

Neben den Herstellern von Automatisierungsgeräten partizipieren auch Hersteller von typi-schen Funkkomponenten (vielfach KMU) von diesem Projekt, da sie durch die Nutzung der Ergebnisse den für sie neuen Markt Automation erschließen können.

Hersteller von Automatisierungsgeräten und von speziellen Transmittern – ebenfalls vielfach KMU – verbessern die Akzeptanz ihrer Lösungen, wenn die Sichtweise auf funkgestützte Geräte der auf kabelgebundene entspricht.

KMU werden mit den Ergebnissen dieses Projektes in die Lage versetzt, Funksysteme mit re-duziertem Aufwand in Betrieb nehmen und neue Funktionen durch Funktechnologie erschlie-ßen zu können. Somit kann die schnelle Amortisierung einer Systemlösung beim Anlagen-betreiber ermöglicht werden, insbesondere auch im Hinblick auf Konzepte zur Nachrüstung oder Modernisierung bestehender Anlagen. In Verbindung mit der oft anzutreffenden, organi-satorisch bedingten Fähigkeit äußerst schnell auf Kundenwünsche reagieren zu können, wurde die Möglichkeit zur Generierung eines Wettbewerbsvorteils geschaffen.

Verwertung 86 / 89


12 Verwertung

In Tabelle 5 sind die vorhabenbezogenen Verwertungsaktivitäten und Veröffentlichungen zu-sammengefasst dargestellt.

Tabelle 5: Veröffentlichungen im Rahmen des FiLiA-Projektes

Maßnahme Termin

Information der Unternehmen des Projektbegleitenden Ausschusses (PA) 12.01.2011

Vorstellung im ZVEI AK "Kommunikationstechnik für Analysatoren (KfA)" 24.02.2011

Vorstellung im ZVEI GAKA 24.03.2011


AK Systemaspekte ZVEI 12.05.2011

WIP zur ETFA 2011: „Lifecycle Management related Model Approach for Wireless Automation“ [20]

07.09.2011

Vorstellung und Diskussion der Projektes im Arbeitskreis "Wireless in der Automation" ZVEI

23.09.2011

Vorstellung und Diskussion der Projektes im GMA Fachausschuss FA5.23 „XML in automatisierungstechnischen Anwendungen“

15.11.2011


Diskussion des Projektes bei GHMT und FNT 01.03.2012

Einarbeitung des Modells in die Vorlesungen „Informationsmodelle“ und „Industrielle Kommunikationssysteme“ der TU Dresden

Juni 2012

Vorstellung der Projektergebnisse auf der Sitzung der Forschungsgemeinschaft Automation

26.02.2013


Beitrag zur Automation 2013: „Modellierung von Funkkomponenten im Kontext des Lebenszyklus der industriellen Automation“ [21]

25.-26.06.2013

Referenzen 87 / 89


13 Referenzen

[1] ISO 15745, „Industrial automation systems and integration,“ 2003.

[2] Wireless Automation, „6. Jahrestagung Funkgestützte Kommunikation in der industriellen Automatisierungstechnik,“ In: VDI-Berichte Nr. 1979 VDI-Verlag Düsseldorf, ISBN 978-3-18-091979-9, Magdeburg-Barleben, Germany, 2007.

[3] Projekt VAN, „Verbundvorhaben "Virtual Automation Networks",“ European Commission, Contract no. 016969.

[4] Projekt SafetyRadio, „Verbundvorhaben "Zuverlässige Funkkommunikation für funktional sichere Automatisierungssysteme",“ Bundesministeriums für Wirtschaft und Technologie (BMWi), Förderkennzeichen: 16IN0429.

[5] Projekt ZESAN, „Verbundvorhaben „ZESAN – Zuverlässige, energieeffiziente drahtlose Sensor-/ Aktornetze für Gebäudeautomatisierung, Anlagenüberwachung und Prozesssteuerung“,“ Bundesministerium für Bildung und Forschung, Förderkennzeichen 01BN0712F.

[6] ZVEI, Zentralverband Elektrotechnik- und Elektronikindustrie, „Leitfaden „Einsatz von Web-Technologien in der Automation“,“ 2006.

[7] ZVEI - Zentralverband Elektrotechnik- und Elektronikindustrie e.V, „Leitfaden „Life-Cycle-Management für Produkte und Systeme der Automation",“ Oktober 2010.

[8] PROFIBUS Nutzerorganisation e.V., „Profile Guidelines Part 1: Identification & Maintenance Functions,“ PROFIBUS Nutzerorganisation e.V., D-76131 Karlsruhe, Germany, 2005.

[9] IEC 61987-10, „Industrial-process measurement and control - Data structures and elements in process equipment catalogues - Part 10: List of Properties (LOPs) for Industrial-Process Measurement and Control for Electronic Data Exchange,“ 2009.

[10] IEC 61804-3, „Function Blocks for Process Control, Part 3: Electronic Device Description Language,“ 2007.

[11] IEC 62390, „Device profile guideline,“ 2012.

[12] IEC 62541, „OPC Unified Architecture,“ 2010.

[13] IEC 62453, „Field device tool (FDT) interface specification,“ 2009.

[14] IEC 62769, „Dield Device Integration (FDI),“ 2012.

[15] IEC 62657, „Industrial Communication Networks - Wireless communication networks,“ 2012.

[16] PROFIBUS Nutzerorganisation e.V., WSAN Air Interface Specification, 2012.

[17] PROFIBUS Nutzerorganisation e.V., WSAN System Specification, 2012.

[18] S. Mätzler, R. Lehmann, S. Theurich, A. Dennert und M. Wollschlaeger, „Virtual Industrial Ethernet Devices for Testing Purposes,“ in ETFA 2012 - 17th IEEE International Conference on Emerging Technologies & Factory Automation, Krakau, Polen, 2012.

[19] S. Mätzler, R. Lehmann und M. Wollschlaeger, „Virtualisierung von PROFINET IO Geräten zur Effizienzsteigerung im Anlagen-Engineering,“ in KommA - 3. Jahreskolloquium "Kommunikation in der Automation", Lemgo, Deutschland, 2012.

Referenzen 88 / 89


[20] M. Wollschlaeger, A. Dennert, L. Rauchhaupt, D. Hasler, A. Schimschar und M. Riedl, „Lifecycle Management related Model Approach for Wireless Automation,“ in IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Toulouse, France, 2011.

[21] A. Schimschar, D. Hasler, M. Wollschlaeger und R. Lehmann, „Modellierung von Funkkomponenten im Kontext des Lebenszyklus der industriellen Automation,“ in Automation, Baden-Baden, Deutschland, 2013.

[22] Projekt FunBus, „Verbundvorhaben "Drahtlose Feldbusse im Produktionsumfeld",“ Bundesministerium für Bildung und Forschung, Förderkennzeichen: 02PV4060.

[23] Project RFieldbus, „Verbundvorhaben "HIGH PERFORMANCE WIRELESS FIELDBUS IN INDUSTRIAL RELATED MULTI-MEDIA ENVIRONMENT",“ European Commission, Contract no. IST-1999-11316.

[24] Projekt FTT, „"Funk-Transfer-Tester für industrielle Funklösungen",“ Bundesministeriums für Wirtschaft und Technologie (BMWi) innerhalb des Förderprogramms "Förderung von Forschung und Entwicklung bei Wachstumsträgern in benachteiligten Regionen" - INNOVATIVE-WACHSTUMS-TRÄGER (INNO-WATT), Reg.-Nr.: IW050103.

[25] VDI/VDE, „"Funkgestützte Kommunikation in der Automatisierungstechnik",“ VDI/VDE, Juni 2006.

[26] Projekt MODALE, „Modellbasiertes Anlagen-Engineering,“ Bundesministerium für Bildung und Forschung, Vorhaben Nr. S 536, FKZ: 01/SC28B.

[27] Projekt PROTEUS, „generische e-Maintenance Plattform,“ Bundesministerium für Bildung und Forschung, ITEA-Initiative, Vorhaben Nr.: 01/SC01A.

[28] R. Simon, Methoden zur Feldinstrumentierung von Verteilten Automatisierungssystemen. Dissertation, Düsseldorf: Forschungsbericht VDI Reihe 8, Nr. 918, VDI Verlag , 2001..

[29] Projekt SOCRADES, „Verbundvorhaben "Service-Oriented Cross-layer infRAstructure for Distributed smart Embedded deviceS",“ European Commission, Contract no. IST-5-034116.

[30] M. Wollschlaeger, H. Kulzer, D. Nübling und P. Wenzel, „A Common Model for XML Descriptions in Automation,“ Prag, 04.-08.07.2005.

[31] M. Wollschlaeger und P. Wenzel, „Common Model and Infrastructure for Application of XML within the Automation Domain,“ in INDIN 2005 – 3rd IEEE International Conference on Industrial Informatics, Perth, 10. 12.08.2005.

[32] M. Wollschlaeger und R. Frenzel, „Handling Field Device Documentations throughout the Life Cycle of Automation Systems – Webbased Information Model and Access Methods,“ in INDIN 2006 4th IEEE Conf. on Industrial Informatics, Singapur, 16.-18.08.2006.

[33] A. Gössling und M. Wollschlaeger, „Life-cycle Oriented Data Access for a Maintenance Framework.,“ in ETFA 2007 12th IEEE Conference on Emerging Technologies and Factory Automation, Patras, 25.-28.09.2007.

[34] R. Frenzel, M. Wollschlaeger und A. Gössling, „Erweitertes Life-Cycle Management für Geräte in der Automatisierung.,“ in INFORMATIK 2007 – Informatik trifft Logistik, 37. Jahrestagung der Gesellschaft für Informatik e.V. (GI), Bremen, 24.-27. 09. 2007.

[35] R. Lehmann, M. Wollschlaeger und F. Iwanitz, „A Secure Proxy Solution for PROFINET IO as a Migration Strategy for Existing Automation Solutions,“ in FeT 2007 - 7th IFAC International Conference on Fieldbuses & Networks in Industrial & Embedded Systems,, Toulouse (France), 07.-09.11.2007.

Referenzen 89 / 89


[36] „IEC 62264 Enterprise Control System Integration – Part 1: Models and Terminology,“ IEC, 2003.

[37] NE 53, „Namur: NE53 - Software von Feldgeräten und signalverarbeitenden Geräten mit Digitalelektronik,“ 2003.

[38] NE 124, „Namur „Anforderungen an Wireless Automation“,“ 13.01.2009.

[39] NE 133, „Namur „Wireless Sensor Netzwerke: Anforderungen an die Konvergenz der verfügbaren Standards“,“ 06.09.2010.

Documents

Gerätebezogene Modellierung von Funkkomponenten zur ... · Gerätebezogene Modellierung von Funkkomponenten zur Berücksichtigung im Lebenszyklus industrieller Automatisierungsanlagen