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

ias.uni.stuttgart.de

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

Weitere Magazine dieses Users
Ähnliche Magazine