Intelligentes Catering mit RFID - Fraunhofer...5 Fraunhofer IAO Intelligentes Catering mit RFID...

F R A U N H O F E R - I N S T I T U T F Ü R A R b E I T S w I R T S c H A F T U N d O R g A N I S AT I O N I A O

IntellIgentes CaterIng mIt rFID

PROzESSE, LOgISTIk UNd INTEgRATION NEUER TEcHNOLOgIEN Im LUFTFAHRTcATERINg

Logistisch organisierte Servicesysteme mit ihrer entsprechenden Vernetzung können heutzutage in vielen Bereichen des alltäglichen Lebens angetroffen werden. Charakterisiert werden diese durch einen Grundprozess und eine Vielzahl von Prozessteilnehmern. Ob nun in einem Flugzeug die Passagiere einen Cateringservice erfahren, in einem Großkrankenhaus der Speiseservice organisiert wird oder im Bahnwesen die zugfahrenden Kunden bedient werden, die Prinzipien und Prozesse der Warenströme sind stets ähnlich.

Die vorliegende Broschüre zeigt wesentliche Ergebnisse des Projektes iC-RFID, das vom Bundesministerium für Wirtschaft und Technologie (BMWi) gefördert wurde. Ziel dieses Projektes war die Entwicklung eines integrierten Airline-Catering-Gesamtsystems.

Dargestellt werden Prozessmodelle für das integrierte Catering, Software-technologien zur Integration und Überwachung sowie intelligente Planungs- und Steuerungssysteme. Des Weiteren werden neue Technologien wie RFID-basierte Trolleys und Kommissionierstationen sowie innovative Konzepte für das Preflight-Shopping und Kabinenservices vorgestellt.

ISBN 978-3-8396-0206-5

9 7 8 3 8 3 9 6 0 2 0 6 5

Inte

llIg

ente

s C

ate

rIn

g m

It r

FID

IC-RFID_lay1.indd 1 17.11.2010 15:21:39

Intelligentes Catering mit RFID Prozesse, Logistik und Integration neuer Technologien

im Luftfahrtcatering

Herausgeber Fraunhofer IAO Kontaktadresse Fraunhofer-Institut für Arbeitswirtschaft und Organisation Nobelstraße 12 70569 Stuttgart Telefon: +49 (0) 711/970-51 20 Telefax: +49 (0) 711/970-51 11 E-Mail: [email protected] Web-Adresse: http://www.e-business.iao.fraunhofer.de

Hinweis auf das Forschungsprojekt iC-RFID Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums für Wirtschaft und Technologie unter dem Förderkennzeichen 01MT06006 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren. Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. ISBN: 978-3-8396-0206-5 Druck und Weiterverarbeitung

IRB Mediendienstleistungen Fraunhofer-Informationszentrum Raum und Bau IRB, Stuttgart Verlag und Druck Fraunhofer Verlag, Fraunhofer-Informationszentrum Raum und Bau IRB Postfach 800469, 70504 Stuttgart Nobelstraße 12, 70569 Stuttgart Telefon: +49 (0) 711/970-25 00 Telefax: +49 (0) 711/970-25 08 E-Mail: [email protected] Web-Adresse: http://verlag.fraunhofer.de Für den Druck des Buches wurde chlor- und säurefreies Papier verwendet. Copyright Fraunhofer IAO, 2010 Alle Rechte vorbehalten Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Verwertung, die über die engen Grenzen des Urheberrechtsgesetzes hinausgeht, ist ohne schriftliche Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Speicherung in elektronischen Systemen. Die Wiedergabe von Waren-bezeichnungen und Handelsnamen in diesem Buch berechtigt nicht zu der Annahme, dass solche Bezeichnungen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und deshalb von jedermann benutzt werden dürften. Soweit in diesem Werk direkt oder indi-rekt auf Gesetze, Vorschriften oder Richtlinien (z.B. DIN, VDI) Bezug genommen oder aus ihnen zitiert worden ist, kann der Verlag keine Gewähr für Richtigkeit, Vollständigkeit oder Aktualität über-nehmen.

3

Fraunhofer IAO Intelligentes Catering mit RFID

Autoren

Prof. Dr. Monika Bauer (Fraunhofer PYCO)

Karl-Heinz Haas (MGS – Modular Galley Systems AG)

Henning Hagg (B&W Engineering GmbH & Co. KG)

Dr. Lutz Hartmann (Fraunhofer PYCO)

Udo Inden (Fachhochschule Köln)

Frank Neubauer (EADS Innovation Works)

Damian Pietrek (MGS – Modular Galley Systems AG)

Thomas Renner (Fraunhofer IAO)

Falk Scheiding (Fraunhofer IAO)

Arnd Schirrmann (EADS Innovation Works)

Reinhold Sell (MGS – Modular Galley Systems AG)

Stephan Tieck (EADS Innovation Works)

Felix Tönnies (autoID systems GmbH)

Krešimir Vidačković (Fraunhofer IAO)

Oliver Vogt (B&W Engineering GmbH & Co. KG)

4


5


Inhalt

Abbildungen 7

Tabellen 9

Abkürzungen 10

Ergebnisübersicht 11

1 Einführung 13 1.1 Ausgangssituation im Luftfahrtcatering 13 1.2 Radiofrequenz-Identifikation (RFID) 15 1.3 Projektziele 16

2 Forschungsergebnisse 18 2.1 Integrierter Cateringprozess 18 2.2 Preflight Shopping 23 2.3 RFID-basierter Trolleyumlauf 26 2.4 IT-gestützte Kommissionierung 37 2.5 Innovativer Kabinenservice 38 2.6 Systemintegration und Prozessüberwachung 52 2.7 Intelligentes Planungs- und Steuerungssystem 72

3 Zusammenfassung und Ausblick 86

Partnervorstellung 88

Anhang 92

6


7


Abbildungen

Abbildung 1: Gesammelte Trolleys an der Rampe eines Caterers 15

Abbildung 2: RFID-System 16

Abbildung 3: Prozessmodell des integrierten Luftfahrtcatering 19

Abbildung 4: Architektur des Preflight-Shops 25

Abbildung 5: Oberfläche des Preflight-Shops 26

Abbildung 6: i-Trolley in Dockingstation 27

Abbildung 7: Bildschirmanzeige des i-Trolley während des Erkennungsvorgangs 27

Abbildung 8: Tag zur Kennzeichnung eines Trolleys 28

Abbildung 9: Demonstrator der Ansteuerung des Displays mit dem 3-Zeilen-Layout für die CeBit 2009 30

Abbildung 10: Display-Zelle mit 160x160 Pixelmatrix während der Bestimmung der elektrooptischen Kennlinien mittels des DMS 505 30

Abbildung 11: Exemplarische elektro-optische Kennlinie für ein Display ohne PI-Orientierungsschicht. Die für die Ansteuerung zu wählende Spannung beträgt 24 V, die Auswahlspannung beträgt ±4 V 31

Abbildung 12: Prinzip des Digital Flight Labels (DFL) 31

Abbildung 13: Prinzip des Digital Flight Labels (DFL): links ein heute typischerweise zur Identifizierung von Trolleys verwendetes Papierlabel, rechts das von PYCO entwickelte DFL 32

Abbildung 14: Einbau von RFID-Antennen in Galley-Compartments 32

Abbildung 15: RFID-Gates mit mehreren Antennen zur Richtungserkennung (Laboraufbau) 34

Abbildung 16: Gate mit Display im Technikdemonstrator 36

Abbildung 17: Handheld beim Auslesen des Trolley-Tags 36

Abbildung 18: Caterer Service Desk, i-Trolley und Rampen-Gate im Technikdemonhstrator 37

Abbildung 19: Caterer Service Desk, i-Trolley und Rampen-Gate im Technikdemonhstrator 38

Abbildung 20: Gestaltungsbereich und -felder von Servicekonzepten 39

Abbildung 21: iC-RFID Konzept: Übersicht 40

8


Abbildung 22: Servicekonzept Inflight Commerce 41

Abbildung 23: Klassifikation des Simulationsmodells (in Anlehnung an Scholtissek (1996) 42

Abbildung 24: Ablauf einer Simulation (in Anlehnung an VDI 3633 (2000)) 43

Abbildung 25: Inflight Service Stimulus Modell, Beispiel Low Cost Carrier, 2 h Flug 44

Abbildung 26: Prozessablauf Servicewunsch über »Sitzknopf« 45

Abbildung 27: SIMUL8 GUI: Grundelemente 45

Abbildung 28: iC-RFID-Simulationsmodell in SIMUL8 46

Abbildung 29: Inflight Control Unit 49

Abbildung 30: Multi-Functional Unit mit RFID-gesteuertem Ofen 50

Abbildung 31: Slide in Module (a), (b) und (c) v.l.n.r. 50

Abbildung 32: RFID-Sensor 51

Abbildung 33: Advanced User Guide 51

Abbildung 34: Management-Konsole der Middleware 53

Abbildung 35: Allgemeine Kommunikationsstruktur 55

Abbildung 36: Frontend Applikation des XHPCI 57

Abbildung 37: Wurzelelement des XML-Standards 58

Abbildung 38: openPlatform-Dokument FlightSchedule 62

Abbildung 39: openPlatform-Dokument PreFlight Order 63

Abbildung 40: openPlatform-Dokument Assembly / Freight List and Additional Delivery 64

Abbildung 41: openPlatform-Element PRODUCT 66

Abbildung 42: openPlatform-Dokument Transfer Order 68

Abbildung 43: openPlatform-Dokument Ground Delivery 69

Abbildung 44: Monitoring Dashboard mit einer Anzeige von RFID-Events und ausgetauschten openPlatform-Nachrichten im Prozessablauf 70

Abbildung 45: Beispiel: Prozessverlauf Flugzeutrolley, hier: Anzeige verspäteter Trolleys inkl. letztem bekannten Standort des Trolleys im geplanten Prozess 70

Abbildung 46: Prozess der kontinuierlichen Planung 80

Tabellen

9

Tabellen

Tabelle 1: Vorabbestellungsmöglichkeiten 24

Tabelle 2: Mögliche Szenarien der Verwendung des openPlatform Konzepts 59

Tabelle 3: Daten eines beispielhaften Multiagentensystems bei einer LKW-Transportqeue 77

10


Abkürzungen

ARINC Aeronautical Radio Incorporated

BDE Betriebsdatenerfassung

CTB Catering-Transportbehälter

DFL Digital Flight Label

HMI Benutzeroberfläche (Human Maschine Interface)

KMU Kleines und mittelständisches Unternehmen

MAS Multiagentensystem

MW Middleware

RFID Radio Frequency Identification

XHPCI eXtensible High Performance Controller Interface

XML Extensible Markup Language

11

Fraunhofer IAOIntelligentes Catering mit RFID

Ergebnisübersicht

Integrierter Cateringprozess

Prozessmodell (Fraunhofer IAO) 18

Preflight Shopping

Preflight Shop (Fraunhofer IAO) 25

RFID-basierter Trolleyumlauf

i-Trolley (B&W Engineering GmbH & Co. KG) 26 Gelabelter Trolley (B&W Engineering GmbH & Co. KG) 28 Digital Flight Label (Fraunhofer PYCO) 28 RFID-Galley (B&W Engineering GmbH & Co. KG) 32 RFID-Gates im Flugzeug mit Richtungserkennung (EADS Innovation Works) 33 Erfassung des Aufenthaltsorts von CTBs im Flugzeug (EADS Innovation Works) 35 RFID-Gates und Rampen-Gates (B&W Engineering GmbH & Co. KG) 35 Handhelds (B&W Engineering GmbH & Co. KG) 36

IT-gestützte Kommissionierung

Caterer Service Desk (B&W Engineering GmbH & Co. KG) 37 Catering Assembling Station (MGS – Modular Galley Systems AG) 37

Innovativer Kabinenservice

Neue Kabinenservicekonzepte (EADS Innovation Works) 39 Simulation von Kabinenservice (EADS Innovation Works) 41 Inflight Control Unit (MGS – Modular Galley Systems AG) 47 Multi-Functional Unit mit RFID-gesteuertem Ofen (MGS – Modular Galley Systems AG) 49

Systemintegration und Prozessüberwachung

Middleware (autoID systems GmbH) 52 eXtensible High Performance Controller Interface (autoID systems GmbH) 56 XML-Austauschformat openPlatform (Fraunhofer IAO) 57 Monitoring Dashboard (autoID systems GmbH, Fraunhofer IAO) 69 Process Monitoring & Quality Assurance (Fraunhofer IAO) 71

Intelligentes Planungs- und Steuerungssystem

CESSAR - Configuration and Evaluation of Service Systems in Air-Catering with RFID (Fachhochschule Köln) 72

12


13


1 Einführung

Logistisch organisierte Servicesysteme mit ihrer entsprechenden Vernetzung können heutzutage in vielen Bereichen des alltäglichen Lebens angetroffen werden. Charakterisiert werden diese durch einen Grundprozess und eine Viel-zahl von Prozessteilnehmern. Durch unseren gesellschaftlichen Wandel und der daraus resultierenden zunehmenden Gewichtung des dienstleistenden Sektors bekommen Servicesysteme einen immer höheren Stellenwert in unserer mo-dernen Gesellschaft. Ob nun in einem Flugzeug die Passagiere einen Catering-service erfahren, in einem Großkrankenhaus der Speiseservice organisiert wird oder im Bahnwesen die zugfahrenden Kunden bedient werden, die Prinzipien und Prozesse der Warenströme sind stets ähnlich.

In vielen Fällen jedoch ist im logistischen Zusammenspiel der Informationsaus-tausch aller Parteien aufgrund der Komplexität der Vernetzung noch nicht aus-gereift und auf einem niedrigen Stand. Es ist Platz für entsprechende Innovati-onen, um auch im besonderen Maße zukünftigen Anforderungen gerecht zu werden. Eine Modernisierung durch immer weiter fallende Marktpreise in Frage kommender elektronischer Hilfsmittel ist nun in einem breiten Anwendungs-spektrum erstmalig wirtschaftlich denkbar.

Im Projekt iC-RFID wurde erstmals die Catering-Prozesskette im Luftfahrtbereich integriert und optimiert sowie die Einführung neuer Servicekonzepte mit Hilfe von aktuellen Technologien untersucht. Das Ziel dieses vom Bundesministerium für Wirtschaft und Technologie (BMWi) geförderten Gemeinschaftsprojektes war die Entwicklung eines integrierten Airline-Catering-Gesamtsystems mit ei-nem beispielhaften Aufbau und Vorführung an einem Demonstrator. Es wurde ein Konsortium mit Vertretern aus Wirtschaft und Forschung gebildet, das sich durch langjährige Kompetenzen im Luftfahrtbereich, in der RFID-Branche sowie in der Prozessstandardisierung auszeichnet. Das Konsortium setzt sich zusam-men aus den Unternehmen Airbus und EADS, den Forschungseinrichtungen Fraunhofer-Gesellschaft (Institute IAO und PYCO) und Fachhochschule Köln sowie den mittelständischen Unternehmen autoID systems, B&W Engineering und MGS - Modular Galley Systems.

Die in der Projektlaufzeit entwickelten Dienstleistungskonzepte ergänzen die technischen Entwicklungen durch neue Geschäftsmodelle und Ertragsmöglich-keiten im Luftfahrtbereich in idealer Weise.

1.1 Ausgangssituation im Luftfahrtcatering

Vor dem Hintergrund der konkurrierenden Geschäftssysteme der etablierten Airlines und der neuen Anbieter, so genannter Low-cost-carrier (Billigfluggesell-schaften), erfordert die aktuelle Wettbewerbssituation und -dynamik anzupas-

Einführung

14


sende, spezielle Strategien, damit die Unternehmen weiter erfolgreich bestehen können.

Zudem hat die Luftfahrtbranche nach Angaben1 der IATA (International Air Transport Association) das vergangene Jahr 2009 mit dem größten Nachfrage-rückgang seit Ende des Zweiten Weltkriegs abgeschlossen. Entsprechend ver-zeichnet die Luftfahrt-Catering-Branche aufgrund der Weltwirtschaftskrise ebenfalls schwere Einbußen.

Durch die aktuelle Situation sind sowohl die Airlines als auch die Zulieferer ins-besondere die Caterer gezwungen, die Kosten im operativen Bereich zu sen-ken, wie z.B.:

- Kostenreduktion als Maßnahme auf den Kostendruck in der gesamten Luft-fahrtbranche,

- Reduktion des Services an Bord durch die Airlines oder

- Verzicht auf kostenlose Mahlzeiten während des Fluges (gerade bei den Bil-ligfluggesellschaften und kürzeren Flügen).

Bedingt durch die sehr große Anzahl und Vielfalt von Artikeln und des entspre-chenden Equipments ist das Luftfahrt-Catering sowohl in der Tiefe, als auch in der Breite der Prozesse, als äußerst komplex anzusehen und ist im Wesentlichen durch eine industrie- und unternehmensübergreifende Gesamtprozesskette ge-kennzeichnet. Laut Aussage des Präsidenten von KLM setzt sich das Luftfahrt-catering aus 70% Logistik und 30% Essenszubereitung zusammen.

So werden jährlich über eine Milliarde Speisen für das Luftfahrtcatering welt-weit produziert. Dies erfolgt entweder in kleinen oder auch sehr großen Kü-chen, nach unterschiedlichen Gerätestandards und Ansprüchen. Zur weiteren Versorgung im Flugbetrieb wird zudem eine Vielzahl von zusätzlichen Cate-ringgütern wie Getränke, Duty-free-Artikel, Toiletten- und Medizinartikel u.v.m. benötigt.

Zudem sind die Cateringabläufe am Boden geprägt durch ständige Änderun-gen des Cateringbedarfs bis zur letzten Minute, wodurch die ordentlichen Pro-zessabläufe nur durch ein Reaktions- und Chaosmanagement gesteuert werden können.

1 airliners.de (2010): IATA: Schwarz, schwärzer, 2009 - Luftverkehr leidet unter Wirtschaftskrise, online verfügbar unter: http://www.airliners.de/verkehr/verkehrszahlen/iata-schwarz-schwaerzer-2009/20216

Einführung

15


Abbildung 1: Gesammelte Trolleys an der Rampe eines Caterers

1.2 Radiofrequenz-Identifikation (RFID)

Radiofrequenz-Identifikation (kurz: RFID) ist ein aktuelles Thema für eine Viel-zahl von geschäftlichen Anwendungsmöglichkeiten. RFID ermöglicht es, Objek-te per Funkübertragung kontaktlos zu identifizieren und zusätzliche Informati-onen über das Objekt z.B. seinen Transportweg) zu lesen und zu speichern. Der Einsatz von RFID stellt Unternehmen einerseits vor Herausforderungen, bringt andererseits aber viele innovative Chancen. Die Radiofrequenz-Identifkation ist keine neue Technologie, sie ist bereits seit einigen Jahren in zahlreichen An-wendungen des Alltags bereits im Einsatz. Dazu zählen Zugangskontrollen, u.a. über elektronische Mitarbeiterausweise in Form von Transponderkarten im Scheckkartenformat oder die Wegfahrsperre im Auto. Heute ist neu, dass RFID in diversen Anwendungsfeldern zur nachhaltigen Optimierung von Prozessen, die innerhalb und zwischen Unternehmen stattfinden, eingesetzt wird. Neben vielen weiteren Bereichen betrifft dies u.a. die Logistik, das Bestandsmanage-ment und die Produktionssteuerung.

Ein RFID-System in der einfachsten Form besteht aus drei Elementen (siehe Abbildung 2): Dazu zählen der Transponder, der auch als »Tag« bezeichnet wird, das Lesegerät, auch »Reader« genannt, sowie die Software im Hinter-grund (auch: »Backend-System«), die im einfachsten Fall eine Produktdaten-bank zur Führung einer Warenwirtschaft ist. In vielen Bereichen wird für die Güter- oder Objektidentifikation der Barcode eingesetzt. Jedoch stößt diese Technologie an Grenzen im Hinblick auf Lesereichweiten, Massenerfassung oder Unempfindlichkeit. Hier bietet RFID klare Vorteile und neue Anwen-

Einführung

16


dungsmöglichkeiten. Dennoch wird der Barcode sicherlich in einer Reihe von Anwendungsgebieten seine Existenzberechtigung behalten.

Abbildung 2: RFID-System

Die Kommunikation zwischen Transponder und Lesegerät erfolgt draht- und berührungslos per Funkübertragung. Ein direkter Sichtkontakt wie etwa beim Barcode ist nicht erforderlich. Abhängig von der Art des Transponders, können Lesereichweiten von wenigen Zentimetern bis zu etwa 100 Metern erzielt wer-den.

Über den Barcode können Daten lediglich ausgelesen werden. Bei RFID gilt dies nur für so genannte »Read-only«-Transponder. Daneben gibt es Transponder, die einfach oder mehrfach beschrieben werden können. Mehrfach beschreibba-re Transponder sind teurer als einfach beschreibbare Tags, bieten aber mehr Einsatzmöglichkeiten. Darüber hinaus ermöglichen manche Tags die Speiche-rung von größeren Datenmengen.

RFID-Transponder sind im Vergleich zum Barcode nicht anfällig gegenüber äu-ßeren Einflüssen wie Verschmutzung oder Nässe. Hingegen ist eine mögliche Abschirmung durch Metalle oder Flüssigkeiten zu berücksichtigen. Die Trans-ponder eignen sich deshalb auch für den Einsatz in widrigen Umgebungen. RFID kann so beispielsweise für die Identifikation von Fahrzeugkarosserien in der Lackierung eingesetzt werden.

1.3 Projektziele

Es exisitierten eine Reihe von wissenschaftlichen und technischen Herausforde-rungen in der Realisierung des Projektes iC-RFID. Das Ziel, die Entwicklung eines integrierten Airline-Catering-Gesamtsystems, wurde in verschiedene Unter-punkte aufgeteilt:

Entwicklung von innovativen Catering-Konzepten und Komponenten wie neue Kabinenservices und Dienstleistungen bei der Flugbuchung

Einführung

17


Konzepte zur Schaffung von Transparenz und Verfolgbarkeit des Wa-renflusses von Materialien und Gütern der Caterer und Airlines sowie Leistungskennzahlen.

Standardisierung relevanter Elemente zum Aufbau intelligenter, ver-netzter Cateringsysteme

Weiterentwicklung einer universellen RFID-Middleware zu einer Bran-chenlösung für die speziellen Anforderungen von Prozessen im Luftver-kehr

Herstellung eines bistabilen Displays zur Visualisierung der auf dem RFID-Tag gespeicherten Information

Entwicklung eines Simulationssystems auf Multiagentenbasis zur Er-schließung der wirtschaftlichen Effekte intelligenter RFID gestützter Ca-tering Supply-Chains

Die Ergebnisse werden in den folgenden Kapiteln im Einzelnen detailliert vorge-stellt.

18


2 Forschungsergebnisse

Die Forschungsarbeiten orientierten sich an den für das Projekt gesetzten Zie-len. Ergebnisse waren die folgenden:

Integrierter Cateringprozess

Preflight Shopping

RFID-basierter Trolleyumlauf

IT-gestützte Kommissionierung

Innovativer Kabinenservice

Systemintegration und Prozessüberwachung

Intelligentes Planungs- und Steuerungssystem

In den folgenden Abschnitten werden die erzielten Ergebnisse entsprechend dieser Einteilung im Detail beleuchtet.

2.1 Integrierter Cateringprozess

Einer der wichtigsten Forschungspunkte des Projekts war die Darstellung eines integrierten logistischen Cateringumlaufes mithilfe aktueller Technologien. In diesem Kapitel wird dieser Umlauf erläutert und dargestellt. Anhand des Mo-dells wurde ein Demonstrator entwickelt, der zur realistischen Darstellung aller Funktionen beim Flugzeugbauer Airbus in Hamburg aufgebaut wurde. Mithilfe dieses Demonstrators konnte die Echtzeittauglichkeit der erarbeiteten Konzepte nachgewiesen werden.

Ergebnis Prozessmodell (Fraunhofer IAO)

Der Gesamtprozess eines integrierten Luftfahrtcatering, der im Projekt erarbei-tet und in der standardisierten Business Process Modeling Notation (BPMN) modelliert wurde, gliedert sich in 10 grundlegende Subprozesse (siehe Abbildung 3). Die gesamte Darstellung in der BPMN kann im Anhang nachge-schlagen werden.

Die einzelnen Subprozesse werden im Folgenden näher beleuchtet.

Forschungsergebnisse

19


Abbildung 3: Pro-zessmodell des integrierten Luft-fahrtcatering

Initialisierung (Versendung von Plandaten)

Bei diesem Prozessschritt werden die Ausgangsdaten des iC-RFID Logistikpro-zesses geliefert und die Prozesskette gestartet, wobei es sich bei den relevanten Daten um den Flugplan, den Sitzplan des Flugzeugs und die eingegangenen Passagierbuchungen handelt. Dabei wird der Flugplan von der »Airline Operati-on« generiert, was im Projekt durch das Multiagentensystem (MAS) realisiert wird (siehe Abschnitt 2.7), und über die Middleware an den Caterer gesendet. Die Kommunikation erfolgt mit Hilfe des Flugplan-Dokuments (Flight Schedule) des openPlatform XML-Formates (siehe Abschnitt 2.6), welches vom MAS er-zeugt und vom Caterer ausgelesen wird.

Preflight Commerce (Bestellung von Waren und Dienstleistungen vor dem Flug)

Dem Passagier wird die Möglichkeit angeboten, bereits während der Flugbu-chung mittels des dafür entwickelten Online-Shops (siehe Abschnitt 2.2) zusätz-liche Waren und Dienstleistungen zu bestellen, die gezielt für ein bestimmtes Flugsegment (Teilflug bei einer Hin- und Rückreise eventuell mit Umsteigen) ausgerichtet sind. Hierbei kann es sich um spezielle Speisen, Getränke, aber auch Entertainment-Angebote wie Filme, Musik oder Spiele handeln. Dabei ist im Preflight-Shop eine Funktion integriert, die eine Warnung visualisiert, sobald


20


die Länge der bestellten Filme die Flugzeit übersteigt. Diese Waren und Dienst-leistungen bekommt der Passagier direkt an seinen Sitzplatz geliefert, entweder zum Direktverzehr oder in das Entertainment-System an seinem Sitzplatz. Dar-über hinaus hat der Passagier auch die Möglichkeit, Waren und Dienstleistun-gen für seinen Zielort zu bestellen. Dies können Hotelreservierungen sein, Ein-trittskarten für Events, Mietwägen aber auch Güter wie z.B. Sportausrüstungen. Die Bereitstellung der Waren und Dienstleistungen erfolgt über spezielle Aus-gabeschalter (Service Point) am Zielflughafen bzw. in Form von elektronischen Gutscheinen, die am Zielort einlösbar sind.

Eine Shop-Bestellung des Passagiers wird über die Middleware zur Airline wei-tergeleitet. Je nachdem, ob sich die Bestellung direkt auf den Cateringauftrag auswirkt (z.B. durch zusätzlich zu ladende Güter) wird sie auch an den Caterer gesendet. Falls die Bestellung für den Service Point am Zielflughafen relevant ist, wird sie auch hierhin geleitet. Ansonsten hat der Preflight-Shop automatisch ein elektronisches Ticket ausgegeben und es muss nichts mehr durchgeführt werden.

Für die Bestellung wird als Kommunikationsdokument die openPlatform PreFlight-Order genutzt, die den Online-Shop im Anschluss an eine Bestellung verlässt und als elektronisches Dokument an die genannten Folgesysteme ge-sendet wird.

Aktualisierung Ladeplan

Sobald eine Bestellung den Caterer erreicht, wird diese zusätzlich in seine Bela-deplanung für den entsprechenden Flug aufgenommen. Bestellungen können auch später noch beim Erfassen der Nachlieferungsaufträge in die Flugzeugtrol-leys aufgenommen werden. Dies wäre allerdings der letztmögliche Zeitpunkt, da eine noch spätere Nachlieferung der Cateringgüter nicht mehr möglich ist. Für die Bestellung von zusätzlichen Gütern für den Flug muss demnach eine zeitliche Grenze von wenigen Stunden vor dem Abflug eingehalten werden. Die daraus entstandene finale Beladeplanung ist in der Bestückungsliste (As-sembly List) geführt, die Kommunikation erfolgt über das gleichnamige openPlatform-Dokument.

Kommissionierung (Zusammenstellung aller Waren beim Caterer)

Mit der Bestückungsliste kann der Caterer in den folgenden Schritten die Kommissionierung der Flugzeugtrolleys durchführen (siehe Abschnitt 2.4). Da-bei werden die Cateringbehälter mit den auf der Bestückungsliste ausgewiese-nen Gütern beladen und die RFID-Tags entsprechend beschrieben (siehe Ab-schnitt 2.3). Neben den Flugzeugtrolleys sind auch hochwertige Güter (z.B. Du-ty-Free-Artikel) sowie spezielle Speisen, welche an Bord im RFID-gesteuerten Ofen zubereitet werden (siehe Abschnitt 2.5), mit RFID-Tags ausgestattet. Das Digital Flight Label (DFL), welches an den Flugzeugtrolleys angebracht ist und


21


Daten über den Flug und die geladenen Waren visualisiert (siehe Abschnitt 2.3), wird ebenfalls im Zuge der Kommissionierung mit Daten beschrieben.

Als Abschnluss der Kommissionierung wird eine elektronische Ladeliste (Freight List) erstellt, welche die tatsächlich geladenen Waren enthält. Im Idealfall ent-spricht diese der Bestückungsliste, doch aufgrund von fehlenden Waren oder Versäumnissen kann es hier zu Differenzen kommen, wobei dieser Fall mög-lichst vermieden werden sollte. Auch »geplante« Änderungen durch zusätzliche Online-Bestellungen von Passagieren können zu einer Abweichung dieser bei-den Listen führen. Im iC-RFID-Logistikprozess gibt es Funktionalitäten, die bei der Identifizierung von Bestandsunterschieden und Fehlmengen unterstützen und dadurch Verspätungen oder gar unzureichendes Catering vermeiden kön-nen. Dies wird in den nächsten Prozessschritten verdeutlicht.

Bodenassistent

Der Bodenassistent wird durch das MAS im Logistikprozess gesteuert. Hier er-folgt der Abgleich der Ladeliste mit der ursprünglich beauftragten Bestückungs-liste. Desweiteren wird geprüft, ob eine zusätzliche Bestellung online einge-gangen ist. Ein Nachlieferungsauftrag wird erstellt, falls sich herausstellt, dass dieser notwendig ist. Nach der anschließenden Ausführung der Nachlieferung wird eine neue Ladeliste erzeugt. Falls notwendig, werden nun die Schritte des Bodenassistenten wiederholt, d.h. beginnend bei der Prüfung, ob die zu korri-gierenden Waren auch tatsächlich verladen wurden. Um Verspätungen beim Catering zu vermeiden, werden die Prüfungen durch den Bodenassistenten ab einer kurzen Zeitspanne vor dem Flug beendet und der Vorfeldtransport veran-lasst.

Vorfeldtransport

Nachdem die Ladeliste die Kontrolle durch den Bodenassistenten passiert hat, erfolgt der Transport auf dem Vorfeld. Der Transportauftrag wird durch den Caterer ausgelöst und die Kommunikation wird mit Hilfe des openPlatform-Formats mit dem Dokument Transfer Order durchgeführt. Der Highloader fährt zur Rampe und wird dort mit den Trolleys beladen, wobei vor dem Transport eine Verladekontrolle erfolgt. Beim Verlassen des Lagers und vor dem Einladen in den Highloader passieren die Trolleys jeweils ein RFID-Gate und werden da-durch ausgelesen. So wird transparent, wann die Trolleys das Lager verlassen haben und wann sie dem Highloader zum Transport bereit standen sowie ob die Beladungen korrekt waren. Der Highloader transportiert die Trolleys im An-schluss über das Vorfeld zum Zielflugzeug.

Informationsbereitstellung im Flugzeug

Die Ladeliste wird zusammen mit den Daten der Online-Bestellungen der Pas-sagiere in den on-Board-Server des Flugzeugs übertragen. Die Crew kann sich nun darüber informieren, welche Güter geladen werden sollen und welche


22


speziellen Bestellungen durch Passagiere im Online-Shop von zu Hause getätigt wurden.

Beladung der Flugzeug-Galley

Bei der Beladung des Flugzeugs kommen die RFID-Tags in den Trolleys und die in die Flugzeug-Galley eingebauten Antennen zur Geltung. Beim Hereinfahren in den Einschub (Compartment) liest die eingebaute Antenne den am Trolley montierten RFID-Tag aus. Dieser beinhaltet die Daten der Waren, die im Trolley enthalten sind. Hochwertige Produkte (High-Value-Items) sind zusätzlich ge-taggt. Im Gegensatz zu den anderen »normalen« Gütern kann bei ihnen jeder-zeit festgestellt werden, ob sie wirklich in dem Trolley sind, ohne dass dieser geöffnet werden muss (Konzept des i-Trolley zur Selbsterkennung der Trolley-inhalte, siehe Abschnitt 2.3).

Nachdem der RFID-Tag am Trolley ausgelesen wurde, erfolgt ein Abgleich der tatsächlichen mit der erwarteten Beladung durch die Soll-Ladeliste, die im vor-herigen Schritt auf den on-Board-Server übertragen wurde. Falls an dieser Stelle Fehlmengen festgestellt werden sollten, werden diese von dem Flugzeug an die Airline gemeldet. Zusätzlich informiert eine zentrale Anzeige im Küchenbereich über sämtliche Lagerinhalte und -orte und gegebenenfalls über vorhandene Fehlmengen.

Eine weitere Besonderheit des Prozesses sind die getaggten Essenseinschübe (Trays) der Trolleys, die komplett in den mit RFID ausgestatteten Ofen einge-schoben werden können. Die Funktionsweise des Ofens wird im Prozessschritt »Novel Cabin Service« und in Abschnitt 2.5 erläutert.

Inflight Commerce (Bestellung von Waren und Dienstleistungen wäh-rend des Fluges)

Auch während der Flugreise hat der Passagier die Möglichkeit, zusätzliche Dienste und Produkte zu bestellen. Dies können spezielle Speisen oder Enter-tainment-Angebote für den Flug sein oder (wie auch schon beim Preflight Commerce) spezifische Wünsche für den Zielort. Ein Inflight Shop zeigt die ge-samte Produktpalette an dem Sitz des Passagiers an. Eine Bestellung wird am Bildschirm in der Küche visualisiert, so dass gleich zu sehen ist, von welchem Sitzplatz diese getätigt wurde. Die Stewardess kann – falls es der Zeitplan zu-lässt – sofort mit der Bearbeitung des Wunsches beginnen (z.B. Essenszuberei-tung, Freischaltung eines Films oder Ausdrucken eines Coupons). Falls das ge-rade nicht möglich ist, kann sie ihn in ihre Aufgabenliste aufnehmen und bear-beiten, sobald sie Zeit hat. Auf jeden Fall muss dafür gesorgt sein, dass der Pas-sagier seinen Wunsch zeitnah erhält, damit aus dem Zusatzangebot nicht Kun-denunzufriedenheit entsteht.


23


Novel Cabin Service (neuartige Dienstleistungen während des Fluges)

Eine besondere Art der Essenszubereitung wird durch den RFID-gesteuerten In-duktionsofen angeboten. Der Ofen kann über innen befindliche Antennen In-formationen auslesen, die auf RFID-Tags gespeichert und auf den Essensein-schüben (Trays) angebracht sind. Dort sind die Kochrezepte des Menüs enthal-ten, und ein einfaches Betätigen des Start-Knopfes genügt, damit die Zuberei-tung beginnt. Dabei weiß der Ofen durch die Informationen auf dem RFID-Tag, wie warm das Essen zubereitet werden muss und wie lange die Zubereitung insgesamt dauert. Die im Induktionsofen zubereiteten Speisen zeichnen sich besonders durch die frische Zubereitung aus, welche sie wesentlich schmack-hafter und damit zu einer echten Alternative zu den normal angebotenen Ge-richten machen, die nur aufgewärmt werden.

Rückführung der Trolleys und Maintenance

Nach der Landung des Flugzeugs, werden die Trolleys vom Caterer in sein Equipmentlager zurückgeführt. Dabei wird am RFID-Gate automatisiert geprüft, ob ein Trolley gewartet bzw. repariert werden muss. Dies ist möglich, weil auf dem RFID-Tag des Trolleys ein Maintenance-Flag gesetzt werden kann, falls ei-ne Wartung oder Reparatur erforderlich ist. Anschließend kann dieses Flag wie-der entfernt werden, so dass dieser Trolley wieder einsatzbereit ist.

2.2 Preflight Shopping

Durch das Konzept Preflight Commerce hat das Fraunhofer IAO eine neuartige eigen-entwickelte Komponente in das iC-RFID-Logistikkonzept eingebracht und die Integration innovativer Dienste ermöglicht. Im Folgenden wird zunächst das Konzept Preflight Commerce und anschließend die dazu entwickelte Kompo-nente PreFlight-Shop vorgestellt.

Das Konzept basiert in erster Linie darauf Waren und Dienstleistungen bereits bei der Flugbuchung anzubieten und an den Passagier zu verkaufen. Dabei soll der Passagier insbesondere durch das vielfältige Angebot und die verschiede-nen Auslieferungsmöglichkeiten zum Kauf geführt werden.

Folgende Szenarien sind allesamt darauf angelegt, einen zusätzlichen Gewinn neben der Buchung eines Fluges zu erzeugen. Dieser muss nicht zwingend aus den gegenwärtig angebotenen Flugdienstleistungen heraus entstehen (wie z.B. Essensbestellungen für den Flug), sondern kann sich auch aufgrund des Zielor-tes oder einem völlig spontan entstehendem Bedürfnis heraus entwickeln. Demzufolge haben Einsatzszenarien für dieses Konzept eine Struktur, wie in Tabelle 1 dargestellt. Inhaltlich behandelt dieses Dokument fünf ausgewählte Beispielszenarien, die nicht Anspruch auf Vollständigkeit der Einsatzmöglichkei-ten dieses Konzeptes erheben.


24


Bei dem »Pre-order for flight« handelt es sich um die Bestellung von Waren oder Dienstleistungen, die während des Fluges genutzt werden. Dabei handelt es sich vorzugsweise um die Bestellung eines oder mehrerer Essen oder digitaler Dienste, wie z.B. ein Kinofilm, Musik oder Videopsiel.

»Pre-order for destination« bedeutet, dass ein Passagier bereits während der Flugbuchung Waren oder Dienstleistungen für den Zielort bestellt. Beispielswei-se wären folgende Szenarien denkbar: Der Passagier weiß während der Flugbu-chung noch nicht in welchem Hotel er übernachten wird und hat außerdem In-teresse an Informationen zu Events (Kultur, Konzerte, Sport), die in seinem Rei-seziel angeboten werden. Er kann die Hotel- und Eventbuchung sofort von zu Hause vornehmen. Außerdem will er Freizeitzubehör zur Miete bestellen, dass er sich direkt am Flughafen abholen kann.

Tabelle 1: Vorabbestellungsmög-lichkeiten

Szenario / Zuordnung

Bestellung be-zogen auf den Flug (Pre-order for flight)

Bestellung be-zogen auf das Flugziel (Pre-order for destination)

Bestellung be-zogen auf die Angebotsdar-stellung (Pre-order for further usage)

Essensbestel-lung ●

Eventbestel-lung ● ●

Hotel- u. Transfer ●

Digitale Dienste ● ●

(Zielbestimm-te) Waren ● ●

Das Konzept kann unabhängig von der Flugbuchung, auch in Hinsicht der Vermarktung oder Erzielen von Werbeeffekten genutzt werden. In den bisher vorgestellten Szenarien werden den Fluggästen Angebote vorgeführt, die den Flug oder den Aufenthalt am Zielort attraktiver machen sollen. Abgesehen da-von besteht die Möglichkeit, dass der Passagier gewisse Angebote auch außer-halb der Flugbuchung interessant findet bzw. auf der Website vom Hersteller weitere Angebote nachschlagen will. Das trifft insbesondere bei der Buchung von speziellen Events, digitalen Diensten und weiteren Waren zu.


25


Ergebnis Preflight Shop (Fraunhofer IAO)

Zur Darstellung des Konzepts Preflight Commerce wurde vom IAO eigens eine Komponente – der Preflight-Shop – entwickelt. Dieser soll prototypisch aufzei-gen wie die im letzten Abschnitt erwähnten Möglichkeiten der Bestellung wäh-rend der Flugbuchung umgesetzt werden können. Das im Shop bereitgestellte Serviceangebot umfasst sowohl Waren als auch Dienstleistungen. Da die Flug-buchung heutzutage häufiger über das Internet erfolgt, ist eine Weiterleitung des Passagiers vom Buchungssystem der Airline zur E-Commerce Platform vor-gesehen, so dass eine Preflight Bestellung im Anschluss an die Buchung des Flugtickets erfolgen kann. Eine erfolgreiche Preflight Bestellung durch den Pas-sagier wird von dem Preflight-Shop mit Hilfe des openPlatform-Formates an das ERP-System des Caterers gesandt, wo sie bearbeitet werden kann. Dies ge-schieht über einen Messaging Bus, welcher per Java Messaging Service (JMS) kommuniziert. Abbildung 4 zeigt die Gesamtarchitektur der Anwendung.

Abbildung 4: Archi-tektur des Preflight-Shops

Messaging Bus (JMS)

XML

BuchungssystemAirline

(angedeutet)

Preflight-ShopCaterer

ERPCaterer

Passagier Internet

XML

Folgende Waren und Dienstleistungen werden dem Benutzer angeboten:

Auswahl von Wunschessen für den Flug

Elektronische Unterhaltung im Flug

Tickets für Events am Zielort

Waren für den Zielort

Hotels im Zielort

Tranferleistungen im Zielort

Die Oberfläche des Preflight-Shops ist angelehnt an die Oberflächen von gängi-gen Flugbuchungssystemen. Nachdem alle wichtigen Flugdaten eingegeben und die entsprechenden Flüge ausgesucht wurden, gelangt der Passagier zu ei-


26


ner Flugübersicht, auf der er für ein Flugsegment den Shop starten kann und für dieses Segment eine Bestellung aufgeben kann. Nach der Sitzplatzauswahl kann der Passagier nun beliebige Waren oder Dienstleistungen aus dem Menü auswählen. Sollte er Filme auswählen wird angezeigt falls ein (oder mehrere) Filme die Flugdauer überschreiten. Abbildung 5 zeigt die Shop-Oberfläche bei diesem Schritt. Im weiteren Verlauf gibt der Passagier seine Zahlungsdaten ein und bestätigt alles.

Abbildung 5: Ober-fläche des Preflight-Shops

2.3 RFID-basierter Trolleyumlauf

Die Kontrolle von Equipment und insbesondere Trolleys war ein elementarer Bestandteil des Projekts. In den Ergebnissen, die in den folgenden Abschnitten dargestellt werden, liegt der Fokus auf der Verfolgbarkeit von Trolleys und der Anzeige von wichtigen oder teuren Inhalten Für diese Zwecke werden Trolleys und diese entsprechenden Inhalte mit RFID-Tags versehen und an wichtigen Punkten im Prozess ausgelesen. Einer dieser Punkte ist die Flugzeugtür. Beim Beladen des Flugzeugs wird der Inhalt der Trolleys gelesen und mit der Ladeliste auf dem Flugzeug-Server verglichen. Eine speziell entwickelte Richtungserken-nung zeigt den Unterschied zwischen einer Be- und Entladung. Eine völlige Neuentwicklung stellt das bistabile Display dar, das anstatt eines Papier-Flight Labels nun alle Informationen und Inhalte zu dem Trolley elektronisch darstellt.

Ergebnis i-Trolley (B&W Engineering GmbH & Co. KG)

Der i-Trolley ist ein mit RFID-Technik ausgestatteter Trolley herkömmlicher Bau-art. Er erfasst seinen Inhalt, mit RFID-Label gekennzeichnete Waren, selbststän-dig, zeigt diesen an und kann die Informationen an übergeordnete Systeme


27


weiterleiten. Der Einsatz erfolgt entlang der gesamten Catering-Prozesskette, d.h. vom Caterer bis in das Flugzeug.

Abbildung 6: i-Trolley in Dockingstation

Abbildung 7: Bildschirmanzeige des i-Trolley wäh-rend des Erken-nungsvorgangs

Integrierte Komponenten:

- RFID-Reader und Antennen

- Controller mit angeschlossenem Touchscreen-Display

- Akku für mehrstündigen netzunabhängigen Betrieb


28


- Dockingstation beim Caterer und eingebaut in der Flugzeuggalley zur drahtlosen Energie- und Datenübertragung

Ergebnis Gelabelter Trolley (B&W Engineering GmbH & Co. KG)

In Anlehnung und Ergänzung des von der IATA erarbeiteten Standards zur Kennzeichnung von Trolleys wird in iC-RFID ein erweitertes Konzept zur Kenn-zeichnung von Catering-Equipment im Allgemeinen mittels UHF RFID-Tags vor-gestellt.

Für den Technik-Demonstrator wird dazu beispielhaft an Trolleys je ein Tag oben im vorderen Bereich und an dessen Unterseite mittig platziert.

Der obere Tag kann automatisiert beim Durchfahren durch ein RFID-Gate und manuell per Handscanner ausgelesen und beschrieben werden. Er enthält unter Anderem eine weltweit eindeutige Identifizierungsnummer (ID) und Trolley-Inhaltsinformationen, die im Cateringverlauf eine wichtige Unterstützung dar-stellen.

Der untere Tag kann durch ein RFID-Rampen-Gate ausgelesen werden und enthält im Wesentlichen Informationen für das Maintenance- und Einsatzma-nagement, beispielsweise die Anzahl der Flugstunden seit der letzten Wartung.

Abbildung 8: Tag zur Kennzeichnung eines Trolleys

Ergebnis Digital Flight Label (Fraunhofer PYCO)

Die Zielsetzung der FhE PYCO bestand in der Entwicklung eines passiven Digital Flight Label (DFL) als Kombination eines bistabilen Flüssigkristall-Displays mit ei-nem RFID-Tag. Dies soll die zusätzliche Visualisierung der auf dem RFID-Tag ge-speicherten Informationen ermöglichen, ohne dass diese mit einem Reader ausgelesen werden müssen. Zur Verbesserung der Catering Supply Chain sollen Catering Transport Behälter (CTB) mit dem DFL ausgerüstet werden, um die in der Logistik der CTB relevanten Informationen wie den Flug-Code, die Stauposi-tion in der Galley oder Inhaltsinformationen anzuzeigen. Im Ergebnis sollen sich gegenwärtige Einweg-Lösungen auf der Basis von Papierlabeln ersetzen lassen, wobei die Kosten sowie die Zeit gespart werden, die beim Erstellen, beim Wechsel und bei der Entsorgung der Label anfallen. Unabhängig von der spe-


29


ziellen Anwendung des Caterings in der Luftfahrt ist eine Übertragung in Berei-che mit ähnlichen Problemstellungen (z.B. Einzelhandel, Logistik, Catering bei der Bahn oder in Krankenhäusern) leicht möglich.

Als bistabile Anzeige wurden cholesterische Flüssigkristalldisplays ausgewählt, die sich durch ein hohes Kontrastverhältnis über einen weiten Blickwinkelbe-reich auszeichnen. Ferner weisen sie eine geringe Abhängigkeit ihrer Eigen-schaften von den Schwankungen der Umweltparameter (Temperatur, relative Feuchte) auf, wie sie in der Einsatzumgebung (Caterer, Flugzeug) typischerwei-se auftreten. Eine weiterführende Darstellung flüssigkristalliner bistabiler Dis-plays findet sich in den Reviews von Wu und Yang (2001)2 bzw. Lueder (2001)3.

Die Arbeiten der FhE PYCO umfassten folglich im ersten Schritt die Synthese chiraler Dotanden und die Auswahl geeigneter nematischer Flüssigkristallmi-schungen, um zu displaytauglichen cholesterischen Flüssigkristallmischungen zu gelangen. Insbesondere wurden Flüssigkristall-Mischungen mit einer hohen die-lektrischen Anisotropie präpariert und untersucht, da sich diese durch ver-gleichsweise geringe elektrische Schaltfelder auszeichnen.

Weiterhin wurden zwei Formate an Display-Zellen realisiert. Für Testmessungen und die Entwicklung der Ansteuerung wurden in Eigenbau Zellen mit Abmes-sungen von 22,5x50 mm und mit einem 3-Zeilen-Layout (je 8x86 Pixel) herge-stellt. Damit konnte zur CeBit 2009 ein erster Demonstrator der Ansteuerung aufgebaut werden (s. Abbildung 9).

Für das eigentliche DFL konnten Zellen des Display-Herstellers AEG MIS mit 160x160 Pixeln auf einer aktiven Fläche von 120x120 mm eingesetzt werden (s. Abbildung 9). Die Verbindung zwischen Display-Zelle und Platine der Ansteue-rung erfolgt mittels eines heat-seal-Kabels. Für die größeren Displays wurde un-tersucht, ob auf üblicherweise verwendete Orientierungsschichten aus Polyimid (PI) verzichtet werden kann. Diese induzieren einen besseren Kontrast, führen aber auch zu einer beträchtlichen Erhöhung der Schaltspannung. Im Ergebnis überwiegt der Vorteil des besseren Kontrastes den Nachteil der höheren An-steuerspannung.

2 Wu, S.-T., Yang, D.-K. (2001): Reflective Liquid Crystal Displays, Wiley-SID Series in Display Technology, Chichester

3 Lueder, E. (2001): Liquid Crystal Displays Adressing Schemes and Electro-Optical Effects, Wiley-SID Series in Display Technol-ogy, Chichester


30


Abbildung 9: De-monstrator der Ansteuerung des Displays mit dem 3-Zeilen-Layout für die CeBit 2009

Im Hinblick auf die Entwicklung der Ansteuerung der Displays wurden zunächst mittels eines Messystems zur Display-Charakterisierung (DMS 505 von Autronic Melchers) die elektro-optischen Kennlinien bestimmt (s. Abbildung 10). Für die Ansteuerung der Displays wurde in Zusammenarbeit mit der alpha-board GmbH, Berlin, das sog. conventional driving scheme implementiert. Dazu wird für die Ansteuerung eines Pixels die Spannung gewählt, die der Mitte der rech-ten ansteigenden Flanke in Abbildung 11 entspricht. Zum Schreiben des Pixels wird dieser Spannung eine zweite Spannung ± überlagert, wobei das Vorzei-chen bestimmt, ob der Pixel auf »OFF« (schwarz) oder »ON« (grün) gesetzt wird. Während des Beschreibens einer Zeile wird an die benachbarten Zeilen eine Gegenspannung angelegt, um ein Übersprechen zu vermeiden.

Abbildung 10: Dis-play-Zelle mit 160x160 Pixelmatrix während der Be-stimmung der elekt-rooptischen Kennli-nien mittels des DMS 505


31


Abbildung 11: Ex-emplarische elektro-optische Kennlinie für ein Display ohne PI-Orientierungsschicht. Die für die Ansteue-rung zu wählende Spannung beträgt 24 V, die Auswahlspan-nung beträgt ±4 V

Das Konzept für die Verwendung des bistabilen Displays als DFL ist in Abbildung 12 gezeigt. Wesentliche Elemente neben dem Display mit der zuvor erläuterten Ansteuerung sind der HF-RFID-Tag (IDS-SL13 von IDS microchip) mit einem serial peripheral interface (SPI) sowie eine Kapazität als Energiespeicher. Letzterer wird über das HF-Feld per induktiver Kopplung geladen und soll das einmalige Beschreiben des Displays ermöglichen. Als Reader kommt das Ident-Control-System IC-KP-R2-V1 von Pepperl & Fuchs mit dem Schreib/Lese-Kopf IQH1-18GM-V1 (18 mm Durchmesser) zum Einsatz. Der Micro-Controller dient schließlich der Übersetzung der eingehenden Daten in die darzustellenden Zei-chen sowie der Ansteuerung des Displays.

Abbildung 12: Prin-zip des Digital Flight Labels (DFL)

line

driver

display

columndriver

micro-controller;character set;

decodingmemory

temporaryenergy storage

RFID-tag

Der prinzipielle Ersatz von Papierlabeln auf Trolleys durch das von PYCO entwi-ckelte Digital Flight Label ist in Abbildung 13 gezeigt. Die für die Beschriftung des Labels relevanten Daten werden der über die Middleware an die Caterer verteilten Ladeliste entnommen. Die Daten für das DFL werden über die serielle Schnittstelle an den Reader (s. Abbildung 13, rechts oben) und anschließend über die Luftschnittstelle an die hinter dem Display sitzende Antenne des DFL übertragen. Auf diesem Kanal erfolgt auch die Energieübertragung für das DFL. Diese funktioniert prinzipiell, allerdings sind die Zeiten, die für die Energieüber-tragung erforderlich sind, mit über einer Stunde für praktische Anwendungen noch zu lang. Der Grund hierfür ist der zu hohe Energieverbrauch der Schal-


32


tung zur Implementierung des conventional driving scheme. Für den De-monstrator des Projektes erfolgt die Energieversorgung daher konventionell über Batterien.

Ein Vorteil des DFL gegenüber der Verwendung von Papierlabeln besteht darin, dass während des Umlaufs des Trolleys mittels eines Readers Veränderungen am Label-Inhalt vorgenommen werden können. Dies ist z.B. dann von Interesse, wenn sich unvorhergesehene Änderungen im Umlauf des Trolleys ergeben.

Abbildung 13: Prin-zip des Digital Flight Labels (DFL): links ein heute typischerweise zur Identifizierung von Trolleys verwen-detes Papierlabel, rechts das von PYCO entwickelte DFL

Ergebnis RFID-Galley (B&W Engineering GmbH & Co. KG)

Die Bordküche des Flugzeugs ist mit RFID-Antennen ausgestattet und verfügt über Schnittstellen zum übergeordneten Datensystem. Diese Technik ermög-licht die automatische Identifikation der eingelagerten Trolleys.

Abbildung 14: Ein-bau von RFID-Antennen in Galley-Compartments


33


Das Crew-HMI (Human Maschine Interface), eine Art von interaktivem Display, unterstützt die Crew bei den Servicevorgängen: Mit diesem System kann nach bestimmten Waren gesucht, der Maintenance-Status von Trolleys ausgelesen und neu beschrieben werden und es werden Informationen zum Inhalt der Trolleys in den einzelnen Compartments (Fächern der Galley) dargestellt.

Ergebnis RFID-Gates im Flugzeug mit Richtungserkennung (EADS Innovation Works)

Heutzutage wird der Beladungsstatus für Cateringgüter eines Flugzeuges durch manuelle Kontrolle durchgeführt, d.h. durch Abzählen der mit Papierzetteln versehenen CTBs als auch durch zusätzliches Öffnen und der Kontrolle des In-halts der CTBs. Zukünftig könnte die Erfassung des Beladungsstatus eines Flug-zeuges, durch das automatische Registrieren von mit RFID Tags gekennzeichne-ten CTBs beim Passieren einer Flugzeugtür erfolgen.

Die technische Herausforderung liegt hierbei, dass Flugzeuge beladen als auch entladen werden und dass beide Vorgänge zeitlich als auch örtlich nicht ein-deutig voneinander zu separieren sind.

Es ist deshalb erforderlich, dass das an der Flugzeugtür zum Einsatz kommende RFID System die Funktionalität zur Erkennung der Bewegungsrichtung eines RFID Tags hat. D.h. das RFID System muss eindeutig erkennen, ob ein CTB ins Flugzeug geladen oder wieder vom Flugzeug entladen wird. Zur Richtungser-kennung wird ein sogenanntes RFID Gate dann meist mit zusätzlicher Sensorik wie z.B. Lichtschranken ausgestattet. Typisch sind z.B. zwei Lichtschranken in Durchfahrrichtung hintereinander folgend installiert, so kann aufgrund der Rei-henfolge derer Aktivierung die Bewegungsrichtung eines CTBs erkannt werden. Ein solches RFID System mit zusätzlicher Sensorik hat bzgl. der Applikation an der Flugzeugtür jedoch prinzipiell mehrere Nachteile. Wesentlich ist hier, dass eine zusätzliche Sensorik nicht unerheblichen zusätzlichen Installationsaufwand, Wartungsaufwand, Gewicht, etc. mit sich bringt und das komplexere Gesamt-system störanfälliger und unzuverlässiger wird. Die Betrachtung der rein funkti-onalen Installation einer doppelten Lichtschranke an einer Flugzeugtür lässt schnell erkennen, dass der notwendige Raum zur Installation nicht wirklich vor-handen ist um eine zuverlässig funktionierende Doppellichtschranke zu betrei-ben (z.B. ist der Abstand beider Lichtschranken zueinander zu gering). Dies hät-te z.B. zur Folge, dass beim Durchgang mehrer CTBs nicht eindeutig festgestellt werden kann, welche Bewegungsrichtung die einzelnen CTBs hatten. Weiter kann nicht eindeutig unterschieden werden ob die Lichtschranken von CTBs oder nicht von Personen oder anderen Gegenständen aktiviert wurden, d.h. die Richtungserkennung kann sehr stark fehlerbehaftet sein. Da eine solche RFID Installation für ein Flugzeug als zu aufwändig und zu unzuverlässig erscheint, wurde ein komplett anderer Lösungsansatz verfolgt.

Die EADS hat ein RFID Gate mit Identifikation und Richtungserkennung konzi-piert, welches als minimale Installation einen RFID Reader mit zwei Antennen


34


benötigt. Optional kann das RFID System zur Steigerung der Zuverlässigkeit mit weiteren Antennen ergänzt werden. Der Installationsaufwand des RFID Systems beschränkt sich dabei auf ein Minimum, so dass sich Gewicht, Wartungsauf-wand, etc. als auch die damit verbundene Störanfälligkeit des Gesamtsystems minimieren und sich im Gegenzug die Zuverlässigkeit des Gesamtsystems auf-grund der geringeren Komplexität erhöht.

Abbildung 15: RFID-Gates mit mehreren Antennen zur Rich-tungserkennung (Laboraufbau)

Der funktionale Unterschied zu konventionellen RFID Gates liegt hierbei in der Art der Erkennung der Bewegungsrichtung der RFID Tags, welche über eine Bewertung der von den Reader Antennen empfangenen RF Signale erfolgt, welche von den RFID Tags rückgestreut wurden. Hierbei werden die Signale beider Antennen zum nahezu gleichen Zeitpunkt betrachtet. Bewegt sich ein CTB an den beiden Antennen vorbei, so wird dieser während seiner Bewegung von beiden Antennen mehrfach nacheinander erfasst. Die Antennensignale weisen dabei abhängig von der Entfernung zur jeweiligen Antenne eine unter-schiedliche Signalstärke auf, welche sich während der Bewegung vorbei an den Antennen stetig verändert. Basierend auf dieser Tatsache und der entsprechen-den Antennensignale kann nun eindeutig für jeden CTB seine individuelle Be-wegungsrichtung errechnet werden. Die gleichzeitige und separate Auswer-tung mehrerer CTBs ist jederzeit möglich, da jedes einzelne Antennensignal eindeutig zu einem bestimmten RFID Tag und somit eindeutig zu einem be-stimmten CTB zuordenbar ist.

Letztendlich ist von jeden CTB bekannt, ob er ins Flugzeug geladen bzw. wie-der von diesem entladen wurde. Ein Vergleich dieser RFID Information mit den Ladelisten für das Flugzeug erlaubt den Rückschluss, ob die Beladung entspre-chend der Planung verläuft oder Abweichungen durch eine Fehlbeladung vor-


35


liegen. Die Information zum Beladungsstatus ist dabei nicht nur innerhalb eines Flugzeugs von Interesse, sondern vielmehr noch im Zusammenhang mit z.B. den logistischen Prozessen zur Flugzeugabfertigung am Flughafen.

Ergebnis Erfassung des Aufenthaltsorts von CTBs im Flugzeug (EADS Innovation Works)

Für einen reibungslosen Cateringbetrieb während des Fluges ist es auch nütz-lich zu wissen, wo genau sich welche CTBs mit welchem Inhalt befinden. Heut-zutage werden die mit Papierzetteln beschrifteten CTBs in die Stellplätze im Flugzeug verstaut und bei Bedarf von der Crew gesucht. Bei mehreren Galleys und einigen zig Trolleys wird die Suche nach bestimmten Dingen jedoch schnell zum Glücksspiel. Deshalb ist es ebenso hilfreich zu wissen, in welchem Bereich (z.B. in welcher Galley) des Flugzeugs sich welcher CTB befindet.

Eine funktionale Erweiterung der im Kapitel zuvor beschriebenen Auswertung der RFID Antennensignale – und wie zuvor, mit einer minimalen Installation von einen RFID Reader mit zwei Antennen – erlaubt u.a. auch die Überwachung ei-nes bestimmten Bereiches, wie z.B. der vor Galley oder anderen Staubereichen von CTBs, um festzustellen, welche CTBs sich in diesem Bereich befinden. Wei-ter kann wiederum festgestellt werden, aus welcher Richtung ein CTB in den überwachten Bereich eingetreten ist bzw. in welche Richtung ein CTB diesen Bereich verlassen hat. Die technische Auswertung der Antennensignale erfolgt grundsätzlich wie im Kapitel zuvor bereits erläutert.

Durch die Verknüpfung aller verfügbarer Informationen von der Detektion der CTBs an der Flugzeugtür als auch in den verschiedenen Bereichen lässt sich mit minimalem Installationsaufwand an RFID Technik und entsprechender Software Funktionalität ein Bewegungsprofil für die CTBs erstellen, so dass jederzeit eine relativ genaue Position eines CTBs im Flugzeug festgestellt und der Crew mitge-teilt werden kann.

Ergebnis RFID-Gates und Rampen-Gates (B&W Engineering GmbH & Co. KG)

Die Rampe (verfügt über Antennen für den unteren Tag eines Trolleys) bzw. das Gate (für den oberen Tag) dient zur automatischen Identifikation von Trolleys und anderen Catering-Transport-Behältern.

- Ein optionales LC-Display am Gate zeigt trolleyspezifische und, sofern vor-handen, auftragsbezogene Informationen an

- Am »Rampen-Gate« werden die Maintenance-Informationen (Wartungsin-formationen) auf dem unteren Tag ausgelesen und beschrieben

- An den RFID-Gates (z.B. an den Ein- und Ausgängen zum Zwischenlager nach der Kommissionierung) wird die ID des Trolleys ausgelesen


36


Abbildung 16: Gate mit Display im Tech-nikdemonstrator

Ergebnis Handhelds (B&W Engineering GmbH & Co. KG)

Mobile Erfassungsgeräte werden zur Unterstützung der Service-Prozesse so-wohl beim Caterer, beim Transport als auch an Bord für die Service-Crew ein-gesetzt.

Der Benutzer (Supervisor) erhält durch Scannen eines Trolleys detaillierte Infor-mationen zum Inhalt und Wartungsstatus. Zusätzlich kann er den Maintenance-Status aktualisieren und die vorliegenden Aufträge verwalten.

Abbildung 17: Handheld beim Auslesen des Trolley-Tags


37


2.4 IT-gestützte Kommissionierung

Durch die IT-gestützte Kommissionierung ist es möglich Cateringaufträge ziel-genau und mit Unterstützung elektronischer Hilfsmittel abzuarbeiten. Dabei werden insbesondere die Vorteile der mit RFID-Tags versehenen Waren und Trolleys sichtbar.

Ergebnis Caterer Service Desk (B&W Engineering GmbH & Co. KG)

Das Catering Service Desk ist ein Arbeitsplatzsystem für die Assemblier- und Kommissionierstationen beim Caterer zur rechnergestützten Kommissionierung der Cateringgüter:

- Ausführliche Anleitungen für die Kommissioniervorgänge

- Mit Tags versehene Waren werden gescannt und in registrierte Trolleys ein-gelagert

- Einzelne Produkte werden auf das Stück genau erfasst

- Ein »Infoscreen« zeigt alle Trolleys an, die sich beim Caterer im Umlauf be-finden. Es werden die wichtigsten Daten zu den einzelnen Trolleys (inkl. des i-Trolleys) angezeigt

- Einsatzmanagement: Daten über jeden Trolley werden in zentraler (Airline-) Datenbank gespeichert – die volle Kontrolle über Inhalt und Aufenthaltsort des Trolleys ist somit möglich.

Abbildung 18: Cate-rer Service Desk, i-Trolley und Rampen-Gate im Technikde-monhstrator

Ergebnis Catering Assembling Station (MGS – Modular Galley Systems AG)

Ziel des Arbeitspunktes war es dem User die Handhabung von Catering-Artikeln zu veranschaulichen. Ferner wird auch ein Eindruck vermittelt, welche


38


technische Vorrichtungen notwendig sind um einen RFID gestützten Arbeits-, Informations und Güterfluss zu generieren.

Die Assembling Station beinhaltet folgende Kernfeatures:

Software zur intuitiven Bedienung der Schreib-Lese Sensoren sowie zur Un-terstützung des Arbeitsflusses über Visualierung.

Anbindung an die Middleware, Integration in den Güter- und Informations-fluss des Gesamtsystems

Entgegennahme der Assembling Orders die durch das MAS System gene-riert wurden

Entgegennahme der Daten über eine TCP/IP Verbindung und Beschreiben des von PYCO entwickelten bistabilen Displays über eine HF- RFID Schnitt-stelle

Abbildung 19: Cate-rer Service Desk, i-Trolley und Rampen-Gate im Technikde-monhstrator

2.5 Innovativer Kabinenservice

Um Flugpassagieren einen größeren Komfort während des Fluges zu bieten und damit eine erhöhte Kundenbindung und schließlich auch höhere Umsätze zu erreichen, sind die Möglichkeiten für einen verbesserten Kabinenservice zu überdenken. Dies erstreckt sich über das gesamte Waren- und Dienstleistungs-angebot und beinhaltet nicht zuletzt eine individuellere Behandlung der einzel-nen Fluggäste


39


Ergebnis Neue Kabinenservicekonzepte (EADS Innovation Works)

Für die Neugestaltung des Kabinenservices lassen sich verschiedene Gestal-tungsbereiche identifizieren (Abbildung 20):

Abbildung 20: Ges-taltungsbereich und -felder von Service-konzepten

On-Board Servicekonzept

Geltungsbereiche

Gestaltungsfelder

Service Technik Organisation

Angebot

Inhalt

Verrechnungs-modell

Lagerung Ablauf

AufbauUmschlag

Transport

Regeneration

Informations-transfer

Der Kabinenservice umfasst alle durch den Passagier wahrgenommenen Dienst-leistungselemente (z.B. Mahlzeiten und Erfrischungen) Eine Unterteilung kann erfolgen in:

– Serviceangebote (Anzahl der Angebote)

– Serviceinhalte (Auswahlmöglichkeiten, Flexibilität)

– Verrechnungsmodell (kostenfrei, d.h. im Flugpreis enthalten, kostenpflichti-ges Zusatzangebot)

Der Gestaltungsbereich Technik beschreibt alle für die Abwicklung des Services benötigten Geräte und Hilfsmittel. Eine Unterteilung kann erfolgen in:

– Technik zur Lagerung (Standard Units, Trolleys, Container etc.)

– Technik zum Umschlag (Lift etc.)

– Technik für den Transport (Trolleys etc.)

– Technik für die Regenerierung (Konvektionsöfen, Induktionsöfen)


40


– Technik für den Informationsaustausch (RFID, Datenschnittstelle)

Die für die Durchführung der Dienstleistung erforderlichen Ablauf- und Res-sourcenstrukturen werden durch den Gestaltungsbereich Organisation be-schrieben. Eine Gliederung kann erfolgen in:

– Aufbau (Zuordnung der Galleys zu den Klassen, Personal zu den Bereichen)

– Ablauf (Anordnung der Dienstleistungselemente zueinander)

Abbildung 21: iC-RFID Konzept: Übersicht

Grundsätzlich lassen sich über diese Gestaltungsbereiche und ihre Merkmale Servicekonzepte beschreiben und systematisieren. Insbesondere durch die Ein-führung neuer Technologien ergeben sich für die Bereiche Service und Organi-sation neue Gestaltungsmöglichkeiten. Innerhalb des iC-RFID-Projekts sind die Gestaltungsmöglichkeiten, die sich aus der Einführung von RFID und Vernet-zung der Inflight Service Stakeholder ergeben (siehe Abbildung 21), näher zu untersuchen.

In diesem Zusammenhang ist z.B. das Servicekonzept »Inflight Commerce« entwickelt worden. Das Konzept basiert auf der Übertragung von e-Commerce-Ansätze des Handels auf die Anwendung im Flugbetrieb. Der Passagier kann bei diesem Konzept über eine Schnittstelle aus einem Dienstleistungs- und Wa-


41


renangebot wählen und seine Angebotsannahme digital abgeben. Die Kabi-nenbesatzung erhält die Bestellungen zentralisiert und aufbereitet. Die Aufbe-reitung der Daten erfolgt dabei so, dass die Bestellungen möglichst effizient abgearbeitet werden können. Über eine Schnittstelle ist es zudem möglich Be-stellungen aus dem Flugzeug an eine Bodenstation zu übertragen, über die dann die Auslieferung am Zielflughafen oder an eine Wunschadresse über Ser-vicepartner organisiert werden kann. Abbildung 22 zeigt das Servicekonzept Inflight Commerce.

Abbildung 22: Servi-cekonzept Inflight Commerce

Passagier

Warenangebot

Menü + Getränke

Auslieferung Flugzeug / Boden

Dienstleistungen

Reservierungen- Hotels + Transfer- Mietwagen- Zielort Events

Digitale Angebote- Wunschfilme- Reiseinformation

Duty Free- Erweitertes Angebot

„Katalogware“- Zielbestimmte Waren

Ergebnis Simulation von Kabinenservice (EADS Innovation Works)

Im IC-RFID-Projekt wird Simulation für die Validierung neuer Kabinenservice-prozesse eingesetzt. Dabei werden folgende Teilziele verfolgt:

– Visualisierung des Serviceablaufs über die gesamte Servicezeit

– Analyse und Bewertung der verschiedenen Konzeptvarianten

– Ableitung von Systemparametern und Systemdesign (z.B. Ressourcenbe-darf, Controller/Algorithmen)

Für die Modellierung und Simulation von Serviceprozessen im Flugzeug ist am Markt bislang kein Simulationsprogramm verfügbar. EADS IW hat daher ver-schiedene Prozesssimulationsprogramme auf ihre Eignung untersucht. Für die


42


Vorauswahl wurde der Simulationsfall nach Scholtissek (1996, S.11ff.)4 klassifi-ziert. Demnach ist der vorliegende Simulationsfall

– stochastisch, da kein deterministisches Modell vorliegt, da viele Eingangs-größen stochastisch vorliegen. (z.B. Servicebedarfe, Servicezeiten).

– diskret, da ein kontinuierliches Modell – bei vernachlässigbaren Zusatznut-zen – zu aufwändig wäre.

– dynamisch, da sich die Zustände zeitabhängig verändern.

– ereignisgesteuert, da zeitgesteuert eine unnötig hohe Rechenleistung er-fordert.

Abbildung 23 zeigt die Klassifikation der iC-RFID Simulation nach Scholtissek.

Abbildung 23: Klassi-fikation des Simulati-onsmodells (in An-lehnung an Scholtis-sek (1996)

Simulationsmodel

stochastisch

statisch

deterministisch

dynamisch

diskret kontinuierlich

ereignisgesteuertzeitgesteuert

Aus der Vielzahl am Markt befindlicher Simulationssoftwarelösungen wählte EADS IW SIMUL8 der SIMUL8 Corporation aus, da es stochastische, dynami-sche, diskrete und ereignisgesteuerte Simulation erlaubt, eine sehr geeignete 2D-Visualisierungsmöglichkeit besitzt und zudem durch die implementierten Programmiermöglichkeiten sehr gut dazu geeignet ist die Besonderheiten, die bei der Simulation von Kabinenprozessen auftreten, abzubilden. Insbesondere die Abbildung des Passagierverhaltens als Auslöser wesentlicher Teilprozesse, wie zum Beispiel von Getränke- oder Speiseservices, kann durch konventionelle Prozesssimulationsmodelle nur schwer nachgebildet werden.

4 Scholtissek, P. (1996): Simulationsprüfstand für Logistikkonzepte der Produktion, VDI Verlag, Düsseldorf.


43


Das Vorgehen bei der Durchführung der Simulationen ist an VDI 3633 (2000) (siehe Abbildung 24) angelehnt.

Abbildung 24: Ab-lauf einer Simulation (in Anlehnung an VDI 3633 (2000))

Situationsanalyse Zielformulierung

Versuchsplanung

DatenbeschaffungModellierung

Simulationsläufe Modifikation

Analyse

[ja]

[nein]

Implementierung

Vorbereitung

Validierung

Durchführung

Ausw

ertung

Ereignisse befriedigend?

Die wesentlichen Schritte bei dieser Vorgehensweise sind

– Versuchsplanung,

– Datenbeschaffung und Modellierung,

– Simulationsläufe und

– Analyse

Im Folgenden werden die Aktivitäten innerhalb dieser Schritte näher beschrie-ben.

Versuchsplanung

Bei der Versuchsplanung wird das experimentelle Vorgehen im Voraus so weit wie möglich festgelegt. Ziel ist es dabei die Anzahl der notwendigen Simulati-onsläufe zu reduzieren, indem unnötige Parameterkonstellationen im Vorfeld ausgeschlossen werden.


44


Zudem wurde festgelegt, dass die Evaluierung neuer Konzepte immer in Relati-on mit heutigen vergleichbaren Servicekonzepten, sogenannten Referenzmo-dellen, erfolgt. Dadurch lassen sich die Auswirkungen neuer Konzepte auf die Evaluierungskennzahlen (wie z.B. Servicegrad oder Ressourcenbelastung) relativ zu den Referenzen darstellen, wodurch eine bessere Anschaulichkeit und Nach-vollziehbarkeit der Simulationsergebnisse erzielt wird. Darüber hinaus verringert diese Methode den Einfluss etwaiger systematischer Fehler in den Modellen.

Für die Referenzmodelle kann EADS IW auf abgeschlossene Forschungsarbeiten zurückgreifen und sowohl auf Servicemodelle der sogenannten »Billigflieger« (»Low Cost Carrier«, LCC) als auch auf solcher traditioneller Fluggesellschaften mit umfangreichen Bordservice (»Full Service Carrier«, FSC) zurückgreifen. Abbildung 25 zeigt ein vereinfachtes Servicemodell eines LCCs als Gantt-Chart Modell.

Abbildung 25: In-flight Service Stimu-lus Modell, Beispiel Low Cost Carrier, 2 h Flug

Mission: S hor t r a nge ( 2 hour s) , da y f l i ght

Aircraf t : A320

Service model: Low Cost c a r r i e r Pre-f light act ivit y

Class: - Flight act ivit y (cabin)

Seat s: 145 Post -f light act ivit y

1 11:10 11:10 00:00 Crew onboard Crew onboard

2 11:10 11:25 00:15 Cat er ing Check Cat er ing Check

3 11:25 11:45 00:20 Boarding Boarding

4 11:45 11:55 00:10 Cabin Clear Cabin Clear

5 11:55 12:00 00:05 Taxi Taxi

6 12:00 12:00 00:00 St art St art

7 12:00 12:12 00:12 0:00 Climb Climb

8 12:20 12:45 00:25 0:20 Beverage service Beverage service

9 12:50 13:25 00:35 0:50 Service on demand Service on demand

10 13:30 13:40 00:10 1:30 Cabin/ galley prep f or landing landing

11 13:40 14:00 00:20 1:40 St art landing St art landing

12 14:00 14:00 00:00 2:00 Landing Landing

13 14:00 14:05 00:05 2:00 Taxi / a/ c on block Taxi / a/ c on block

14 14:05 14:18 00:13 2:05 Deboarding Deboarding

Af t e r

t a k e -I D P ha se / se r v i c e e l e meFr om

[ h]

P ha se / se r v i c e - 1 1 2 3

To De l t a

Datenbeschaffung und Modellierung

Grundgedanke der Modellierung ist die Abbildung der Servicekonzepte als Ver-kettung ihrer Teilprozesse. Teilprozesse stellen im Modell die kleinste abzubil-dende Einzelaktivität dar. Kern der Modellierung eines konkreten Servicekon-zeptes ist somit die Identifikation, Beschreibung und Verkettung seiner Teilpro-zesse (Einzelaktivitäten). Die Beschreibung der Teilprozesse beinhaltet dabei die Festlegung der Dauer des Teilprozesses, der notwendigen Ressourcen und der Bedingungen für den Start.

Ein Beispiel für die Verkettung von Einzelprozessen zu einem Gesamtprozess zeigt Abbildung 26.


45


Abbildung 26: Pro-zessablauf Service-wunsch über »Sitz-knopf«

Bestellwunsch Rufen eines Flugbegleiters

Kommissionierung für Transport Transport zum Pax Servieren Nachbereitung

Auftragseingang Flugbegleiter Start Flugbegleiter

Rückkehr Galley, Vorbereitung Bestellung

Ankunft Sitz,Wunschabfrage

Die konkrete Modellierung der Systemmodelle erfolgte direkt in der Simulati-onssoftware SIMUL8. Dabei wurde im Wesentlichen auf die folgenden SIMUL8 Grundelemente zurückgegriffen: Eingang (1), Entität (2), Warteschlange (3), Arbeitsstation (4), Ausgang (5) und Ressource (6). Abbildung 27 zeigt die Grundelemente der SIMUL8 GUI.

Abbildung 27: SI-MUL8 GUI: Grund-elemente

Für die Modellierung von Kabinenprozessen sind die Systemelemente Passagie-re, Kabinenpersonal, Transportbehälter, Küchenausstattung, Serviceelemente und Kabinenlayout notwendig. Nachfolgend werden diese Elemente den SI-MUL8 Grundelemente zugeordnet.

– Eingang (1)

o Servicewunsch vom Passagier

o Start Serviceprogramm

– Entitäten (2)

o Serviceelemente z.B. Getränke, Menü

– Warteschlange/Puffer (3)

o Passagier, Puffer für Entitäten

– Arbeitsstation (4)


46


o Öfen und Kaffeemaschinen

– Ressourcen (6)

o Kabinenpersonal

o Transportbehälter, Trolleys, Boxen,…

Die eigentliche Prozessabfolge und –logik der Servicekonzepte ist durch die Verknüpfungen der Prozesselemente untereinander und durch zusätzlichen Programmiercode innerhalb der Elemente abgebildet.

Simulationsläufe

In diesem Schritt erfolgt die Abarbeitung des Versuchsplans. Dabei sind die Pa-rameter gemäß dem Versuchsplan solange zu variieren, bis eine zufriedenstel-lende Annäherung an die Zielwerte erreicht ist.

Abbildung 28 zeigt den Modellaufbau und die Durchführung eines Simulations-laufs für einen Economy-Kabinenbereich eines Langstreckenflugzeuges in SI-MUL8.

Abbildung 28: iC-RFID-Simulationsmo-dell in SIMUL8


47


Analyse

Innerhalb der Analyse werden die generierten Ergebnisse gemäß den festgeleg-ten Zielen bewertet. Neben dem Erreichen des Servicegrades beim Passagier spielen hier Kennzahlen wie Robustheit bei Systemausfällen und erträgliche Crewbelastung eine wichtige Rolle.

Eine aussagefähige Größe, um den Servicegrad beim Passagier zu beurteilen, ist die Wartezeit auf eine Bestellung. Bei Individualbestellungen ist diese eindeutig zu ermitteln. Es ist die Zeitspanne von der Angebotsannahme bis zur Ausliefe-rung am Platz. Bei der programmbezogenen Auslieferung ist es der Zeitraum zwischen dem Zeitpunkt der planmäßigen Auslieferung des Referenzmodells und der tatsächlichen Auslieferung.

Aus den vorliegenden Analyseergebnissen soll hier exemplarisch ein Ergebnis zum Servicekonzept »Service on Demand« vorgestellt werden, d.h. der Service-ablauf erfolgt nicht starr sondern erfolgt frei nach Passagierwunsch bzw. einge-schränkt frei,

Mithilfe der Simulation konnte festgestellt werden, dass eine völlige Flexibilität zu einer für die Kabinenbesatzung unbeherrschbaren Arbeitssituation führt. Auch die Zugabe weiterer Kabinenbesatzung hilft bei diesem Szenario nur be-dingt, da die Servicewünsche zu unvorhersehbar auflaufen und Bestellungen dadurch nicht effizient abgearbeitet werden können.

Wird bei diesem Szenario die Flexibilität eingeschränkt, indem zugunsten vorde-finierter Auslieferungszeitfenster auf eine vollständige zeitliche Wahlfreiheit verzichtet wird, bleibt der Prozess für die Kabinenbesatzung beherrschbar. Gleichzeitig steigt der Servicegrad für die Passagiere gegenüber dem Konzept mit starren Zeiten, da immer noch eine Wahlmöglichkeit zwischen den Zeitfens-tern besteht.

Ergebnis Inflight Control Unit (MGS – Modular Galley Systems AG)

Die Inflight Control Unit dient im Flugzeug als Schnittstelle zwischen den Bord-küchengeräten und den übergeordneten Systemen. Da sie auch sicherheitsrele-vante Aufgaben übernehmen soll, müssen die Hard- und Softwarearchitektur sowie die verwendeten Kommunikationsprotokolle aktuell gültigen Luftfahrt-standards entsprechen.

Speziell die Verwendung des ARINC 812 Standards zur Kommunikation zwi-schen den Galley Inserts und ein strikt modularer Aufbau der Software stellt ei-ne spätere Verwendbarkeit der erarbeiteten Lösungen in zukünftigen MGS-Produkten sicher. Der ARINC 812 Standard wurde und wird von Boeing und Airbus gemeinsam mit Anbietern wie MGS entwickelt und derzeit im Rahmen des A350 Programms erstmals für eine reales Luftfahrtprogramm implemen-tiert.


48


Folgende Funktionen des ARINC 812 Standards wurden in der Inflight Control Unit implementiert:

Network Monitoring

Beim »Network Monitoring« wird durch das Senden vordefinierter »Lifepulses« der Status der Geräte ständig überprüft. Die Lifepulses sind damit die Grundla-ge aller weiteren Features wie Power Management, Content Management oder später auch BITE [zentralisierte Fehlerdiagnose von elektrischen Geräten im Flugzeug], da damit die im Netzwerk vorhandenen Geräte identifiziert und die korrekte Funktion verifiziert werden können.

Content Management (enhanced for RFID features)

Beim »Content Management« definiert der ARINC Standard ein Format, wel-ches zur Übermittlung von Mealcodes (Speisen-Codes) dienen soll. Aufgrund der Arbeiten im Rahmen des Projekts wird MGS neue Eingaben für Erweiterung des ARINC-Standards beantragen, um die Features eines RFID gestützten Cate-ring im Flugzeug nutzbar zu machen.

Power Management

Dieses wichtige Feature ermöglicht ein »Power Management« innerhalb der Bordküche. Mit Hilfe des Power Managements wird eine größere Flexibilität bei der Auslegung der Bordküchen als größten elektrischen Verbrauchern im Flug-zeug erzielt, da damit Überinstallation von Leistung innerhalb einer sogenann-ten Flexzone ermöglicht wird. Als Flexzone wird im Flugzeug der Bereich be-zeichnet, in den Kunden (Airlines) ihre gewünschten Bordküchen installieren können. Möchte der Kunde heute beispielsweise in eine Flexzone, welche für 15kVA ausgelegt ist, Geräte mit einer max. elektrischen Gesamtleistung von 15.1kVA installieren, zieht dies sofort ein aufwändiges Redesign des elektri-schen Systems im Flugzeug nach sich, obwohl in der Regel nur ca. 20…40% der Leitungskapazitäten gleichzeitig genutzt werden. Intelligente ARINC 812 kompatible Inserts (MFU, Heißluftöfen, Kaffeemaschinen, …) hingegen können überinstalliert werden, da durch das integrierte Power Management eine Über-beanspruchung des elektrischen Systems ausgeschlossen werden kann.

Remote Control

ARINC 812 bietet auch Befehlssätze für »Remote Control«, d.h. Fernsteuerung von Bordküchengeräten über ein zentrales in der Bordküche installiertes Panel. In diesem Projekt wurde erstmals ein Remote Control auf Sub-GAIN Level ge-mäß ARINC 812 erprobt. Das heißt es wurde nicht nur ein komplettes Gerät bedient sondern auch Untereinheiten des Geräts sogenannte »Cluster« (reprä-sentiert durch die Heizebenen des Induktionsofens) erfolgreich gesteuert.


49


Der ARINC Standard und die damit gegebene Möglichkeit zur Vernetzung von Geräten innerhalb der Kabine ist Grundlage für eine RFID System mit zentraler Datenhaltung im Flugzeug.

Die von MGS umgesetzte dezentrale Speicherung der Daten direkt auf den Tags überbrückt auch schon heute die Unterbrechung der Datenkette an der Flugzeugtür. Damit wurde ein System entwickelt, welches schon heute unab-hängig vom Flugzeugprogram eine geschlossene Datenkette ermöglicht und die Voraussetzung für zukünftige auch redundante Systeme [zentrale & dezen-trale Datenhaltung] bietet.

Im Rahmen des Arbeitspunktes wurde ein Demonstrator für eine Inflight Control Unit (siehe Abbildung 29) mit Network Monitoring, Content Manage-ment, Remote Control sowie einem einfachen Power Management implemen-tiert.

Abbildung 29: Inflight Control Unit

Neben der Verwendung des ARINC 812 Standards wurden folgende weitere Vorgaben umgesetzt, um eine Verifikation des Grundkonzepts sowie die Ver-wendbarkeit von Komponenten in anderen Projekten zu gewährleisten.

Verwendung einer Linux Plattform, um die spätere Portierung auf Avionik Plattformen (bspw. VxWorks) zu ermöglichen.

Umsetzung der Crew HMI Befehle zu ARINC 812 Standard und umgekehrt

Verwendung einer »Low Performance« Hardware, um eine spätere Portie-rung in eingebettete elektronische Systeme zu ermöglichen.

Ergebnis Multi-Functional Unit mit RFID-gesteuertem Ofen (MGS – Modular Gal-ley Systems AG)

Im Rahmen des Projekts wurden zwei MGS Multi-Functional Units modifiziert.

Eine Multi Functional Unit ist ein neuartiger Ofen, der über Induktion kontakt-los, d.h. ohne elektrische oder mechanische Schnittstelle, sogenannten »Slide in Modules« betreiben kann (siehe Abbildung 30).


50


Abbildung 30: Multi-Functional Unit mit RFID-gesteuertem Ofen

Slide in Modules sind Einschübe für den Ofen, die komplett verschiedene An-wendungen gleichzeitig innerhalb eines Geräts ermöglichen (siehe Abbildung 31):

(a) »Heating Box« zum Braten innerhalb eines Geräts

(b) »Toaster«

(c) »Top-Heater« zum Kochen und Überbacken von Speisen

Abbildung 31: Slide in Module (a), (b) und (c) v.l.n.r.

RFID kann speziell in Hinblick auf die Vielfalt der möglichen Inserts eine ent-scheidende Rolle bei der Beherrschung der Logistikkette spielen.

Dazu wurde das bereits angesprochene ARINC 812 Protokoll sowie die not-wendigen Controller und die Sensorik in das Gerät implementiert. Ein wichtiger Designtreiber war die Implementierung eines hochrobusten, leicht zu imple-mentierenden und zertifizierbaren Systems. Dazu wurden bezüglich der RFID-Sensoren ein Ansatz mit miniaturisierten HF-Sensoren und verteilter Intelligenz gewählt, wie in Abbildung 32 dargestellt:


51


Abbildung 32: RFID-Sensor

Die Hauptaufgabe bestand darin, die Software auf die für das Projekt notwen-digen Anforderungen zu modifizieren. Auch hier wurde bei der Implementie-rung besonderen Wert auf ein luftfahrtgerechtes Softwaredesign gelegt. Fol-gende neue Kernfeatures wurden integriert und verifiziert.

RFID gestützte Benutzerführung (Advanced User Guide): Über die Vorauswahl von Heizprogrammen sowie die Übermittlung von Klartext-nachrichten über die RFID-Labels wurde demonstriert, wie Informationen (Inhalt, Heizprogramm, Be-dienhinweise) von der Küche on Ground in die Bordküche in einfachster Art und Weise übermittelt werden können (siehe Abbildung 33). Aufgrund der de-zentralen Datenspeicherung auf den Labels ist dieser neue Service nicht auf an-dere Systeme angewiesen, kann aber durch diese unterstützt werden.

Abbildung 33: Ad-vanced User Guide

ARINC 812 basiertes und RFID gestütztes Content Management: Dieses Feature wurde über das Crew HMI umgesetzt. Der Ofen liest die RFID Tags aus und sendet über den ARINC 812 Standard Informationen über seinen Inhalt an die Inflight Control Unit. Diese bereitet die empfangen Codes auf sendet diese an


52


das Crew HMI. Hier können die Inhaltsinformationen über ein Touch Panel von der Crew abgerufen werden.

ARINC 812 basiertes Remote Control: Auch dieses Feature wurde mithilfe des Crew HMI implementiert. Auch hier basiert die Kommunikation zwischen Öfen und der Inflight Control Unit auf dem ARINC 812 Protokoll. Die Inflight Control Unit kommuniziert mit dem Crew HMI, welches die Fernbedienung der Geräte über einen großen komfortablen Touchscreen ermöglicht.

2.6 Systemintegration und Prozessüberwachung

Der Logistikprozess im Luftfahrtcatering ist geprägt durch eine Vielzahl an teil-nehmenden Rollen über Unternehmensgrenzen hinweg, wodurch es zwangs-läufig zu Medienbrüchen, Verzögerungen und Intransparenzen kommt. Um diese zu vermeiden, ist eine technische Integration der einzelnen IT-Systeme er-forderlich, insbesondere im Hinblick auf einen RFID-gestützte Prozess. Dies kann zum einen durch eine Middleware erreicht werden, welche die Leseereig-nisse der RFID-Gates und -Reader an die angeschlossenen Systeme weiterreicht und zudem die Kommunikation zwischen diesen Systemen ermöglicht. Zum anderen ist ein standardisiertes Austauschformat für die Nachrichten erforder-lich, welches von allen angebundenen Systemen verarbeitet werden kann. Ist eine Systemintegration erreicht, so kann der Prozess trotz mehrerer Teilnehmer auch wirksam überwacht werden.

Ergebnis Middleware (autoID systems GmbH)

Der Einsatz von Auto-ID-Technologien wird aktuell durch bereits vorhandene Infrastrukturen erschwert. Neue Technologien müssen in der Regel in vorhan-dene, meist heterogene, Systemstrukturen integriert werden.

Die Middleware der AIS ist die Grundlage für die erfolgreiche Integration von neuen Technologien in vorhandene Systeme. Der Grundgedanke dabei ist die vollständige Unabhängigkeit von diesen bereits bestehenden Systemen und ei-ne größtmögliche Variabilität von einzubindenden Auto-ID-Systemen und Gerä-ten. Dies bezieht sich sowohl auf RFID-Komponenten, als auch auf andere Sys-teme wie Barcode oder BDE.

Die Middleware stellt im Projekt iC-RFID die zentrale Datendrehscheibe zur Kommunikation aller Partner untereinander dar. Die Daten fließen hierbei durch ein Sonic Messaging System, dass ähnlich eines Postfaches durch sogenannte Queues die Nachrichten vorhält, bis diese abgeholt werden können.

Abbildung 34 zeigt die Management-Konsole der Middleware mit den einge-richteten Message Queues.


53


Abbildung 34: Ma-nagement-Konsole der Middleware

Um die Queues anzusprechen sind Middlewareadapter notwendig, die in die jeweiligen Systeme integriert werden müssen. Diese Adapter sind lizenzfrei ein-zusetzen und die Bibliotheken sind für .Net und C/C++ verfügbar.

Den Queues können unterschiedliche Dateninhalte geschickt werden, d.h. es können String, XML und Binärdaten verwendet werden. Da aber der Empfän-ger die Datenstruktur kennen muss, wurden die Formate der Daten bei den Übergängen zwischen den Mockupmodulen zuvor fest definiert (Transponder-Datenstruktur, Event- und XML-Struktur).

Die Queues sind die angelegten Datenleitungen, die nach vorgegebenen Re-geln die Daten, bzw. Events aus dem System erkennen und verteilen. Die flexib-le Struktur und Standardisierte Datenformate machen es möglich die im Daten-strom vorhandenen Informationen weiteren Partnern zur Verfügung zu stellen, die sonst nur nach mehreren Systembrüchen an ihre benötigten Daten gelan-gen. Selbst neue, vorher nicht eingeplante Teilnehmer des Arbeitsprozesses können mit minimalem Aufwand in den Informationsfluss integriert werden, indem ein-


54


fach die für den Partner notwendigen Informationskanäle »reserviert« werden. Alle Daten, die über diesen Kanal laufen sind nun für ihn verfügbar, sofern die-ser Partner die Berechtigungen besitzt die Daten zu empfangen.

Systemarchitektur

Da es sich bei einer MW um eine Integrationssoftware handelt, sind verschie-dene Komponenten aus diversen Bereichen zu berücksichtigen. Dabei kann es sich um eigene, aber auch um fremde Komponenten handeln, die eingebunden werden müssen.

Prinzipiell verbinden sich alle Komponenten mit dem Messaging Bus (G / Trans-portebene), der als zentrale Kommunikationsschnittstelle dient. Der Bus wird durch einen Messaging Server verwaltet, der sowohl Hardware- als auch Soft-warekomponente bereitstellt.

Der zweite Bereich der Middleware wird durch den Datenbank- und Applicati-onserver (H / Anwendungsebene) dargestellt. Hier findet die Verarbeitung der eingehenden Events und Dokumente statt.

Ein Anschluss von externen Systemen ist für verschiedene Lösungen möglich:

A: Anschluss von intelligenten Readern (interne Steuerung) direkt an den Bus.

B: Anschluss von SiteServern an den Bus, dadurch Verbindung zu beliebi-gen Readern

C: Bidirektionaler Anschluss von externen Systemen über dort lokal laufen-de Adapter

D: Unidirektionales pullen von Daten aus externen Datenquellen (Adapter in MW)

E: Unidirektionales pushen von Daten aus externen Quellen (Adapter bei Quelle)

F: SiteServer+ Eigenständiges Middlewaresystem für Partner, ermöglicht unabhängiges und voll integriertes Arbeiten im Zentralsystem

I: Dashboard als optionale Visualisierungskomponente der MW

J: MAS-Anbindung (unidirektional realisiert)

Abbildung 35 verdeutlicht die allgemeine Kommunikationsstruktur.


55


Abbildung 35: All-gemeine Kommuni-kationsstruktur

Der Anwendungsbereich der MW liegt in jeglicher Integrationsumgebung, die Datenströme verteilen, anpassen und bearbeiten muss.

Im Allgemeinen ist die MW aber branchenunabhängig und kann ebenso in den Bereichen Logistik, Produktion, Lagerhaltung, Automotive usw. eingesetzt wer-den.


56


Weiterführende Eigenschaften der Middleware sind die Wandlung und Bearbei-tung entsprechender Daten:

Wandlung

Die Wandlung ist die erste Erweiterungsstufe nach dem Transport. Falls die empfangenen Daten nicht der im System verwendeten Norm entsprechen, müssen die Daten in vorgegebene normierte Form gebracht werden (z.B. Open Trans für B2B Dokumente, Event-XML für Readerereignisse). Dies ist ins beson-ders bei der Anbindung von Fremdsystemen notwendig (z.B. SAP = iDoc) und bei RFID und GPS Geräten. Diese Hardwaregeräte haben meist je nach Herstel-ler unterschiedliche Ausgabeformate. Falls eine Wandlung nicht in den Hard-wareadaptern erfolgt oder erfolgen kann, muss eine Wandlung spätestens durch die Middleware erfolgen.

Bei der Weiterleitung an Fremdsysteme kann auch der umgekehrte Fall eintre-ten, dass eine intern mit Standardformaten transportierte Message in ein Fremdformat gewandelt werden muss, da dass Fremdsystem nicht mit dem Standardformat der Middleware klarkommt.

Die Wandlung umfasst auch Datenberechnungen, solange die Inhalte nicht ge-ändert werden. Dies betrifft insbesondere Zeit- und Positionsdaten, die von je-dem Gerät anders ausgegeben werden. Hierbei handelt es sich somit nicht um eine Bearbeitung der Daten, sondern nur um die Ausgabe in einem anderen Format.

Bearbeitung

Die Bearbeitung ist die zweite Erweiterungsstufe und setzt auf die Wandlung auf. Hier werden die Daten nicht nur im Format, sondern auch inhaltlich geän-dert. Dies wird ebenfalls über hinterlegte Regeln geleistet. Dies kann in Form von Kalkulationen, Datenänderung über Mappingtabellen oder Datenbankin-halte geschehen.

Die Bearbeitung ist sehr individuell und muss mit den benötigten Prozessen ab-gestimmt werden. Für den Applicationserver ist somit wie bei den Hardware-adaptern eine variable Pluginlösung vorzusehen, so dass auf geänderte Prozes-se neue Logikschritte eingefügt werden können.

Ergebnis eXtensible High Performance Controller Interface (autoID systems GmbH)

Der XHPCI ist eine Eigenentwicklung der autoID systems und verbindet Endge-räte mit nachgelagerten Informationssystemen. Die meisten RFID-Reader sind zwar in sich bereits intelligent, erfüllen jedoch nicht die Ansprüche eines Systemintegrators, der im Zweifelsfall mehrere ver-schiedene Systeme zueinander führen muss. Der XHPCI übernimmt zum einen


57


die Vorfilterung von Sensordaten, um die verfügbare Netzwerkbandbreite nicht zu belasten, und zum Anderen die direkte Steuerung mehrerer Endgeräte durch eine Frontend Applikation (siehe Abbildung 36).

Abbildung 36: Fron-tend Applikation des XHPCI

Zweck des XHPCI ist es zum einen Schnittstellen für RFID-Hardware auf mög-lichst breiter Basis zu nachgelagerten Systemen bereitzustellen, um RFID-Daten für Anwendungen nutzbar zu machen (Data-Mining), zum anderen um die RFID-Hardware direkt aus der Anwendungsapplikation heraus steuern und be-dienen zu können. Der XHPCI an sich ist ein Standardmodul, um Daten von verschiedenen Geräten standardisiert an die MW weiterzuleiten.

Mögliche Ansätze finden sich im Transportlogistikbereich im Konzept »Mobiles Lager«. In diesem Fall kann ein Transportfahrzeug, neben dem Transport an sich, auch als mobiles Lager fungieren, das mittels RFID-Unterstützung Echt-zeitauskunft über seinen Inhalt geben kann. Besteht eine Verbindung zu einer zentralen Planungsstelle können außerplanmäßige Bedarfe schnell und effizient durch Überschüsse aus dem mobilen Lager bedient werden ohne einen weite-ren, neuen Transport einleiten zu müssen. Die anfallenden RFID-Daten werden vom XHPCI gesammelt und per Middleware an die nachgelagerten Systeme verteilt. Die dort eingehenden Daten werden dann dazu verwendet auf die ver-änderte Situation zu reagieren und weitere Abläufe zu planen.

Ergebnis XML-Austauschformat openPlatform (Fraunhofer IAO)

Die bei zwischenbetrieblichen E-Commerce zwischen Unternehmen oder im weiteren Sinne auch zwischen autonomen Unternehmenseinheiten ausge-tauschten Daten werden als elektronischer Datenaustausch bzw. Electronic Da-ta Interchange (EDI) bezeichnet. EDI umfasst den uni- und bidirektionalen


58


Transfer von Geschäftsdaten, die nach standardisierten Formaten strukturiert sind und von Anwendungssystem zu Anwendungssystem mittels offener elekt-ronischer Kommunikationsverfahren zwischen Organisationen mit der Möglich-keit der bruchlosen Weiterverarbeitung ausgetauscht werden.

Das openPlatform-Konzept ist ein XML-Format, das Strukturen anbietet, die den Austausch von Daten zwischen allen im Prozess beteiligten Partnern er-möglichen. Aktuell beherrscht kaum eine Airline den integrierten Austausch von strukturierten digitalen Daten entlang der Wertschöpfungskette zwischen Passagier und Airline, über den Caterer bis hin zur Crew im Flugzeug da an den unterschiedlichen Flughäfen unterschiedliche Dienstleister für die Airlines arbei-ten. Gerade deswegen ist es unabdingbar ein System mit offenen und standar-disierten Schnittstellen anzubieten, um die unterschiedlichsten Dienstleister kos-tengünstig anzubinden.

Das XML-Schema des openPlatform-Konzepts besteht von der Wurzel aus fünf verschiedenen Listen bzw. Dokumenten, die allesamt Original-Dokumenten aus dem Airline-Bereich nachempfunden wurden. Im einzelnen sind das die folgen-den (siehe auch Abbildung 37):

Abbildung 37: Wur-zelelement des XML-Standards

iCRFID_OPENPLATFORM

FLIGHT_SCHEDULE

PREFLIGHT_ORDER

GROUND_DELIVERY

ASSEMBLY_FREIGHT_LIST_ADDITIONAL_ORDER

TRANSFER_ORDER

Flight Schedule (Flugplan): Der Flugplan mit den genauen Daten zu den Flügen. Der Caterer erhält Zugang zu dem Plan über den Flughafen.

Preflight-Order (Vorabbestellung): Die Vorabbestellung kann bei der Flugbu-chung genutzt werden, um zusätzliche Waren und Dienstleistungen für den Flug oder den Zielort zu bestellen. Sie wird vom Passagier von zu Hause aus dem Internet ausgelöst und erreicht den Caterer.

Assembly / Freight List + Additional Delivery (Bestückungs- / Ladeliste und Nachlieferungsauftrag): Diese Listen sind insbesondere für den Caterer wichtig,


59


da sie darstellen was in ein Flugzeug geladen werden soll, was tatsächlich gela-den wird und was nachträglich nachgeliefert wird.

Transfer Order (Transportauftrag): Dieses Dokument beschreibt die genauen Daten für den Transport der Trolleys von der Rampe des Caterers über das Flug-feld zum Flugzeug durch den Highloader.

Ground Delivery (Bodenauslieferung): Die Bodenauslieferung ist die Datenstruk-tur für die Pre- und Inflight-Bestellungen, die zur Abholung an einem Service-Point am Flughafen oder Direktlieferung an die vom Passagier angegebene Ad-resse vorgesehen ist.

Tabelle 2: Mögliche Szenarien der Ver-wendung des openPlatform Kon-zepts

Auftrag an Caterer

bisheriges Szenario der wöchentlichen Versendung von Flugplänen und täglichen Beauftragung des Caterers durch die Airline (per e-Mail)

manuelles Eingeben der Daten in Individualsoftware manuelles Zuordnen der Beladeversionen der Flugzeuge

zu Auftrag Verbesserungen durch einheitlichen Standard: Auftrag wird in Airline-System eingegeben und durch

Transaktionsstandard medienbruchfrei an Caterer-System überliefert

Zuordnung von Beladeversionen bereits im System

Ladeliste auf iC-RFID-Server

bisher wird Ladeliste manuell mit dem Trolley-Bestand abgeglichen

Verkaufszahlen werden per USB-Stick oder im Papier-format in den Trolley gelegt

Verbesserungen durch einheitlichen Standard: Ladeliste wird standardisiert auf iC-RFID-Server abgelegt Trolley erkennt Inhalt durch getaggte Items bei Einlagerung in Flugzeug automatischer Abgleich

durch Auslesen der Trolley-Inhalte und Vergleich mit Ladeliste

Korrekter Transport aller Trolleys

eindeutige Identifikation der Trolleys an der Rampe Transporteur erhält Informationen entsprechend der

transfer order auf seinem Handheld Kein Ablesen von Daten von Papierlisten, dadurch kön-

nen Verwechslungen ausgeschlossen werden


60


Tabelle 2 stellt verschiedene konkrete Einsatzszenarien für das openPlatform Konzept vor.

Die einzelnen Dokumente werden im Folgenden detaillierter vorgestellt.

Flight Schedule

Der FlightSchedule (Flugplan) enthält alle geplanten Flüge, Zeiten, Positionen und Statusangaben eines bestimmten Datums. Er dient als Basis für den Cate-rer und kann zur Grobplanung eingesetzt werden, da der Caterer bereits durch die Bekanntgabe des Flugzeugtyps die Beladung planen kann. Eine detailliertere Planung ist allerdings erst mit der Bestückungsliste möglich, da diese die exak-ten Soll-Beladungen für jeden einzelnen Flug darstellt. Abbildung 38 zeigt die komprimierte Hauptstruktur.

Nach dem Oberelement werden in der darauffolgenden Ebene die ID des Flug-plans sowie die Flugdaten eingetragen. Das Element Local Airport beinhaltet die genaue Bezeichnung des Flughafens sowie länderspezifische Informationen. Anschließend werden in dem Mehrfachelement Flight alle Flüge aufgelistet, die für den Flughafen eingeplant sind. Die Informationen zu diesen Flügen reichen von der Fugnummer, den genauen Abflug- und Landezeiten, das Gate usw. Der Status des Flugzeugs und des Gepäcks mit verschiedenen Auswahlfeldern sowie Bemerkungen und Informationen zum Flugzeug können optional einge-fügt werden. Das für diese Flugzeuginformationen vorgesehene Feld Aircraft erstreckt sich u.a über die Registrierungsnummer des Flugzeuges, den genauen Typ, den Besitzer, die Konfiguration der Sitze und die Anzahl der gebuchten Plätze in den Passagierkategorien.

Preflight-Order

Die Preflight-Order beschreibt die Bestellung eines Passagiers während der Flugbuchung. Dabei sind entsprechend dem Konzept Preflight Commerce un-terschiedlichste Bestellmöglichkeiten enthalten. Es wird angeboten Essens- oder Entertainmentangebote für die Flugdauer zu bestellen oder für den Zielort spe-zifische Waren oder Dienstleistungen wie Hotels, Taxi oder Sportausrüstungen.

Die XML-Struktur unterteilt sich insbesondere in die Passagier-Informationen (PAX_INFO), Informationen zum Flug (FLIGHT) und der Bestellung (ORDER). Eine komprimierte Übersicht ist in Abbildung 39 einzusehen. Eine PreFlight-Order wird vom Passagier zu Hause während der Flugbuchung durchgeführt und geht in die Bestückungsliste ein, kann aber auch u.U. als Nachbestellung (additional delivery) verzögert auf der Ladeliste erscheinen. Wie lange eine PreFlight-Order-Nachlieferung zulässig ist, hängt von der Flexibilität des Caterers ab. Grundsätz-lich darf sie auf keinen Fall zu Flugverspätungen führen. Es muss andererseits immer darauf geachtet werden, dass die Bestellungen des Kunden noch erfüllt werden können, um keine Kundenunzufriedenheit zu erzeugen.


61


Im Detail gliedert sich die PreFlight-Order in die folgenden Elemente auf:

Der Passagier gibt im Feld PAX_INFO Informationen zu seiner Person (Name, Anschrift). Im Feld DELIVERY wird eingetragen, wie seine Bestellung ausgelie-fert wird. Entweder direkt an seinem Sitzplatz (z.B. bei Essens- oder Entertain-mentbestellungen), als Coupon am Sitzplatz (z.B. bei Gutscheinen) oder zur Selbstabholung am Service Point (z.B. bei Sport-Equipment). Zum Service Point selber sind Detailinformationen wie Öffnungszeiten und genaue Flughafenbe-zeichnung hinterlegt.

Das Element FLIGHT verknüpft die Passagierinformationen mit denen des Flu-ges. Dabei sind einige wesentliche Angaben obligatorisch (wie z.B. Flugnum-mer, Gatenummer und Start-/Landezeiten) und andere optional (wie. z.B. An-gaben zum Flugzeug und der Flug-/Gepäckstatus). Auf dieses Element wird auch in den folgenden Dokumenten oft referenziert, da die genaue Flugzuord-nung ein zentraler Bestandteil vieler openPlatform-Dokumente ist.

Das spezifischste Element für die PreFlight-Order ist das Element ORDER. Es be-inhaltet vor allem mit dem Element ORDER_ITEM die genauen Angaben zu dem bestellten Produkt. Da es möglich ist mehrere Produkte vorab zu bestellen, ist dieses Element ein Mehrfachelement. Ergänzt werden die Auftragspositionen durch den Gesamtpreis und Angaben zur Steuer.

Assembly / Freight List and Additional Delivery

Die Struktur wird benutzt für drei wichtige Listen, die der Caterer zu ver- und bearbeiten hat. Zunächst die Bestückungsliste (Assembly List), die die detaillier-ten Vorgaben für die Soll-Beladung eines Flugzeuges beinhaltet. Der Caterer erhält diese und sollte möglichst versuchen die Beladung nach dieser Liste komplett durchzuführen. Das ist allerdings aufgrund von z.B. Ressourceneng-pässen nicht immer der Fall. Der Caterer muss daher eine Liste haben, die exakt darstellt was er tatsächlich in die Flugzeug-Trolleys geladen hat. Diese Liste ist die Ladeliste (Freight List). Sie entspricht dem Dokument, das verbindlich dar-stellt, was auf jeden Fall vom Caterer ausgeliefert wird. Zusätzliche Waren kön-nen nur noch über den Weg des Nachlieferungsauftrages (Additional Delivery) in die Trolleys gelangen. Dieser Nachlieferungsauftrag kann nur ausgelöst wer-den, wenn ein Fehler bei der Beladung festgestellt wird (Über- oder Unterbela-dung) oder noch eine kurzfristige PreFlight-Shop Bestellung eingeht. Bei der letzten Variante ist es jedoch unumgänglich, dass ein zeitliches Limit für die Shop-Bestellungen gesetzt wird, damit diese nicht überraschend noch bei der endgültigen Beladung des Flugzeuges eingehen.


62


Abbildung 38: openPlatform-Dokument Flight-Schedule

FLIGHT_SCHEDULE

LOCAL_AIRPORT

DATE

SCHEDULE_ID

IATA

ICAO

AIRPORT_NAME

COUNTRY

ZONE

FLIGHT_NO

ARRIVAL_TIME

DEPARTURE_TIME

LEG

GATE_NO

CLEARANCE_POSITION

BAGGAGE

REMARK

FLIGHT_STATUS

AIRCRAFT

FLIGHT


63


Abbildung 39: openPlatform-Dokument PreFlight Order

PREFLIGHT_ORDER

PAX_INFO

FLIGHT

FLIGHT_NO

ARRIVAL_TIME

DEPARTURE_TIME

LEG

GATE_NO

CLEARANCE_POSITION

BAGGAGE

REMARK

FLIGHT_STATUS

AIRCRAFT

ORDER_ITEM

TOTAL_PRICE

TAX

TAX_VALUE

ORDER

Für alle drei Listen wird dieselbe Struktur verwendet (siehe Abbildung 40), da sie in fast allen Punkten gleich sind. Lediglich bei wenigen Elementen ist eine Anwendung für nur eine Liste sinnvoll. Das einleitende Element ist der HEA-DER1. Er gibt mit der LIST_ID eine eindeutige Identifikation der Liste, stellt die wichtigsten Flugdaten dar und beinhaltet mit der CATERER_ORDER_ID eine Re-ferenz zu der Auftragskennzeichnung des Caterers.


64


Abbildung 40: open-Platform-Dokument Assembly / Freight List and Additional Delivery

ASSEMBLY_FREIGHT_LIST_ADDIT...

CARGO

HEADER 1

LIST_ID

DATE

FLIGHT_NO

ARRIVAL

DEPATURE

AIRCRAFT

LEG

CLEARANCE_POSITION

CATERER_ORDER_ID

MAS_ID

CTB_ID

CTB_TYPE

CTB_STANDARD

ASSEMBLY_LINE

DISPOSITION

DUTY

GALLEY_NO

COMPARTMENT

CONTENT

OPTIONAL_INFORMATION

PRODUCT

CTB

OTHER

SUMMARY


65


Die spezifischen Elemente der Listen, die Beladung, sind unter CARGO zusam-mengefasst. An dieser Stelle wird alles aufgeführt, was in das Flugzeug geladen wird. Dabei wird unterteilt ob es in einem Container-Transportbehälter (CTB) also Trolley oder sonstigen (other) Behältnis an Bord gebracht wird. CTBs sind immer mehrere (mindestens einer) an Bord zu laden, während die Angabe an-derer Behältnisse optional bis ebenfalls mehrere definiert ist. CTBs haben zu-nächst eine eindeutige ID (MAS_ID) innerhalb der sie im projektinternen Multi-agentensystem eindeutig zu identifizieren sind. Desweiteren besitzt jeder CTB eine eindeutige CTB_ID, die allerdings bei der Funktion als Bestückungsliste auf »0« festgelegt ist, da sie erst bei der Zusammenstellung der Trolleys in Form der Ladeliste bekannt wird. Der Caterer legt während der Kommissionierung fest welche Trolleys mit welchen IDs eingesetzt werden und nicht bereits vorher. Der CTB_TYPE (z.B. Essens- oder Getränketrolley) und CTB_STANDARD (z.B. KSSU oder ATLAS) wird allerdings bereits von Beginn an festgelegt. Bei der AS-SEMBLY_LINE wird festgelegt, ob der Trolley Meal Trays also Essenseinschübe beinhaltet oder Sales Trays (also Behälter für Verkaufsgegenstände). Von den Einschüben ist abhängig in welche Kommissionierstraße der Trolley kommt. Im Feld DISPOSITION ist die Entscheidung enthalten, ob der Trolley nach dem Flug im Flugzeug verbleibt oder nicht. Das Feld DUTY gibt an, ob es sich um zollfreie Ware oder nicht handelt. GALLEY_NO und COMPARTMENT geben an wo der Trolley genau im Flugzeug hingehört und CONTENT bezeichnet den Oberbeg-riff des Inhalts des Trolley (Essen, Trinken, Non-Food, usw.). Das Feld OPTIO-NAL_INFORMATION kann genutzt werden um weitere Informationen beizufü-gen bspw. ob der Trolley versiegelt werden muss.

Das Feld PRODUCT (siehe Abbildung 41) im Element CTB stellt alle Produkte dar, die in einem CTB geladen sind. Es ist durch viele charakterisierende Felder begleitet, wobei hier nur auf die wichtigsten eingegangen werden soll. Im Feld ADDITIONAL_INFORMATION ist für den Fall einer Additional Order der Platz zur Spezifizierung warum etwas nachgeliefert werden musste (entweder zusätzli-che PreFlight-Order, oder ein Produkt zu viel / zu wenig mitgeliefert). Für eine genauere Beschreibung des Grundes einer Nachlieferung ist die ER-ROR_DESCRIPTION auszufüllen. Die PRODUCTTYPE_ID wird benutzt, um den genauen Typ eines Produktes zu spezifizieren (z.B. Rotwein). »Normale« Wa-ren, die nicht über eine PreFlight-Order oder als höherwertige Waren in den Prozess kommen haben nur diese ID. Die anderen besitzen eine SERIAL_NO um sie eindeutig identifizieren zu können. Das Feld TRAY_TYPE spezifiziert den Typ des Tabletts auf dem das Produkt in dem Trolley gelagert wird (z.B. Essens- / Getränke- oder Verkaufswarentrolley). Unter PRODUCT_FEATURE kann einge-tragen werden welche speziellen Zusätze das Menü hat (vor allem, wenn es sich z.B. um vegetarisches Essen handelt oder für Allergiker, usw.). Bei PRO-DUCT_COMPOSITION können zwei Dinge angegeben werden: Zum einen aus welchen Komponenten das Menü besteht (z.B. Rindfleisch, Reis, Salz, Pfeffer) und zum anderen die Anzahl an Mahlzeiten, die mit den Produktkomponenten hergestellt werden können.


66


Abbildung 41: open-Platform-Element PRODUCT

PRODUCT

LINE_ITEM

ADDITIONAL_INFORMATION

ERROR_DESCRIPTION

PRODUCTTYPE_ID

SERIAL_NO

TRAY_TYPE

TARGET_FLIGHT_CLASS

PRODUCT_NAME

PRODUCT_FEATURE

PRODUCT_COMPOSITION

PRODUCT_QUANTITY

SPACE_REQ_PER_ENTITY

UNIT_OF_QUANTITY

COURSE

SPECIFIC_CONTENT

PRODUCT_DELIVERY

PACKING_UNIT

HACCP

COMPLETE


67


Das Feld SPECIFIC_CONTENT gibt Auskunft darüber ob ein Produkt mit einem speziellen Inhalt zusammen geladen werden muss. Damit kann angegeben werden ob z.B. ein bestellter Film nur in Verbindung mit einem mobilen IFE ge-laden werden soll. Falls ein Passagier eine Bestlellung aus dem PreFlight-Shop ausgelöst hat und dieses Produkt an seinem Sitzplatz erwartet, so gibt das Feld PRODUCT_DELIVERY Auskunft über den genauen Sitz und Namen des Passa-giers. Im Feld COMPLETE kann angegeben werden ob ein Produkt vollständig geladen wurde (Wert 1) oder nicht (Wert 0).

Für das Element OTHER für jegliche andere Inhalte, die nicht in einem CTB ge-lagert werden, ist eine nahezu identische Aufteilung der Felder vorhanden. Es fehlen lediglich die Zuordnungen und Bezeichnungen für die CTBs .

Transfer Order

Die Transfer Order (Transportauftrag) zeigt dem Fahrer des Highloader die zu ladenden CTBs und das Zielflugzeug bzw. die Abfertigungsposition an. Der Highloader fährt zu der entsprechenden Rampe, lädt die CTBs bzw. anderen Inhalte, die auf dem Transportauftrag stehen, und fährt die korrekte Position an. Am Flugzeug angekommen wird alles ausgeladen. Die vorhandenen Con-tainer werden nun mit der Ladeliste, die die Crew zur Verfügung hat, vergli-chen. Abbildung 42 zeigt die komprimierte Hauptstruktur. Die Aufteilung ist der der Ladeliste sehr ähnlich allerdings wurden hier deutlich weniger Detailin-formationen zu den Ladeinhalten hinterlegt, da diese zum bloßen Transport der fertigen Trolleys nicht benötigt werden.

Die Hauptstruktur des Transportauftrags teilt sich in zwei Elemente: Der HEA-DER2, der im Gegensatz zu dem HEADER1 der Ladeliste zum einen weniger und zum anderen transportspezifische Elemente beinhaltet. Dazu gehören die TRUCK_ID, die darstellt welcher Truck gewählt wurde um die Trolleys zu trans-portieren und die RAMP, die darstellt an welcher Rampe die Trolleys abgeholt werden sollen.

Das TRANSPORT-Element ist ähnlich der Ladeliste aufgebaut und enthält alle CTBs und weiteren Behälter (OTHER), die vom Highloader von der Rampe ins Flugzeug transportiert werden müssen. Die hier referenzierten Elemente ent-sprechen der der Ladeliste, wobei es weniger sind und manche nur optional de-finiert wurden.


68


Abbildung 42: openPlatform-Dokument Transfer Order

TRANSFER_ORDER

HEADER2

FLIGHT_NO

ARRIVAL

DEPARTURE

AIRCRAFT

LEG

CLEARANCE_POSITION

CATERER_ORDER_ID

TRANSPORT_CTB

TRANSPORT_OTHER

CTB_ID

MAS ID

CTB_TYPE

CTB_STANDARD

GALLEY_NO

COMPARTMENT

OPTIONAL_INFORMATION

TRANSPORT

DATE

RAMP

TRUCK_ID

LIST_ID

Ground Delivery

Die Ground Delivery (Bodenauslieferung) ist die Datenstruktur für die Pre- und Inflight-Bestellungen, die zur Abholung an einem Service-Point am Flughafen oder Direktlieferung an die vom Passagier angegebene Adresse vorgesehen ist. Die entsprechende Order liegt bereits vor und die notwendigen Aktionen, um den Service-Point mit den Waren auszustatten oder die Adresse zu beliefern, werden angestoßen.

Die Struktur (siehe Abbildung 43) besteht hauptsächlich aus inzwischen ver-trauten Elementen. Der HEADER1 wurde bereits bei der Ladeliste eingeführt. Das Element PRODUCT_TO_DELIVER ist ein Mehrfachelement, das alle Produkte beinhaltet, die ausgeliefert werden müssen. Da es sich hier auf jeden Fall um besondere Produkte handelt, die bestellt wurden haben die Produkte auf jeden Fall eine SERIAL_NUMBER, die sie eindeutig identifizieren. Auch hier sind die bereits vorgestellten Muster mit Produkt Features und Komponenten zu finden. Zu guter Letzt gibt es die DELIVERY_INFORMATION, die darstellt wohin genau


69


die Bodenauslieferung stattfinden soll. Dies kann der lokale Service Point am Flughafen sein oder die Privatadresse des Passagiers zu der die Ware geliefert werden soll.

Abbildung 43: openPlatform-Dokument Ground Delivery

GROUND_DELIVERY

HEADER1

PRODUCT_TO_DELIVER

LINE_iTEM

PRODUCTTYPE ID

SERIAL_NO

PRODUCT_NAME

PRODUCT FEATURE

PRODUCT_COMPONENT

PRODUCT_QUANTITY

UNIT_OF_QUANTITY

PACKING_UNIT

DELIVERY_INFORMATION

Ergebnis Monitoring Dashboard (autoID systems GmbH, Fraunhofer IAO)

Alle Objekte, die in einer zentralen RFID Middleware aus dem Eventdatenstrom heraus identifizierbar sind, können über ein Dashbord darstell- und auswertbar gemacht werden.

Die Notwendigkeit der genauen Anpassung führt aber auch dazu, dass es keine Standardausführung eines Event-Dashboards geben kann. Für eine Realisierung ist nicht nur eine hochindividuelle Prozessanpassung, sondern auch genaues Wissen um alle relevanten Kennzahlen des Prozessablaufes notwendig, damit Events entsprechend konfiguriert und damit korrekt interpretiert werden kön-nen.


70


Abbildung 44: Moni-toring Dashboard mit einer Anzeige von RFID-Events und ausgetauschten openPlatform-Nachrichten im Prozessablauf

In dem Konzeptionsvorschlag für das Projekt iC-RFID ist eine der möglichen Ausprägungen dargestellt, welche alle RFID Lese/Schreibvorgänge von in einem Flugzeug verwendeten Trolleys aus dem Eventstrom herausgefiltert werden und über ein Managementboard über die gesamte Prozesskette hinweg angezeigt werden (siehe Abbildung 44).

Abbildung 45: Bei-spiel: Prozessverlauf Flugzeutrolley, hier: Anzeige verspäteter Trolleys inkl. letztem bekannten Standort des Trolleys im ge-planten Prozess

Die Mandantenfähigkeit erlaubt eine zentralisierte Applikation für heterogene Prozessansichten mehrerer Firmen an einem übergeordneten Standort (z.B. Flughafen). Hierbei sind im Prinzip dieselben Informationen für jeden Partner verfügbar, werden jedoch mit verschiedenen Mechanismen und Ansichten sinnvoll voneinander getrennt. Hintergründe bei der Abgrenzung könnten Si-cherheitsrelevanz oder Vertraulichkeit, aber auch Reduktion der Informations-menge auf ein übersichtliches Maß sein. Abbildung 45 illustriert eine Dashbo-ardansicht für einen Caterer.


71


Ergebnis Process Monitoring & Quality Assurance (Fraunhofer IAO)

Process Monitoring & Quality Assurance stellt anhand geeigneter Kennzahlen (Key Performance Indicators) die Prozessqualität über Unternehmensgrenzen hinweg in einem Monitoring-Dashboard dar und überwacht diese. Zudem er-folgt im Dashboard eine Visualisierung des Tracking & Tracing der Trolleys über die gesamte Catering-Logistikkette hinweg, so dass insgesamt deren Transpa-renz erhöht wird und Optimierungspotentiale aufgedeckt werden können. Bei Engpässen oder großen Abweichungen der Key Performance Indicators (KPIs) von ihren Normalwerten, können zeitnahe Warnungen angezeigt werden, um die Reaktionsfähigkeit entlang des Logistikprozesses zu verbessern.

Zielgruppen des Dashboards sind zum einen Airlines, die an einem transparen-ten Gesamtprozess interessiert sind, und zum anderen Caterer, die hauptsäch-lich eine Visualisierung ihrer eigenen Prozesse im Fokus haben. Für Airlines und Caterer sind verschiedene Dashboard-Sichten vorgesehen, da unterschiedliche Visualisierungsinformationen benötigt werden.

Als Dashboard-Software kommt das kommerzielle Produkt Progress® Apa-ma®5 zum Einsatz. Hierbei handelt es sich um eine Event Processing Plattform, welche darauf spezialisiert ist, eine Vielzahl von Events kontinuierlich anhand definierter Muster zu analysieren, gegebenenfalls mit entsprechenden Aktionen mittels festgelegter Regeln unmittelbar darauf zu reagieren und all dies in ei-nem Dashboard zu visualisieren. Unter einem Event versteht man hierbei ein wahrnehmbares Vorkommnis, im Projektkontext beispielsweise ein RFID-Event bei der Durchfahrt eines Trolleys durch ein Gate oder ein Alarm-Event, das im System generiert wird und im Dashboard angezeigt werden soll. Im Gegensatz zu traditionellen Software-Architekturen kommt hierbei eine Ereignis-gesteuerte Architektur (Event-Driven Architecture) zum Einsatz, welche auf eine Reaktionsfähigkeit in Echtzeit und eine hohe Performance in der Verarbeitung einer Vielzahl von Events abzielt.

Kernstück der Lösung ist eine Complex Event Processing (CEP) Engine mit einer systemeigenen Event Processing Language (EPL) zur Definition von Event-Typen, zur Beschreibung von Eventmustern, die in einem beliebigen Eventstrom er-kannt werden sollen, sowie zur Festlegung von Aktionen, die im Bedarfsfall auszuführen sind. Als Input für die CEP Engine fungieren verschiedene Adapter, welche die Events in das systemeigene Format überführen, so dass eine Intero-perabilität mit unterschiedlichen Systemen gewährleistet ist.

Das Dashboard, das in einem Internet Browser lauffähig ist, kommuniziert mit der CEP Engine, um die Events in aufbereiteter Form in Echtzeit anzuzeigen. Letztere ist über einen Adapter mit dem Messaging Bus der Middleware ver-

5 http://web.progress.com/de-de/apama/event-processing-platform.html


72


bunden, so dass Events aus allen an der Middleware angeschlossenen Systemen verarbeitet und somit im Dashboard visualisiert werden können.

2.7 Intelligentes Planungs- und Steuerungssystem

Im Rahmen von iC-RFID wurde der Funktionsprototyp eines Multiagentensys-tems entwickelt. CESSAR (Configuration and Evaluation of Service Systems in Air-Catering with RFID) plant eine Supply Chain im Luftverkehrscatering an ei-nem Flughafen und im Verkehrsnetzwerk einer Airline. Dabei demonstriert das System »intelligente« Methoden, um geplante Ziele »doch noch« zu erreichen (Improvisationsintelligenz). Wenn z.B. RFID-Systeme oder andere Quellen Ab-weichungen vom geplanten Ablauf anzeigen, generiert CESSAR sofort einen neuen, ausführbaren und bei gegebenen Regeln zulässigen Plan. Alternativ greift CESSAR auf Eventualpläne zu. In beiden Fällen fließen wirtschaftliche Kri-terien wie Kosten und vereinbarte Servicelevel in die Entscheidung ein.

Die in CESSAR verwendeten Managementstrategien und technologischen Kon-zepte beruhen auf einer Vielzahl seit 1995 in Zusammenarbeit mit Unterneh-men durchgeführter Projekte, in denen neue Ansätze des Managements kom-plexer Dienstleistungssysteme entwickelt und auch erfolgreich implementiert wurden. Erste praktische Studien zur ständigen Verfolgung und ereignisindu-zierten Steuerung wurden am Beispiel von Luftfrachtsendungen 1996 durch-geführt. In deren Fortsetzung wurden 1998 / 2000 erste Multiagentensysteme entwickelt, um dynamische Steuerungsprozesse zu automatisieren. Neben lo-gistischen Anwendungen ist die von »wissensverarbeitenden« (ontologiebasier-ten) Multiagentensystemen gestützte interdisziplinäre »Wissensarbeit« ein wei-terer Schwerpunkt des Zentrums. Die technologischen Grundlagen stammen u.a. aus der internationalen Zusammenarbeit mit anwendungsorientierten For-schern aus Groß-Britannien, USA und der Russischen Akademie der Wissen-schaften.

Ergebnis CESSAR - Configuration and Evaluation of Service Systems in Air-Catering with RFID (Fachhochschule Köln)

Im Folgenden werden zuerst die Herausforderungen an die Intelligenz darge-stellt, operative Pläne dynamisch an ungeplante Ereignisse anzupassen. An-schließend wird erläutert, wie Multiagentensysteme als »intelligente Middlewa-re« die technische Grundlage dafür bereitstellen. Zuletzt werden die wesentli-chen Eigenschaften und Arbeitsweisen von CESSAR beschrieben.

Die Herausforderung: Komplexe Dienstleistungssysteme und Improvisa-tionsintelligenz

Verkehrsnetzwerke, Flughafenbetriebe, industrielle Supply-Chains, große Logis-tik- oder Entwicklungsprojekte bestehen aus vielen, auf viele Orte und viele Or-ganisationen verteilten, aber untereinander abhängigen Akteuren. Am Flugha-fen muss jeder Dienstleister die eigenen Serviceziele erreichen, das Flugzeug


73


pünktlich »drehen« können nur alle gemeinsam. Wenn z.B. ein Gepäckwagen die Arbeitsposition des Caterers am Flugzeug blockiert, kommt man dort viel-leicht bei einem Problem mit Gepäckförderband schneller voran, aber die Bela-dung der Galley ist verspätet. Diese Abhängigkeit verändert auch Konkurrenz-beziehungen: Verspätet Dienstleister A ein Flugzeug, blockiert es die Position für das nächste, das z.B. vom Konkurrenten B bedient wird. In Peaks überträgt sich die Verspätung aber weiter und A steht eine Stunde später vor dem Folgen seiner früheren Panne. Um die Propagation zu stoppen, arbeitet B vielleicht so-gar schneller. Damit hilft er dem Konkurrenten, aber auch sich selbst – im Ver-trauen darauf, dass A sich in einer entsprechenden Situation ebenso verhalten wird. Die Interdependenz der Dienste erzeugt einen gemeinsamen Kontext, der eine effektive Kooperation zwischen allen Dienstleistern einfordert.

Komplex ist ein System, dessen Verhalten nicht auf ein Beschreibungs- und Erklärungsmodell zu reduzieren ist, das es reproduzierbar und prog-nostizierbar macht. Für Beobachter ist das Verhalten daher emergent.

Dieser Artikel betrachtet Systeme, deren Verhalten aus dem Zusammen-spiel von Teilsystemen (Agenten) entsteht, die autonom, aber mit unvoll-ständiger Information und bei hoher Interdependenz entscheiden. Auch bei Kenntnis der Abhängigkeit und rationalem Verhalten entstehen Glo-balzustände, die niemand wünscht. Jeder Agent trägt zum Globalverhal-ten bei, ist bei der Informationsbeschaffung aber ein schlecht informierter Beobachter.

Die Offenheit gegenüber externen Ereignissen oder die Zugehörigkeit zu unterschiedlichen Kontexten steigern die Komplexität weiter.

Jeder Serviceagent entscheidet lokal aber mit unvollständiger Information. Nie-mand verfügt über eine vollkommene Beobachterfähigkeit und schon die 50 m Distanz zwischen Boarding Gate und Ramp-Agent am Flugzeug kann kritisch sein. Das System produziert so einen Störpegel, eine Folge unerwarteter und daher ungeplanter Ereignisse, die auch kritische Situationen erzeugen können. Da Dienstleistungssysteme offen sind, verstärken externe Ereignisse wie Wetter oder das Passagierverhalten die Unsicherheit. Ein herrenloser Koffer kann den Betrieb für Stunden blockieren. Gesellschaftliche und politische Einflüsse verän-dern Entscheidungskontexte mit neuen Unwägbarkeit und neuen Zielkonflikten (z.B. Lärmschutz versus Kosten und Service für Airlines und Passagiere).

Kritizität und das Risiko positiver Rückkopplungen (Selbstverstärkung) steigen mit dem Störpegel und dem Mangel freier Ressourcen. Es gibt zwei konventio-nelle Gegenstrategien: Zum einen mehr Flexibilität (z.B. Zeitpuffer einrichten), die verbesserte Prozesse, aber auch qualifiziertere und vor allem mehr Ressour-cen fordert und / oder zum anderen ein besseres Informationsmanagement.


74


Ein vereinfachtes Rechenbeispiel veranschaulicht die Implikation von Zeitpuf-fern: Zur Unterbrechung von Störsequenzen erhöht eine Airline die Bodenzei-ten ihrer Kontinentalflotte (A318/319, B737) um 5 Minuten. Bei 100 Flugzeu-gen mit durchschnittlich fünf Flügen und fünf Abfertigungsstopps an den Flug-häfen pro Tag werden 2500 Minuten verplant. Bei (optimistischen) 18 Einsatz-stunden investiert die Airline rechnerisch die Kapazität von 2,3 Flugzeugen. Ka-pitalkosten, Crews, Maintenance, Kerosin, Gebühren, etc. summieren sich zu einem zweistelligen Millionenbetrag pro Flugplanperiode. Alternativ könnten die Puffer am Flughafen aufgebaut werden. Aber selbst ohne den Bau neuer Runways, Vorfeldpositionen oder Terminals, auch zusätzliches Bodengerät und Personal verursachen Kosten – und zwar in einer Situation, in der Airlines z.B. das Overcatering (mehr als gebucht) auf null bringen.

Verbesserungen des Informationsmanagements werden u.a. im EU-Programm SESAR angestrebt (Single European Sky Air traffic Research, Budget 2,1 Mrd. €). Zu den Themen zählen u.a. ein System-Wide Information Management (SWIM), verbesserte Telemetriesysteme (GPS, RFID), und eine effizientere Zu-sammenarbeit zwischen den Organisationen. Das Programm antwortet auf die erwartete Verkehrsverdopplung in den nächsten 10 Jahren. Das rapide Wachs-tum wird diese Maßnahmen jedoch letztlich kompensieren. Und neue Hand-lungsspielräume werden im Wettbewerb wahrscheinlich bald in Kostenvorteile übersetzt werden. Störungen könnten sogar stärker wiederkehren. D.h. »Ab-stimmungspräzision« ist unverzichtbar, aber nicht hinreichend, da ihre Wirkung mit zunehmender Komplexität deutlich nachlässt.

Das führt zu einer dritten Strategie, der Entwicklung einer »Improvisationsintel-ligenz«, die kritische Situationen u.U. antizipiert, ihren Eintritt verhindert, zu-mindest begrenzt und erff. den Service wiederherstellt. In der Betriebswirtschaft ist Improvisation eher ein Unwort. Systeme werden auf ihre Zielparameter hin optimiert, Aktionspläne formuliert und implementiert. Das englische Wort Im-provisation verweist dagegen auf ‚improve‘ – und zwar den Plan, der aufgrund ungeplanter Ereignisse nicht mehr zu halten ist. Verbessert wird also der Plan aufgrund der aktualisierten Information. Ein wichtiger Faktor ist die zunehmen-de Empfindlichkeit für Details, die zwar vor Ort, aber z.B. nicht von einem Leit-stand her erkennbar aber doch relevant sind. Sie können große Wirkungen ha-ben – ein herrenloser Koffer, der den Betrieb zum Stillstand bringt, ein blockier-ter Dolley, der den Anschluss verspätet. D.h. die Häufigkeit unerwarteter Ereig-nisse steigt und erzeugt so eine kontinuierliche Planung.

In der Musik ist Improvisation ein spontaner, kreativer Vortrag bei virtuoser Be-herrschung von Instrument und Stil, Liebe zum Detail und Aufmerksamkeit für die Umgebung. In der profanen Welt von Logistik und Flughäfen geht es um das hervorragende Wissen über Prozesse und Ressourcen und über Handlungs-optionen, ihre Implikationen für den Gesamtablauf und verbunden die Beach-tung von Details. Es ist die Königsdisziplin der Disponenten, die die vielen Dienste steuern und auch die ihrer Augen und Ohren draußen: der Service-


75


Agenten und der telemetrischen Systeme. Improvisationsintelligenz in komple-xen Dienstleistungssystemen ist eine Teamleistung.

Der Lösungsansatz: Architekturen einer intelligenten Middleware

»Nicht selten halten wir den Betrieb durch Improvisation aufrecht. Aber man muss sehr gut vorbereitet sein und sehr sorgfältig arbeiten, wenn man von den Standardverfahren abweicht. Dabei macht uns gerade in kritischen Situationen eine Informationsflut zu schaffen, die niemand effektiv auswerten kann. Ein in-telligentes System könnte uns Arbeit abnehmen. Vielleicht gibt es ja eine besse-re Lösung als die, die uns gerade eingefallen ist. «6

Eine zentrale Frage ist daher: Wie wird die kontinuierliche Planung technolo-gisch unterstützt? Hinsichtlich Wissen, Assoziations-, Improvisations- und Lern-fähigkeit ist der Mensch (noch?) besser, als die Maschine. Zum Ausgleich ist de-ren Merk- und Rechenfertigkeit größer. Multiagentensysteme fügen die Fähig-keiten der assoziativen Wissensverarbeitung, des Auslotens von Handlungsopti-onen und des Erfahrungslernens hinzu. Sie sind geeignete Kandidaten, um das Problem des Supervisors zu lösen. Die

Multiagentensysteme bilden sich aus der direkten Peer-2-Peer Interaktion zwischen autonomen Softwareobjekten oder Dingen (Agenten). Die In-teraktion beruht auf der Nachfrage und dem Angebot von Diensten (Dienstleistungsnetzwerk). Agenten nehmen ihre Umwelt wahr und nut-zen ein Wissensmodell (Ontologie), um kontext und zielbezogen Hand-lungsbedarfe zu identifizieren und zu bewerten sowie Handlungsmög-lichkeiten zu verhandeln.

Sofern Dinge (z.B. Fahrzeuge) entsprechend ausgestattet sind, können sie auch direkt interagieren. Alternativ können sie von Softwareagenten in einem System vertreten werden, das die materielle Realität so detailliert wie nötig abbildet. Die beiden Welten werden u.a. durch telemetrische Systeme verbunden.

Aufgabe ist nicht trivial: Die LSG Frankfurt plant und steuert für hunderte Flüge am Tag ca. 3,5 Mio. Catering Items in ca. 30.000 Ladelisten, dutzende Produk-tionsstraßen, Lager, Gates, Rampen, Fahrzeuge und hunderte Mitarbeiter.

Ein Multiagentensystem ist eine Middleware, die mit Kommunikationsprotokol-len sowie Handlungs- bzw. Verhandlungslogiken und Schnittstellen zu Daten-banken oder anderen Informationsquellen die direkte Peer-to-Peer Interaktion

6 Zitat aus einem Gespräch mit einem sehr erfahrenen Supervisor am Flughafen Frankfurt


76


zwischen autonomen Agenten unterstützt. Die wichtigste Datenbank ist die Ontologie. Sie enthält Fachwissen, mit dem die Agenten Ziele sinnvoll (mit Wis-sen) verfolgen und sich dazu mit anderen Agenten in einer Peer-to-Peer Archi-tektur verständigen können. Die Agenten können dabei nicht nur »Software-« sondern auch »Hardware«-Objekte sein:

In der Vision vom »Internet der Dinge« geht es um eine Internet-gestützte Kommunikation zwischen Hardware-Objekten. Ein Beispiel ist die in Anfängen schon vorhandene direkte Kommunikation zwischen Fahrzeugen (»Internet der Fahrzeuge«) in dem diese lokale, aktuelle Information austauschen. Fahrzeuge im Stau veranlassen so andere, ihrem Fahrer eine neue Route oder andere Fahrweise vorzuschlagen. Ein anderes Beispiel ist »Free-flight«, ein zukünftiges Luftverkehrskontrollsystem, das ohne Luftstraßen und mit weniger Assistenz durch die Fluglotsen auskommt, weil die Flugzeuge den verfügbaren Luftraum untereinander verhandeln. Ein erster Schritt ist TCAS (Traffic Alert and Collision Avoidance System). Es greift ein, wenn zwei Flugzeuge ihre Mindestdistanz (Separation) unterschreiten. Jeder der Piloten bekommt dann vom TCAS seines Flugzeugs konkrete Anweisungen, die sogar Vorrang vor den Anweisungen der Boden-Controller haben. Peer-to-Peer-Lösungen sind eine sehr effiziente Form zur Erfassung und Ausnutzung lokaler Information, die das Beobachterproblem der Zentrale umgeht und sie vermeiden auch Kommunikationsumwege und damit verbundene Informationsverluste – wenn die Middleware sie dabei wirk-sam unterstützt.

Die Reichweite des Konzeptes »intelligenter Dinge« ist aber begrenzt und nur teilweise auf Cateringsysteme übertragbar. Von Ausnahmen abgesehen, ist es technisch und / oder wirtschaftlich nicht möglich, alle Objekte mit der Techno-logie auszustatten, die sie zu einer direkten Kommunikation befähigt. Stattdes-sen baut man die Welt der realen Objekte im Multiagentensystem mit Soft-wareobjekten nach, die – wie Schauspieler – deren Rolle in der virtuellen Welt übernehmen. Durch die Modellierung aller Objekte, die Dienste anbieten oder nachfragen, entsteht eine strukturerhaltende (homomorphe) Abbildung der Re-alwelt. Zum Erhalt der Integrität dieser Abbildung muss die virtuelle Welt stän-dig aktualisiert werden, z.B. durch:

- Datenverbindungen zu den Flight-Information Systems des Flughafens oder der Airlines,

- Verbindungen zu E-Shops, über die Passagiere u.U. weitere Bestellungen tätigen,

- Warenwirtschafts- und Lagersysteme sowie Statuskontrollsysteme im Cate-ringbetrieb

- GPS-Systeme, mit denen bewegliche Ressourcen auf dem Vorfeld verfolgt werden,


77


- RFID-Systeme, die Status und Qualität von Cateringobjekten sowie der Kommissionier-, Transport- und Verladeprozesse zugänglich machen – u.v.a.m.

Tabelle 3: Daten eines beispielhaften Multiagentensystems bei einer LKW-Transportqeue

Belastungswerte zu planende Ressourcen (z.B. LKW)

150

Ereignisdichte (min/max) 30-120 events per hour

Auftragsdichte (min/max) 5-10 orders per day for one re-source

Leistungsdaten

Antwortzeit pro Ereignis Max. 180 sec

Min. 100 msec

Ø 14 sec

Anzahl interdependenter Ob-jekte

100 000

Anteil von Antwortzeiten < 14 sec

60 %

Max. geplanter Aufgaben pro Ereignis

12

Max. erforderlicher Reallokatio-nen

3 (je geringer desto besser)

systeminterne Nachrichten pro Minute

250

Max. Zahl gleichzeitig aktiver Agenten

300 (=von Ergebnis betroffene Objekte)

Max. Optionen pro Entschei-dung

10

Max. Zahl Iterationen pro Ent-scheidung

7

Max. Anteil neuer Ressourcen-pläne

75 %

Die wirtschaftlichen Vorteile von Multiagentensystemen können am Beispiel ei-nes 2006 in England bei einem LKW-Transporteur implementierten System plausibilisiert werden, das von Technologiepartnern der FH Köln entwickelt wurde. (Beispiele aus dem Luftverkehrscatering liegen noch nicht vor.) Die ak-tuellen Systeme waren einige Jahre zuvor eingeführt worden, weil sie ein wei-tes Spektrum operativer Aufgaben abdeckten und transparente Standards so-wie Optimierungsverfahren unterstützen. Sie stießen aber immer häufiger an ihre Grenzen: Die Planung für einen Tag dauerte ca. 12 Stunden. In dieser Zeit trafen aber weiterhin neue Aufträge ein, andere wurden storniert oder neu pri-orisiert, Lieferungen verspäteten sich, geplante Strecken wurden gesperrt, Fahr-zeuge oder Fahrer fielen aus usw. Bei ca. 150 täglich eingesetzten LKW waren letztlich nur ca. 40 % der »Optimalpläne« brauchbar. Das System war unfähig,


78


auf neue Information sinnvoll zu reagieren. Die während der Planung eingetre-tenen »ungeplanten Ereignisse« wurden am nächsten Tag von den Disponen-ten manuell in den Plan eingearbeitet. Tabelle 3 zeigt die Leistung des imple-mentierten MAS.

CESSAR – Configuration and Evaluation of Service Systems in Air-Catering with RFID

CESSAR ist der Funktionsprototyp eines Multiagentensystems für die Simulati-on, Planung und wirtschaftlichen Bewertung von Luftverkehrscateringsystemen. Konzentriert auf die wesentlichen Prinzipien bildet das System mit ca. 100 ver-netzten Funktionen einen großen Teil der Air-Cateringwelt ab. D.h. die Ge-schäftsprozesse sind zwar vereinfacht aber im richtigen Zusammenhang darge-stellt und können realistisch spezifiziert werden. Das Funktionsspektrum reicht von der Kommissionierung und Containerisierung der Cateringgüter über den Vorfeldtransport und Ent- und Beladung der Galleys bis zur Verfolgung ausge-wählter Objekte über die Flüge und Bodenstationen im Luftverkehrsnetz der Airline. Hierzu werden Güter, Servicekonzepte, Flugzeugflotten und Galleys, das

Intelligenz ist die Fähigkeit Wissen zu nutzen oder zu gewinnen, um sich u.U. auch vorausschauend (z.B. szenariogestützt) effektiv (zielführend) und effizient (ressourcenschonend) an unerwartete und ungeplante Er-eignisse anzupassen.

Wissen ist assoziativ. Es besteht aus Verknüpfungen zwischen Objekten bzw. Konzepten die die reale Welt beschreiben, erklären und handhabbar machen. Lernen bedeutet, Assoziationen aufgrund neuer Information zu verändern bzw. zu erweitern – oder auch durch Denken, die z.B. logische oder »spielerische« Prüfung von Assoziationen.

Ein Software-Agent verfügt nur über Bruchstücke des relevanten Wissens. Assoziationen sind daher Ergebnisse von Verhandlungsprozessen. Es gibt Verfahren, die dieses System befähigen, zu lernen oder die Ontologie auf Widersprüche zu prüfen.

Luftverkehrsnetz mit Routen und Flughäfen sowie an einem Hauptflughafen die Details des Cateringbetriebes (Lager, Produktionsstraßen, Wege, Gates etc.) und des Vorfelds (Abfertigungspositionen, Straßen, Gates, Arbeitspositionen am Flugzeug) detailliert erfasst. Auch ein einfacher Gepäckbetrieb für ein- und ausgehende Flüge wird simuliert, um die Optionen einer interaktiven Planung aller Dienste um Flugzeuge, Passagiere und Fracht anzudeuten. CESSAR unter-stützt (mit erträglichen Rechenzeiten) die Planung und Steuerung tausender Cateringobjekte und verarbeitet sowohl reale externe (z.B. RFID) als auch z.B. zu Test- und Simulationszwecken künstlich generierte Ereignisse.


79


Improvisationsintelligenz demonstriert CESSAR in zwei Formen: Zunächst als kontinuierliche Planung, die intern generierte oder externe, z.B. aus einem RFID-System übertragene Ereignisse mit dem Plan abgleicht und auf der Basis der Standardprozesse Korrekturmaßnahmen einleitet, die z.B. später im be-triebswirtschaftlichen Report dargestellt werden. Die zweite Form ist ein »Intel-ligenter Assistent«, der auf konkret formulierte »B-Pläne« zugreift, um Fehler zu korrigieren und dabei u.a. betriebswirtschaftlich determinierte Entscheidun-gen trifft.

CESSAR unterstützt zwei Betriebsmodi

- die Simulation von Cateringszenarien die das gesamte Funktionsspektrum ausnutzen, in dem aber alle Störereignisse künstlich erzeugt werden

- die Planung- und Steuerung in einem realen, materiellen Mockup eines Ca-teringsystems, in dem das MAS Ereignisse, die über RFID-Reader und -Gates erzeugt werden, gegen den Plan prüft und erff. Korrekturmaßnahmen an-weist.

Entwicklung eines ersten Plans

Der erste Schritt der kontinuierlichen Planung ist die Definition der Ausgangs-daten eines konkreten Szenarios. Sie umfassen u.a.:

- den Flugplan, mit Rotationen der Flugzeuge im Verkehrsnetz, Start- und Zielflughäfen, Zeitlage der Flüge, Bodenzeiten, Flugzeugklasse, Zahl der Sit-ze pro Serviceklasse usw.

- die Servicekonzepte, die in Abhängigkeit von der Serviceklasse die während eines Fluges angebotenen Servicegänge mit Mahlzeiten, Getränken, käufli-chen Waren etc. definieren,

- das eingesetzte Flugzeug mit der tatsächlichen Sitzplatzkapazität, der Zahl der Galleys mit Art, Maß-Standard und Zahl der Stauplätze bzw. Geräte wie Öfen oder Kaffeemaschinen.

- die Buchungen, d.h. der Zahl der tatsächlichen Fluggäste pro Serviceklasse eines Fluges, die mit zusätzlichen, vor dem Flug getätigten individuellen Be-stellungen z.B. für Waren oder spezielle Mahlzeiten (z.B. koscheres oder al-lergenfreies Essen) verbunden sein können.

- die Auslegung / Ausstattung der Cateringbetriebe mit Lagern, Arbeitsstati-onen, internen Wege, Bereitstellungszonen, Gates für Beladung und Entla-dung der Transportfahrzeuge, Gerät und Personal, Lagerbestände …

- die Ausstattung der Transportbetriebe mit Fahrzeugen, Fördergerät, Perso-nal usw. nach Typ.


80


- die Ausstattung der Flughäfen mit Flugzeugabfertigungspositionen (Termi-nal, Vorfeld), Sicherheitsgates, Vorfeldstraßen, Abstellpositionen für Gerät.

- die geografische Ausgangsverteilung aller Ressourcen auf Betriebe, Flug-zeuge und Flüge im Netz (Ladeeinheiten, bewegliches Gerät und Personal, Flugzeuge …) nach Typ und Zahl.

- die technischen Rahmendaten wie Beladungs- und Verladeregeln, Hygiene-kontroll-, Sicherheits- oder Umweltvorschriften etc.

- die wirtschaftlichen Rahmendaten wie Details der Servicelevel, Strafzahlun-gen, Kosten, Bewertungsmodelle, Produktionsmodi (Batch-, Auftragsferti-gung …) etc.

Flugplan, Servicekonzepte, Flugzeuge und Passagierbuchungen konkretisieren die Cateringaufträge. Kommissionier- und Transportbetriebe, Flughafeninfra-strukturen und das mobile Gerät bilden den Produktionsapparat. Die Rahmen-daten zählen zu den Nebenbedingungen. Das Startszenario von CESSAR um-fasst einige hundert Objektklassen (zum Vergleich: das Szenario eines mittel-großen Flughafens mit allen Diensten umfasst einige tausend). Diese Daten sind in den Stammdatenbanken und Prozessmodellen etc. der Airlines oder Caterer verfügbar.

Der Prozess der kontinuierlichen Planung wird in Abbildung 46 veranschaulicht.

Abbildung 46: Pro-zess der kontinuierli-chen Planung

Der Starttrigger wird pragmatisch gewählt. In der Abbildung ist es der Passa-gier. Alternativ könnte das Objekt Business Class für »seine« Passagiere bestel-len oder das Flugzeug bzw. die Instanz »Flug« für alle. Nachfolgende Trigger entstehen entlang des Geschäftsprozesses und können, soweit die Technologie


81


keine Reihenfolge erzwingt, ähnlich frei zugeordnet werden. Auch die in der Abbildung gewählte streng rekursive Organisation der Trigger ist nur eine vieler Möglichkeiten. Andere Organisationsformen sind leistungsfähiger, auf zwei Dimensionen aber nicht anschaulich abzubilden: Die Kontrollparameter sind zwar bekannt und das Ergebnis kann man prüfen und vergleichen. Der Weg dorthin ist aber nicht rekonstruierbar (s.o.: Beobachterproblem). Aus Akzep-tanzgründen muss also ein Ausgleich zwischen Leistung und Anschaulichkeit gefunden werden.

CESSAR entwickelt den Plan durch Verhandlungen zwischen den Agenten, die auf eine Nachfrage antworten und ihrerseits Nachfragen platzieren: Ein Highlo-ader reagiert auf einen Fahrauftrag, muss aber eine freie Verladerampe finden usw. Jeder Agent versucht, seine Ziele zu erreichen. Die Planung ist abgeschlos-sen, wenn alle Agenten eine zufriedenstellende Lösung für ihre Aufgaben er-zielt haben. Für die Agenten stellt sich dieser Plan als Folge erwarteter Ereignis-se und Aktivitäten dar. Ungeplante Ereignisse wie ein RFID-Ereignis, das eine Fehlbeladung anzeigt, implizieren, dass zumindest ein Agent »unzufrieden« ist. Oder »kündigt« z.B. der Agent der Laderampe den Vertrag mit dem Highloader H1, um einen anderen, dringenderen Auftrag vorzuziehen, triggert H1 sofort eine neue Sequenz von Suchprozessen nach einer neuen, zufriedenstellenden Lösung. Diese Suche folgt also dem Prinzip »so lokal wie möglich, so global wie nötig«. Aus einer dichten Folge ungeplanter Ereignisse entsteht so ein dynami-scher, kontinuierlicher Planungsprozess, mit einer definierbaren Detaillierung und steuerbaren Eskalation der Problemlösung. Materiell bestimmen die in der konkreten Situation verfügbaren Ressourcen die Grenzen des Machbaren.

Ontologiegestützte B-Pläne sind die zweite in CESSAR implementierte Variante der Improvisationsintelligenz. Während im Modus »kontinuierliche Planung« die Agenten ad-hoc einen neuen Arbeitsgang definieren indem sie die Frei-heitsgrade (verfügbar, möglich, erlaubt usw.) ausnutzen, sucht der sog. Boden-assistenten nicht nach Freiheitsgraden sondern wendet eine definierte, in der Ontologie abgelegte Strategie an.

Verfahren, die dieser »Plan-B Logik« folgen, wurden auf der Basis konventio-neller Software erst kürzlich vom Lufthansa Hub-Management am Flughafen Frankfurt eingeführt. Ist ein einkommender Flug so viel verspätet, dass Verbin-dungen in Gefahr sind, wird z.B. das Anschlussgepäck nicht über die Gepäck-sortieranlage sondern über eine »Abkürzung« geführt, die von einem interdis-ziplinären Team mit Mitgliedern aus mehreren Unternehmen detailliert geplant und von den Managements abgesegnet wurde. Die Analyse umfasste viele As-pekte wie Sicherheitsfragen, die zusätzlichen Kosten der »Abkürzung« und die ggf. gesparten Kosten für fehlendes Gepäck. Am Flughafen, im Luftverkehr all-gemein oder an einem Krankenhaus führt man solche kontrollierten B-Pläne ein, weil niemand akzeptiert, dass ein System »einen neuen Weg ausprobiert«.

CESSAR kennt zurzeit zwei B-Pläne, von denen der erste operativ ist. In beiden Fällen arbeitet es als Entscheidungsunterstützungssystem für die zuständigen


82


Dispatcher bzw. Ramp-Agents. Die von einem aktiven B-Plan erzeugten Er-eignisse triggern dabei auch die kontinuierliche Planung.

Beispiel 1 ist einfach und nur begrenzt realistisch, aber mit den heute verfügba-ren Systemen nicht zu beherrschen: Es kommt vor, dass ein Highloader die La-dung für zwei Flüge transportiert, deren geplante Starttermine eine gewisse Zeit auseinander liegen. Bei der Beladung des ersten Flugzeugs meldet das RFID-System einen Fehlbestand von z.B. 5 Flaschen Wein. CESSAR prüft nun, ob diese Flaschen (1) in der Ladung für den zweiten Flug vorhanden sind und (2) ob der Austausch wirtschaftlich sinnvoll ist: Wenn bei Flug 1 keine Strafzahlun-gen für fehlende Ladung anfallen, wird das System keinen Austausch anweisen, der Flug startet ohne den Wein. Im anderen Fall prüft das System die Folgen für Flug 2. Wenn dort keine Zusatzkosten entstehen, wird der Austausch vorge-nommen. Wenn Flug 2 auch »strafbewehrt« ist, werden die Strafen und die im Falle des Austauschs entstehenden Kosten für die dann zu veranlassende Nach-lieferung für Flug 2 ermittelt. Sollten die Kosten für den Fehlbestand in Flug 1 größer sein als die Gesamtkosten für Flug 2 wird ausgetauscht …

Beispiel 2 ist komplexer und ähnelt mehr dem oben beschriebenen Beispiel von Lufthansa. Es ist nicht operativ, da dafür in CESSAR zumindest ein weiterer Dienst implementiert werden muss. Der Ausgangspunkt ist, dass zwei Highloa-der an der Parkposition eines ankommenden Fluges warten, der sich zuneh-mend verspätet und dass zu diesem Zeitpunkt keine freien Highloader mehr verfügbar sind (Peak, Krankmeldungen …). Es besteht die Gefahr, dass für ei-nen späteren Flug Kapazität fehlt. Daher wird mit den Airlines bzw. den Ramp-Agents von zwei folgenden Flügen die Absprache getroffen, diese mit jeweils nur einem Highloader anzufahren (ausreichende Ladekapazität sei gegeben). Da beim Einsatz von nur einem Highloader Zeit verloren geht (er muss z.B. von der Arbeitsposition an der vorderen zur Position an der hinteren Galley repositi-onieren), wird mit dem Passagiergate abgestimmt, dass die Beladung der zwei-ten Galley noch während des Einstiegs der Passagiere fortgesetzt wird. Bei einer Terminalposition sollte das möglich sein, da die Passagiere durch die Gangway vorne einsteigen. Bei einer Vorfeldposition steigen wahrscheinlich aber auch Passagiere über eine zweite Treppe durch die hintere Galley ein, in der der Ca-terer noch arbeitet … In diesem Beispiel geht es zwar auch um Kosten, aber mehr noch um die Prozessqualität verschiedener Dienste, die sich präzise ab-stimmen müssen.

Das betriebswirtschaftliche Modell ist eine zeitbezogene Ressourceneinsatz-rechnung für Aufträge und Arbeitsprozesse: Sie erfasst die tatsächliche Zeiten (nicht die geplanten), die z.B. ein Highloader für einen konkreten Flug und für die dazu durchgeführten Prozesse (Beladung, Fahrt, Ladungsaustausch …) auf-gewendet hat. In einer kontinuierlichen Planung


83


Das betriebswirtschaftliche Modell von CESSAR arbeitet mit einer Res-sourceneinsatzrechnung: Das MAS kennt alle tatsächlich durchgeführten Jobs, d.h. weiß, wie viel Zeit die Ressourcen jeweils für welche Aufträge beschäftigt waren und welche Teilprozesse sie durchgeführt haben. Mit den Zeitkostensätzen wird eine vollständige Prozesskostenrechnung er-zeugt. CESSAR verwendet Kostensätze, die für jede Ressource spezifiziert werden können. Die aktuell verwendeten wurden an einem Flughafen erhoben. Neben leistungsabhängigen Kosten wird auch der Beschäfti-gungsgrad der Ressourcen ermittelt werden. Kosten einer mangelhaften Dienstleistungsqualität werden über Penalties operationalisiert.

Alternative Systemkonfigurationen werden in CESSAR über Testreihen bewertet, bei denen für jeden der Vergleichsfälle – z.B. mit und ohne den Einfluss von RFID-Systemen – Szenarien simuliert werden, die sich hin-sichtlich wesentlicher Faktoren wie Flugpläne, Servicekonzepte und vor allem der Zahl und Art von Fehlerereignissen unterscheiden.

ist jede geplante Einsatzzeit nur ein temporär gültiger Wert. Würde CESSAR als Steuerungssystem im realen Betrieb eigesetzt, würde es mit der Steuerung auch unmittelbar die betriebswirtschaftliche Dokumentation aller Aktivitäten liefern.

Aus diesen Zeitdaten können durch Multiplikation mit den geltenden Kos-tensätzen die Prozesskosten pro Auftrag und Arbeitsgang sowie durch Division durch die vom Controller definierte Planverfügbarkeit der Beschäftigungsgrad unmittelbar abgeleitet werden. Als Einstieg in das operative Qualitätsmanage-ment werden außerdem Vertragsstrafen (Penalties) für Beladungsfehler und Verspätungen gerechnet. Diese Daten unterstützen eine vollständige Prozess-kostenrechnung, ein kostenbasiertes Qualitätscontrolling sowie die Entwicklung bzw. Überprüfung von Investitionsrechnungen. Zur Weiterverarbeitung durch einen Controller werden die Daten im Excel-Format exportiert.

Gemessen an klassischen Planungsmethoden gibt es aber ein Problem: CESSAR liefert kein nachweisbares Optimum. Allerdings ist »das Optimum« in der Reali-tät ein flüchtiges Wesen und bei hoher Dichte ungeplanter Ereignisse vollends eine Fiktion. Den Planungskraftakt ersetzt ein Multiagentensystem durch die Konstruktion immer wieder neuer, machbarer und zulässiger Prozesse, die die Ziele so gut wie möglich erreichen. Viele Lösungen könnten also verbessert werden. Hat das System Zeit, kann ein neuer Suchprozess künstlich gestartet werden. Der aktuelle Plan bleibt gültig, bis das System eine bessere Lösung ge-funden hat oder ein »echtes« Störereignis eintritt.

Die wirtschaftliche Bewertung alternativer Systemkonfigurationen befasst sich z.B. mit der Beantwortung der Frage, ob und in welcher Form bzw. unter wel-chen Bedingungen sich der Einsatz von RFID-Systemen im Catering wirtschaft-lich lohnt. Dabei werden die betriebswirtschaftlichen Daten zu Beschäftigung,


84


Prozesskosten und Qualitätsverletzungen verwendet, die in den Simulationsläu-fen erzeugt werden. Der Vergleich alternativer Systemlayouts verläuft kompara-tiv-statisch, d.h. es wird eine Reihe von Szenarien entwickelt. Sie stellen unter-schiedliche Rahmenbedingungen dar, unter denen sich die zu vergleichenden Varianten bewähren müssen. Zu den Parametern der Szenarien zählen z.B. der »Betriebsstress« (Verhältnis von Auftragsvolumen und Störpegel zur Verfügbar-keit von Ressourcen), technische und kommerzielle Rahmenbedingungen oder die Art und Dichte ungeplanter Ereignisse. Für jedes Szenario werden mehrere Simulationsläufe durchgeführt und ausgewertet.

Bei der Frage nach der Wirtschaftlichkeit von RFID-Systemen wird also deren Beitrag zur Planeffizienz geprüft. Beim System mit RFID wird dabei z.B. ange-nommen, dass Fehler früher entdeckt und daher kostengünstiger behoben werden können. Wenn ein Nutzer realistische Szenarien entwickelt, sollte die-ses Vorgehen auch realistische Hinweise auf die Wirtschaftlichkeit geben. Die Bewertung des Einflusses eines RFID-Systems erfolgt aber immer unter Ein-schluss der Effekte der intelligenten Planung: Der Wert der von RFID-Systemen bereitgestellten Information ist nicht unabhängig von der Qualität der Informa-tionsverarbeitung. Ohne die kontinuierliche Planung »verdummt« das System zu einem komplizierten Excel-Modell.7

Die Bewertung neuer Servicekonzepte, die vom RFID-Einsatz ermöglicht wer-den, ist eine Variante dieser Methode. Es wird untersucht, wie sich der Einsatz von RFID auf die Wirtschaftlichkeit eines Servicekonzeptes auswirkt. Da CESSAR das Logistiksystem des Luftverkehrscatering und nicht dessen Marktumgebung, sind Zusatzerträge, die z.B. von neuen Verkaufsdienstleistungen erzielt werden, externe Daten. Für eine Investitionsrechnung wird daher nur der effizienzseitige Teil (Zeiten und Kosten) analysiert.

Die Wiederverwendbarkeit bzw. das Transferpotenzial von Lösungen oder Kon-zepten für andere Anwendungsbereiche ist ein typisches Merkmal eines Multi-agentensystems. Sie beruht auf der Trennung von Middlewarefunktionen und Ontologie: Das im System nicht »fest verdrahtete« sondern in einer Datenbank abgelegte Wissen kann leicht geändert werden. Ein triviales Beispiel ist, dass aus einem Catering Highloader mit wenigen Änderungen ein Krankenwagen wird, dessen Agent weitgehend ähnliche Logiken und Verhandlungsstrategien nutzt und dessen Grundfunktionen (be- / entladen, fahren …) identisch sind. Mit zunehmender Detaillierung der Funktionen bzw. Prozesse geht diese direk-te Vergleichbarkeit zwar verloren (Liegend-Transporte und Kontrolle der Vitali-tätsfunktionen findet man im Catering kaum). Aber auch dann beschränken sich viele Anpassungen auf die Ontologie. Im Prototyp können diese Arbeiten allerdings nur von Softwareentwicklern ausgeführt werden.

7 Für einfache Planrechnungen zur Bewertung von Servicekonzepten wurde nebenher ein Excel-Modell mit über 50 Prozessen 350 Parametern entwickelt, das auch als Template für die Weiterverarbeitung exportierter CESSAR-Daten dient.


85


Weiterentwicklungen von CESSAR werden solche B-Pläne schon vorbereiten, wenn sie eine kritische Situation antizipieren. Im zweiten Beispiel wäre die Ver-spätung des eingehenden Flugs ein Grund, die im B-Plan vorgesehenen Maß-nahmen schon vorsorglich mit den anderen Diensten abzustimmen. So wird Zeit gewonnen, nicht zuletzt für die Dispatcher, die letztlich die Entscheidung treffen und vorbereiten müssen. Das System erfüllt dann auch im realen opera-tiven Betrieb den Wunsch des eingangs zitierten Supervisors. Ein entsprechend ausgebautes MAS kann B-Pläne nicht nur simulieren sondern auch aktiv nach möglichen kritischen Situationen und passenden B-Plänen suchen. Wichtige weitere Schritte der Entwicklung von CESSAR ist die Einführung einer modula-ren Architektur, die u.a. die Verteilung von Planungsbereichen wie Betrieb, Vor-feld und Netzwerk auf mehrere Rechner oder auf Multicoresysteme ermöglicht. Damit würden die Leistungsfähigkeit und die Erweiterbarkeit erheblich gestei-gert. U.a. können dann mehrere Dienste sich im aktiven Betrieb über die Not-wendigkeit und die Umsetzung von B-Plänen abstimmen. Ein weiteres Thema ist die Nutzeroberfläche. Sie ist im Prototyp hauptsächlich entwickler- und we-niger nutzerorientiert. Bedienung und Interpretation von Ergebnissen erfordern daher eine größere Erfahrung. Kritisch ist das besonders, wenn die Transferpo-tenziale von CESSAR z.B. für Krankenhausbetriebe plausibilisiert werden sollen.

86


3 Zusammenfassung und Ausblick

Die vorliegende Dokumentation zeigt die Ergebnisse des Forschungsprojektes iC-RFID. Ziel war die Entwicklung eines integrierten Airline-Catering-Gesamtsystems mit einem beispielhaften Aufbau und Vorführung an einem Demonstrator. Der Warenumlauf wurde ausgehend von der Buchung von Wa-ren im Preflight-Shop durch den Passagier, hin zur IT-gestützten Kommissionie-rung und Einlagerung in Trolleys bis ins Flugzeug und der Auslieferung an den Sitzplatz dargestellt. Der gesamte Umlauf wurde durch RFID-Tags transparent und verfolgbar und damit auch sicherer und fehlerfreier gestaltet. Ein elektroni-sches Datenaustauschformat ersetzt sämtliche papierbasierten Dokumente, die in dem Umlauf integriert sind. Darüberhinaus wurden innovative Servicekon-zepte an Bord des Flugzeuges entwickelt und vorgestellt. Die technische Um-setzung und Demonstration erfolgte durch einen Demonstrator, der beim Flug-zeugbauer Airbus aufgebaut und vorgeführt wurde.

Die iC-RFID-Ergebnisse beziehen sich auf die Anwendung von RFID im Cate-ringbereich. Eine sehr naheliegende Branche, die ebenso wie die Luftfahrt mit Trolleys arbeitet ist das Krankenhauscatering. Insbesondere ist an dieser Stelle die Fehlertoleranz gegenüber dem Luftfahrtbereich wesentlich geringer, da be-stimmte Patienten gewisse Nahrung gar nicht zu sich nehmen dürfen. Nicht nur die Nahrungsaufnahme auch die Kommissionierung von Medikamenten muss fehlerfrei, nachvollziehbar und patientengenau stattfinden.

Folgende Anwendungsgebiete zum Einsatz von RFID sind im Krankenhaus denkbar:

HACCP-Kontrolle (z.B. Temperatur) durch RFID-Chips mit zusätzlicher Sensorik;

Zuordnung der Medikamente zu den Patienten;

Logistikprozess bei wichtigen Materialien (z.B für OP -> Überwachung, Qualitätskontrolle, Sicherheit);

Anwendung in Krankenhauskantinen;

Diebstahlsicherung von Medikamenten und Krankenhauszubehör.

Der nächste naheliegende Anwendungsfall für RFID neben dem Krankenhaus-bereich ist das Catering im Bahntransportbereich. Auch hier ist das Tracking und Tracing der Cateringgüter von Interesse. Dabei sind neben der bloßen Ver-folgung von Gütern auch andere Ansätze von iC-RFID anwendbar. Im Moment sieht sich das Bahncatering mehr als ein fahrendes Restaurant, welches von den Passagieren besucht werden kann. Eine neue Umsetzung wäre bspw. die Mög-

Zusammenfassung und Ausblick

87


lichkeit der Vorab-Platzreservierung im Speisewagen. Dadurch kann man die Auslastung besser absehen und Passagiere könnten sich bereits vorab genauer mit dem Angebot beschäftigen. Des Weiteren sollte man den Passagieren die Möglichkeit geben Mahlzeiten vorab zu buchen, um ein besseres Vorratsmana-gement betreiben zu können. Auch das Buchen von Mahlzeiten während der Fahrt kann das Angebot attraktiver machen.

Das Projekt iC-RFID hat die Logistikkette des Airline-Catering mittels neuer Technologien in einem integrierten Gesamtdemonstrator dargestellt und neue Servicekonzepte und Geschäftsmodelle ausgearbeitet. Die Projektziele konnten vollständig erreicht werden. Für weiterführende Fragen und Erläuterungen der Ergebnisse stehen die Autoren und entsprechenden Organisationen jederzeit gerne zur Verfügung.

88


Partnervorstellung

autoID systems GmbH (www.georgkohl.de)

Die autoID systems GmbH ist eine Tochterfirma der GEORG KOHL Gruppe, und wurde im Jahr 2007 gegründet.

Als RFID-Experte rundet die autoID systems das »inspired by data«® Portfolio des Druck- und Datendienstleisters GEORG KOHL optimal ab, und bildet mit der Fokussierung auf die RFID-Technologie ein sicheres Standbein in einem zu-kunftsträchtigen Markt.

Kernaufgabe der autoID ist die Integration von RFID in bestehende Systeme und ist damit in den Bereichen Versand, Lager, Prozesssteuerung- und Automation in verschiedensten Branchen aktiv.

Die Leistungen der autoID systems reichen von der Beratung und Planung bei der Integration komplexer RFID-Systeme in Heterogene Strukturen, bis hin zur Auswahl der passenden Hardware und Programmierung individueller Soft-waremodule. Hierbei kann unser kompetentes Mitarbeiterteam auf die Erfah-rungen mehrfacher erfolgreich durchgeführter Projekte zurückgreifen.

B&W Engineering GmbH & Co. KG (www.bw-forschung.de)

Die B&W Engineering GmbH & Co. KG (B&W) ist ein in Bayern angesiedeltes KMU mit dem Schwerpunkt Forschung und Entwicklung im Luftfahrtbereich und arbeitet seit über 15 Jahren an innovativen und intelligenten Lösungen und Systemen für den Luftfahrt-Cateringbereich.

Neben dem Engagement in großen, integrierten Technologievorhaben auf EU-Ebene sowie nationalen Forschungsvorhaben im Rahmen der Luftfahrtfor-schungsprogramme als auch der bayerischen Luftfahrtforschungs- und -technologieförderung liegt der Schwerpunkt der Arbeiten in der Umsetzung von in Eigenleistung entwickelten Konzepten zur Serienreife und anschließen-der Markteinführung. Wir entwickeln, produzieren, verkaufen und warten qua-litativ hochwertige und zukunftssichere Produkte und darüber hinaus »Denken wir im Auftrag unserer Kunden.«

Unsere Stärken liegen unter anderem im Verständnis für die komplexen Prozes-se, beginnend beim Caterer am Flughafen über den Transport zum Flugzeug bis in die Galley, weiter mit dem Service der Crew am Passagier zu dessen Wohlbefinden und wieder zurück am Boden, wo alles begann, verbunden mit den Zusammenhängen im Arbeits-, Material- und Datenfluss als auch dem er-forderlichen Equipment.

Partnervorstellung

89


Durch die erfolgreiche Entwicklung und Markteinführung von Produkten, wie z.B. der Induction Heating Unit (Induktionsofen), sowie insbesondere der in nur gut zwei Jahren etablierten A-LogEqu-Familie (Aviation Logistic Equipment), ei-nem System hochisolierender Lager- und Transportbehälter für das Luftfahrtca-tering, konnte sich die B&W den Ruf eines effizienten und zuverlässigen Trei-bers für Innovationen erarbeiten. Dies wird durch die vielen national und inter-national gewonnenen Preise unterstrichen.

Dementsprechend folgen wir unserem wichtigsten Grundsatz: Listen, Think and Do.

EADS Innovation Works (www.eads.com)

Die EADS ist ein weltweit führendes Unternehmen der Luft- und Raumfahrt, im Verteidigungsgeschäft und bei den dazugehörigen Dienstleistungen mit einem Umsatz von 42,8 Milliarden Euro im Jahr 2009 und über 119.000 Mitarbeiter. Zur EADS gehören Airbus, Eurocopter, EADS Astrium und EADS Defence & Se-curity.

EADS Innovation Works ist das transnationale Forschung- und Entwicklungs-zentrum der EADS mit 700 Mitarbeitern an Standorten in Frankreich, Deutsch-land, Großbritannien, Spanien, Singapur, den USA, Russland, Indien und China.

Fachhochschule Köln (www.fh-koeln.de)

Die Fachhochschule Köln ist die größte Hochschule für Angewandte Wissen-schaften in Deutschland. 16.000 Studierende werden von rund 400 Professo-rinnen und Professoren unterrichtet. Das Angebot der elf Fakultäten und des Instituts für Tropentechnologie umfasst ca. 70 Studiengänge, jeweils etwa die Hälfte in Ingenieurwissenschaften bzw. Geistes- und Gesellschaftswissenschaf-ten sowie seit 2009 auch Angewandte Naturwissenschaften.

Das »Zentrum für Anwendungen intelligenter Systeme« und der »Forschungs-schwerpunkt Wissensmanagement« an der Fakultät für Wirtschaftswissenschaf-ten befassen sich in Forschung, Beratung und Lehre mit wissensbasierten, intel-ligenten Lösungen für das Management komplexer Dienstleistungssysteme. Damit verbinden sich Fragen zur operativen Strategie und Organisation, zu Ge-schäftsprozessen und unterstützenden Technologien sowie zu den zugrunde-liegenden kulturellen und personellen Infrastrukturen.

Fraunhofer IAO (www.iao.fraunhofer.de)

Das Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO bearbeitet aktuelle Fragestellungen im Bereich des Technologiemanagements. Insbesonde-re unterstützt das Institut Unternehmen und Verwaltungen dabei, die Potenzia-le zukunftsweisender Informations- und Kommunikationstechnologien und in-novativer Organisationsformen zu erkennen, individuell auf ihre Belange anzu-

Partnervorstellung

90


passen und konsequent einzusetzen. Die Bündelung von Management- und Technologiekompetenz gewährleistet, dass wirtschaftlicher Erfolg, Mitarbeiter-interessen und gesellschaftliche Auswirkungen immer gleichwertig berücksich-tigt werden.

Entsprechend den Anforderungen der Unternehmen entwickelt das Institut markt- und kundengerechte Technologiestrategien und Lösungen. Es plant und begleitet den Technologieeinsatz im Gesamtunternehmen, in Geschäftsberei-chen und in Einzelprojekten. Ganzheitliche Lösungen werden in multidis-ziplinären Teams entwickelt, in denen Ingenieure, Informatiker, Wirtschafts- und Sozialwissenschaftler eng zusammenarbeiten.

Fraunhofer IAO bearbeitet jährlich über 100 Forschungs- und Projektvorhaben für die öffentliche Hand und die Industrie. Einige Projektvorhaben haben Volu-men von mehreren Millionen Euro. Die Ergebnisse der Projekte werden in einer Vielzahl von Veröffentlichungen und Studien publiziert.

Das Competence Center Electronic Business des Fraunhofer IAO berät Unter-nehmen bei der Konzeption und Umsetzung innovativer E-Business- und IT-Lösungen. Um Geschäftsstrategien bestmöglich umzusetzen, werden innovati-ve Konzepte, Internet-Plattformen und IT-Systeme genutzt. Mit Hilfe Fraunho-fer-eigener »intelligenter« IT-Lösungen können Geschäftsprozesse entworfen, überwacht und gesteuert werden. Durch den Einsatz von Methoden des »Web Mining« werden Unternehmen zudem dabei unterstützt, innovationsrelevante Informationen im Internet zu finden.

In ergänzenden Forschungsprojekten werden neue Methoden und Technolo-gien für das »Internet der Dienste« und servicebasierte Lösungen, für Unter-nehmensportale, Partner- und Prozessintegration entwickelt. Auf Basis von »Green IT« realisiert das Competence Center energieeffiziente Systeme der Zu-kunft.

Fraunhofer PYCO (www.pyco.fraunhofer.de)

Die Fraunhofer-Einrichtung Polymermaterialien und Composite (FhE PYCO) entwickelt hochvernetzte Polymere (Duromere) für Anwendungen in der Ver-kehrstechnik, speziell in der Luftfahrt, und in der Informations- und Kommuni-kationstechnik. Schwerpunkte der Entwicklung sind beispielweise faserverstärk-te Polymere, Sandwichstrukturen, bistabile Displays, optisch integrierte Bauele-mente oder Barriere-schichten. Ein Alleinstellungsmerkmal der Forschungsein-richtung besteht in der Abdeckung der gesamten Entwicklungskette vom Mo-nomer bis zum Bauteil. Auch Methoden-Entwicklungen wie das optical crack tracing (OCT) zur Ermittlung der Bruchzähigkeit, die Nano-TMA/TGA/DVS zur thermophysikalischen Untersuchung (ultra-) dünner Polymerschichten oder ein Permeationsmessplatz zur Charakterisierung von Barrierematerialien erfahren rege Nachfrage durch Hersteller und Anwender.

Partnervorstellung

91


MGS – Modular Galley Systems AG (www.mgs-aircraft.com)

Die MGS – Modular Galley Systems AG ist ein Unternehmen der Luftfahrtin-dustrie und entwickelt und vertreibt neu entwickelte Galley-Inserts, insbesonde-re mikroprozessorgesteuerte Induktionsöfen, die neuartige Servicemöglichkei-ten für die Versorgung von Passagieren in Flugzeugen ermöglichen.

Neben der Entwicklung von innovativen Produkten ist die MGS Mitglied im ARINC Commitee und entwickelt in diesem Rahmen gemeinsam mit anderen Lieferanten sowie Airbus und Boeing einen neuen übergreifenden Standard für Bordküchengeräte (Galley Inserts) ARINC 810 /812. Ferner verfügt die MGS über große Erfahrung im Bereich der Entwicklung von Software Applikationen und Tools sowie Elektronik.

Die MGS ist seit 2005 TÜV-zertifiziert (EN 9100:2003) und ein vom Luftfahrt-Bundesamt zugelassener Herstellungsbetrieb (EASA part 21G) für Bordküchen-geräte. Von den ITCA Awards für Innovationen im Luftfahrtcatering hat MGS in 2005 den Preis in Bronze für die IHU und in 2006 den Preis in Gold für die Hea-ting Box gewonnen.

iC-R

FID

BP

MN

-Prozessd

iagramm

Dashboard(AIS)

Flugplan

generieren

Flugplan

verteilen

Flugplan

visualisieren

Pre-F

light Bestellung

aufnehmen

Shop-O

rdergenerieren

Bestückungsliste

verteilen

Bestückunvisualisi

Bestückungsliste

generieren

Shop-O

rder verteilen

Shop-O

rder visualisieren

Shop-O

rder ablegen

Middleware(AIS)

MAS(FHK)

3 -B

estückungsliste1 -

Flugplan

2 -S

hop-Order

1 -F

lugplan3 -

Bestückungsliste

2 -S

hop-Order

eCommerce Platform

(IAO)

2 -S

hop-Order

Caterer I(MGS)

Caterer II(B&W)

Bistabiles Display(PYCO)

Highloader(AIS)

B&W Inventory Control(B&W)

RFID GatesAC Door / Flexzone

(EADS M)

EADS Server / Crew HMI

(EADS HH)

In-FlightControl Unit

(MGS)

3 -B

estückungsliste

Szenario

definierenS

imulation

starten

scheidin

Schreibmaschinentext

scheidin


Anhang: BPMN-Prozessmodell

scheidin


92

Bestückungsliste visualisieren

Trays

bestücken

Trolley aus

Equipm

entlager holen

RF

ID-E

vent verteilen

RF

ID-E

vent visualisieren

Trolley m

it Trays

und Items beladen

Trays m

itR

FID

labeln

Trays von C

aterer I (M

GS

) empfangen

Trays an C

aterer II (B

&W

) weiterreichen

Digital F

light Label (D

FL) beschreiben

Trolley-T

ags beschreiben

4 -T

rolley aus Equipm

entlager(R

FID

-Event)

Items m

itR

FID

labeln

5 -Ladeliste

(Trays)

Daten für D

igital Flight

Label (DF

L) liefern

6 -D

aten für DF

L

4 -T

rolley aus Equipm

entlager(R

FID

-Event)

6 -D

aten für DF

L

Ladeliste (Trays)

verteilen

5 -Ladeliste

(Trays)

Ladeliste ablegen

Daten auf D

FL

visualisieren

el n

Trolley ins

Ladeliste verteilen7a -

Ladeliste

7a -Ladeliste

Abgleich Ladeliste / B

estückungsliste

DF

L9 -

Troll

Ladelisten zusam

menführen

Nachlieferungsauftrag

verteilen

8 -N

achlieferungsauftrag

8 -N

achlieferungsauftrag

Fehlladung

OK

Ladeliste visualisieren

7b -Ladeliste

Ladeliste verteilen7b -

Ladeliste7b -

Ladeliste

Transportauftrag

verteilen

Trolley au

Zw

ischenlager

Transportauftrag visualisieren

Trolley in Z

wischenlager

schieben

RF

ID-E

vent verteilen

RF

ID-E

vent visualisieren

Statusupdate

Transportauftrag

updaten

10 -T

ransportauftrag

Transportauftrag

empfangen

Statusupdate

Ram

pe anfahren

9 -T

rolley in Zw

ischenlager(R

FID

-Event)

9 -T

rolley in Zw

ischenlager(R

FID

-Event)

9 -T

rolley in Zw

ischenlager(R

FID

-Event)

10 -T

ransportauftrag

10 -T

ransportauftrag

Transportauftrag

empfangen

Trolley aus

Zw

ischenlager holen

RF

ID-E

vent verteilen

RF

ID-E

vent visualisieren

Trolleys

transportierenT

rolleys ausladen

RF

ID-E

vent verteilen

RF

ID-E

vent visualisieren

Trolley verlässt

Zw

ischenlager

RF

ID-E

vent verteilen

RF

ID-E

vent visualisieren

Statusupdate

Statusupdate

Statusupdate

Trolley in H

ighloader einladen

11 -T

rolley aus Zw

ischenlager(R

FID

-Event)

11 -T

rolley aus Zw

ischenlager(R

FID

-Event)

11 -T

rolley aus Zw

ischenlager(R

FID

-Event)

12 -T

rolley in Highloader

(RF

ID-E

vent)

12 -T


(RF

ID-E

vent)

12 -T


(RF

ID-E

vent)

13 -T

rolley aus Highloader

(RF

ID-E

vent)

13 -T


(RF

ID-E

vent)

13 -T


(RF

ID-E

vent)

Korrekte E

ntnahme

prüfen und visualisieren

RF

ID-E

vent visualisieren

Soll/Ist-A

bgleich

Trolley an A

C D

oor registrieren

RF

ID-E

vent verteilen

RF

ID-E

vent visualisieren

Galley inventarisieren

Trolley an F

lexzone registrieren

Statusupdate

Statusupdate

14 -T

rolley in AC

Door

(RF

ID-E

vent)

14 -T

rolley in AC

Door

(RF

ID-E

vent)

14 -T

rolley in AC

Door

(RF

ID-E

vent)

Galleyinventarisierung

auslösen

15 -Inventory List

Trolley-R

egistrierung visualisieren

Trolley-R


gleich

Inventory visualisieren

Ordable Item

s updaten

Inventory visualisieren

Ordable Item

s updaten

Tracking Inventory

updatenItem

aus iTrolley

entnehmen

Rem

ote Monitoring &

C

ontrol

Oven activity

-Inventory List

15 -Inventory List(U

pdate)

16 -O

ven Rem

ote Control

(AR

INC

)17 -

Oven S

tatus(A

RIN

C)

Info Ground D

elivery überm

itteln

Info Ground D

elivery visualisieren

Info Ground D

elivery verteilen

Defekten T

rolley identifizieren

Defekten T

rolley m

arkieren

Trolley an A

C D

oor registrieren

RF

ID-E

vverrteile

usC)

Auslieferung P

re-und In-

Flight C

omm

erce anstoßen

18 -Info G

round Delivery

18 -Info G

round Delivery

19 -M

aintenance Nachricht

20 -T

rolley aus AC

Door

(RF

ID-E

vent)

20 -T

rolley aus(R

F

Trolley-R


RF

ID-E

vent visualisieren

RF

ID-E

vent verrteilen

20 -T

rolley aus AC

Door

(RF

ID-E

vent)

Trolley registrieren und

Maintenance-F

lag prüfen

21 -T

rolley auf Eingangsram

pe(R

FID

-Event)

RF

ID-E

vent visualisieren

RF

ID-E

vent verteilen

21 -T

rolley auf Eingangsram

pe(R

FID

-Event)

Ok

Trolley in E

quipmentlager

schiebenT

rolley reparieren(R

eset Maintenance-F

lag)D

efekt

RF

ID-E

vent verteilen

RF

ID-E

vent visualisieren

22 -T

rolley in Equipm

entlager(R

FID

-Event)

22 -T

rolley in Equipm

entlager(R

FID

-Event)

egistrierung lisieren

Prozess-S

tart

Prozess-E

nde

Aktivität

Message-E

mpfang (als S

tart eines Prozesses)

Message-E

mpfang (w

ährend eines Prozesses)

Message-S

endung (während eines P

rozesses)

Message-S

endung (als Ende eines P

rozesses)

Dokum

ent

Prozessfluß

Informationsfluß

Assoziation

Beschreibung

Verw

endete E

lemente d

er Busin

ess Process M

odellin

g Notation

(BP

MN

)

Exclusive G

ateway

Tim

er (als Start eines P

rozesses)

Tim

er (während eines P

rozesses)

F R A U N H O F E R - I N S T I T U T F Ü R A R b E I T S w I R T S c H A F T U N d O R g A N I S AT I O N I A O

IntellIgentes CaterIng mIt rFID

PROzESSE, LOgISTIk UNd INTEgRATION NEUER TEcHNOLOgIEN Im LUFTFAHRTcATERINg

Logistisch organisierte Servicesysteme mit ihrer entsprechenden Vernetzung können heutzutage in vielen Bereichen des alltäglichen Lebens angetroffen werden. Charakterisiert werden diese durch einen Grundprozess und eine Vielzahl von Prozessteilnehmern. Ob nun in einem Flugzeug die Passagiere einen Cateringservice erfahren, in einem Großkrankenhaus der Speiseservice organisiert wird oder im Bahnwesen die zugfahrenden Kunden bedient werden, die Prinzipien und Prozesse der Warenströme sind stets ähnlich.

Die vorliegende Broschüre zeigt wesentliche Ergebnisse des Projektes iC-RFID, das vom Bundesministerium für Wirtschaft und Technologie (BMWi) gefördert wurde. Ziel dieses Projektes war die Entwicklung eines integrierten Airline-Catering-Gesamtsystems.

Dargestellt werden Prozessmodelle für das integrierte Catering, Software-technologien zur Integration und Überwachung sowie intelligente Planungs- und Steuerungssysteme. Des Weiteren werden neue Technologien wie RFID-basierte Trolleys und Kommissionierstationen sowie innovative Konzepte für das Preflight-Shopping und Kabinenservices vorgestellt.

ISBN 978-3-8396-0206-5

9 7 8 3 8 3 9 6 0 2 0 6 5

Inte

llIg

ente

s C

ate

rIn

g m

It r

FID

IC-RFID_lay1.indd 1 17.11.2010 15:21:39

Intelligentes Catering mit RFID - Fraunhofer...5 Fraunhofer IAO Intelligentes Catering mit RFID...

Documents

Transcript of Intelligentes Catering mit RFID - Fraunhofer...5 Fraunhofer IAO Intelligentes Catering mit RFID...