Verteilte Software-Systeme im Kontext von Industrie 4.0

Verteilte Software-Systeme im Kontext von Industrie 4.0
Impulsvortrag
Dr. Peter Tröger

Technische Universität Chemnitz

7. Oktober 2014

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]

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]

Daimler, Oktober 2014 4
Forschung
Verteilte
Echtzeitsysteme
Skalierbare 
verteilte Systeme
Verfügbarkeit und
Zuverlässigkeit

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äuﬁgkeit 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

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

Big Data - Wie groß ist groß genug ?
[oracle.com]
„There are only two companies with a big data problem, Google and the NSA.“

Skalierbare verteilte Systeme
Load Balancing
Micro
Services
Sharding
[microservices.io]

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

[Martin Fowler]

• Netﬂix

• 2008: Gesamte Funktionalität in einer Web Applikation

• 2012: Hunderte von Diensten auf AWS

• Entkoppeltes Ausrollen von Funktionen

• Dezentralisierte Verwaltung ist Pﬂicht (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

Netﬂix

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

Forschung
Verteilte
Echtzeitsysteme
Skalierbare 
verteilte Systeme
Verfügbarkeit und
Zuverlässigkeit
• Neue Architekturmuster
• Konsistenzmodelle
• DevOps
• Micro Services

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 Rekonﬁguration

• Vorhersagbare drahtlose Kommunikation im Produktionsumfeld

• Forschung

• Verteilte Mobilität ist noch nicht vollständig verstanden (Ortswechsel = Störung)

• Ziel: Awareness
15

[Acatech]
Cyber-physische Systeme

Internet der Dinge
• Verknüpfung von eindeutig identiﬁzierbaren 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

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

Beispiel: Time-Triggered Architecture
[Kopetz]

Forschung
Verteilte
Echtzeitsysteme
Skalierbare 
verteilte Systeme
Verfügbarkeit und
Zuverlässigkeit
• Cyber-physische 
Systeme
• Internet der Dinge
• Temporale Firewalls
• Mesh - Netzwerke
• DevOps
• Micro Services

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 Konﬁguration

• Wechselseitige nicht-funktionale Beziehungen (Safety vs. Security)

• Erhöhter Software-Anteil macht das Problem noch schwieriger
21

Andere Domänen - Gleiches Problem

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ässlichkeit
Nicht-funktionale Eigenschaften
Abbildung 1.1: Die Dimensionen der Verlässlichkeit, nach Malek.
Die beobachtete Funktionalität wird an der Schnittstelle zum System bereitgestellt, w
keine Informationen über die internen Abläufe hat (black box Prinzip). Die korrekte
manifestiert sich daher nur im beobachtbaren Verhalten der Systemschnittstelle. Diese
der Systemschnittstelle ist die Grundlage für verschiedenste Verlässlichkeitsmechanismen

Problem #1 - Konﬁgurierbarkeit
• 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 Konﬁguration

• Grad der Redundanz ist frei wählbar

• Aufrüstung mit neueren / unbekannten Komponenten

• Variabler Funktionsumfang
24

Problem #2 - Fehlende Daten
• Quantitative Verlässlichkeitsanalyse für komplexe Systeme

• Schnellere Produktzyklen mit signiﬁkanten 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

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 konﬁgurierbaren 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 Paciﬁc Rim
International Symposium on Dependable
Computing (PRDC), 2013.

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
fuzztrees.net/editor/42
Disc
Failure
#2
RAID
1
Power
Unit
Failure
#4
k/N:
2-4Primary
CPU
Failure
Server
Failure
Primary
CPU
Failure
Server
Failure
Disc
Failure
#2
RAID
0
Power
Unit
Failure
#5
k/N:
3-5
Primary
CPU
Failure
Server
Failure
Disc
Failure
#2
RAID
1
Power
Unit
Failure
#5
k/N:
3-5
Secondary
CPU
Failure
Primary
CPU
Failure
Server
Failure
Disc
Failure
#2
RAID
0
Power
Unit
Failure
#4
k/N:
2-4
Secondary
CPU
Failure
Primary
CPU
Failure
Server
Failure
Disc
Failure
#2
RAID
1
Power
Unit
Failure
#4
k/N:
2-4
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

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).

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

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
  





• 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

!"#$
%&'()*(+&,$-**$
!.'($!.'($
!.'($!.'($
*&/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.

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.

„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
• DevOps
• Micro Services

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

Verteilte Software-Systeme im Kontext von Industrie 4.0

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Verteilte Software-Systeme im Kontext von Industrie 4.0

Ähnlich wie Verteilte Software-Systeme im Kontext von Industrie 4.0 (20)

Mehr von Peter Tröger

Mehr von Peter Tröger (20)

Verteilte Software-Systeme im Kontext von Industrie 4.0