Konzept eines Cyber-Physischen Logistiksystems in einer schlanken Produktion am Beispiel einer Reihenfertigung mit Kanban

Inhaltsverzeichnis

Abstract

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Potential der Informations- und Kommunikationstechnologie in der Intralogistik
1.1.1 Einfluss und Potential von eingebetteten Computersystemen in der heutigen Zeit
1.1.2 Vorteile und Grenzen der schlanken Produktion
1.1.3 Verbindung von CPS und schlanker Produktion zu CPLS
1.2 Fachkonzept für ein CPLS als Ziel der Arbeit
1.2.1 Status Quo in der Literatur
1.2.2 Ziel und Abgrenzung der Arbeit
1.3 Sechs Bestandteile der Arbeit

2 Grundlagen
2.1 CPS: Vernetzte, eingebettete Systeme
2.1.1 Historische Entwicklung von CPS
2.1.2 Definition und Abgrenzung von artverwandten Begriffen
2.1.3 Definition und Bestandteile eines CPS
2.1.4 Zusammenfassung der bestehenden Erkenntnisse zu CPS
2.2 CPLS: Ein CPS in der Logistik
2.2.1 Vorgehen zur Definition eines CPLS
2.2.2 Definition der Logistik und dessen Entwicklung
2.2.3 Bestehende Definitionen für ein CPLS
2.2.4 Zusammenführung der Logistik- und CPS-Definition in einem CPLS
2.3 Design von CP(L)S: Bestehende Vorgehensmodelle und Architekturen
2.3.1 Bestehende Vorgehensmodelle für die Entwicklung von CP(L)S
2.3.2 Bestehende Referenzarchitekturen für den Aufbau von CP(L)S
2.3.3 Bestehende Modellierungsnotationen für die Beschreibung von CP(L)S
2.3.4 Zusammenfassung des Status Quo zur Entwicklung von CP(L)S
2.4 Schlanke Produktion: Das Produktionssystem von Toyota
2.4.1 Historische Entwicklung der schlanken Produktion
2.4.2 Methoden und Prinzipien der schlanken Produktion
2.4.3 Zusammenfassung der schlanken Produktion
2.5 Kanban: Die Produktionssteuerung der schlanken Produktion
2.5.1 Stellenwert und Aufgaben von Kanban in der schlanken Produktion
2.5.2 Funktionsweise des Kanban-Systems
2.5.3 Unterschiedliche Arten von Kanban-Systemen
2.5.4 Abgrenzung von eKanban und CPLS
2.5.5 Zusammenfassung des Kanban-Systems

3 Anforderungen an ein CPLS und das Vorgehensmodell
3.1 Festlegung von ALEM-P als verwendetes Vorgehensmodell
3.2 Ziele und Schwachstellen der schlanken Produktion
3.2.1 Ziele der schlanken Produktion und deren Zusammenhänge
3.2.2 Heutige Schwachstellen der schlanken Produktion
3.3 Bestandteile und Designanforderungen an ein CPLS
3.3.1 Notwendige Elemente eines CPLS
3.3.2 Anforderungen an das Design von CPLS
3.4 Lastenheft für ein CPLS in einer schlanken Produktion
3.4.1 Übergeordnete Aufgabenbeschreibung eines CPLS
3.4.2 Anwendungsfälle für ein CPLS
3.4.3 Funktionale und nicht-funktionale Anforderungen an das CPLS

4 Konzept für ein CPLS in der schlanken Produktion
4.1 Schritt 1: Vertiefen der Ziele
4.2 Schritt 2: Festlegen der Struktur
4.3 Schritt 3: Zuordnen der Fähigkeiten je Objekt
4.4 Schritt 4: Beschreiben des Prozesses
4.4.1 Zielsetzung des Schrittes und Erläuterung des Vorgehens
4.4.2 Beschreibung der Ergebnisse
4.4.3 Zusammenfassung des Prozesses
4.5 Schritt 5: Identifizieren der zu treffenden Entscheidungen
4.5.1 Zielsetzung des Schrittes und Erläuterung des Vorgehens
4.5.2 Beschreibung der Ergebnisse
4.5.3 Zusammenfassung der zu treffenden Entscheidungen
4.6 Schritt 6: Bestimmen der notwendigen Informationen
4.6.1 Zielsetzung des Schrittes und Erläuterung des Vorgehens
4.6.2 Beschreibung der Ergebnisse
4.6.3 Zusammenfassung der benötigten Informationen
4.7 Schritt 7: Beschreiben der Kommunikation
4.7.1 Zielsetzung des Schrittes und Erläuterung des Vorgehens
4.7.2 Beschreibung der Ergebnisse
4.7.3 Zusammenfassung der Kommunikation im CPLS

5 Übertragung des CPLS auf ein Beispielunternehmen
5.1 Beschreibung der Ist-Situation
5.2 Übertragung des Konzeptes auf das Beispielunternehmen

6 Fazit
6.1 Zusammenfassung der Arbeit
6.2 Kritische Betrachtung der Ergebnisse und des Vorgehens
6.3 Ausblick und weiterer Forschungsbedarf für CPLS

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

Abbildung 1 Entwicklung des Verbraucherpreisindex für PCs und Notebooks 2007-2012

Abbildung 2 Struktur der Arbeit

Abbildung 3 Schematische Darstellung eines CPS

Abbildung 4 Gegenüberstellung Phasenmodell des Systems Engineering und Vorgehensmodell für selbststeuernde Logistiksysteme

Abbildung 5 Das ALEM-P Vorgehensmodell

Abbildung 6 SOA-basierte CPS-Architektur

Abbildung 7 Architektur für ein Multiagentensystem in der Intralogistik

Abbildung 8 Event- und multiagentenbasierte Architektur für CPS auf Grundlage von INGENIAS

Abbildung 9 Das TPS-Haus

Abbildung 10 Funktionsweise des Pull-Prinzips im Kanban-System

Abbildung 11 Arbeitsweise des Transportsystems („Small Trains“)

Abbildung 12 Vorgehensmodell zur Konzepterstellung für das CPLS in einer schlanken Produktion

Abbildung 13 Zusammenspiel der Ziele des TPS und mögliche Messgrößen

Abbildung 14 Schwachstellen der schlanken Produktion

Abbildung 15 Skizze für das Zusammenspiel der Elemente eines CPLS

Abbildung 16 Übersicht der Designanforderungen an ein CPLS

Abbildung 17 Anwendungsfalldiagramm für ein CPLS in einer schlanken Produktion

Abbildung 18 Schritt 1: Klassendiagramm der Ziele

Abbildung 19 Schritt 2: Klassendiagramm der Struktur

Abbildung 20 Schritt 3: Klassendiagramm der Fähigkeiten

Abbildung 21 Schritt 4: Ausschnitt des Aktivitätsdiagramms für den Standard-Prozess

Abbildung 22 Schritt 4: Zustandsdiagramm für das Planungssystem

Abbildung 23 Schritt 4: Zustandsdiagramm für das LHM

Abbildung 24 Schritt 4: Zustandsdiagramm für die Lagerfläche

Abbildung 25 Schritt 4: Zustandsdiagramm für das Transportsystem

Abbildung 26 Schritt 4: Zustandsdiagramm für das KVP-System

Abbildung 27 Schritt 5: Ausschnitt der Entscheidungen des Planungssystems als Aktivitätsdiagramm

Abbildung 28 Schritt 5: Ausschnitt der Entscheidungen des LHM als Aktivitätsdiagramm

Abbildung 29 Schritt 5: Ausschnitt der Entscheidungen der Lagerfläche als Aktivitätsdiagramm

Abbildung 30 Schritt 5: Ausschnitt der Entscheidungen des Transportsystems als Aktivitätsdiagramm

Abbildung 31 Schritt 5: Entscheidungen des KVP-Systems als Aktivitätsdiagramm

Abbildung 32 Schritt 6: Wissen im CPLS als Klassendiagramm

Abbildung 33 Schritt 7: Ausschnitt der Kommunikation im CPLS als Sequenzdiagramm

Abbildung 34 Beispiel für einen Bericht zur Identifikation von Verbesserungspotentialen

Abbildung 35 Zusammenhang der Diagramme und Sichten (Quelle: Eigene Darstellung in Anlehnung an Kolditz, 2009)

Tabellenverzeichnis

Tabelle 1 Zuordnung der Unterkapitel zu den Sichten und Modellen von ALEM

Tabelle 2 Einteilung der UML-Diagramme und deren Zweck

Tabelle 3 Die acht Arten der Verschwendung (Muda) inkl. Beispiel für deren Auswirkung

Tabelle 4 Anforderungen an das Vorgehen und deren Erfüllung durch bestehende Vorgehensmodelle

Tabelle 5 Auszug aus den funktionalen und nicht-funktionalen Anforderungen

Tabelle 6 Gruppierung der Klassen im CPLS

Tabelle 7 Entscheidungssituation „Prüfe, ob die Fertigungsaufträge bis zum Liefertermin erfüllt werden können"

Tabelle 8 Entscheidungssituation „Überwache Standort und Inhaltsmenge"

Tabelle 9 Entscheidungssituation „Prüfe Anzahl und Art der LHM auf der Lagerfläche“

Tabelle 10 Entscheidungssituation „Routenoptimierung durchführen"

Tabelle 11 Entscheidungssituation „Route abfahren“

Tabelle 12 Ausschnitt der Wissenslandkarte für das CPLS (Anm.: E=erstellt; V=verwendet)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Potential der Informations- und Kommunikationstechnologie in der Intralogistik

1.1.1 Einfluss und Potential von eingebetteten Computersystemen in der heutigen Zeit

In den letzten Jahrzehnten veränderte die Informations- und Kommunikationstechnologie (IKT) unseren Alltag: Büroarbeitsplätze ohne PC sind heutzutage kaum noch vorstellbar, statt mit Landkarten navigieren wir mit Navigationssystemen, bei Fragen „googeln" wir im Internet und digitale Nachrichten, gelesen auf einem Tablet-PC, verdrängen die gedruckte Tageszeitung (vgl. Bundesverband Deutscher Zeitungsverleger e.V., 2012a, 2012b; Drüge, 2012: S. 5). Die IKT unterstützt uns bei der Bewältigung unseres täglichen Lebens und ist für viele ein fester Bestandteil dessen geworden.

Begründet wird die voranschreitende Integration der IKT in das alltägliche Leben durch die Entwicklung immer kleinerer Computersysteme bei gleichzeitigem Preisverfall (vgl. Broy, 2010: S. 19; Mattern, Floerkemeier, 2010: S. 107). Beispielsweise kostet ein handelsübliches Notebook im Vergleich zu 2005 nur noch drei Viertel des Preises und Smartphones sind bereits für unter 100 Euro erhältlich (vgl. Labs, 2012; Statistisches Bundesamt, BITKOM, 2013). Auch wenn die Anschaffungskosten für einen durchschnittlichen Computer in den letzten Jahren langsamer sanken, sanken sie 2012 immer noch mehr als zehn Prozent im Vergleich zum Vorjahr (siehe Abbildung 1). IKT wurde so über die Zeit für immer mehr Anwender erschwinglich und die Amortisationszeit von IKT-Investitionen in Unternehmen verkürzte sich. Neben dem Preisverfall fand in der IKT eine ausgeprägte Miniaturisierung statt. Mit 12,4 x 5,9 x 0,8 cm ist das Apple iPhone 5 kleiner als manch ein Taschenrechner, verfügt aber über die CPU und Speicherausstattung eines Oberklasse-Desktop-PCs aus dem Jahr 2005 (vgl. Apple Inc., 2013; Ziegler, 2006).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Entwicklung des Verbraucherpreisindex für PCs und Notebooks 2007-2012

(Quelle: Statistisches Bundesamt, BITKOM, 2013)

Darüber hinaus ist das Apple iPhone 5 auch ein Beispiel für den technischen Fortschritt in der IKT. Ein integrierter Akku zusammen mit mobilem Internet und W-LAN ermöglichen es dem Nutzer, nahezu unabhängig von seinem Standort auf das Internet zuzugreifen. Die Geräte können durch Kamera, GPS, Lage- und Helligkeitssensoren die Umwelt wahrzunehmen und durch Nutzung des eingebauten Lautsprechers oder Vibrationsmotors darauf reagieren.

Computer sind heutzutage nicht nur in Smartphones zu finden. Ob als Antiblockiersystem in PKWs, Antikollisionssystem in Flugzeugen, Steuerung für das heimische Heizungssystem oder als Regelungs- und Überwachungssystem von Produktionsanlagen - in einer Vielzahl von alltäglichen Gegenständen sind Computer bereits unsichtbar eingebettet. Sie übernehmen hierbei nicht nur Aufgaben, die zuvor von mechanischen Systemen wahrgenommen wurden. Durch Sensoren, Aktoren und eine Vernetzung mit anderen Systemen sind sie in der Lage, selbstständig Entscheidungen zu treffen, mit ihrer Umwelt zu interagieren und so den Menschen bei der Bewältigung von Problemen zu unterstützen.

Die Erforschung von überall unsichtbar eingebetteten Computersystemen erfolgt in der wissenschaftlichen Literatur bereits seit 1991 (siehe Weiser, 1991). Begriffe wie „Internet of Things" (IoT; dt.: Internet der Dinge), „Ubiquitous Computing" oder „Embedded Systems" beschreiben seit dem die Erforschung von intelligenten, in Gegenständen integrierten Computersystemen aus unterschiedlichen Gesichtspunkten. Unter anderem von Lee geprägt, existiert seit 2006 auch der Begriff des „Cyber-Physical System" (CPS; dt.: Cyber-Physisches System). Kennzeichnend für CPS ist ebenfalls die Einbettung von Computersystemen in physische Objekte, sodass intelligente Systeme entstehen. Im Gegensatz zu den zuvor genannten Begriffen liegt hier der Fokus insbesondere auf der Vernetzung untereinander und mit dem Internet sowie auf der Betrachtung von Prozessen. (vgl. Broy, 2010: S. 26; Lee, 2008: S. 4)

Obwohl CPS bis dato nur in Ansätzen erforscht sind, wird ihnen schon jetzt ein großes Potential nachgesagt. Ob in der Automobilbranche, Medizintechnik, Energiewirtschaft oder im Maschinen- und Anlagenbau, in fast allen Bereichen wurden bereits Anwendungsfalle für CPS identifiziert, welche bestehende Produkte und Dienstleistungen verbessern oder neue Geschäftsmodelle ermöglichen (siehe beispielsweise Asare et al., 2012; Geisberger, Broy, 2012: S. 22-23). Insbesondere die Möglichkeit, CPS in Unternehmensprozessen einzusetzen, hat in Deutschland Interesse geweckt. Unter dem Begriff „Industrie 4.0" wird bereits die nächste industrielle Revolution prognostiziert, welche auf dem Einsatz von intelligenten, vernetzten Maschinen basiert. Dass es sich hierbei nicht nur um einen temporären Trend handelt, zeigt die Investitionsbereitschaft der Bundesrepublik Deutschland: Im Rahmen der „Hightech-Strategie Industrie 4.0" stellt sie 200 Millionen Euro bereit, um CPS und CPS-ähnliche Systeme für die Industrie zu erforschen. (vgl. Bundesministerium für Bildung und Forschung, 2013)

1.1.2 Vorteile und Grenzen der schlanken Produktion

Neben dem Einsatz in der Produktion wurden auch Anwendungsfälle für CPS in der Logistik identifiziert. Eine autonome, dezentral organisierte Logistik könnte beispielsweise dazu beitragen, die zur Vermeidung von Produktionsstörungen notwendige und als heutige Kernkompetenz der Logistik identifizierte Flexibilität zu erhöhen. Ferner könnte ein CPS selbstständig auf Planänderungen reagieren und individuellere Produkte umsetzen. Eine höhere Transparenz sowie die Reduzierung des Fachkräftemangels durch Automatisierung sind weitere Potentiale (vgl. Geisberger, Broy, 2012: S. 23; Günthner, ten Hompel, 2010: S. 15-21). Aufgrund des überwiegenden Anteils an den Logistikkosten, dem geringen Beitrag zur unmittelbaren Wertschöpfung im Produkterstellungsprozess und der wichtigen Koordinationsfunktion für den innerbetrieblichen Warenfluss ist die Intralogistik ein Bereich, in dem Verbesserungen durch CPS einen großen Nutzen versprechen (vgl. Arnold et al., 2008: S. 22-26, 48; Dickmann, 2009: S. 147-148; Takeda, 2006: S. 88).

In diesem Zusammenhang erkannte schon Ohno in den 1960ern das Einsparpotential in der Intralogistik. In dem von ihm mit gestaltetem Toyota Production System (TPS; dt.: Toyota Produktionssystem) führte er Prinzipien und Methoden zusammen, welche die Flexibilität der Produktion erhöhen und Kosten durch geringere Lager- und Umlaufbestände sowie Verschwendung in der Produktion verringern (siehe Ohno, 1988a). Das heute auch unter dem Namen schlanke Produktion (engl.: Lean Production) bekannte Modell erfreut sich einer weiten Verbreitung, da die verwendeten Methoden und Prinzipien aufeinander abgestimmt und einfach zu implementieren sind. Der Erfolg des TPS bei Toyota sowie auch in heutigen Unternehmen noch mögliche Einsparungen von bis zu 70 % der Materialbestände, 75 % der Durchlaufzeit und eine um 25 % höhere Produktivität zeigen die Vorteilhaftigkeit der Lean Production gegenüber anderen Produktionssystemen. (vgl. Dickmann, 2009: S. 19; Mählck, Panskus, 1995: S. 11; Womack et al., 1990a: S. 236)

Kernelement der schlanken Produktion ist das Kanban-System, welches die Elemente des TPS vereint. Es setzt die nachfrageorientierte Produktion um, steuert den Takt der Fertigung und stellt sicher, dass benötigte Materialien zum Bedarfstermin an den Arbeitsplätzen eintreffen. In seiner ursprünglichen Form kommt diese Produktionssteuerung vollkommen ohne IT aus und verwendet lediglich Behälter und Karten, um Transport- und Fertigungsaufträge auszulösen. Beim elektronischen Kanban-System (eKanban-System), einer Weiterentwicklung vom Kan- ban-System, wird ein Computersystem eingesetzt, um Behälter und Karten darüber abzubilden. (vgl. Lage Junior, Godinho Filho, 2010: S. 16; Ohno, 1988a: S. 54-65)

Doch auch wenn sich durch die Lean Production erhebliche Verbesserungen der Logistikkennzahlen erzielen lassen, stößt das System heutzutage an Grenzen. Die Verringerung der Materialbestände erreicht das TPS durch eine Just-in-Time-Anlieferung (JiT) und Vermeidung von Pufferbeständen an den Arbeitsplätzen. Die Umstellung auf eine nachfrageorientierte Fertigung stellt darüber hinaus sicher, dass nur die tatsächlich benötigten Fertigwaren produziert werden. Um unter diesen Umständen einen Versorgungsengpass und damit verbundene Wartezeiten zu vermeiden, führte Ohno eine geglättete, getaktete Produktion ein. Eine schlanke Produktion ist somit nur bedingt in der Lage, auf schwankende Nachfragen, wie sie in den heutigen Käufermärkten vorliegen, zu reagieren. Die Fertigungslinie muss deshalb über Zwischenlager oder eine weitere Steuerungsmethode von der Nachfrage entkoppelt werden, was wiederum zu erhöhten Beständen oder organisatorischem Mehraufwand durch eine zusätzliche Produktionsplanung führt. Das Kanban-System ist außerdem nicht für den Einsatz bei variantenreichen Produkten oder werkstattähnlichen Fertigungen geeignet. Verlorene Behälter oder Karten sind darüber hinaus eine Fehlerquelle und eine bei Auslastungsschwankungen notwendige Erhöhung oder Verringerung der Behälter oder Karten ist aufwändig. (vgl. Dickmann, 2009: S. 24-25, 146-147, 163, 230-231, 406; Erlach, 2007: S. 17; Ohno, 1988a: S. 53+60-61)

1.1.3 Verbindung von CPS und schlanker Produktion zu CPLS

Die Anwendung von CPS in der Intralogistik ist zusammenfassend ein vielversprechender Ansatz, um Verbesserungen zu erzielen. Sowohl CPS als auch die schlanke Produktion erhöhen die Flexibilität und setzen eine dezentrale Steuerung um. Unter dem Begriff „Autonomation" forderte bereits Ohno auf, den Maschinen Intelligenz zu verleihen. Maschinen müssen so gestaltet werden, dass sie selbstständig Probleme und Prozessabweichungen erkennen und auf diese aufmerksam machen, um eine höchstmögliche Produktqualität zu erreichen. (vgl. Ohno, 1988a: S. 32-34) Der Einsatz von CPS in der schlanken Produktion wäre die Umsetzung dieser Forderung: Maschinen, welche Abweichungen durch Einsatz von vernetzten Computern noch schneller melden, Ursachen selbstständig analysieren und Maßnahmen automatisch in Absprache mit anderen Maschinen einleiten. Scholz-Reiter et al. (2006) haben darüber hinaus in Simulationen erarbeitet, dass eine selbststeuernde Logistik in einer komplexen Produktion gegenüber zentralen Planungssystemen vorteilhaft ist.

Ein Cyber-Physisches Logistiksystem (CPLS), also die Übertragung von intelligenten, vernetzten Systemen auf die Logistik, könnte den Einsatz von Lean Production in komplexeren Produktionsabläufen, wie beispielsweise variantenreichen Produkten oder nicht vollständig nivellierten und getakteten Fertigungslinien, unterstützen. Zudem könnten CPLS in der Lage sein, die Flexibilität durch eine geringere Reaktionsgeschwindigkeit und selbstständige Entscheidungen zu erhöhen. Durch das selbstständige und zeitnahe Lösen von Fehlern würde ein CPLS ferner ermöglichen, Zeit- und Bestandspuffer zu reduzieren. Ein CPLS würde somit die Effizienz der schlanken Produktion erhöhen und dessen Einsatzgebiete erweitern.

1.2 Fachkonzept für ein CPLS als Ziel der Arbeit

1.2.1 Status Quo in der Literatur

Wie ein solches CPLS für eine schlanke Produktion zu gestalten ist, wurde bis dato noch nicht erforscht. Auch wenn das ursprünglich von Ohno entworfene TPS heute noch in der Praxis weit verbreitet ist und spätestens seit den 1990ern in der Wissenschaft erforscht wird, bestehen auf dem Gebiet der CPS erst wenige allgemeingültige Erkenntnisse und Praxiserfahrungen. In der wissenschaftlichen Literatur finden sich erste Anwendungsfälle, an denen oftmals aus der Softwareentwicklung und den Embedded Systems stammende Vorgehensmodelle und Architekturen erprobt wurden (siehe beispielsweise Lin et al., 2010; Wan et al., 2010; Zhai et al., 2012). Bei den Ergebnissen handelt es sich allerdings in vielen Fällen um Prototypen oder Zwischenstände aktueller Forschungsvorhaben. Die Erkenntnisse zu einem CPLS beschränken sich auf zwei Definitionen in der Literatur. Zur Übertragung von CPS und CPLS auf eine schlanke Produktion existieren noch keine Arbeiten.

1.2.2 Ziel und Abgrenzung der Arbeit

Für die Entwicklung des Konzeptes liefert diese Arbeit einen Überblick über bestehende Entwicklungserkenntnisse zu CPS und intelligenten Logistiksystemen. Darüber hinaus definiert es auf Basis der bestehenden Definition von Veigt et al. (2013) ein CPLS für diese Arbeit. Das beschriebene Konzept für ein CPLS in einer schlanken Produktion betrachtet speziell das Kanban-System, da es als Kernstück des TPS dessen Prinzipien vereint und die logistische Steuerung der Informations- und Warenflüsse übernimmt. Einsatzort für das CPLS ist eine Reihenfertigung, welche sich dadurch auszeichnet, dass die Bearbeitungsvorgänge für die Produkte gleich sind und die Arbeitsplätze dem Fertigungsfluss entsprechend angeordnet sind. Im Gegensatz zu einer Fließfertigung, welche über die für ein Kanban-System vorausgesetzte Taktung der Arbeitsabläufe verfügt, ist die Taktung bei der Reihenfertigung nicht zwingend. Der Einsatz in der Fließfertigung verspricht aufgrund der hohen Automatisierung und Standardisierung des Warenflusses sowie der Tatsache, dass die schlanke Produktion hierfür speziell entwickelt wurde, wenig Potential für ein CPLS. Eine Werkstattfertigung lässt aufgrund der hohen Variantenanzahl, des nicht standardisierten Warenflusses und der fehlenden geglätteten Produktion den Einsatz von Kanban nicht zu. Fertigungsabläufe lassen sich in der Werkstattfertigung durch die hohe Individualität der Aufträge nur schwer beschreiben, was die Komplexität für die Prozessmodellierung eines CPLS erhöht. Ein CPLS in einer Reihenfertigung ist somit ein Ansatzpunkt, um die Einsatzmöglichkeiten eines Kanban-Systems zu erweitern. (vgl. Dickmann, 2009: S. 230-231; Khanna, 2007: S. 86; Pfohl, 2010: S. 184-185)

Das Konzept beschreibt, was ein CPLS ist, welche Anwendungsfälle es in einer schlanken Produktion abdecken muss und zusätzlich könnte und welche Anforderungen sich daraus ergeben. Darüber hinaus beinhaltet es ein fachliches Modell für die Umsetzung dieser Mindestanforderungen an ein CPLS in einem Kanban-System. Das Modell enthält die für ein CPLS notwendigen Elemente, die vom CPLS verfolgten Ziele, die Fähigkeiten und die übernommenen Aufgaben des CPLS. Des Weiteren enthält es die Beschreibung der Vernetzung der Elemente im CPLS sowie eine Beschreibung der Aktivitäten und des für die Ausführung notwendigen Wissens. Ferner wird im Rahmen der Masterthesis das Konzept auf einen Reihenfertiger in der Verzahnungstechnologie-Branche übertragen. Diese Übertragung soll Schwierigkeiten und die für die Praxis notwendige Anpassung bei der Einführung eines CPLS exemplarisch zeigen.

Nicht Bestandteil des Modells ist die Umsetzung der identifizierten, aber für ein Kanban-System nicht zwingend notwendigen Anwendungsfälle. Damit das CPLS später ergänzt werden kann, werden diese optionalen Anwendungsfällen allerdings bei der Modellierung durch entsprechende Schnittstellen und Hinweise im Text berücksichtigt. Ferner ist die technische Implementierung, welche die konkrete Umsetzung in einer gegebenen Produktion beschreibt, nicht Bestandteil der Arbeit. Da diese Implementierung ausbleibt, kann eine Simulation des Modells mangels vorliegender Daten nicht stattfinden. Das Ausbleiben der konkreten Umsetzung erschwert auch die Evaluation der Wirtschaftlichkeit des CPLS, welche ebenfalls nicht Bestandteil dieser Arbeit sind.

1.3 Sechs Bestandteile der Arbeit

Die Arbeit unterteilt sich, neben der Einleitung in Kapitel 1 und dem Schlussteil am Ende der Arbeit, in vier weitere Teile. Kapitel 2 enthält die für das Verständnis der Arbeit notwendigen Grundlagen und den aktuellen Stand der Forschung. Zu den in diesem Kapitel beschriebenen Themen gehören zum einen die Entwicklung des recht jungen Begriffes CPS (Kapitel 2.1) sowie die Herleitung einer Definition für ein CPLS (Kapitel 2.2). Ferner ist in dem Kapitel auch ein Überblick über die für die Entwicklung von CPS und CPLS bereits bestehenden Vorgehensmodelle, Architekturen und Modellierungsnotationen vorhanden (Kapitel 2.3). Neben diesen informationstechnischen Themen widmet sich die vorliegende Arbeit anschließend der schlanken Produktion und deren Prinzipien und Methoden (Kapitel 2.4). Da das Kanban-System ein Schwerpunkt der Arbeit ist, wird es in Kapitel 2.5 noch einmal vertieft und dabei unter anderem der Unterschied zwischen einem eKanban-System und einem CPLS herausgestellt.

Kapitel 3 widmet sich anschließend dem verwendeten Vorgehen zur Konzepterstellung sowie den Anforderungen an ein CPLS in einer schlanken Produktion. Aus den im vorherigen Kapitel vorgestellten Vorgehensmodellen, Architekturen und Modellierungsnotationen wird ein geeignetes Modell ausgewählt und Anpassungen daran vorgenommen (Kapitel 3.1). Ausgangspunkt für die Anforderungen an das CPLS und dessen Ziele sind die bestehenden Schwachstellen und die Ziele der schlanken Produktion (Kapitel 3.2). Bisherige Herausforderungen beim Design von CPS, welche für die Entwicklung eines CPLS zu berücksichtigen sind, werden in Kapitel 3.3 beschrieben. Die Erkenntnisse in diesem Kapitel fasst das Kapitel 3.4 in einem Lastenheft für ein CPLS zusammen. Das Lastenheft enthält eine Beschreibung der Anwendungsfälle und eine Liste mit Anforderungen, die bei der Konzepterstellung zu berücksichtigen sind.

Anhand des ausgewählten Vorgehensmodells ist in Kapitel 4 das CPLS in einer schlanken Produktion beschrieben. Das Kapitel untergliedert sich in die sieben Vorgehensschritte des verwendeten, angepassten Vorgehensmodells ALEM-P. Die einzelnen Unterkapitel beschreiben das betrachtete System jeweils aus einer anderen Sicht. Das Konzept enthält mit der Struktur-, Wissens- und Fähigkeitensicht zum einen ein statisches Modell, welches die Struktur abbildet, als auch ein dynamisches Modell, welches die Abläufe und Zustände beinhaltet und in der Prozess- und Kommunikationssicht beschrieben ist. Tabelle 1 gibt einen Überblick über den Zusammenhang der Sichten und Unterkapitel. Obwohl das verwendete Vorgehensmodell ALEM-P ein iteratives Durchlaufen vorsieht, bilden die Unterkapitel nur eine Iteration ab. Dies hat den Vorteil, dass Wiederholungen im Text vermieden werden und die Übersichtlichkeit besser ist. Stellen, an denen bedingt durch dieses Vorgehen auf Wissen späterer Kapitel vorgegriffen werden muss, enthalten einen Verweis auf das jeweilige Kapitel.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1 Zuordnung der Unterkapitel zu den Sichten und Modellen von ALEM

Kapitel 5 beschreibt, welche Herausforderungen bei der Implementierung des Konzeptes in der Praxis zu bewältigen sind. Die Beschreibung dieser Herausforderungen erfolgt exemplarisch anhand eines Unternehmens aus der Praxis, welches in Kapitel 5.1 beschrieben ist. Kapitel 5.2 widmet sich anschließend den notwendigen Anpassungen und Herausforderungen.

Das eingangs erwähnte Kapitel 6 fasst abschließend die Ergebnisse zusammen (Kapitel 6.1), betrachtet sowohl das Konzept als auch das verwendete Vorgehen kritisch (Kapitel 6.2) und zeigt Ansatzpunkte für weitere Arbeiten auf (Kapitel 6.3). Abbildung 2 stellt die beschriebene Struktur der Arbeit und die Zusammenhänge der Kapitel graphisch dar.

Abbildung 2 Struktur der Arbeit

2 Grundlagen

2.1 CPS: Vernetzte, eingebettete Systeme

2.1.1 Historische Entwicklung von CPS

Bei CPS handelt es sich allgemein um in Objekte eingebettete Computersysteme, welche physische Prozesse steuern und überwachen. Durch diese Computersysteme und die Vernetzung mit der Umwelt werden physische Vorgänge mit digitalen Diensten verknüpft. Die Abläufe und Objekte wirken so für Außenstehende intelligent und als ob sie selbstständig agieren. (vgl. Broy, 2010: S. 25-26; Lee, 2007)

Die Wurzeln eines CPS finden sich zum einen in den eingebetteten Systemen, zum anderen in der intelligenten Vernetzung physischer Objekte und Prozesse. Bereits in den 1980er Jahren tauchte in der wissenschaftlichen Literatur der Begriff „Embedded Systems" (ES; dt.: Eingebettete Systeme) auf. Ursprünglich für spezielle militärische Anwendungen verwendet, wurde er schon damals benutzt, um in reale Prozesse integrierte Computersysteme zu beschreiben (vgl. Kündig et al., 1986: S. 1). Heute beschreiben ES Systeme, welche über Sensoren und Aktoren kontinuierlich die Umwelt wahrnehmen, durch analoge und digitale Schaltungen diese Informationen verarbeiten und anhand der Ergebnisse nahezu in Echtzeit Einfluss auf Ihre Umwelt nehmen. Sie zeichnen sich durch einen geringen Stromverbrauch sowie eine geringe Baugröße aus, sodass sie oftmals unsichtbar in Gegenstände integriert sind. Eingebettete Systeme werden dort eingesetzt, wo die technischen Systeme unmittelbar mit ihrer Umwelt interagieren müssen. In der Vergangenheit beschränkte sich dies auf einfache Steuerungs- und Regelungsaufgaben. Aufgrund der gestiegenen Leistungsfähigkeit von Prozessoren und Speichern übernehmen ES heute z. B. Aufgaben in der Klima- und Beleuchtungssteuerung in Gebäuden, als Assistenzsysteme, wie das Antiblockiersystem oder elektronische Stabilitätsprogramm, im PKW oder als Steuerung in CNC-Maschinen in der Fertigung. (vgl. Berns et al., 2007; Marwedel, 2007; Nauth, 2005)

Die Idee intelligenter Objekte ist zurückzuführen auf eine Veröffentlichung Weisers in den 1990er Jahren. In seinem Artikel „The Computer for the 21st Century" (1991) beschrieb er seine Vision von Computern, die überall unsichtbar integriert sind. Weisers Vorstellung nach sind diese Systeme in der Lage, die Umwelt wahrzunehmen und über ein Netzwerk miteinander zu interagieren. So könnten sie den Anwender dabei unterstützen, bestehende Aufgaben schneller und mit weniger Aufwand zu bewältigen. (vgl. Weiser, 1991) Diese Verbreitung von Computern stellte seiner Ansicht nach eine neue Stufe der Computerisierung dar, welcher er den Namen „ubiquitous Computing" gab (vgl. Weiser, 1996). Die Wissenschaft entwickelte seitdem die Idee intelligenter, vernetzter Objekte weiter. Unter Bezeichnungen wie „Pervasive Computing", „Ambient Intelligence" oder „Smart Objects" finden sich in der Literatur mehrere Begriffe, welche den gleichen Sachverhalt aus unterschiedlichen Perspektiven beschreiben: Die Gestaltung von intelligenten Objekten durch die Verbindung der virtuellen mit der realen Welt (vgl. Broy, 2010; Marwedel, 2007). Seit 2002 existiert darüber hinaus der vom Auto-ID Center am Massachusetts Institute of Technology geprägte Begriff „Internet of Things". Ursprünglich im Kontext eines Forschungsprojektes für eine berührungslose Identifikations-Infrastruktur entstanden, ist der Begriff des IoT in der Wissenschaft und in der Praxis heute weit verbreitet (vgl. Mattern, Floerkemeier, 2010: S. 2). Unter dem Konzept des IoT wird die nahtlose Verbindung von realer und virtueller Welt verstanden, wobei sich bis heute keine einheitliche Definition durchgesetzt hat und der Begriff als Modewort strapaziert wurde (vgl. Uckelmann et al., 2011: S. 2-4).

2.1.2 Definition und Abgrenzung von artverwandten Begriffen

Im Jahr 2006 tauchte erstmals der Begriff „Cyber-Physical Systems" in der Wissenschaft auf. Lee, einer der Mitinitiatoren dieses Ausdrucks, lieferte die erste Definition für CPS. Seiner Vorstellung nach sind CPS eingebettete, vernetzte Computersysteme, welche physische Prozesse steuern und überwachen (vgl. Lee, 2007). Im Vergleich zu ES sind CPS ebenfalls in physische Objekte integriert, darüber hinaus aber miteinander vernetzt. Auch wenn hier wie beim IoT wieder die Interaktion zwischen virtueller und physischer Welt im Vordergrund steht, liegt die Betonung bei CPS nicht auf den realen Dingen, sondern auf Prozessen. Broy präzisierte diese Definition, indem er die Bestandteile konkretisierte. CPS sind demnach eine „[...] enge Vernetzung physischer Vorgänge (über Sensoren, Aktuatoren, mobile Geräte) mit digitalen Diensten (über digitale Netze)." (Broy, 2010: S. 26; Lee, 2008: S. 4).

Die Abgrenzung zwischen IoT und CPS ist unklar und in der Literatur finden sich hierzu widersprüchliche Aussagen. Broy differenziert beide Begriffe, indem er das IoT auf Gegenstände des Alltags beschränkt und das CPS als allgemeine Bezeichnung ansieht. Zu einer ähnlichen Erkenntnis kommen Koubaa und Andersson, welche das IoT als ein Element von CPS sehen (vgl. Koubaa, Andersson, 2009). Demgegenüber stuft die acatech - Deutsche Akademie der Technikwissenschaften e.V. das IoT als eine übergeordnete Vision ein und sieht CPS als diesem untergeordnet an (vgl. Geisberger et al., 2011: S. 10). Koubaa und Andersson führen diese unklare Differenzierung darauf zurück, dass das IoT im Kontext der drahtlosen Identifikationssysteme und das CPS im Kontext von Sensornetzwerken entstanden ist und somit unterschiedliche Gruppen nahezu unabhängig voneinander unterschiedliche Begriffe für einen ähnlichen Sachverhalt prägten (vgl. Koubaa, Andersson, 2009: S. 1).

Im Zusammenhang mit CPS und dem IoT muss auch der seit 2011 in den deutschsprachigen Medien existierende Begriff „Industrie 4.0" erwähnt werden (siehe beispielsweise Bent, 2012; Jasperneite, 2012; o. A., 2012). Er beschreibt die vierte industrielle Revolution, welche nach der Einführung mechanisch angetriebener Produktionsanlagen Ende des 18. Jahrhunderts, der Verbreitung der Massenproduktion zu Beginn des 20. Jahrhunderts und dem Aufkommen von elektronisch- und informationstechnisch unterstützten Anlagen in den 1970er Jahren nun die nächste nachhaltige Veränderung der Produktion durch die Vernetzung von physischer und virtueller Welt prognostiziert (vgl. Kagermann et al., 2013). Dass es sich hierbei nicht nur um ein Modewort handelt, zeigt die Investitionsbereitschaft der Bundesrepublik Deutschland. Im Rahmen der Hightech-Strategie zur Förderung von Schlüsseltechnologien unterstützt sie unter dem Titel „Zukunftsprojekt Industrie 4.0" CPS-bezogene Forschungsaktivitäten (vgl. Bundesministerium für Bildung und Forschung, 2013).

2.1.3 Definition und Bestandteile eines CPS

Da bis dato keine klare Trennung zwischen CPS und IoT existiert und diese im Rahmen der Arbeit sekundär ist, sollen die Begriffe hier als synonym betrachtet werden. Für einen einheitlichen Sprachgebrauch wird durchgängig der Begriff CPS verwendet. Im Folgenden ist hier- runter die von Lee und Broy definierte Verbindung eines ES mit einem Netzwerk zu verstehen. Es sind somit in Gegenstände integrierte, vernetzte Computersysteme, welche physische Prozesse steuern und überwachen. Sie bestehen aus Sensoren, einem Datenverarbeitungsmodul, einem Kommunikationsmodul und Aktoren. (vgl. Broy, 2010; Lee, 2008: S. 21-26)

Durch Sensoren, wie beispielsweise Beschleunigungssensoren, Feuchtigkeitssensoren, Drucksensoren oder Bildsensoren, nehmen CPS ihre Umgebung war. Das Datenverarbeitungsmodul, bestehend aus dem Prozessor und dem Speicher, deren Leistungsfähigkeit von einem einfachen Mikroprozessor bis hin zu Mehrkernprozessoren mit hoher Speicherkapazität reichen kann, verarbeitet und speichert anschließend diese Daten. Die für die Verarbeitung benötigten Softwarealgorithmen können im CPS hinterlegt sein oder als Softwaredienst im digitalen Netz zur Verfügung stehen. Für den Datenaustausch mit dem Netzwerk nutzt das CPS die Kommunikationseinheit, welche z. B. über Standards wie das Internet Protocol Version 6 (IPv6) oder ZigBee drahtgebunden oder -los mit anderen CPS, im Netzwerk vorhandenen Softwarediensten oder anderen Objekten kommuniziert. Die Kommunikationseinheit ist darüber hinaus auch Schnittstelle für den Austausch mit dem Menschen. Hierzu kann es beispielsweise über berührungsempfindliche Bildschirme, Schalter, Tastaturen oder analogen und digitalen Anzeigen Informationen mit ihm austauschen. Die Ergebnisse dieser Datenverarbeitung nutzt das CPS nicht nur zur Kommunikation, sondern auch, um via Aktoren die Umwelt zu beeinflussen. Zu diesen Aktoren zählen beispielsweise rotarische Aktoren, um z. B. eine Achse anzutreiben, oder Piezoelemente. Abbildung 3 visualisiert dieses Zusammenspiel der CPS-Ele- mente mit der Umwelt. (vgl. Broy, 2010: S. 21-22)

Abbildung 3 Schematische Darstellung eines CPS

Abbildung in dieser Leseprobe nicht enthalten

(Quelle: Eigene Darstellung in Anlehnung an Veigt et al., 2013)

Obwohl der vorherige Absatz bereits ein recht klares Bild der Bestandteile eines CPS darstellt, handelt es sich um eine Beschreibung auf hoher Abstraktionsebene. CPS, als ein junges Forschungsgebiet, sind weder vollständig beschrieben noch abschließend erforscht (vgl. Hu et al., 2012: S. 29). Die heterogene Zusammensetzung aus physischen Bauteilen und virtuellen Algorithmen sowie deren Integration in einer ebenso heterogenen Umwelt erschweren darüber hinaus deren Analyse und Modellierung, worauf in Kapitel 2.3 noch vertiefend eingegangen wird (vgl. Lee, Seshia, 2012: S. 15). Bestehende Herausforderungen, welche es weiter zu erforschen gilt, sind unter anderem die Robustheit. CPS sind umgeben von einer teilweise unbekannten, sich wandelnden Umwelt. Auch in neuen Situationen dürfen sie nicht versagen, sondern benötigen Strategien, um diese Umwelt zu erfassen, zu analysieren und sich daran anzupassen, sodass sie ihren Zweck weiterhin autonom erfüllen. Hierzu sind nicht nur geeignete Sensoren und Aktoren notwendig, sondern auch die Fähigkeit, nahezu in Echtzeit oder zumindest binnen einer festgelegten Maximalzeit auf eintreffende Ereignisse zu reagieren. Des Weiteren ist die Kommunikation mit der Umwelt eine Herausforderung. CPS müssen über eine standardisierte Schnittstelle verfügen, mit welcher sie mit anderen Systemen kommunizieren können. Sie sollen des Weiteren den Menschen berücksichtigen, für welchen CPS eine neue, ihm unbekannte Form von selbstständig agierenden Gegenständen darstellt. Hinzu kommen Sicherheitsanforderungen: Daten müssen vor dem unberechtigten Zugriff genauso geschützt sein wie die Software vor Manipulationen. Zuletzt darf für den Betrieb in Unternehmen die Wartbarkeit und Wirtschaftlichkeit solcher Systeme nicht außer Acht gelassen werden. (vgl. Geisberger et al., 2011: S. 127-173; Lee, 2008; Sha et al., 2008)

2.1.4 Zusammenfassung der bestehenden Erkenntnisse zu CPS

Als Zusammenfassung lässt sich festhalten, dass die Idee intelligenter, vernetzter, in physische Objekte integrierter Computersysteme seit den 1980er Jahren bis heute unter unterschiedlichen, aber ähnlichen Begriffen entwickelt wurde. Populär ist neben den CPS heutzutage auch der Begriff „Internet of Things".

Bei einem CPS handelt es sich nach Lee und Broy um eine Verbindung eines ES mit einem Netzwerk (vgl. Broy, 2010; Lee, 2008). Bestandteile sind somit physische Objekte, vernetzte Computersysteme zur Steuerung und Überwachung physischer Prozesse sowie Sensoren, ein Datenverarbeitungsmodul, ein Kommunikationsmodul und Aktoren. Herausforderungen sind unter anderem die Echtzeitfähigkeit und Robustheit, wobei sich die Erforschung von CPS noch im Anfangsstadium befindet.

2.2 CPLS: Ein CPS in der Logistik

2.2.1 Vorgehen zur Definition eines CPLS

Der Begriff „Cyber-Physisches Logistiksystem" ist eine Kombination der Begriffe „Cyber-Physisches System" sowie „Logistik". In der bestehenden wissenschaftlichen Literatur gibt es hierzu erst zwei Erwähnungen (siehe Veigt et al., 2013; Vogel-Heuser et al., 2012). Eine allgemein anerkannte Definition konnte sich noch nicht herausstellen. Dieses Kapitel grenzt ein CPLS von anderen Begriffen ab, indem es die Definition der Logistik mit der in Kapital 2.1 vorgestellten Definition für ein CPS zusammenführt und mit der bestehenden Definition von Veigt et. al. (2013) vergleicht.

2.2.2 Definition der Logistik und dessen Entwicklung

Der Begriff „Logistik" ist abgeleitet aus dem Wort „Logik", welches zurückzuführen ist auf das Altgriechische und dort „denkende Kunst" bzw. „Vorgehensweise" bedeutete. Hieraus ergab sich die Verwendung in der Wissenschaft der Logik, in welcher „Logistik" in der Vergangenheit als Synonym für die mathematische und symbolische Logik verwendet wurde. Der zweite Ursprung des Wortes „Logistik" lässt sich zurückführen auf das französische Wort „loger qn./ qc.", welches „jmdn. irgendwo unterbringen" bedeutet. Ursprung ist hier das französische Militär: Im 19. Jahrhundert bezeichnete „Logis" die Truppenunterkunft und „Logistik" war die Planung und Steuerung der Streitkräfte und des Nachschubs. (vgl. Arnold et al., 2008: S. 3; Pfohl, 2010: S. 11; Wikipedia - Die freie Enzyklopädie, 2013b)

Die Wirtschafts- und Ingenieurswissenschaften sowie die Praxis übernahmen das militärische Verständnis für das Wort „Logistik". Bis in die 1960er Jahre spielte die Logistik in Unternehmen eine untergeordnete Rolle und wurde in der Wissenschaft mit Begriffen wie u. a. „Materialflusssteuerung" behandelt. Bowersox gilt als einer der Autoren, welche in der Neuzeit die Logistik wiederaufleben ließen. Seitdem erhielt der Begriff eine stetige Ergänzung, sodass Logistik heutzutage nicht mehr nur die Lagerung und den Transport von Sachgütern umfasst, sondern eine allgemeine Querschnittsfunktion im Unternehmen ist. Sie betrifft alle Bereiche zwischen der Auftragserfassung und der Auslieferung. (vgl. Baumgarten, 2008: S. 25ff.; Gudehus, 2010: S. XIX; Pfohl, 2010: S. 11)

Obwohl unterschiedliche Definitionen für die Logistik existieren, gibt es bei den bestehenden Gemeinsamkeiten. Logistik befasst sich mit der Gestaltung von logistischen Systemen und der Steuerung der darin stattfindenden logistischen Prozesse. Zu diesen logistischen Prozessen gehören Transport-, Lager-, Umschlag- und Kommissionieraktivitäten, welche das Ziel haben, Objekte bedarfsgerecht zur Verfügung zu stellen. Objekte sind dabei nicht nur Sachgüter, sondern auch Personen und Informationen. (vgl. Arnold et al., 2008: S. 2) Eine der aktuellsten Definitionen stammt von der Bundesvereinigung der Logistik, nach welcher Logistik arbeitsteilige Wirtschaftssysteme analysiert und sie als Flüsse von Objekten durch Raum und Zeit modelliert. Logistik befasst sich dabei mit der Konfiguration, Organisation, Steuerung und Regelung solcher Systeme mit dem Ziel, ökonomische, ökologische und soziale Ziele zu erfüllen. (vgl. Delfmann et al., 2010: S. 2) Älter, aber dafür weiter verbreitet und anschaulicher, ist hingegen die Definition der „vier R", nach welcher sich Logistik mit der Bereitstellung der richtigen Produkte, am richtigen Ort, zur richtigen Zeit, im richtigen Zustand, unter minimalen Kosten befasst (vgl. Pfohl, 2010: S. 12 zit. n. Pfohl, 1972: S. 288). In leicht abgewandelter Form, beispielsweise ergänzt um den Zusatz „beim richtigen Kunden", ist diese Definition unter den „sechs R" bzw. „Seven Rights" bekannt (siehe Plowman, 1964).

2.2.3 Bestehende Definitionen für ein CPLS

Allgemein bezeichnet der Begriff „System" eine Menge von Objekten, auch Elemente genannt, welche über zugeordnete Eigenschaften verfügen und über Beziehungen miteinander verknüpft sind. Ein System grenzt die Menge von Objekten durch eine Systemgrenze von anderen Objekten seiner Umwelt ab. (vgl. Krallmann et al., 2007: S. 60-62) Aufbauend auf der bereits vorgestellten Definition der Logistik charakterisiert ein Logistiksystem, eine Spezialform eines Systems, dass sich mit Bewegungs- und Lagerprozessen von Objekten befasst (vgl. Pfohl, 2010: S. 5). Bei einem CPLS wiederum handelt es sich um eine Spezialisierung eines Logistiksystems, welches die Systemgrenze, Elemente und Beziehungen für ein CPS in der Logistik beschreibt.

Eine der beiden Erwähnungen eines CPLS stammt von Vogel-Heuser et al. (2012: S. 10). Sie lassen bei der Definition ihres „CPS Logistik" die vorgestellten Definitionen der Logistik vollständig außer Acht. Im Rahmen ihrer Beschreibung eines „Production CPS" (ProCPS) erwähnen sie als erste Autoren ein „CPS Logistik". Ihrer Ansicht nach umfasst es alle logistischen Elemente entlang der Wertschöpfungskette. Sie sind vernetzt mit dem ProCPS und zeichnen sich durch Selbststeuerung und Intelligenz aus. Eine weitere Konkretisierung der Elemente und dessen Aufgaben oder Ziele erfolgt nicht. Da der Fokus der Arbeit nicht auf der Logistik liegt, fällt die Beschreibung recht allgemein und kurz aus. (vgl. Vogel-Heuser et al., 2012: S. 10)

Die zweite Erwähnung in der wissenschaftlichen Literatur stammt von Veigt et al. (2013) im Rahmen des „Zukunftsprojekts Industrie 4.0". Für das aktuell noch in Bearbeitung befindliche Forschungsprojekt „CyProS" mit Fokus auf ein CPLS stellen sie eine erste Definition auf. Ihrer Ansicht nach handelt es sich bei einem CPLS um eine Zusammenfassung von Logistikelementen mit CPS-Eigenschaften, welche mit Produktions-CPS und Menschen interagieren. Sie arbeiten autonom, um ökonomische, ökologische und soziale Ziele zu erreichen. (vgl. Veigt et al., 2013) Aus Sicht von CPS übernimmt diese Definition die von Broy und Lee beschriebenen Elemente eines CPS. Aus logistischer Sicht beschränkt sich die Definition, ähnlich wie die von Vogel-Heuser, auf die Anforderung „Logistikelemente", welche in ein Produktionsumfeld integriert sind. Die Zielsetzung eines CPLS ist dabei aus der Logistik-Definition des Bundesverbands für Logistik übernommen. (vgl. Veigt et al., 2013)

2.2.4 Zusammenführung der Logistik- und CPS-Definition in einem CPLS

Für das in dieser Arbeit verwendete Verständnis von einem CPLS werden die vorgestellten, bestehenden Definitionen eines CPLS verwendet und mit den Definitionen der Logistik und der von CPS zusammengeführt. Im Folgenden ist ein CPLS wie folgt zu interpretieren:

Ein Cyber-Physisches Logistiksystem (CPLS) ist als eine Zusammenfassung von primär Cyber-Physischen Systemen (CPS) zu verstehen, welche logistische Aufgaben übernehmen. Bei den CPS handelt es sich um eingebettete, vernetzte Systeme, die autonom handeln und mit ihrer Umwelt interagieren. Logistische Aufgaben sind Aufgaben, die sich insbesondere mit dem Fluss von Informationen und Waren in der Wertschöpfungskette befassen. CPLS streben ökonomische, ökologische und soziale Ziele an.

Im Gegensatz zu der vorgestellten Definition von Veigt et al. unterscheidet sich diese Beschreibung dadurch, dass in einem CPLS nicht zwingend alle Elemente die von Broy und Lee beschriebenen CPS-Eigenschaften besitzen müssen. Sie konkretisiert die „Logistikelemente", indem sie den Bezug zum Fluss von Informationen und Waren herstellt. Die Verbindung zu einer Produktion ist hier durch die Vernetzung und den Bezug zur Wertschöpfungskette indirekt vorhanden. Das CPLS grenzt sich ferner von der Umwelt dadurch ab, dass es logistische Aufgaben wahrnimmt.

2.3 Design von CP(L)S: Bestehende Vorgehensmodelle und Architekturen

2.3.1 Bestehende Vorgehensmodelle für die Entwicklung von CP(L)S

Für die Systementwicklung und Problemlösung liefern Vorgehensmodelle den Entwicklern eine Hilfestellung, wie sich eine übergeordnete Aufgabenstellung in Teilaufgaben zerlegen lässt, welche Bearbeitungsreihenfolge sinnvoll ist und welche Methoden jeweils angewendet werden können (vgl. Krallmann et al., 2007: S. 135). Wie in den vorherigen Kapiteln festgestellt, ist die Erforschung von CPS und CPLS noch nicht abgeschlossen. Somit überrascht es nicht, dass - auch wenn es als entscheidender Erfolgsfaktor gilt - für den Entwurf von CPS und CPLS noch kein einheitliches, etabliertes Vorgehensmodell existiert (vgl. Hu et al., 2012: S. 1; Lee, 2008: S. 5; Sha et al., 2008: S. 6). Erste Vorschläge in der Literatur wurden bisher nur in Einzelfällen erprobt.

Eine ausführliche Vorstellung bestehender Vorgehensmodelle, wie dem des Systems Engineering, dem V-Modell, die VDI-Richtlinie 2221 oder eXtreme Programming, findet sich in Haberfellner et al. (2012), auf welchen aufgrund der Vielzahl der Modelle an dieser Stelle verwiesen sei. Die Autoren unterscheiden agile Ansätze, welche flexibel, aber unkoordinierter sind und sich für kleinere Projekte mit dynamischem Umfeld und qualifizierten Projektmitgliedern besonders eignen, und plangetriebene Methoden, welche sich systematisch vom Groben zum Detail vorarbeiten und durch das strukturierte Vorgehen besonders für kritische und große Anwendungen geeignet sind (vgl. Haberfellner et al., 2012: S. 87+110). Die plangetriebenen Methoden vereint, dass sie alle ein ähnliches Vorgehen beschreiben, welches Haberfellner et. al im „Phasenmodell des Systems Engineering" (SE-Phasenmodell) verallgemeinern. In den Phasen „Anstoß" und „Vorstudie" wird ausgehend von einem identifizierten Problem das zu verändernde System abgegrenzt, Vor- und Nachteile abgewogen und grundsätzlich denkbare Lösungsprinzipien ausgewählt. Die Haupt- und Detailstudie sind die nächsten Schritte: Nachdem ein Gesamtkonzept ausgewählt wurde, ist dieses in Teile zu zerlegen und vertieft auszuarbeiten. Anschließend wird dieses System erstellt und getestet, bevor es endgültig eingeführt werden kann. Mit der ordnungsgemäßen Übergabe ist das Systementwicklungsprojekt abgeschlossen. (vgl. Haberfellner et al., 2012: S. 65-72)

Für den Einsatz in einem intelligenten, dezentral organisierten Logistiksystem übernehmen Scholz-Reiter et al. (2009) das SE-Phasenmodell und passen es an (vgl. ScholzReiter et al., 2009: S. 1-2). In dem von ihnen entworfenen „Autonomous Logistics Engineering Methodology" (ALEM) beschreiben sie eine Modellierungsmethode, welche ein Vorgehen für die Entwicklung von selbststeuernden Logistiksystemen (ALEM-P), eine Modellierungsnotation (ALEM-N) sowie ein Softwarewerkzeug (ALEM-T) enthält. Die Haupt- und Detailstudie des SE-Phasenmodells vertiefen sie hierbei durch ein iteratives Vorgehen mit vier Schritten. Dies umfasst zum einen die Spezifikation des Systems, welche semiformal erfolgt und die Abstimmung von Struktur und Prozessen beinhaltet. Anschließend wird dieses System simuliert und die hierfür notwendige Software entwickelt, bevor im dritten Schritt die für die Umsetzung notwendigen physischen Elemente zu bestimmen sind. Der vierte Schritt betrachtet die Kosten und Nutzen dieses Systems. Sofern die Zielsetzung noch nicht erfüllt ist, ist eine weitere Iteration durchzuführen. Abbildung 4 stellt das Phasenmodell des System Engineering dem soeben vorgestellten Vorgehensmodell gegenüber, um die Unterschiede zu verdeutlichen. (vgl. Scholz-Reiter et al., 2009: S. 2-3, 2008: S. 3-4)

Abbildung 4 Gegenüberstellung Phasenmodell des Systems Engineering und Vorgehensmodell für selbststeuernde Logistiksysteme

Abbildung in dieser Leseprobe nicht enthalten

(Quelle: Eigene Darstellung in Anlehnung an Haberfellner et al., 2012: S. 65; Scholz-Reiter et al., 2009: S. 3)

Das Vorgehensmodell ALEM-P beschreibt speziell das Vorgehen für die Modellierung intelligenter Logistiksysteme und trägt dazu bei, ein qualitativ hochwertiges Modell zu erstellen und den Arbeitsaufwand bei der Modellierung zu reduzieren. Da bei verteilten Entscheidungen den einzelnen Objekten eine erhöhte Aufmerksamkeit zukommen muss, zu Beginn der Modellierung aber noch Ungewissheit über Details besteht, vereint das Vorgehensmodell den Top- Down-Ansatz mit dem Bottom-Up-Ansatz. (vgl. Scholz-Reiter et al., 2009: S. 5+9) Insgesamt beinhaltet ALEM-P acht Schritte, welche nacheinander abgearbeitet werden, wobei Rücksprünge zu vorherigen Schritten möglich sind. Der erste Schritt ist die Definition des übergeordneten Zieles, welches sich aus der Anpassung von allgemeinen Logistikzielen, wie beispielsweise eine verkürzte Durchlaufzeit oder ein geringerer Umlaufbestand, ableitet. Im nächsten Schritt werden die für das System notwendigen Elemente und deren Beziehung zueinander gesammelt. Bereits an dieser Stelle findet eine Zuordnung statt, welche Elemente „Intelligenz" benötigen und welche nicht. Im dritten Schritt werden diesen Elementen Eigenschaften zugeordnet. Diese Eigenschaften leiten sich aus der Abstraktion von Tätigkeiten ab. Im vierten Schritt sind die Prozesse zu modellieren, welche in dem Logistiksystem ablaufen. Das Vorgehen erfolgt hier in zwei Teilschritten: Zuerst wird der ideale Prozess ohne Ausnahmen modelliert. Erst danach werden Ausnahmen und deren Behandlung ergänzt. Die von den intelligenten Objekten getätigten Entscheidungen sind im fünften Schritt zu ergänzen. Anschließend wird evaluiert, welche Informationen für diese Entscheidungen notwendig sind und wo diese abgerufen werden können. Erst im siebten Schritt werden die auszutauschenden Nachrichten und die hier verwendeten Protokolle ergänzt. Nach diesem Schritt ist die erste Iteration der Modellierung durchlaufen. Im abschließenden Schritt wird das Modellverhalten anhand realer Daten simuliert und unterschiedliche Szenarien getestet. In einer weiteren Iteration werden anschließend aus den Simulationsergebnissen abgeleitete Anpassungen vorgenommen. Abbildung 5 fasst das beschriebene Vorgehen zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 Das ALEM-P Vorgehensmodell

(Quelle: Eigene Darstellung in Anlehnung an Scholz-Reiter et al., 2008: S. 6)

Neben dem vorgestellten ALEM-P existiert ein neueres Vorgehensmodell für die Modellierung intelligenter logistischer Systeme von Veigt et al. (vgl. Veigt et al., 2013). Im Rahmen des Forschungsprojektes CyProS (siehe CyProS Konsortium, 2013) verwenden sie ein vierstufiges, sequentielles Vorgehen für die Entwicklung eines CPLS. In der Anforderungsanalyse erheben sie zuerst in der Wissenschaft bestehende Anforderungen an Komponenten und Schnittstellen von CPS für den Einsatz in Produktionssystemen und nehmen den bestehenden Logistikprozess auf. In der Konzeption wird anschließend geprüft, welche Informationen zur Verfügung stehen und wie diese unter Berücksichtigung von autonomen Steuerungsmethoden von CPLS-Elementen verarbeitet werden können. Die Evaluation der Prozesse und Steuerungsmethoden erfolgt in der Simulation im dritten Schritt. Abschließend wird in einem Kompetenz- und Transferzentrum ein Prototyp entwickelt. (vgl. Veigt et al., 2013) Auch wenn sich dieses Vorgehen sich speziell auf ein CPLS bezieht, ist es auf einer hohen Abstraktionsebene dargestellt und angepasst auf das konkrete Forschungsvorhaben.

Ein weiteres Vorgehensmodell stammt aus der Entwicklung eingebetteter Systeme, auf welchen CPS basieren. Das „Embedded Systems Design and Development Lifecycle Model" von Noergaard (2005) ist eine Kombination des Wasserfall- und Spiralmodells und somit eine Kombination von plangetriebenem und agilem Vorgehen (siehe Haberfellner et al., 2012: S. 87-89+103-105; Noergaard, 2005: S. 7). Sie unterteilt das Vorgehen in die vier Phasen „Architektur erstellen", „Architektur implementieren", „System testen" und „System warten". Insbesondere die erste Phase, „Architektur erstellen", ist detaillierter untergliedert. Sie beginnt ebenfalls mit der fachlichen Ausarbeitung, wobei hier zuerst ein Konzept für das neue Produkt zu erstellen ist. Anschließend erfolgt - ähnlich wie im SE- Vorgehensmodell bei der Vorstudie - eine einleitende Analyse der Anforderungen, bevor im dritten Schritt die Architektur zu bestimmen ist. In den nachfolgenden Schritten wird iterativ dieser Architekturentwurf umgesetzt und evaluiert, bis abschließend die finale Version der Architektur in der Phase „Architektur implementieren" umzusetzen ist. (vgl. Noergaard, 2005: S. 8) Dieses, laut Aussage der Autorin, auf langjähriger Praxiserfahrung mit ES beruhende Vorgehen (vgl. Noergaard, 2005: S. 7) hat Ähnlichkeit mit dem bereits vorgestellten Vorgehen für selbststeuernde Logistiksysteme von Scholz-Reiter et al. Die Iterationen in der Methode von Scholz-Reiter et al. beinhalten zusätzlich die Aktualisierung der Anforderungen sowie eine Kosten-Nutzen-Betrachtung pro Iteration, welche im Embedded Systems Design and Development Lifecycle Model fehlt. Dafür berücksichtigt das Embedded Systems Design and Development Lifecycle Model auch die Wartung nach der Einführung des Systems.

Eine andere, abstraktere Vorgehensweise ist das in der Model Driven Architecture (MDA; dt.: Modellgetriebene Architektur) von der Object Management Group (OMG) erarbeitete Vorgehen. Die primär für die Erstellung von verteilten, komplexen Softwareanwendungen entwickelte Methode sieht zuerst die Dokumentation der Anforderungen in einem computerunabhängigen Modell vor. Anschließend wird dieses Modell zusammen mit den Systemfunktionalitäten in ein plattformunabhängiges, von der konkreten Implementierung losgelöstes Modell transformiert, bevor abschließend ein auf den Prozess zugeschnittener Entwurf erstellt wird. Jede Transformation reichert das Modell mit neuen Informationen an, sodass ausgehend von einem umgebungsunabhängigen Modell letztendlich das zu implementierende System erstellt wird. Diese Methode verwenden beispielsweise Magureanu für den Entwurf eines CPS zur Überwachung eines städtischen Gasverteilungssystems. (vgl. Hailpern, Tarr, 2006; Magureanu et al., 2010; Miller, Mukerji, 2003; Rempp et al., 2011: S. 13-14)

Zusammenfassend lässt sich zu den Vorgehensmodellen für CPS und CPLS festhalten, dass es hierfür noch kein detailliertes Modell gibt. ALEM-P ist ein Vorgehen, welches für selbststeuernde Logistiksysteme entwickelt wurde und somit aus einem ähnlichen Kontext wie CPLS stammt. Zusätzlich berücksichtigt es die für den Entwurf von CPS geforderte iterative Entwicklung (vgl. Sha et al., 2008: S. 6). Es basiert auf dem allgemeinen SE-Vorgehensmodell und hat Ähnlichkeiten zum Modell von Noergaard zur Entwicklung von ES. MDA trennt die Funktion von der für die Umsetzung notwendigen Technik und ist ebenfalls für den Entwurf von komplexen Systemen geeignet, allerdings ist das Vorgehen sehr allgemein beschrieben.

2.3.2 Bestehende Referenzarchitekturen für den Aufbau von CP(L)S

Architektur lässt sich nach Haberfellner et al. als die Beschreibung der Struktur eines betrachteten Systems und die Zuordnung von Funktionen zu Elementen dieser Struktur beschreiben (vgl. Haberfellner et al., 2012: S. 183). Auch bei der Architektur mangelt es zurzeit an einer Referenzarchitektur, welche für den Entwurf von CPS und CPLS als Vorlage und idealtypische Struktur verwendet werden kann. Eine solche Referenzarchitektur muss Herausforderungen wie der Verteilung der Funktionalität auf unterschiedliche Objekte und der Ad-Hoc-Vernetzung mit anderen Geräten gerecht werden. Außerdem muss sie berücksichtigen, dass CPS in sich verändernden Umwelten arbeiten und in der Lage sein müssen, auf unbekannte Ereignisse zu reagieren. Bestehende Referenzarchitekturen aus anderen Bereichen berücksichtigen diese neuen Anforderungen nicht. (vgl. Kagermann et al., 2013: S. 101-103; Rajhans et al., 2009: S. 2; Reinhart et al., 2013: S. 5)

In der wissenschaftlichen Literatur finden sich bereits erste Vorschläge zur Gestaltung dieser Referenzarchitektur. So empfiehlt Lewandowski (2013: S. 2) aufgrund der Vielzahl der selbstständig agierenden und miteinander kommunizierenden Entitäten innerhalb eines verteilten CPS die Verwendung von Ansätzen aus den weiter unten beschriebenen Multiagentensystemen. Des Weiteren schlagen unter anderem Hu et al. (2012) La und Kim (2010) sowie Lin und Panahi (2010) den Rückgriff auf serviceorientierte Architekturen vor, welche Kagermann et al. (2013) sogar als notwendig für CPS in der Produktion ansehen und im Folgenden ebenfalls beschrieben werden. Erprobt wurden diese Architekturansätze in Einzelfällen unterschiedlichster Art, wie beispielsweise einem Gasverwaltungssystem für eine urbane Umgebung, zur Temperatursteuerung in Gebäuden, für die Materialverwaltung in der Intralogistik oder für ein Überwachungssystem im Gesundheitswesen (siehe La, Kim, 2010; Lewandowski et al., 2013; Magureanu et al., 2010; Rajhans et al., 2009).

Einer der ersten Ansätze zur Architektur eines CPS enthält die bei den ES etablierte Unterteilung in die zwei Bereiche „physische Elemente" und „digitale Elemente". Die physischen Elemente wie Aktoren werden hier den digitalen Elementen wie Software und Sensoren gegenübergestellt. Beide Bereiche sind fest miteinander verbunden und von einer zentralen Steuerungseinheit kontrolliert. (vgl. Hu et al., 2012: S. 1; Tan et al., 2008: S. 1)

La und Kim (2010) nehmen diesen zwei Schichten-Ansatz als Grundlage und verwenden eine serviceorientierte Architektur (SOA). Bei SOA handelt es sich um ein Paradigma, welches in der jüngsten Vergangenheit großen Einfluss auf die Softwareentwicklung hatte. Die SOA verbindet über standardisierte Schnittstellen Softwaredienste lose miteinander, um übergeordnete Geschäftsprozesse abzubilden. Diese Services können hierbei verteilt im Netzwerk abgelegt werden, sind einfach austauschbar und ermöglichen eine schnelle Anpassung bei Änderungen im Geschäftsprozess. Für ein besseres Verständnis werden diese Services, ähnlich wie in anderen Software-Architekturen, in Schichten gruppiert. Vorteile sind die hohe Flexibilität, wiederverwendbare Services, die leichte Wartbarkeit und die Skalierbarkeit des Systems. Für die Verwendung von SOA und CPS spricht, dass die Rechenleistung von im Netzwerk stetig verfügbaren Servern genutzt werden kann und CPS-Entitäten so auf leistungsstarke Computer verzichten können. Auch wenn eine Weiterentwicklung dieser bestehenden Architekturansätze den Entwurf von CPS vereinfacht, hebt Lee (2008: S. 6) dennoch die Notwendigkeit eines neuen Architekturentwurfs hervor, welcher die Eigenschaften von Software und physischen Prozessen besser miteinander vereint. (vgl. Finger, Zeppenfeld, 2009: S. 2-19; Günthner, ten Hompel, 2010: S. 33-35; Kagermann et al., 2013: S. 101-102; Lin, Panahi, 2010: S. 1)

La und Kim (2010) schlagen für die Umsetzung einer SOA eine Unterteilung in drei Schichten (engl.: Tier) vor. Im „Environmental Tier" werden alle physischen Geräte sowie die nicht zum CPS gehörende Umwelt wie zum Beispiel Endnutzer zusammengefasst. Die „Service Tier" beinhaltet die über das weltweite Netz erreichbaren, digitalen Dienste. Auch gehört zu dieser Schicht ein Verzeichnisdienst, um die Services zu indizieren. Die „Control Tier" sammelt und überwacht alle von Sensoren aufgenommenen Daten, trifft Entscheidungen und wählt die richtigen Services aus. Durch diese Serviceorientierung können Dienste wiederverwendet werden und lassen sich flexibel für unterschiedliche Geschäftsprozesse orchestrieren. Die Trennung von physischen Objekten und Services ermöglicht kurzfristige Funktionsanpassungen der Services sowie eine Verwendung dieser auf heterogener Hardware. (vgl. La, Kim, 2010: S. 2)

Basierend auf den Überlegungen zu einer Einteilung in zwei Bereiche bzw. drei Schichten kommen Hu et al. (2012) zu einer SOA-basierten Architektur mit fünf Schichten, welche in Abbildung 6 dargestellt ist. Auf unterster Ebene befindet sich hier die „Perceive Tier", welcher alle Elemente zur Wahrnehmung der Umwelt und Vorfilterung von Daten zusammenfasst. Die „Data Tier" umfasst die Elemente zur Speicherung und Vorverarbeitung der Daten und ist gleichzeitig die Schnittstelle zwischen „Perceive Tier" und der übergeordneter „Service Tier". Die „Service Tier" enthält die Funktionalität des CPS. Dies beinhaltet die Schnittstellen zur Verarbeitung der Daten durch andere Dienste, Entscheidungsmodule sowie Dienste zur Aufgaben- und Ablaufplanung. Die oberste Schicht bildet abschließend die „Execution Tier" mit den Aktoren. Dieser Architekturansatz berücksichtigt des Weiteren eine Komponente für die Sicherheit, welche auf alle Ebenen Einfluss hat.

Abbildung 6 SOA-basierte CPS-Architektur

Abbildung in dieser Leseprobe nicht enthalten

(Quelle: Hu et al., 2012: S. 4)

Ein Multiagentensysteme (MAS) für die Anwendung eines CPS im innerbetrieblichen Warenfluss erarbeiteten Lewandowski et al. (2013). Kennzeichnend für Multiagentensysteme ist die Verlagerung der Planungs- und Kontrollaktivitäten von einem zentralen System hin zu den einzelnen Objekten des Systems, welche als Agenten bezeichnet werden. In dem ebenfalls mit Schichten arbeitenden Modell fasst der „User-Interaction-Layer" die Benutzeroberfläche zur Interaktion mit dem CPS sowie den Administrations-Agenten für die Verwaltung zusammen. Die „Transport-Agent-Layer" umfasst Agenten, welche das Ziel verfolgen, Waren innerhalb der Intralogistik an ihr Ziel zu bewegen. Alle Agenten für die Kontrolle von Hardware sind im „Hardware-Agent-Layer" gruppiert. Wie in einem agentenbasierten System üblich, kommunizieren die Agenten untereinander, um Absprachen zu treffen und ihre individuellen Ziele zu erreichen. Im Gegensatz zu den vorherigen SOA-Ansätzen sind hier die Schichten nicht nach technischen Gesichtspunkten gruppiert, sondern nach den Rollen der Agenten. Neben den Layern existieren darüber hinaus zwei übergreifende Agenten, welche zum einen die Aktivitäten protokollieren und zum anderen die Standorte von Waren überwachen. Abbildung 7 visualisiert dieses Ebenenmodell. (vgl. Lewandowski et al., 2013: S. 2-3)

Abbildung 7 Architektur für ein Multiagentensystem in der Intralogistik

Abbildung in dieser Leseprobe nicht enthalten

(Quelle: Lewandowski et al., 2013: S. 3)

Im Kontext der MAS ist außerdem das Architekturmodell aus dem INGENIAS-Rahmenkon- zept zu erwähnen, welches von Sanislav und Miclea (2012) für die Entwicklung eines CPS verwendet wird. INGENIAS ist eine Methode zur Entwicklung von ereignisgesteuerten Multiagentensystemen und stammt aus der Softwareentwicklung. Hier unterstützt es den Entwickler bei der Analyse, dem Design und der Implementierung, indem es das betrachtete System in die fünf Sichten „Organisation", „Umwelt", „Aufgaben/ Ziele", „Agenten" und „Interaktionen" zerlegt. Diese nach Ansicht der Autoren für die Komplexitätsreduzierung hilfreiche Zerlegung ergänzen sie um ein Architekturmodell für CPS. In dem Architekturmodell unterscheiden sie zwischen einer physischen und digitalen Welt. Von Sensoren wahrgenommene Ereignisse werden, wie in Abbildung 8 visualisiert, an in einem Netzwerk verteilte Dienste weitergeleitet, um neue Ereignisse zu erzeugen, Services zu aktivieren, Prozesse zu initiieren oder Aktoren anzusprechen. (vgl. Gomez-Sanz et al., 2012; Sanislav, Miclea, 2012: S. 1+4)

Abbildung 8 Event- und multiagentenbasierte Architektur für CPS auf Grundlage von INGENIAS

Abbildung in dieser Leseprobe nicht enthalten

(Quelle: Sanislav, Miclea, 2012: S. 3)

Auch Lin et al. (2010) verwenden einen agentenbasierten Ansatz zur Realisierung eines CPS. Die Agenten sind hier, ähnlich wie in einer SOA, an Services gekoppelt, um Redundanzen zu vermeiden. Ihr Modell ist allerdings für das konkrete Fallbeispiel „Wasserverteilungssystem" entworfen worden und befindet sich im Prototypen-Status. (vgl. Lin et al., 2010) Einen weiteren Ansatz für die Architektur von CPS findet sich des Weiteren in Rajhans et al. (2009). Sie erweiterten die Softwarearchitektur-Beschreibungssprache ACME ADL (siehe ACME Team, 2011), welche Elemente nach ihren Fähigkeiten und Verbindungen gruppiert und für flexible Strukturen verwendbar ist. In ihrem Ansatz wählten Sie ebenfalls eine Einteilung in eine „Cyber-Familie" und eine „Physische Familie". (vgl. Rajhans et al., 2009) Unter der Bezeichnung „eingebettete, intelligente Systeme" befasste sich darüber hinaus schon Nauth (2005) mit der Architektur, wobei die Beschreibung hier sehr technisch ist und sich ebenfalls auf einen speziellen Anwendungsfall bezieht.

Zur Architektur von CPS lässt sich zusammenfassend festhalten, dass zwar noch keine Referenzarchitektur existiert, allerdings erste Ansätze existieren und in Einzelfällen erprobt wurden. Diese Ansätze sind primär durch die Anpassung von Softwareentwicklungsmodellen entstanden. Vielversprechende Ansätze sind das SOA-Paradigma und die MAS. Allerdings betonte schon Lee, dass die Herausforderungen beim Design von CPS nur durch eine neue Architektur vollständig bewältigt werden können.

2.3.3 Bestehende Modellierungsnotationen für die Beschreibung von CP(L)S

Allgemein ist ein Modell als ein Abbild eines Systems aufzufassen. Dieses Abbild unterscheidet sich von dem betrachteten System dadurch, dass es das System zweckorientiert, auf die relevanten Informationen beschränkt und abstrakt beschreibt. Unter Modellierung ist im Folgenden die Tätigkeit der Modellbildung zu verstehen, also das Abbilden der relevanten Aspekte aus Sicht des Modellierers. Grundsätze der ordnungsgemäßen Modellierung sind unter anderem Relevanz und Klarheit. Ein Modell soll demnach nur die für den Zweck, in dieser Arbeit die fachliche Beschreibung eines CPLS, relevanten Informationen enthalten und muss für Dritte nachvollziehbar sein. Letzteres wird durch die Verwendung einer Notation, die den formalen Aufbau und die verwendeten Konstrukte definiert, angestrebt. (vgl. Krallmann et al., 2007: S. 71-72; zit. n. Stachowiak, 1973: S. 131; Lehmann, 2008: S. 7-10)

Für die Modellierung hat sich bis dato keine Notation durchgesetzt, welche speziell auf die Bedürfnisse von CPS und CPLS zugeschnitten und allgemein anerkannt ist. Bestehende Visualisierungsformen, welche sich für die Darstellung von Computersystemen etabliert haben, lassen beispielsweise die Ausführungszeit von Aktivitäten außer Acht. Diese ist wiederum für die physischen Prozesse notwendig. Die Einführung einer „Worst Case Execution Time" (WCET; dt.: Maximale Ausführungszeit) konnte dieses Problem bedingt lösen. (vgl. Lee, 2008: S. 2; Zhai et al., 2012: S. 1) Bestehende Arbeiten greifen für die Modellierung von CPS größtenteils auf UML zurück und passen dies auf die individuellen Bedürfnisse an. Im Folgenden soll ein Überblick über bestehende Notationen gegeben werden.

Bei der Unified Modeling Language (UML) handelt es sich um eine von der OMG standardisierte und ISO-zertifizierte Sammlung von Diagrammtypen, um insbesondere während der frühen Phase der Entwicklung objektorientierte Systeme zu beschreiben und zu visualisieren (vgl. Krallmann et al., 2007: S. 106; Marwedel, 2007: S. 51). Die in den 1990ern in der Softwareentwicklung entstandene, frei verfügbare Notation liegt heute in der Version 2.4.1 vor und erfreut sich einer sehr weiten Verbreitung (vgl. Rumpe, 2011: S. V; Wikipedia - Die freie Enzyklopädie, 2013c). UML beschränkt sich nicht nur auf die Modellierung der technischen Sicht, sondern ist auch geeignet, die fachliche Sicht abzubilden oder Nicht-Computersysteme zu entwickeln (vgl. Object Management Group, 2013b). Software-Werkzeuge wie das kostenlose PapyrusUML (siehe Platter, 2008) ermöglichen darüber hinaus die teilweise automatische Generierung von Quellcode aus UML-Diagrammen.

UML enthält insgesamt 13 Diagrammtypen, welche in drei Kategorien eingeteilt sind. Durch Strukturdiagramme wird der Aufbau eines Systems dargestellt, wohingegen Verhaltensdiagramme den Ablauf abbilden. Die Kategorie der Interaktionsdiagramme stammt von den Verhaltensdiagrammen ab und visualisiert das Zusammenspiel von Objekten. Eine Übersicht über den Zweck der Diagramme zeigt Tabelle 2. Für eine Einführung in die Modellierung mit UML sei an dieser Stelle auf Rumpe (2011) verwiesen, tiefergehende Informationen wie die Spezifikation finden sich direkt auf der Homepage der OMG (vgl. Object Management Group, 2013a, 2013b).

Tabelle 2 Einteilung der UML-Diagramme und deren Zweck

Abbildung in dieser Leseprobe nicht enthalten

(Quelle: Fowler, 2003: S. 29–31; Object Management Group, 2013b)

Für spezielle Anwendungsfälle existiert mittlerweile eine Vielzahl von Anpassungen, welche UML entweder um eigene Diagrammtypen ergänzen oder nur eine Auswahl der vorhandenen Diagramme für die Entwicklung verwenden (siehe Object Management Group, 2013c). So ist beispielsweise die Anpassung „SysML" speziell für die Entwicklung komplexer Systeme geeignet (vgl. Magureanu et al., 2010: S. 2). Magureanu et al. (2010) verwenden die für die Entwicklung plattformunabhängiger Systeme angepasste Methode „PIM" und passen sie für CPS an, indem sie CPS-relevante Objekte aufnehmen und sich auf Klassen-, Komponenten- und

Einsatzdiagramme beschränken. Zhai et al. greifen auf HybridUML zurück, welches UML um Elemente zur Beschreibung des Verhaltens über die Zeit ergänzt. Für die Verifizierung der erstellten CPS-Modelle verwenden sie die aus dem Bereich der hybriden Systeme stammende Differential Dynamic Logic. (vgl. Zhai et al., 2012) Auch die Modellierungsmethode ALEM von Scholz-Reiter et al. verwendet eine stark an UML angelehnte Notation, welche sie als ALEM-N bezeichnen. ALEM-N verwendet sieben Sichten, welche aus dem zuvor vorgestelltem Vorgehensmodell ALEM-P abgeleitet sind. Diese Sichten sind aufgeteilt auf ein statisches Modell zur Beschreibung der Struktur und ein dynamisches Modell zur Beschreibung des Verhaltens. (vgl. Scholz-Reiter et al., 2009: S. 6-8) Liu et al. verwenden ebenfalls UML zur Beschreibung von CPS, stellen allerdings die Modellierungssprache Modelica in den Vordergrund, da diese in der Lage ist, das Systemverhalten zu simulieren (vgl. Liu et al., 2012).

Für die visuelle Beschreibung von CPS und CPLS lässt sich zusammenfassend festhalten, dass zwar noch kein einheitlicher Standard vorliegt, erste Vorschläge allerdings in der Entwicklung sind und in der Praxis erprobt wurden. Diese greifen zurück auf die standardisierte und dominierende UML, welche speziell für die Planungsphase von Systemen geeignet ist. Die ursprünglich aus der Softwareentwicklung stammende Notation berücksichtigt seit der Version 2.0 und einigen der daraus abgeleiteten Anpassungen Anforderungen für die Entwicklung eingebetteter Systeme. (vgl. Haberfellner et al., 2012: S. 406; Marwedel, 2007: S. 51)

[...]