Verteilte Software-Systeme im Kontext von Industrie 4.0

1.433 Aufrufe

Veröffentlicht am

Impulsvortrag zu den relevanten Forschungsfragen in der Informatik beim Thema Industrie 4.0.

Veröffentlicht in: Software
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.433
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
177
Aktionen
Geteilt
0
Downloads
8
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Verteilte Software-Systeme im Kontext von Industrie 4.0

  1. 1. Verteilte Software-Systeme im Kontext von Industrie 4.0 Impulsvortrag Dr. Peter Tröger Technische Universität Chemnitz 7. Oktober 2014
  2. 2. Daimler, Oktober 2014 Industrie 4.0 • Forschungs- und Industrieagenda • Zielsetzung • Integration von (Echtzeit)-Daten aus verschiedenen Quellen • Vernetzung von Mensch, Maschine, Objekten und IKT-Systemen • Selbstoptimierende Prozesse • Ermittlung und Ausnutzung von Verbesserungspotential • Berücksichtigung der Mensch- Maschine-Schnittstelle 2 [Bitcom, Fraunhofer IAO]
  3. 3. Daimler, Oktober 2014 Industrie 4.0 - Für Informatiker • Keine Monolithen mehr • Flexibel koppelbare Software- Komponenten • Funktionale Integration von Komponenten mit und ohne Echtzeitanforderungen • Integration und Auswertung 
 verschiedener Datenquellen • Physische Sensoren und Aktuatoren • Was bietet die Forschung ? 3 [Bitcom, Fraunhofer IAO]
  4. 4. Daimler, Oktober 2014 4 Forschung Verteilte Echtzeitsysteme Skalierbare
 verteilte Systeme Verfügbarkeit und Zuverlässigkeit
  5. 5. Daimler, Oktober 2014 Skalierbare verteilte Systeme • Coulouris et al.: 
 „…[system] in which hardware or software components located at networked computers communicate and coordinate their actions only by passing messages…“ • Konsequenzen • Nebenläufigkeit als Normalzustand, asynchrone Kommunikation • Partielle Ausfälle • Heterogenität, Sicherheit, Schutz, … • Aktiver Gegenstand der Forschung • Großer Hype um Big Data als ein Vertreter 5
  6. 6. Daimler, Oktober 2014 Big Data • Was heißt „big“ ? • Ein großes Berechnungsproblem ? • „Viele“ Eingabedaten ? • Strukturierte vs. unstrukturierte Daten • Datenformate sind nichts Neues • Problem des korrekten Einsatzes von
 existierenden Analyseansätzen • Mathematiker und Statistiker sind gefragt • Big data = Werkzeuge zur skalierbaren Datenverarbeitung
 • Rechtfertigen die Datenmengen eigene Infrastrukturen ? 6
  7. 7. Daimler, Oktober 2014 7 Big Data - Wie groß ist groß genug ? [oracle.com] „There are only two companies with a big data problem, Google and the NSA.“
  8. 8. Daimler, Oktober 2014 8 Skalierbare verteilte Systeme Load Balancing Micro Services Sharding [microservices.io]
  9. 9. Daimler, Oktober 2014 Architekturmuster: Micro Services • „Feingranulare“ dienstorientierte Architektur (SOA) • Kleine Dienste (services) und Komponenten • Orientieren sich jeweils nur an einer geschäftlichen Funktion • Einheitliches leichtgewichtiges Kommunikationsprotokoll (HTTP REST) • Unabhängig und automatisch installierbar / aktualisierbar • Programmiersprachen und Datenspeicherung sind lokale Entscheidung • Führt typischerweise zur grobgranularer API (Overhead) • Kein RPC über HTTP, sondern eher dokumentenorientiert • „Smart endpoints, dumb pipe“ -> kein Enterprise Service Bus ! 9
  10. 10. Daimler, Oktober 2014 10 Architekturmuster: Micro Services [Martin Fowler]
  11. 11. Daimler, Oktober 2014 Architekturmuster: Micro Services • Netflix • 2008: Gesamte Funktionalität in einer Web Applikation • 2012: Hunderte von Diensten auf AWS • Entkoppeltes Ausrollen von Funktionen • Dezentralisierte Verwaltung ist Pflicht (DevOps) • Probleme mit Test und Schnittstellenversionierung • Fehlertoleranz entsteht nicht automatisch • Hystrix Projekt - Überwachung und Redundanz als Bibliothek für Entwickler • Amazon: You built it, you run it. • Entwickler sind für den Betrieb ihrer Teile zuständig -> DevOps in Industrie 4.0 ? 11
  12. 12. Daimler, Oktober 2014 12 Netflix
  13. 13. Daimler, Oktober 2014 Architekturmuster • Content-based router • Daten werden an funktionale Komponenten anhand ihrer Eigenschaften weitergeleitet • Consumer-driven contracts • Client-System liefert
 dem Dienst-Anbieter eine
 Test Suite mit den geforderten Erwartungen • Ähnliche Idee: Tolerant reader • Weak consistency • Besseres Verständnis über geforderte Datenkonsistenz • Eventual consistency: Keine Versprechen über Zeitverhalten („noSQL“)im verteilten System bei Aktualisierung der Daten 13
  14. 14. Daimler, Oktober 2014 14 Forschung Verteilte Echtzeitsysteme Skalierbare
 verteilte Systeme Verfügbarkeit und Zuverlässigkeit • Neue Architekturmuster • Konsistenzmodelle • DevOps • Micro Services
  15. 15. Daimler, Oktober 2014 Cyber-physische Systeme • Vernetzung von physikalischen und technischen Elementen • Vernetzung ohne zentrale Kontrolle (Autonomie) • Sensoren und Aktuatoren auf physikalischer Ebene • Kooperative Datenverarbeitung und Rückkoppelung an physikalische Welt • Industrie 4.0 ? • Verlässliche Maschine-zu-Maschine Kommunikation, leichte Rekonfiguration • Vorhersagbare drahtlose Kommunikation im Produktionsumfeld • Forschung • Verteilte Mobilität ist noch nicht vollständig verstanden (Ortswechsel = Störung) • Ziel: Awareness 15
  16. 16. Daimler, Oktober 2014 16 [Acatech] Cyber-physische Systeme
  17. 17. Daimler, Oktober 2014 Internet der Dinge • Verknüpfung von eindeutig identifizierbaren Gegenständen • RFID, Strichcode, QR-Code • Virtuelle Repräsentation in Internet-artiger Struktur • Gemeinsame Konzepte • Benennung (naming) • Sensorik • Informationsverarbeitung • Kommunikation • Neuer Anwendungsfall für bewährte
 Konzepte 17
  18. 18. Daimler, Oktober 2014 18 IoT vs. CPS ‚Cyber‘ Entität ‚Cyber‘ Entität ‚Cyber‘ Entität Physische Entität Physische Entität Physische Entität Internet Internet
 der Dinge Cyber-physische
 Systeme
  19. 19. Daimler, Oktober 2014 19 Beispiel: Time-Triggered Architecture [Kopetz]
  20. 20. Daimler, Oktober 2014 20 Forschung Verteilte Echtzeitsysteme Skalierbare
 verteilte Systeme Verfügbarkeit und Zuverlässigkeit • Cyber-physische
 Systeme • Internet der Dinge • Temporale Firewalls • Mesh - Netzwerke • Neue Architekturmuster • Konsistenzmodelle • DevOps • Micro Services
  21. 21. Daimler, Oktober 2014 Verlässliche Systeme • Neue Architekturmuster als Startpunkt • Alles wird gemessen und korreliert (Big Data) • DevOps mit Echtzeitanforderungen • Neue Granularität der Systemkomponenten • Nicht-funktionale Eigenschaften ? • Informationen sind unvollständig • Zuverlässigkeitszahlen, Zeitverhalten, dynamische Konfiguration • Wechselseitige nicht-funktionale Beziehungen (Safety vs. Security) • Erhöhter Software-Anteil macht das Problem noch schwieriger 21
  22. 22. Daimler, Oktober 2014 22 Andere Domänen - Gleiches Problem
  23. 23. Daimler, Oktober 2014 Beispiel: Verlässlichkeitsmodellierung • Etablierte Methoden der Verlässlichkeitsmodellierung und -analyse • Markov-Ketten, Petri-Netz, Fehlerbaumanalyse, Zuverlässigkeitsblockdiagramm, FMEA, FMECA, Ereignisbaum, HAZOPS, … • Qualitativ vs. quantitativ • Zustandsbasiert vs. komponentenorientiert • Erfolgsraum vs. Ausfallraum • Ergebnisse • Verständnis über die Fehlerzustandsausbreitung • Verständnis von unerwünschten Ereignissen
 und Bedingungen für kontinuierlichen Betrieb • Identifikation kritischer Systemkomponenten 23 8 KAPITEL 1. TE Kosten Performanz Verl¨asslichkeit Nicht-funktionale Eigenschaften Abbildung 1.1: Die Dimensionen der Verl¨asslichkeit, nach Malek. Die beobachtete Funktionalit¨at wird an der Schnittstelle zum System bereitgestellt, w keine Informationen ¨uber die internen Abl¨aufe hat (black box Prinzip). Die korrekte manifestiert sich daher nur im beobachtbaren Verhalten der Systemschnittstelle. Diese der Systemschnittstelle ist die Grundlage f¨ur verschiedenste Verl¨asslichkeitsmechanismen
  24. 24. Daimler, Oktober 2014 Problem #1 - Konfigurierbarkeit • Eigenschaften moderner technischer Systeme • Stetig zunehmende Komplexität von Software und Hardware • Zunehmender Anteil von Software • Modularisierte Architekturen mit optionalen Komponenten • Beispiele: Fahrzeugelektronik, Telefone, eingebettete Steuerungsanlagen, 
 medizinische Geräte, Industrieautomatisierung, … • Flexible Konfiguration • Grad der Redundanz ist frei wählbar • Aufrüstung mit neueren / unbekannten Komponenten • Variabler Funktionsumfang 24
  25. 25. Daimler, Oktober 2014 Problem #2 - Fehlende Daten • Quantitative Verlässlichkeitsanalyse für komplexe Systeme • Schnellere Produktzyklen mit signifikanten Zeitdruck • Unpräzise Architekturmerkmale • Finale Auswahl der verwendeten Komponenten relativ spät • RAS-Analyse ist selten Teil des Budget, eher ‚Nebentätigkeit‘ • Vertrauenswürdige Zuverlässigkeitsdaten als Unsicherheitsfaktor • Einige Domänen müssen das Investment leisten (Sicherheit, sensible Anwendungen) • Viele sind dazu nicht in der Lage • Typischerweise Beschränkung auf rein qualitative Analyse 25
  26. 26. Daimler, Oktober 2014 Beispiel: Verlässlichkeitsmodellierung • Vorschlag: Unterstützung für unpräzise Modellierung • Expliziter Umgang mit partiellen Systemwissen • Unsicherheit als expliziten Teil der Analyse betrachten • Unterstützung von inkrementeller Verbesserung und iterativer Wissenserweiterung • Fokus auf relative Vergleiche, kein „numbers game“ • Ingenieure bevorzugen nicht-zustandsbasierte Modelle • FuzzTrees - Erweitere Fehlerbaumnotation • Analyse von konfigurierbaren Systemen • Nutzung von Methoden der Fuzzy Logik 26 http://amybrucker.com/ P. Tröger, F. Becker, and F. Salfner, “FuzzTrees - Failure Analysis with Uncertainties,” in 19th Pacific Rim International Symposium on Dependable Computing (PRDC), 2013.
  27. 27. Daimler, Oktober 2014 FuzzTree Notation 27 ble ise ble ty. ers nts try ge ed hy are he ng ve ise cit ort em on un- on an- ity N: 4-5 k: N-2 Secondary CPU Failure p=0.08 ± 0.008 Primary CPU Failure p=0.08 ± 0.008 Server Failure Power Unit Failure p=0.15 ± 0.05 RAID 0 Failure RAID 1 Failure Disc Failure p=0.12 ± 0.01 #2 Disc Failure p=0.12 ± 0.01 #2 11.02.13 FuzzEd - Server Failure (1xCPU, N=4, RAID 0) fuzztrees.net/editor/43 1/1 Primary CPU Failure Server Failure Disc Failure #2 RAID 0 Power Unit Failure #4 k/N: 2-4 11.02.13 FuzzEd - Server Failure (1xCPU, N=4, RAID 1) fuzztrees.net/editor/42 Disc Failure #2 RAID 1 Power Unit Failure #4 k/N: 2-4Primary CPU Failure Server Failure 11.02.13 FuzzEd - Server Failure (1xCPU, N=5, RAID 0) fuzztrees.net/editor/48 Primary CPU Failure Server Failure Disc Failure #2 RAID 0 Power Unit Failure #5 k/N: 3-5 11.02.13 FuzzEd - Server Failure (1xCPU, N=5, RAID 1) fuzztrees.net/editor/49 1/1 Primary CPU Failure Server Failure Disc Failure #2 RAID 1 Power Unit Failure #5 k/N: 3-5 11.02.13 FuzzEd - Server Failure (2xCPU, N=4, RAID 0) fuzztrees.net/editor/44 1/1 Secondary CPU Failure Primary CPU Failure Server Failure Disc Failure #2 RAID 0 Power Unit Failure #4 k/N: 2-4 11.02.13 FuzzEd - Server Failure (2xCPU, N=4, RAID 1) fuzztrees.net/editor/45 Secondary CPU Failure Primary CPU Failure Server Failure Disc Failure #2 RAID 1 Power Unit Failure #4 k/N: 2-4 11.02.13 FuzzEd - Server Failure (2xCPU, N=5, RAID 0) k/N: 3-5 Secondary CPU Failure Primary CPU Failure Server Failure Disc Failure #2 RAID 0 Power Unit Failure #5 Server Failure k=3 Primary CPU Failure Secondary CPU Failure Power Unit Failure #5 RAID 1 Disc Failure #2 Fehler- bäume Inclusion Variation Point Redundancy Variation Point Feature Variation Point
  28. 28. Daimler, Oktober 2014 28 Quantitative Analyse es), a reasonable f all the precise deling infeasible y costly activity. n, such numbers me components ck from industry the sole usage ny safety-related ting trustworthy e and software to maintain the n in engineering ng should evolve ns of imprecise certainty explicit order to support nly of the system . to this direction to embrace un- ault tree notation ned with a quan- ecise probability initial FuzzTrees ON ws the causal de- to an undesired d out in multiple dary conditions, tem design, the and quantitative primary events, ts, intermediate s to higher-level N: 4-5 k: N-2 Secondary CPU Failure p=0.08 ± 0.008 Primary CPU Failure p=0.08 ± 0.008 Server Failure Power Unit Failure p=0.15 ± 0.05 RAID 0 Failure RAID 1 Failure Disc Failure p=0.12 ± 0.01 #2 Disc Failure p=0.12 ± 0.01 #2 Figure 1. A FuzzTree example. Dashed lines visualize the variation points. to allow a condensed notation and evaluation of all the possible variations. We explain the extended notation based on a minimal example shown in Figure 1. The tree describes a small part of a real-world server system that has three different system design variation points: • The system could be equipped with a second CPU that acts as a redundant unit for the primary CPU. • The number of power units used in the system is flexible. At least three of the N power units must 0 1 0.05 0.1 0.15 0.2 0.25 x µ CPU Failure Disc Failure Power Unit Failure Figure 8. Membership functions for the example existing efficient solutions, such as the one by Rushdi et al. [13]. For the XOR gate case, the restriction of the possible com- binations is not possible, so all of them must be considered. Beside that, the approach is equivalent to the k-out-of-N case. A. Example Continuing with our illustrating example in Figure 1, we assume some fuzzy membership functions for the probabil- ities of CPU, disc and power failures (see also Figure 8): de C S “e pr the approach is equivalent to the k-out-of-N g with our illustrating example in Figure 1, we e fuzzy membership functions for the probabil- U, disc and power failures (see also Figure 8): U Failure”) = tfn(0.072, 0.08, 0.088) wer Unit Failure”) = tfn(0.1, 0.15, 0.2) c Failure”) = tfn(0.11, 0.12, 0.13) a rather low decomposition number of m = 2, ng in three ↵-cuts that need to be computed. s the resulting intervals for each ↵-cut. As the follows the same principle for each value of ↵, w computations for ↵ = 0. The same holds for system configurations, where we only focus on configuration. Table II S FOR THE ↵-CUTS OF THE BASIC EVENTS IN (2-4-0). CPU Failure Power Unit Failure Disc Failure [0.072, 0.088] [0.100, 0.200] [0.110, 0.130] [0.076, 0.084] [0.125, 0.175] [0.115, 0.125] [0.080, 0.080] [0.150, 0.150] [0.120, 0.120] en example, the top event may happen if either at least 2 out of 4 power units, or one of the = [0.0523, 0.1808] The interval describing the 0-cut for the top event fuzzy probability then equals: X = C _ P _ S = (C _ P) _ S = [0.057212877, 0.187143885] _ S = [0.25321832, 0.384749206] The same computation has to be performed for ↵ = 0.5 and ↵ = 1.0 per instance, resulting in the complete result as shown in Table III and Figure 9. Table III ↵-CUTS FOR ALL SYSTEM CONFIGURATIONS. FuzzTree ↵ = 0.0 ↵ = 0.5 ↵ = 1.0 (2-4-0) [.25322, .38475] [.28271, .34901] [.31482, .31482] (1-4-0) [.30338, .43451] [.33337, .39946] [.36558, .36558] (2-5-0) [.21875, .29246] [.2338, .27057] [.25103, .25103] (1-5-0) [.27122, .34969] [.28792, .3271] [.30651, .30651] (2-4-1) [.06862, .20088] [.09629, .16302] [.12796, .12796] (1-4-1) [.13118, .26552] [.16012, .22787] [.19255, .19255] (2-5-1) [.02563, .08101] [.03467, .06217] [.04677, .04677] (1-5-1) [.09108, .15534] [.10286, .13484] [.11738, .11738] It can be seen that the most reliable configuration is (2-5-1), which is not surprising and could have been also determined by manual inspection. However, other questions are harder to answer without analytical support, such as if “it is more reliable to use two CPUs with RAID 0, or one CPU with RAID 1?”. The example also shows how FuzzTrees can 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 0.2 0.22 0.24 0.26 0.28 0.3 0.32 0.34 0.36 0.38 0.4 0.42 0.44 0 1 (2-4-0) (1-4-0)(2-5-0) (1-5-0)(2-4-1) (1-4-1)(2-5-1) (1-5-1) x µ Figure 9. The resulting top event fuzzy probabilities for all system configurations (a)–(h).
  29. 29. Daimler, Oktober 2014 Software FuzzTrees 29 • Einsatz von FuzzTrees für Abhängigkeitsanalyse in Software • Beispielhafter Einsatz für Ubuntu Paketsystem • ODER-Gatter für kombinierte Abhängigkeiten • Feature Variation Points für Abhängigkeitsalternativen • Inclusion Variation Points für empfohlene Pakete • (Fuzzy) Ausfallwahrscheinlichkeit aus Code-Metriken oder Bug-Statistik http://fuzzed.org
  30. 30. Daimler, Oktober 2014 Beispiel: Proaktive Fehlertoleranz • Reaktive Fehlertoleranz hat Skalierbarkeitsprobleme • Dauer der Fehlererholung korreliert mit Systemgröße, CAP-Theorem • 24/7 Verfügbarkeit im Geschäftsumfeld • Proaktive Fehlertoleranz reagiert ‚im Voraus‘ 30 Fehlertoleranz Latente Fehlerursache Fehler- zustand Normal- betrieb Aktivierung Erkennung Ausfall       
  31. 31. Daimler, Oktober 2014 Beispiel: Proaktive Fehlertoleranz • Erweiterter Ansatz für Anomalieerkennung
 [Oliner et al.] • Inkompatible Metriken für die 
 Überwachung verschiedener
 Systemschichten • Jede Schicht birgt eigene Fehlerursachen • Normalisierung zu Anomaliesignalen • Korrelation der Signale zur Vorhersage
 von Fehlerausbreitung 31
  32. 32. Daimler, Oktober 2014 32 Beispiel: Proaktive Fehlertoleranz !"#$ %&'()*(+&,$-**$ !.'($!.'($ !.'($!.'($ *&/01.&'2$ 3(4/5(6$ 78$ 9::,/5&;.0$8('4('$ 78$ <.'=,.&2$ 9::,/5&;.0$8('4('$ <.'=,.&2$ -/'+>&,/?&;.0$!,>6+('$*&0&@(A(0+$ PhysicalMachineStatusVirtualMachineStatus B(&,+C$D02/5&+.'$E&'@(+$*&5C/0($85C(2>,('$*/@'&;.0$!.0+'.,,('$ "'()2/5+.'6$"'()2/5+.'6$ B&'2F&'($,(4(,G$ !"#$%"&'%&()*+,-.$%/&!/% B&'2F&'($,(4(,G$ !"#$%"&'%&()*+,-.$%/&!/% B&'2F&'(G$ !"#$%"&'%&()*+,-.$%/&!/% "'()2/5+.'6$"'()2/5+.'6$ "'()2/5+.'6$ B&'2F&'($,(4(,G$ !"#$%"&'%&()*+,-.$%/&!/% B&'2F&'($,(4(,G$ !"#$%"&'%&()*+,-.$%/&!/% -/'+>&,$*&5C/0($*.0/+.'G$ -:'.1(H$0123)4$%4()5% "'()2/5+.'6$"'()2/5+.'6$ "'()2/5+.'6$ B&'2F&'($,(4(,G$ !"#$%"&'%&()*+,-.$%/&!/% B&'2F&'($,(4(,G$ !"#$%"&'%&()*+,-.$%/&!/% 7:('&;0@$8I6+(AG$ 63(750$%8,-6)91%!)-,3)(,-.%:0(-0+% "'()2/5+.'6$"'()2/5+.'6$ "'()2/5+.'6$ B&'2F&'($,(4(,G$ !"#$%"&'%&()*+,-.$%/&!/% B&'2F&'($,(4(,G$ !"#$%"&'%&()*+,-.$%/&!/% 9::,/5&;.0$J$*/22,(F&'(G$ #44+,57;)-$%#44<0(=0($%><?@AA% "'()2/5+.'6$"'()2/5+.'6$ F. Salfner and P. Tröger, “Predicting Cloud Failures Based on Anomaly Signal Spreading,” in 42nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2012.
  33. 33. Daimler, Oktober 2014 33 Beispiel: DFD-basierte Schutzanalyse K. Schmidt, P. Tröger, H.-M. Kroll, T. Bünger, F. Krüger, and C. Neuhaus, “Adapted Development Process for Security in Networked Automotive Systems,” in SAE World Congress, 2014.
  34. 34. Daimler, Oktober 2014 34 „Auf den Schultern von Giganten“ Verteilte Echtzeitsysteme Skalierbare
 verteilte Systeme Verlässliche
 (dynamische) Systeme • Unscharfe 
 Verlässlichkeitsmodellierung • Ausfallvorhersage • Anomalieerkennung • Cyber-physische
 Systeme • Internet der Dinge • Temporale Firewalls • Mesh - Netzwerke • Neue Architekturmuster • Konsistenzmodelle • DevOps • Micro Services
  35. 35. Daimler, Oktober 2014 Kontaktdaten Dr. Peter Tröger Akademischer Assistent
 (assistant professor) Technische Universität Chemnitz
 Fakultät für Informatik
 Professur Betriebssysteme
 Straße der Nationen 62, Haus C
 09111 Chemnitz Tel.: +49 371 531 36181
 Fax: +49 371 531 836181 peter.troeger@informatik.tu-chemnitz.de
 www.troeger.eu
 @ptroeger 35

×