Full Paper (PDF) - Institut für Automatisierungs- und Softwaretechnik ...

Zuverlässigkeitsbewertung softwareintensiver
mechatronischer Systeme in frühen Entwicklungsphasen
Dipl.-Ing. P. Jäger, Universität Stuttgart; Dipl.-Ing. M. Wedel, Universität
Stuttgart; Dipl.-Math. oec. A. Gandy, Universität Hohenheim; Prof. Dr.-
Ing. B. Bertsche, Universität Stuttgart; Prof. Dr.-Ing. Dr. h. c. P. Göhner,
Universität Stuttgart; Prof. Dr. U. Jensen, Universität Hohenheim
Kurzfassung
Dieser Beitrag befasst sich mit der systematischen Zuverlässigkeitssicherung
mechatronischer Produkte in frühen Entwicklungsphasen. Da der Begriff Mechatronik heute
auch Softwareanteile beinhaltet, ist es das Ziel, einen Ansatz darzustellen, welcher die
systematische Entwicklung zuverlässiger, softwareintensiver mechatronischer Produkte
unterstützt. Die entsprechende methodische Vorgehensweise bewertet verschiedene
Lösungsvarianten im Hinblick auf das Erreichen einer bestimmten Zuverlässigkeitsvorgabe.
Der vorgestellte Ansatz konzentriert sich auf frühe Entwicklungsphasen, weil dort getroffene
Entscheidungen den größten Einfluss auf den späteren Erfolg eines Produkts haben.
Abstract
This contribution deals with systematically securing the reliability of mechatronic products in
early development phases. As the term mechatronics nowadays also encompasses software
stakes it is the aim to present an approach to systematically develop reliable softwareintensive
mechatronic products. The aim is to present a method that evaluates different
solutions with respect to reaching a certain given reliability goal. The presented approach
concentrates on early development phases, where decision making has the most extensive
impact on later product success.
1. Einführung
Moderne mechatronische Produkte bieten ein weites Spektrum an Funktionen für den
Produktnutzer. Dies ist ein Grund, weshalb mechatronische Produkte heute eine immer
größer werdende Bedeutung erlangen. Zusätzlich erlaubt die Mechatronik die Verbesserung
bisheriger Technologien. Ein Beispiel hierfür sind stufenlos verstellbare Getriebe
(Continuously Variable Transmission, CVT). Die ersten Getriebe dieser Bauart wiesen
weitgehend mechanische und hydraulische Strukturen auf [1]. Moderne CVT [2] verfügen

über eine elektronische Steuerung, die die Leistungsfähigkeit des Getriebes zu steigern
vermag, aber auch zu Unzuverlässigkeiten führen kann.
Zusätzlich zu der Steigerung von Funktionalität und Bedienkomfort ist die
Produktzuverlässigkeit heutzutage ein wichtiger Faktor für den wirtschaftlichen Erfolg eines
Produkts [3]. Die momentanen Probleme, die durch den kombinierten Einsatz von Mechanik
sowie Soft- und Hardware entstehen, zeigen, dass es im Bereich der Zuverlässigkeit
mechatronischer Produkte noch Nachholbedarf gibt. Verschärft wird dieser Umstand
dadurch, dass die Produktlebenszyklen stark gesunken sind und unentdeckte Fehler in
frühen Entwicklungsphasen gravierende Auswirkungen auf den weiteren Verlauf der
Entwicklung haben können.
Häufig stehen in frühen Entwicklungsphasen mehrere Lösungsvarianten für ein
Gesamtsystem zur Auswahl. Es wird eine methodische Vorgehensweise vorgestellt, welche
den Vergleich von Lösungsvarianten hinsichtlich ihrer Zuverlässigkeit in frühen
Entwicklungsphasen ermöglicht. Die Vorgehensweise zielt auf softwareintensive
mechatronische Produkte und bezieht die Domänen Mechanik, Hardware und Software ein,
um eine ganzheitliche Zuverlässigkeitsbetrachtung zu erreichen.
Ein Problem bei der Bewertung der Zuverlässigkeit mechatronischer Systeme ist, dass
Modelle für die Bewertung der Softwarezuverlässigkeit erst anhand von umfangreichen
bereits durchgeführten Entwicklungsprojekten oder anhand von Daten aus dem Test der
bereits entwickelten Software kalibriert werden müssen. Ersteres ist nur selten vorhanden,
letzteres ist in frühen Entwicklungsphasen sicherlich nicht gegeben. Die Idee ist, für die
Software ein Modell zu verwenden, welches einen unbekannten Parameter (im Folgenden
meist als α bezeichnet) aufweist. Grundsätzlich ist dieses Vorgehen, das heißt die Annahme
eines unbekannten Parameters, nicht auf die Software beschränkt. Da jedoch die größten
Probleme bei der Bewertung der Softwarezuverlässigkeit auftreten, ist es sinnvoll, diese
Annahme dort zu verwenden. In der Regel ist für das Gesamtsystem ein zu erreichendes
Zuverlässigkeitsziel gegeben. Man kann nun eine Schranke α zul für den unbekannten
Parameter α angeben, bei der das Ziel gerade noch erreicht wird. Diese Schranke kann als
"Entwicklungsspielraum" interpretiert werden, wobei der Entwicklungsspielraum stets auf
einen einzigen, noch unbekannten Parameter abgebildet werden muss. Die Kenntnis des
Entwicklungsspielraums erlaubt den Vergleich von Lösungsvarianten für das mechatronische
Gesamtsystem.

Der Artikel ist folgendermaßen aufgebaut. In Abschnitt 2 wird der Stand der Technik bei der
Zuverlässigkeitsbewertung mechatronischer Systeme in frühen Phasen erläutert. Abschnitt 3
führt den Ansatz ein und erläutert ihn mittels eines sehr einfachen Beispiels. Abschnitt 4
diskutiert, wie man Software bestehend aus mehreren Komponenten im vorgestellten Ansatz
verwenden kann. Dabei wird die sogenannte Defektdichte von Softwarekomponenten als
Größe für die Zuverlässigkeit herangezogen. In Abschnitt 4 wird diskutiert, wie man diese
Defektdichte bestimmen kann. Abschnitt 5 beinhaltet ein umfangreicheres Beispiel. Es
werden Voraussetzungen und Annahmen für den Vergleich zwischen zwei Lösungsvarianten
für ein PKW Automatikgetriebe skizziert. Eine Lösungsvariante ist ein CVT, die andere ist ein
Stufenautomat. In Abschnitt 6 werden Ergebnisse des Vergleichs diskutiert. Eine
Zusammenfassung findet sich in Abschnitt 7.
2. Stand der Technik bei der Zuverlässigkeitsbewertung mechatronischer Systeme in
frühen Phasen
Ziel der Entwicklungsarbeit in frühen Entwicklungsphasen ist sowohl im rein mechanischen
als auch im mechatronischen Ingenieurwesen die Festlegung einer weiter zu verfolgenden
Lösungsvariante [4]. Die Auswahl der entsprechenden Lösungsvariante wird meist anhand
verschiedener Kriterien durchgeführt. Eines dieser Kriterien ist die Zuverlässigkeit. Die
Zuverlässigkeit ist ein Produktcharakteristikum, das in den drei Domänen Mechanik,
Elektronik und Software jeweils verschiedenen Einflüssen unterliegt und dessen Berechnung
auf gänzlich verschiedenen Datenquellen beruht.
Im Vergleich zu rein mechanischen Strukturen wird der Auswahlprozess in frühen Phasen
insbesondere bei mechatronischen Produkten durch den Umstand einer nicht exakt oder
überhaupt nicht quantifizierbaren Zuverlässigkeit bestimmt. Dieser Umstand soll im
Folgenden näher erläutert werden.
In der Mechanik gibt es für viele Maschinenelemente Modelle, welche aus angegebenen
Betriebsbedingungen und Bauteileigenschaften die Verteilung der Lebensdauer der
Maschinenelemente liefern. Ein bekanntes Erklärungsmodell für den Einfluss von wirkender
Belastung und Bauteileigenschaften (Geometrie und Werkstoff) auf die Zuverlässigkeit ist die
so genannte stress-strength inference [5]. Im Falle der DIN 3990 [6] für die
Zahnradlebensdauerberechnung, sind Modelle für die Beanspruchungsermittlung gegeben,
die in Kombination mit so genannten Wöhlerlinien und zusätzlich evtl. dem
Schadensakkumulationskonzept [7], [8] zu Lebensdauern führen.

Bei elektronischen Komponenten wird zur Beschreibung des Ausfallverhaltens oft eine
Exponentialverteilung genutzt. Diese reicht meistens aus, um das Ausfallverhalten
elektronischer Bauteile im Bereich der nutzbaren Lebensdauer zu modellieren, da im
Gegensatz zu Mechanik hier kein Verschleiß vorliegt. Aufgrund der vergleichsweise starken
Standardisierung sind Lebensdauerwerte für entsprechende Komponenten oft in
Katalogwerken, wie z.B. dem Military Handbook [9], enthalten.
Bei Software kann nicht von Ausfällen aufgrund physischer Gegebenheiten, wie z.B. dem
Bruch eines Zahnrads, gesprochen werden. Softwareausfälle entstehen durch die
Auswirkung eines während der Tests nicht aufgefundenen Programmierfehlers [10]. Dazu
kommen noch Fehler, welche bereits in frühen Phasen begangen wurden, beispielsweise die
fehlerhafte oder nicht erfolgte Umsetzung bestimmter Anforderungen oder Fehler in den
Anforderungen selbst. In der Literatur sind etliche Modelle bekannt, die mittels verschiedener
Softwaremaße, wie z.B. der Anzahl der Codezeilen, die Softwarezuverlässigkeit
beschreiben, aber weder einheitlich noch verallgemeinerbar sind. Dieser Umstand wird in
eindrucksvoller Weise in [11] dargestellt. Die in der Literatur vorgeschlagenen Modelle sind
häufig Regressionsmodelle, deren Parameter mithilfe eines Datensatzes geschätzt werden.
Die teilweise großen Unterschiede zwischen den in der Literatur aufgeführten Modellen
legen den Schluss nahe, dass keine allgemein gültigen Lebensdauer- oder
Zuverlässigkeitsmodelle für Software existieren, sondern bestenfalls fallspezifische Modelle.
Dies führt zu dem Problem, dass es selbst in späten Entwicklungsphasen äußerst schwierig
ist, eine quantitative Zuverlässigkeitsaussage über ein softwareintensives mechatronisches
Produkt zu tätigen. Ferner sind die meisten der oben genannten Datensätze nicht öffentlich
verfügbar, da sie auf proprietären Entwicklungen basieren. Im Gegensatz dazu sind im
Bereich der Open-Source Softwareentwicklung oft Fehlerberichte öffentlich zugänglich, die
zur Analyse der Softwarezuverlässigkeit verwendet werden können [12]. Entwicklungen im
Bereich der Mechatronik sind aber in der Regel nicht Open-Source.
Diese Tatsache trägt dazu bei, dass nicht gewährleistet werden kann, dass das quantitative
Zuverlässigkeitsziel systematisch erreicht wird. Ebenso wenig wird verhindert, dass in frühen
Phasen eine Lösungsvariante ausgewählt wird, bei der die Erreichung des gesteckten
Zuverlässigkeitsziels schwieriger ist bzw. mehr Aufwand erfordert oder unmöglich ist.
Dementsprechend wird eine methodische Vorgehensweise benötigt, um die Auswahl von
Lösungsvarianten zu unterstützen. Damit soll vermieden werden, dass aufgrund der Auswahl
einer unterlegenen Variante entweder zusätzliche Kosten für die Nachbesserung anfallen

oder dass ein unausgereiftes Produkt mit mangelhafter Zuverlässigkeit zum Kunden gelangt.
Beides führt direkt oder indirekt über Garantie- und Kulanzkosten sowie Imageschäden zu
wirtschaftlichen Einbußen. An diesem Punkt setzt die vorgestellte Vorgehensweise an.
3. Ein Ansatz zur Entscheidungsunterstützung bei der Auswahl einer Lösungsvariante
Ansatzpunkt ist der Umstand, dass es für die Softwarezuverlässigkeit kein einheitlich
anwendbares Modell gibt. Vielmehr existieren verschiedene Modelle für jeweilige
Einsatzbereiche, wie es unter anderem durch [13], [14] bestätigt wurde. Dementsprechend
ist es für Firmen nur möglich, die Softwarezuverlässigkeit zu bestimmen, wenn hierfür
spezifische dokumentierte Ausfallldaten vorhanden sind. Diese liegen entweder nicht vor
oder sind sehr schwer übertragbar, sodass die Zuverlässigkeit einer bestimmten
Lösungsvariante in frühen Phasen nicht quantifiziert werden kann. Ferner sind in frühen
Entwicklungsphasen mechatronischer Produkte die Eingangsdaten für die Berechnung der
Zuverlässigkeit von Mechanik und Elektronik meist nicht genau bekannt.
3.1. Bestimmung des Spielraums zur Erreichung eines Zuverlässigkeitszieles
Trotz der Ungenauigkeiten der Eingangsdaten und trotz eines fehlenden allgemeinen
Softwarezuverlässigkeitsmodells besteht die Möglichkeit, eine Bewertung einzelner Systeme
relativ zueinander vorzunehmen (Bild 1). Das Ziel ist dann nicht mehr die Ermittlung der
Zuverlässigkeit, sondern der Vergleich verschiedener Lösungsvarianten. Als
Vergleichskriterium dient der Spielraum zur Erreichung eines vorgegebenen
Zuverlässigkeitszieles (Entwicklungsspielraum).
Lösungsvariante A Lösungsvariante B Lösungsvariante C
Entwicklungsspielraum
Lösungsvariante B
Lösungsvariante A
Bild 1: Auswahl einer Lösungsvariante aufgrund des zur Verfügung stehenden
Entwicklungsspielraums

Dieses Vorgehen wird im Folgenden geschildert. Dabei wird davon ausgegangen, dass für
die Entwicklung ein bestimmter Aufwand eingeplant ist sowie die geforderten Funktionen
bekannt sind. Aufwand und Funktionalität sind für alle Lösungsvarianten identisch. Zu
bestimmen ist nun die Lösungsvariante, welche den größten Entwicklungsspielraum im
Hinblick auf das Erreichen eines vordefinierten Zuverlässigkeitsziels bietet.
3.2. Komponentenorientierte Modellierung der Zuverlässigkeit
Gegenstand der Betrachtung ist das gesamte mechatronische System. Dieses besteht aus
real vorhandenen Mechanik- und Elektronikbauteilen sowie der Informationsverarbeitung,
welche keine direkte physische Repräsentation hat. Aufgrund der physischen Abgrenzbarkeit
von Mechanik- und Elektronikbausteinen hat sich für diese Domänen eine
komponentenorientierte Zuverlässigkeitsmodellierung etabliert. Hierbei repräsentieren die
Komponenten eine oder mehrere Ausfallursachen, deren Ausfallverhalten in der Regel durch
Verteilungen beschrieben wird.
Ähnlich wie in der Mechanik lassen sich auch Softwaresysteme in Komponenten zerlegen.
Nach [15] handelt es sich bei einer Komponente um eine abgeschlossene funktionale
Einheit. Jede dieser Einheiten interagiert mit ihrer Umgebung über wohldefinierte
Schnittstellen und stellt so ihre Funktionen nach außen hin bereit. Allerdings bestehen bei
der Entwicklung von Softwarekomponenten andere Randbedingungen, als sie in der
Mechanik vorzufinden sind. Zwar gibt es bei eingebetteten Systemen auch hier physische
Beschränkungen, z.B. durch den zur Verfügung stehenden Speicher oder Anforderungen an
die Ausführungsgeschwindigkeit; die Aufteilung von Funktionen auf Komponenten kann
jedoch beinahe beliebig erfolgen.
Während in der Mechanik der Zusammenhang zwischen dem Auftreten einer Fehlerart und
der Auswirkung auf das Gesamtsystem fast immer bekannt ist, lässt sich dieser
Zusammenhang bei Software und auch bei speziell für die Informationsverarbeitung
entwickelter Hardware nicht immer einfach ermitteln. Zum einen können fehlertolerante
Strukturen die Auswirkung eines Fehlers verhindern oder Fehler vermeiden. Zum anderen
können Wechselwirkungen auftreten, z.B., dass eine Softwarekomponente die Ausführung
aller anderen blockiert, obwohl keine direkte funktionale Abhängigkeit zwischen diesen
besteht. Aus diesem Grund wird ein geeignetes Modell für das Auftreten von Fehlern in der
Software sowie deren Auswirkung auf andere Komponenten benötigt. Im Folgenden wird die
Annahme zu Grunde gelegt, dass der Ausfall einer Softwarekomponente bewirkt, dass all
ihre Ausgangssignale falsche Werte aufweisen und diese auch an alle anderen

Komponenten weitergeleitet werden, sofern diese miteinander verbunden sind. Diese
Annahme ist sehr pessimistisch, da in der Realität eine Softwarekomponente beim Auftreten
eines Fehlers nicht unbedingt ihre Gesamtfunktionalität verliert. Dies stellt aber für einen
relativen Vergleich von Lösungsvarianten eine zulässige Einschränkung dar, wenn man
davon ausgeht, dass sich diese Annahme auf alle Komponenten gleichermaßen auswirkt.
Trifft dies auf ein zu betrachtendes System nicht zu, so muss mit einem detaillierteren
Fehlermodell gearbeitet werden.
Ein mechatronisches System besteht aus Mechanik-, Elektronik- und Softwarekomponenten.
Diesem System wird eine Zielzuverlässigkeit vorgegeben, z.B. in Form einer
Systemausfallrate oder eines Lebensdauerquantils (B 10 -Lebensdauer). Bei der
Zuverlässigkeitsmodellierung werden den Ausfallarten der Systemkomponenten
Wahrscheinlichkeitsverteilungen zugeordnet, woraus sich die Systemlebensdauer berechnen
ließe. Die hierfür notwendige Wahrscheinlichkeitsverteilung für den Ausfall einer
Softwarekomponente ist in frühen Phasen selten oder gar nicht vorhanden. Nimmt man an,
dass die Zuverlässigkeit der Software mittels einer Exponentialverteilung beschrieben
werden kann, so ist es möglich, eine Schranke für die Ausfallrate der Software anzugeben,
bei deren Unterschreiten das Zuverlässigkeitsziel erreicht wird. Es geht also nicht mehr
darum, aus bekannten Komponentenzuverlässigkeiten eine Systemzuverlässigkeit zu
ermitteln. Vielmehr sollen ausgehend vom Gesamtzuverlässigkeitsziel Rückschlüsse auf die
benötigte Zuverlässigkeit bestimmter - in diesem Fall softwaretechnischer - Komponenten
gezogen werden, sodass das Gesamtzuverlässigkeitsziel gerade noch erreicht wird. Das
Resultat ist eine implizite Aussage über die Softwarezuverlässigkeit. Der folgende Abschnitt
verdeutlicht das prinzipielle Vorgehen durch ein einfaches Beispiel.
3.3. Prinzipielles Vorgehen anhand eines einfachen Beispiels
Ein mechatronisches System, bestehend aus einem Getriebe und der entsprechenden
Getriebesteuerung (Bild 2), soll betrachtet werden. Die Getriebesteuerung teilt sich auf in die
entsprechende Elektronik (Leiterplatte, Chips, usw.) und die darauf ablaufende Software. Der
Einfachheit halber sei angenommen, dass sowohl die Getriebemechanik, die Elektronik als
auch die Software jeweils nur eine Ausfallart aufweisen. Dies soll beim Getriebe ein
Wellenbruch sein, bei der Elektronik der Bruch einer Leiterbahn und bei der Software der
Ausfall dieser durch das Auftreten einer beliebigen Ursache.
Getriebemechanik Elektronik Software
Bild 2: Zuverlässigkeitsblockschaltbild des Beispielsystems

Es wird angenommen, dass die Ausfallzeitpunkte der drei Ausfallarten unabhängig sind und
jeweils einer Exponentialverteilung mit den Ausfallraten λ Mechanik , λ Elektronik und λ Software folgen.
Somit gilt, dass der Ausfallzeitpunkt des Systems ebenfalls einer Exponentialverteilung mit
der Ausfallrate
λ = λ + λ + λ
(1)
System
Mechanik
Elektronik
Software
folgt. Die Annahme konstanter Ausfallraten dient hier zur Vereinfachung dieses
Einführungsbeispiels. In der Anwendung in Abschnitt 5 und 6 werden zeitabhängige
Ausfallraten zugrunde gelegt.
Angenommen als Ziel ist vorgegeben λ System ≤ λ Ziel , so muss, um das Ziel zu erreichen
λ ≤ λ − λ − λ = : λ
(2)
Software
System
Mechanik
Elektronik
zulässig
Software
gelten, wobei λ zulässig Software denjenigen Wert der Ausfallrate der Software beschreibt, bei dem
das Zuverlässigkeitsziel gerade noch erreicht wird und als zulässige Softwareausfallrate
bezeichnet wird.
Diese Berechnung wird für zwei zu vergleichende Lösungsvarianten A und B (Bild 3)
durchgeführt. Das Ergebnis der Berechnung sind zwei zulässige Softwareausfallraten für die
betrachteten Varianten, die miteinander verglichen werden können. Da Funktionalität und
Aufwand für beide Varianten als identisch vorausgesetzt werden, weist eine im Vergleich
höhere zulässige Softwareausfallrate auf einen größeren Entwicklungsspielraum hin. Somit
wäre die Variante mit der höheren zulässigen Softwareausfallrate auszuwählen.
λ
Getriebe-
Getriebe-
Elektronik A
Software A
Elektronik B
Software B
mechanik A
mechanik B
Lösungsvariante A
Lösungsvariante B
zulässig Software A
= λSystem
A
− λMechanik
A
− λElektronik
A
λzulässig
Software B
= λSystem
B
− λMechanik
B
− λElektronik
B
λ zulässig Software A
λ zulässig Software B
Bild 3: Vergleich zweier Lösungsvarianten mittels der zulässigen Softwareausfallrate

Um die Berechnung hier zu vereinfachen, wurde vernachlässigt, dass in realen
mechatronischen Systemen die Mechanik meist entsprechend einer Weibullverteilung
ausfällt und in frühen Phasen gewisse, die Zuverlässigkeit der Komponenten beeinflussende,
Größen nur ungenau, z.B. in Form von Verteilungen, gegeben sind.
3.4. Betrachtung gemischter Strukturen
Mechatronische Systeme zeichnen sich oft durch eine hohe funktionale Komplexität aus.
Dies führt bei der Modellierung der entsprechenden Funktionszuverlässigkeiten zu
gemischten Strukturen, die auch Redundanzen aufweisen können.
Insbesondere sollte Software aber nicht, wie im obigen Beispiel, als monolithischer Block,
sondern entsprechend der tatsächlich zu erwartenden Struktur in Form einzelner
Komponenten betrachtet werden. Dies ist erforderlich, um die unterschiedliche Bedeutung
von möglicherweise mehreren Produkt-Fehlfunktionen aus Sicht des Kunden beschreiben zu
können. Hierbei ist zu berücksichtigen, dass die Funktionsstruktur lediglich einen
Anhaltspunkt für die spätere Gestaltung der Software vorgibt. Es sind aber viele weitere
Gesichtspunkte für die Strukturierung vorhanden wie z.B. die Umgebung, in welcher die
Software ablauffähig sein muss, oder nicht-funktionale Gesichtspunkte, wie z.B. die
Wartbarkeit. In frühen Entwicklungsphasen können Softwarekomponenten identifiziert
werden, welche die geforderten Funktionen grob abbilden. Weiter sind die grundlegenden
Abhängigkeiten innerhalb der Software sowie zu anderen Komponenten des
mechatronischen Systems bekannt. Dies ist die Voraussetzung für die Modellierung der
Gesamtzuverlässigkeit. Der Nachteil beim Vorliegen mehrerer Softwarekomponenten ist
jedoch, dass sich diese durch Aufbau, Komplexität, Nutzungsdaueranteil und somit
schließlich auch in ihrer Ausfallrate unterscheiden.
Zudem sollen ungenaue Informationen, wie in [16] gezeigt, mittels Verteilungen beschrieben
werden. Dies setzt die Verwendung eines Verfahrens voraus, mit dem stochastisch verteilte
Informationen kombiniert werden können. An dieser Stelle wird die Monte Carlo Methode
genutzt, deren Funktionsweise in Abschnitt 6 genauer dargestellt wird. Bei mechatronischen
Systemen ist es nicht realitätsnah, lediglich konstante Ausfallraten als
Zuverlässigkeitsindikatoren zu nutzen, da damit verschleißbedingte Ausfälle mechanischer
Komponenten nicht gut repräsentiert werden können. Mittels der Monte Carlo Methode
können aber Verteilungen beliebiger Art kombiniert werden, was auch dieses Problem
behebt.

Ferner können gemischte Strukturen mit mehreren Softwarekomponenten auftreten, wie es
beispielhaft in Bild 4 gezeigt wird.
Elektronik 1
Software 1
Mechanik 1
Elektronik 2
Software 2 Mechanik 2
Elektronik 3
Bild 4: Zuverlässigkeitsblockschaltbild einer gemischten Struktur mit mehreren
Softwarekomponenten
Wenn annahmegemäß jeder Komponente nur eine Ausfallart zugeordnet wird und diese
unabhängig sind, so ergibt sich die Systemzuverlässigkeit R System für das Beispielsystem aus
Bild 4 entsprechend der Zuverlässigkeiten der Mechatronikkomponenten aus Mechanik (R M1 ,
R M2 ), Elektronik (R E1 , R E2 , R E3 ) und Software (R S1 , R S2 ) zu
R
System
[ − ( 1−
R R )( 1−
R R )( − R )]
= R
. (3)
M 1RM
2
1
E1
S1
E 2 S 2
1
E3
Um einen Wert für die Systemzuverlässigkeit ermitteln zu können, müssen die
Einzelzuverlässigkeiten mathematisch beschrieben werden. Während für Mechanik und
Elektronik häufig geeignete Zuverlässigkeitsmodelle vorliegen, muss für
Softwarekomponenten ein geeignetes Zuverlässigkeitsmodell ausgewählt werden. Hierbei ist
die Unterschiedlichkeit der verschiedenen Softwarekomponenten im Hinblick auf die
Zuverlässigkeit zu berücksichtigen. Zudem ist zu beachten, dass in frühen Phasen zwar
entsprechende Größen bekannt sind, welche die Zuverlässigkeit beeinflussen (z.B.
Komplexität), aber nicht deren exakter Einfluss, sodass keine vollständige
Modellparametrisierung vorgenommen werden kann.
4. Berücksichtigung mehrerer Softwarekomponenten
Nach den Überlegungen im vorherigen Abschnitt werden folgende Annahmen über das
Ausfallverhalten der einzelnen Softwarekomponenten gemacht. Die Ausfallzeitpunkte der
Softwarekomponenten sind unabhängig und folgen je einer Exponentialverteilung. Die
Ausfallrate der i-ten Softwarekomponente ist gegeben durch eine einfache Gleichung der
Form
λ i
= α ⋅Einflussgröße i . (4)

Hierbei stellt der Faktor α einen grundlegenden Zusammenhang zwischen in frühen Phasen
bestimmbaren Eigenschaften einer Softwarekomponente und deren Ausfallrate her. Es wird
keinerlei Kenntnis über α vorausgesetzt. Die Variable Einflussgröße i steht für Eigenschaften
der i-ten Komponente, welche man bereits in frühen Phasen durch eine
Wahrscheinlichkeitsverteilung beschreiben kann.
4.1. Defektdichte als Maß für die Softwarezuverlässigkeit
Die Defektdichte stellt das Verhältnis zwischen der Anzahl der Fehler und der Größe des
untersuchten Objekts dar. Sie ist ein wichtiges Maß für die Softwarezuverlässigkeit [17] und
bietet sich daher als geeignete Einflussgröße für Gleichung (4) an. Nach [18] ist die
Defektdichte aussagekräftiger als die absolute Zahl der Fehler, wobei die Größe eines
Softwareprodukts durch die Zahl der Quellcodezeilen beschrieben werden kann.
In der Praxis auftretende Defektdichten sind beispielsweise nach [19] Werte zwischen
ungefähr 0,1 und 9 Fehler pro tausend Zeilen Quellcode (KLOC). In [20] wird ein
Fehler/KLOC als eine typische Zielgröße für die Softwareentwicklung genannt. Ein weiteres
Beispiel mit Bezug zum Automobilbereich ist das Betriebssystem OSEKturbo, für welches
laut Herstellerangaben Werte bis zu 0,07 Fehler/KLOC erreicht werden [21].
4.2. Abschätzung der Defektdichte anhand verfügbarer Informationen in frühen
Phasen
In [11] wird vorgeschlagen, die Defektdichte mithilfe von Bayesian Belief Nets (BBN) in
Abhängigkeit der Einflussgrößen Komplexität des umzusetzenden Problems sowie
Programmier- und Testaufwand zu bestimmen. Meist liegt in den Unternehmen
undokumentiertes Wissen in Form von subjektiven Entscheidungsabläufen vor, die u.a. auf
langjährigem Erfahrungswissen basieren. Dieses Wissen kann mittels eines BBN formalisiert
werden. Dabei handelt es sich um ein Netz aus Knoten und Kanten, in dem jeder Knoten
eine bestimmte Variable repräsentiert, welche entweder einen diskreten oder einen
kontinuierlichen Wertebereich aufweist. Abhängigkeiten zwischen Variablen können mittels
gerichteter Kanten zwischen den Knoten dargestellt werden. Der Wert eines Knotens folgt
einer Wahrscheinlichkeitsverteilung, die bedingt auf die Werte seiner Vorgänger gegeben ist.
Konkret wird in [11] ein prototypisches BBN vorgestellt, welches sich als Beispiel für die
Abschätzung der Defektdichte sehr gut eignet und hier etwas verkürzt dargestellt ist (Bild 5).

Komplexität
des Problems
Entwicklungsaufwand
Größe des
Quellcodes
Vorhandene
Defekte
Testaufwand
Gefundene
Defekte
Verbleibende
Defekte
Defektdichte
Bild 5: Beispiel für ein Bayesian Belief Net zur Ermittlung der Defektdichte nach [11]
In diesem Beispiel haben die in frühen Phasen abschätzbaren Einflussfaktoren wie
Problemkomplexität, Entwicklungs- und Testaufwand, Größe des Quellcodes usw.
Auswirkungen auf die Defektdichte. Dieses einfache Beispiel kann nun beliebig verfeinert
und an die spezifischen Bedürfnisse einer Firma angepasst werden. Im gezeigten Beispiel
wurde den meisten Knoten ein diskreter Wertebereich zugewiesen, z.B. kann die
Komplexität des Problems zwischen „sehr niedrig“ und „sehr hoch“ liegen. Der Einfluss eines
Knotens auf einen anderen über die gerichteten Kanten wird in Form von Tabellen
angegeben. Die Werte in diesen Tabellen basieren auf dem Expertenwissen der jeweiligen
Anwender. Ebenso können weitere Einflussfaktoren und deren Abhängigkeiten
berücksichtigt werden, was eine firmenspezifische Ausprägung der Modellierung erlaubt.
Aus Bild 5 wird ersichtlich, dass sich alle modellierten Einflussfaktoren auf eine Zielgröße
fokussieren. In [11] werden mehrdimensionale Ansätze kritisch beleuchtet, da bereits ab
wenigen Einflussfaktoren das Modell eine ausreichende Korrelation zum realen Verhalten
aufweist und jede zusätzliche Dimension eine immer geringere Verbesserung der Korrelation
bewirkt [22]. Weiter wird in [23] darauf hingewiesen, dass eine einzelne Maßzahl mehrere
Einflussfaktoren abbilden kann. Dementsprechend kann man viele der in frühen Phasen
vorhandenen Informationen über Softwarekomponenten in ihrer Auswirkung auf die
Defektdichte modellieren, was zu Informationen über die Defektdichten der einzelnen
Softwarekomponenten führt.

4.3. Modellierung weiterer Einflussfaktoren auf die Softwarezuverlässigkeit
Eine direkte Berechnung der Systemzuverlässigkeit ist auf dieser Basis aber noch nicht
möglich, da im Falle von Gleichung (4) der Modellparameter α unbekannt ist. Zusätzlich
muss berücksichtigt werden, dass es neben der Defektdichte auch noch Einflussfaktoren
gibt, die sich erst beim Einsatz einer Komponente auf die Zuverlässigkeit auswirken können.
So spielt beispielsweise die unterschiedliche Nutzungsintensität von Softwarekomponenten -
in diesem Zusammenhang wird oft der Begriff operational profile genutzt - eine Rolle.
Eine notwendige Bedingung für das Auftreten eines Softwarefehlers ist, dass die fehlerhafte
Stelle ausgeführt wird. Somit weist eine Komponente, die nur während 10 % der
Systembetriebszeit genutzt wird, ein viel geringeres Ausfallrisiko auf, als wenn sie permanent
betrieben wird. Um diesen Umstand zu berücksichtigen, wird das Modell aus Gleichung (4)
zu einem verfeinerten Modell der Form
λ i
= α ⋅ Einflussgröße i ⋅ opi
. (5)
Der Faktor op i wird hierbei wiederum aus Erfahrungswissen bestimmt. Aufgrund der schon
mehrfach beschriebenen Datenungenauigkeiten in frühen Entwicklungsphasen sind auch die
Defektdichte und der Faktor op i eventuell davon beeinflusst. Auf Basis des bisher Gezeigten
ist es also möglich, fast allen Größen für die Bestimmung der Systemzuverlässigkeit einen
quantitativen Wert zuzuordnen. Diese Werte können deterministisch sein oder durch eine
Verteilung beschrieben werden. Lediglich der Faktor α ist noch unbekannt, da man ihn nicht
direkt aus Entwicklungsdaten heraus bestimmen kann.
Somit stellt der Faktor α bei der Bestimmung der Zuverlässigkeit der verschiedenen
Lösungsvarianten den letzten verbleibenden Freiheitsgrad dar. Dies erlaubt es, diesen
Faktor als Vergleichsmaßstab für den Entwicklungsspielraum zu nutzen. Zu berücksichtigen
ist hierbei die Voraussetzung, dass der Faktor α für alle Softwarekomponenten als konstant
angenommen wird. Dies ist zulässig, da zunächst davon ausgegangen wird, dass sich alle
Softwarekomponenten bei Auftreten eines Fehlers gleich verhalten, wie oben bereits
beschrieben wurde. Falls dies nicht ausreichend ist, können – wie bereits für den Faktor op
dargestellt – weitere komponentenspezifische Einflussfaktoren im Modell berücksichtigt
werden. Der Ansatz lässt sich aber nicht ohne weiteres auf ein mehrdimensionales α
erweitern.
5. Anwendungsbeispiel
Die zuverlässigkeitstechnische Bewertung mechatronischer Systeme in frühen
Entwicklungsphasen soll anhand eines Beispiels dargelegt werden. Zu bewerten sind zwei

mögliche Lösungen für die Konstruktion eines PKW-Automatikgetriebes mit drei Gangstufen.
Für beide Varianten sind die funktionalen Anforderungen und der zulässige
Entwicklungsaufwand als identisch anzusehen. Als Zuverlässigkeitsziel wird eine bestimmte
Lebensdauer vorgegeben, welche mindestens einzuhalten ist.
5.1. Mögliche Lösungsvarianten
Die in der Konzeptphase erarbeiteten Lösungsvorschläge sind in Bild 6 dargestellt. Es
handelt sich zum einen um ein CVT mit einem Wandler als Anfahrelement. Mittels der
Getriebesteuerung können die geforderten drei festen Übersetzungen dargestellt werden.
Das Alternativkonzept ist ein 3-Gang-Stufenautomat, ebenfalls mit Wandleranfahrelement
und mit Lamellenkupplungen.
Bild 6: Die zu vergleichenden Konzepte CVT (links) und Stufenautomat (rechts)
Das Getriebeeingangsmoment kann aufgrund noch existierender Planungsunsicherheiten
lediglich in Form einer Gleichverteilung angegeben werden und wäre für beide Konzepte
identisch. Die Gangstufen der beiden Getriebe sollen die Übersetzungen 2,9 (1. Gang), 2,0
(2. Gang) und 1 (3. Gang) liefern. Die Laufzeitanteile des Wandlers sowie der drei Gänge
gemessen in Umdrehungen der Getriebeeingangswelle werden als bekannt vorausgesetzt.
Es wird ferner davon ausgegangen, dass das Getriebeeingangsmoment durchschnittlich
konstant ist.

Zunächst muss für die Konzepte die mechanische Struktur zuverlässigkeitstechnisch
analysiert werden. Es ergeben sich hierbei für das CVT die kritischen Komponenten
• Axiallager im Wandler,
• Ölpumpe,
• Lauffläche des oberen Kegelscheibensatzes und
• die Lauffläche des unteren Kegelscheibensatzes.
Bei dem Stufenautomaten wird der identische Wandler und somit auch dasselbe Axiallager
verbaut, was bei annahmegemäß identischer Belastung zu gleichem Ausfallverhalten führen
wird. Die Ölpumpe im CVT ist baugleich mit der im Automaten, wird aber im Automaten
weniger stark belastet. Das Hauptunterscheidungsmerkmal zwischen CVT und Automat sind
die Stufensätze des Automaten, die je nach Gang zu den Ausfallarten Zahnbruch und
Grübchen führen können.
Im Rahmen einer quantitativen Zuverlässigkeitsanalyse müssen die verschiedenen
Ausfallarten quantitativ beschrieben werden. Insbesondere in frühen Entwicklungsphasen ist
dies jedoch nur eingeschränkt möglich. Manche der Parameter, welche die Verteilung der
Ausfallarten beschreiben, sind nur näherungsweise bekannt. Diese Unsicherheit kann
dadurch berücksichtigt werden, dass den unsicheren Parametern statt eines festen
Zahlenwertes eine Wahrscheinlichkeitsverteilung zugeordnet wird. Die folgende
Datenbeschreibung spiegelt dies wider.
Bekannte Größen in frühen Phasen
Bei dem Wandler-Axiallager wird von Weibull verteiltem Ausfallverhalten ausgegangen.
Aufgrund von Vorgängerinformationen wird eine bestimmte B 10 -Lebensdauer angenommen.
Diese könnte z.B. 800 Mio. Umdrehungen (bei dieser Umdrehungsanzahl sind 10 % der
Bauteile ausgefallen) bei einem Eingangsdrehmoment der Eingangswelle von 130 Nm
betragen. Basierend auf Literaturangaben wird ein Weibullformparameter von b = 1,1
gewählt.
Für die Ölpumpe wird entsprechend der nicht von Ungenauigkeiten beeinflussten
Verteilungsparameter t 0 , b und B 10 ein dreiparametriges Weibull-Ausfallverhalten
angenommen. Dabei gibt t 0 die ausfallfreie Zeit an.
Bei den Laufflächen der Kegelscheibensätze ist festzustellen, dass der obere motornahe
Scheibensatz aufgrund der geringeren Anpressradien höhere flächenspezifische

Anpressungen auf die Kette aufzubringen hat, als der untere Satz, was zu einem früheren
Ausfall des oberen Satzes führt.
Da die Scheibensätze ein vergleichsweise neues Produkt sind, bestehen über das
Ausfallverhalten in einer frühen Entwicklungsphase auch noch gewisse Datenunsicherheiten.
So sind für die Scheibensätze Vorversuche durchgeführt worden. Zum Beispiel erhält man
B 50 -Werte für die einzelnen Gänge in Höhe von 300 Mio. Umdrehungen für den 1. Gang und
360 Mio. Umdrehungen für den 2. Gang. Im 3 Gang traten in den Vorversuchen keine
Ausfälle auf. Daher wird das Ausfallverhaltens des 3. Ganges mithilfe von Überlegungen
basierend auf Wöhlerlinien und einer Spannungsanalyse abgeschätzt.
Für die Formparameter der einzelnen Gänge können aufgrund der geringen
Versuchsumfänge keine sicheren Werte angegeben werden. Zur Beschreibung dieser
Unsicherheiten wird ebenfalls wieder eine Gleichverteilung herangezogen.
Beim Stufenautomatikgetriebe wird dieselbe Ölpumpe, wie beim CVT eingesetzt, nur wird
diese weniger stark belastet. Die entsprechenden angepassten Verteilungsparameter t 0 , b
und B 10 sind nicht exakt bekannt und werden durch Verteilungen beschrieben, weil die
vergleichsweise geringere Belastung in ihrer Auswirkung auf die Lebensdauerverteilung
bisher nicht genauer berechnet werden konnte.
Da es sich bei den im Stufenautomaten verwendeten Zahnrädern um Bauteile handelt, die
schon sehr lange im Hinblick auf die Lebensdauerermittlung untersucht werden, kann man
sich für die Ausfallartbeschreibung auf etablierte Vorgehensweisen, wie z.B. die DIN 3990 [6]
stützen. Es ist ein einzuhaltender Achsabstand angegeben und es liegt auch eine
Bauraumrestriktion in Achsrichtung vor. Mit diesen Informationen erfolgt eine
Vordimensionierung, deren Ergebnisse von Ungenauigkeiten geprägt sind, welche in die
weitere Berechnung mit einfließen.
5.2. Aufbau der Steuerung der beiden Getriebe
Als Beispiel für die Steuerung des CVT wurde eine vereinfachte Architektur basierend auf [2]
verwendet (Bild 7). Diese wird nachfolgend aus der Sicht des Kenntnisstands in frühen
Phasen und mit Hinblick auf die Zuverlässigkeitsbetrachtung beschrieben. Für das Beispiel
des Stufenautomaten wird auf entsprechende Änderungen der Steuerung im Vergleich zum
CVT hingewiesen.

Sollübersetzung
Fahrstrategie
Automatisch
Manuell
Gaspedal, Kickdown
Schalthebel (+/-)
Fahrprogramm
Geschwindigkeit
Variatorregelung
Ansteuerung
Wandler-Überbrückungskupplung
Primär-,
Sekundärdrehzahl
Gas-, Bremspedal
Signalverarbeitung
Betriebssystem
Steuergerät
Bild 7: Steuergerät mit Softwarekomponenten und relevanten Ein- und Ausgangssignalen
Steuergerät
Das Steuergerät soll aus einem Mikrocontroller sowie der entsprechenden Software
bestehen. Es wird angenommen, dass auf dem Controller Speicher sowie Schnittstellen für
Feldbusse (z.B. CAN) und andere Ein- und Ausgangssignale untergebracht sind. Sensoren
zur Erfassung von Signalen (z.B. Drehzahlsensor) und Aktoren zur Beeinflussung der
eigentlichen physikalischen Prozessgrößen sollen der Einfachheit halber nicht betrachtet
werden. Sie können aber als weitere Komponenten in das Modell eingefügt werden, wenn
dieser Detaillierungsgrad erforderlich sein sollte. Die Software zur Getriebesteuerung soll die
Komponenten Betriebssystem, Signalverarbeitung und Fahrstrategie (Automatisch/Manuell)
sowie die Regelung der Hydraulik zur Einstellung des Getriebes (Variatorregelung) und die
Ansteuerung der Wandler-Überbrückungskupplung enthalten. Die genannten Komponenten
werden im Folgenden kurz vorgestellt.
Betriebssystem
Auf dem Steuergerät stellt ein Betriebssystem grundlegende Basisdienste zur Verfügung.
Für den Automobilbereich kommt dabei ein Betriebssystem nach OSEK/VDX in Frage [24].
Bei OSEK (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug)
handelt es sich um eine offene Architektur, welche unter anderem auch ein

Echtzeitbetriebssystem umfasst. Aufgabe des Betriebssystems ist die Bereitstellung von
Diensten für andere Komponenten, wie etwa das Aktivieren und Beenden verschiedener
Tasks. Fällt das Betriebssystem aus, so stehen diese Basisdienste nicht mehr zur Verfügung
und das gesamte Getriebe funktioniert nicht mehr wie erwartet.
Umwelterkennung / Signalverarbeitung
Hier werden die erfassten Signale aufbereitet und den anderen Komponenten als Eingabe
zur Verfügung gestellt. Manche Signale wie z.B. die Aktivität des Fahrers werden dabei erst
aus mehreren Sensorwerten durch die Umwelterkennung berechnet. Da diese Komponente
in dem gezeigten Beispiel nicht weiter verfeinert wird, wird angenommen, dass das Getriebe
nicht mehr ordnungsgemäß funktioniert, sobald ein Fehler auftritt und damit falsche Signale
ausgegeben werden. Eine mögliche Verfeinerung wären Fehlertoleranzmaßnahmen wie z.B.
die Einführung einer Plausibilitätsprüfung.
Fahrstrategie
Durch die Fahrstrategie wird die optimale Übersetzung für den aktuellen Fahrzustand
bestimmt. Der Fahrer kann wählen, ob er manuell schalten möchte oder ob der
Schaltvorgang automatisch gesteuert werden soll. Beim CVT müssen im manuellen
Fahrbetrieb feste virtuelle Übersetzungen vorgegeben werden, zwischen denen gewählt
werden kann. Da sowohl manuelles wie auch automatisches Schalten die Funktionalität des
Getriebes gewährleisten, wird angenommen, dass beide Komponenten ausfallen müssen,
damit auch das Gesamtsystem Getriebe ausfällt.
Variatorregelung
Diese Komponente ist für die Regelung des Drucks verantwortlich, mit dem das
Schubgliederband an den Variator angepresst wird. Je nach geforderter Übersetzung wird
die Verstellung des Variators so durchgeführt, dass ein Durchrutschen des Bands stets
vermieden wird. Ein Ausfall dieser Komponente ist als extrem kritisch einzustufen, da
dadurch das Getriebe nachhaltig beschädigt werden kann. Weiter entfällt diese Komponente
beim Stufenautomaten, da hier kein Schubgliederband vorhanden ist, sondern
Zahnradstufen eingesetzt werden. Die Hydraulik muss lediglich so angesteuert werden, dass
der korrekte, fest vorgegebene Gang eingelegt wird.
Ansteuerung der Wandler-Überbrückungskupplung
Der Wandler ermöglicht das Anfahren und Anhalten des Fahrzeugs. Bei höheren
Geschwindigkeiten soll die Wandler-Überbrückungskupplung geschlossen werden, um so

den Verlust durch Wärme möglichst gering zu halten. Es wird angenommen, dass diese
Komponente sowohl für das CVT als auch für den Stufenautomaten identisch ist. Fällt die
Überbrückungskupplung aus, so wird davon ausgegangen, dass damit die Funktion des
gesamten Getriebes stark beeinträchtigt wird.
Zuverlässigkeitsblockschaltbild
Aus den obigen Überlegungen ergibt sich das folgende Zuverlässigkeitsblockschaltbild für
die Getriebesteuerung des CVT. Da sowohl der automatische als auch der manuelle
Schaltvorgang das Funktionieren des Gesamtsystems gewährleisten können, sind diese
beiden Komponenten parallel verzweigt. Im Fall des Stufenautomaten entfällt außerdem die
Variatorregelung, wie oben beschrieben.
Steuergerät
(Mikrocontroller)
Betriebssystem
Variatorregelung
Signalverarbeitung
Automatisch
Manuell
Ansteuerung
Wandler-Überbrückungskupplung
Bild 8: Zuverlässigkeitsblockschaltbild der Getriebesteuerung für das CVT
5.3. Bestimmung der Defektdichte für die Softwarekomponenten
Anhand eines geeigneten Modells bzw. dessen firmenspezifischer Ausprägung muss nun
zunächst die Defektdichte der einzelnen Softwarekomponenten abgeschätzt werden.
Basierend auf Bild 5 wurden die folgenden Abhängigkeiten festgelegt und an das
vorliegende Problem angepasst.
Grundsätzlich lässt sich annehmen, dass die Komplexität des Problems sowohl die Größe
des Quellcodes als auch die Zahl der vorhanden Defekte erhöht. Auf der anderen Seite
werden diese beiden Werte reduziert, je höher der Entwicklungsaufwand ist.
Vorhandene Defekte= f 1 (Komplexität des Problems, Entwicklungsaufwand, ε 1 )
Größe des Quellcodes= f 2 (Komplexität des Problems, Entwicklungsaufwand, ε 2 )
(6)
Je nach Testaufwand und der Größe des Quellcodes kann ein bestimmter Anteil der
vorhandenen Defekte gefunden werden.

Gefundene Defekte= f 3 (Vorhand. Defekte, Größe des Quellcodes, Testaufwand, ε 3 ) (7)
Um zu modellieren, dass die beschriebenen Zusammenhänge nicht deterministisch sind,
wurden zusätzlich die Zufallsvariablen ε 1 , ε 2 und ε 3 eingeführt, welche als Störgrößen
fungieren. Für diese Zufallsvariablen werden Verteilungen angenommen. Schließlich
verbleiben im Quellcode diejenigen Defekte, welche nicht beim Testen aufgefunden werden
konnten. Die eigentliche Defektdichte ist der Quotient aus der Zahl der verbleibenden
Defekte und der Größe des Quellcodes.
Verbleibende Defekte= Vorhandene Defekte - Gefundene Defekte
Defektdichte = Verbleibende Defekte / Größe des Quellcodes in KLOC
(8)
Auf eine Beschreibung der genauen Form von f 1 , f 2 , f 3 wird hier verzichtet. Die verwendete
Wahl dieser Funktionen ergibt ein Bayessches Modell, welches nicht mit dem in [11]
vorgeschlagenen Modell übereinstimmt und welches auch nicht mehr in Form eines BBN
dargestellt werden kann.
6. Anwendung der methodischen Vorgehensweise
In diesem Abschnitt sollen Auswertungen für das Beispiel des PKW-Automatikgetriebes
dargestellt werden. Das betrachtete Modell der zwei Lösungsvarianten beinhaltet Parameter
b 1 ,...,b k , die gewissen Wahrscheinlichkeitsverteilungen folgen. Hieraus resultiert eine
Wahrscheinlichkeitsverteilung der Schranken für α, die mit α zul,CVT für das CVT und mit α zul,Stuf
für den Stufenautomaten bezeichnet werden. Einige der Parameter b 1 ,...,b k beeinflussen
sowohl das CVT als auch den Stufenautomaten. Deswegen sind α zul,CVT und α zul,Stuf nicht
unabhängig. Die Verteilung von α zul,CVT und α zul,Stuf kann man wie folgt mithilfe der Monte
Carlo Methode erhalten.
Es werden n unabhängige Wiederholungen (Replikationen) durchgeführt, in denen jeweils
die Parameter b 1 ,...,b k entsprechend den angenommenen Verteilungen gezogen werden. In
jeder Wiederholung berechnet man nun α zul,CVT und α zul,Stuf . Die sich hieraus ergebenden
empirischen Verteilungen werden als Näherung der exakten Verteilungen verwendet. Durch
Erhöhung der Anzahl der Wiederholungen kann man die Verteilung von α zul,CVT und α zul,Stuf
beliebig gut annähern.
In unserem Beispiel ist das Zuverlässigkeitsziel eine Schranke für den B 10 -Wert. Im
Gegensatz zu dem einfachen auf Exponentialverteilungen beruhenden Beispiel aus

Abschnitt 3.3 kann hier α zul,CVT und α zul,Stuf nicht explizit berechnet werden. Diese Berechnung
erfordert den Einsatz einer eindimensionalen numerischen Nullstellensuche.
Im Folgenden wurde die Monte-Carlo Methode stets mit n = 1000 Wiederholungen
angewandt. Plottet man die sich so ergebenden empirischen Verteilungsfunktionen von
α zul,CVT und α zul,Stuf, so ergibt sich Bild 9. Es suggeriert, dass der Stufenautomat mehr
Entwicklungsspielraum erlaubt als das CVT. Die Verteilungsfunktion von α zul,CVT liegt „links“
von der Verteilungsfunktion von α zul,Stuf , was im Sinn der so genannten stochastischen
Ordnung bedeutet, dass α zul,CVT kleiner als α zul,Stuf ist. Aus Bild 9 lässt sich aber nicht
schließen, dass α zul,CVT ≤ α zul,Stuf immer (d.h. mit Wahrscheinlichkeit 1) gilt. Man kann aber die
Wahrscheinlichkeit der Gültigkeit von α zul,CVT ≤ α zul,Stuf angeben. Aus dem in Bild 10 gezeigten
Plot der Verteilungsfunktion von α zul,CVT - α zul,Stuf lässt sich diese Wahrscheinlichkeit direkt
ablesen – sie ist der Schnittpunkt der Kurve der Verteilungsfunktion mit der y-Achse. Im
vorliegenden Beispiel ergibt sich, dass α zul,CVT ≤ α zul,Stuf mit einer Wahrscheinlichkeit von ca.
80 % gilt. Somit weist mit einer Wahrscheinlichkeit von 80 % der Stufenautomat einen
höheren Entwicklungsspielraum auf als das CVT.
P (α zul ≤ x)
0.0 0.2 0.4 0.6 0.8 1.0
CVT
Stufenautomat
0.0 e+00 2.0 e-08 4.0 e-08 6.0 e-08 8.0 e-08 1.0 e-07 1.2 e-07
x
Bild 9: Verteilungsfunktion von α zul,CVT und α zul,Stuf

P (α zul,CVT −α zul,Stuf ≤ x)
0.0 0.2 0.4 0.6 0.8 1.0
-1 e-07 -5 e-08 0 e+00 5 e-08
x
Bild 10: Verteilung der Differenz der Faktoren α zul beider Lösungsvarianten
Um die beschriebene Beurteilung vornehmen zu können, sind, wie oben dargestellt,
zunächst die Defektdichten der einzelnen Softwarekomponenten zu ermitteln. Mithilfe der
Modellgleichungen (6) - (8) lassen sich Verteilungen für die Defektdichten der
Softwarekomponenten berechnen. Diese sind als Eingangsdaten für die Modellierung der
Ausfallraten einzelner Softwarekomponenten erforderlich. Bild 11 zeigt die Verteilung der
Defektdichte für die Steuerung der Wandler-Überbrückungskupplung unter der Annahme,
dass sowohl die Komplexität wie auch der Entwicklungs- und Testaufwand verhältnismäßig
hoch sind. Die Komplexität hängt von den geforderten Funktionen ab, welche in diesem Fall
als entsprechend umfangreich angenommen werden.

P (dd w ≤ x)
0.0 0.2 0.4 0.6 0.8 1.0
0.0 0.2 0.4 0.6 0.8 1.0
x
Bild 11: Beispielhafte Defektdichte für die Softwarekomponente zur Steuerung der Wandler-
Überbrückungskupplung
Ein Problem wurde bisher noch nicht erwähnt. Bei der Berechnung von α zul,CVT und α zul,Stuf
kann es passieren, dass kein α ≥ 0 existiert, mit dem das Ziel erreicht wird. Anders formuliert
kann man in einem solchen Fall das Ziel selbst mit perfekter Software nicht erreichen. Falls
dieser Fall eintritt, so setzen wir α zul,CVT = -∞ bzw. α zul,Stuf = -∞. Verschärft man in unserem
Beispiel die Anforderung an das Gesamtsystem von einem B 10 -Wert von mindestens 0,5·10 8
Umdrehungen der Eingangswelle auf 1,5·10 8 Umdrehungen, so ergibt sich das zu Bild 9
analoge Bild 12 der Verteilungsfunktionen von α zul,CVT und α zul,Stuf . Mit einer
Wahrscheinlichkeit von ca. 35 % erreicht man bei dem CVT das gesteckte
Zuverlässigkeitsziel nicht.

P (α zul ≤ x)
0.0 0.2 0.4 0.6 0.8 1.0
CVT
Stufenautomat
0.0 e+00 5.0 e-09 1.0 e-08 1.5 e-08 2.0 e-08 2.5 e-08
x
Bild 12: Plot der Verteilungsfunktionen von α zul,CVT und α zul,Stuf bei verschärftem
Zuverlässigkeitsziel
7. Zusammenfassung
In diesem Beitrag wurde dargestellt, wie in frühen Entwicklungsphasen mechatronischer
Produkte der Auswahlprozess von Lösungsvarianten im Hinblick auf die Erreichung eines
Zuverlässigkeitsziels unterstützt werden kann. Kernelement der vorgestellten
Vorgehensweise ist die Idee, die Zuverlässigkeit nicht direkt ermitteln zu wollen, sondern den
noch zulässigen Spielraum zur Erreichung eines Zuverlässigkeitsziels zu bewerten. Dies
wird ermöglicht durch die komponentenorientierte Betrachtung des Gesamtsystems – auch
der Software – und der realitätsnahen Modellierung von Eigenschaften der Software
bezüglich der Zuverlässigkeit. Mittels der Monte Carlo Methode können in frühen Phasen
typischerweise vorhandene ungenaue Daten, z.B. aus der Befragung von Experten,
gehandhabt werden. Anhand zweier verschiedener Lösungsvarianten in Form von
unterschiedlichen Gesamtgetriebekonzepten wurde gezeigt, auf welchen Informationen der
Auswahlprozess basiert und wie er praktisch durchzuführen ist.
Die vorgestellte Vorgehensweise ermöglicht es einem Anwender, ohne firmenspezifisches
dokumentiertes Ausfallverhalten, insbesondere von Software, Zuverlässigkeitsbewertungen
durchzuführen. Ist jedoch ein solches Ausfallverhalten innerhalb einer Firma ausreichend
dokumentiert und auf eine entsprechende Entwicklung in frühe Phasen übertragbar, erlaubt

dies eine weiterreichende Beurteilung. Solange eine solche Dokumentation nicht vorliegt,
stellt die vorgestellte Vorgehensweise ein geeignetes Instrument dar.
Der Beitrag entstand im Rahmen der Forschergruppe 460, welche durch die Deutsche
Forschungsgemeinschaft gefördert wird.
8. Literaturverzeichnis
[1] Bernhard, W., Heidemeyer, Y.: Auswahl und Strukturen stufenloser PKW-Getriebe. VDI
Berichte 803, 1990 Drehzahlvariable Antriebe. VDI Verlag
[2] Greiner, J., Kiesel, J., Veil, A., Strenkert, J.: Front-CVT Automatikgetriebe (WFC280)
von Mercedes-Benz. VDI Berichte 1827. Getriebe in Fahrzeugen 2004
[3] Bertsche, B., Lechner, G.: Zuverlässigkeit im Fahrzeug- und Maschinenbau. Springer
Verlag 2004
[4] Gausemeier, J.; Möhringer, S.: Die neue Richtlinie VDI 2206: Entwicklungsmethodik für
mechatronische Systeme. VDI Berichte 1753. 2003
[5] O’Connor, P.D.T.: Practical reliability engineering. Chichester; Wiley, 2002
[6] DIN 3990-31, Ausgabe:1990-07, Tragfähigkeitsberechnung von Stirnrädern;
Anwendungsnorm für Schiffsgetriebe
[7] Palmgren, A.: Die Lebensdauer von Kugellagern. VDI-Z 58 (1924), S. 339/41
[8] Miner, M. A.: Cumulative damage in fatigue. J. Appl. Mech. 12 (1945), S. 159/64
[9] Department of Defense: Reliability Prediction Of Electronic Equipment. MIL-HDBK-
217F, Washington, DC., Notice 1, Dezember 1991
[10] Becker, G.: Softwarezuverlässigkeit: Quantitative Modelle und Nachweisverfahren. De
Gruyter 1989
[11] Fenton, N.E., Neil, M.: A Critique of Software Defect Prediction Models. Software
Engineering, 25 (1999), 5, S. 675-689
[12] Gandy, A., Jensen, U.: A Nonparametric Approach to Software Reliability. Appl. Stoch.
Models Bus. Ind. 20 (2004), S. 3-15
[13] Nagappan, N., Williams, L., Vouk, M.: Towards a Metrics Suite for Early Reliability
Assessment. 14. IEEE International Symposium on Software Reliability Engineering,
(ISSRE), Fast Abstract, USA 2003
[14] Rosenberg, L., Hammer, T., Shaw, J.: Software Metrics and Reliability. 9th
International Symposium on Software Reliability Engineering, Deutschland 1999.
[15] Szyperski, C.: Component Software – Beyond Object-Oriented Programming. New
York: Addison-Wesley 1998

[16] Jäger, P.; Gandy, A.; Bertsche, B.; Jensen, U. 2004. Decision Support in Early
Development Phases – A Case Study form Machine Engineering. Eingereicht beim
International Journal of Reliability, Quality and Safety Engineering (IJRQSE)
[17] Naixin Li, Yashwant K. Malaiya, Jason Denton: Estimating the Number of Defects: A
Simple and Intuitive Approach. International Symposium on Software Reliability
Engineering, Deutschland 1998
[18] Ebert, C., Dumke, R.: Software-Metriken in der Praxis. Berlin: Springer Verlag 1996
[19] McGarry, F., Pajerski, R., Page, G., Waligora, S., Basili, V.R., and Zelkowitz, M.V.:
Software Process Improvement in the NASA Software Engineering Laboratory.
Software Engineering Institute, Carnegie Mellon University, Technical Report
CMU/SEI-94-TR-22 , Dezember 1994
[20] Holzmann, G.J.: Economics of Software Verification. In Proc. Workshop on Program
Analysis for Software Tools and Engineering, Snowbird, Utah, USA, June 2001
[21] Statement of Quality, Test and Process Maturity for OSEK turbo, Prospekt,
metrowerks, Austin, USA, v2.1draft
[22] Denaro, G., Morasca, S., Pezzè, M.: Deriving Models of Software Fault-Proneness.
SEKE ’02, Ischia, Italien
[23] Munson, J.C., Khoshgoftaar, T.M.: Regression Modelling of Software Quality: An
Empirical Investigation. Information and Software Technology, 32 (1990), 2, S. 106-114
[24] www.osek-vdx.org