Design for Testability: Effizienzsteigerung für den gesamten ...rentschler/Publications/...-...

Markus Rentschler, Hirschmann Automation & Control

Berlin, 27.09.2012

Design for Testability: Effizienzsteigerung für den gesamten

Produktlebenszyklus

2ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

1. Motivation2. Design for Testability3. Produktlebenszyklus4. Testaktivitäten im Produktlebenszyklus5. Testarten im Produktlebenszyklus6. Quantifizierung der Testkosten7. ROI-Ermittlung8. Lösungsansatz „Design for System Testability“

• Methodik• Prozess

9. Fazit

Agenda

Rentschler, Markus: "Design for Testability - The Holistic Future of Testing?". In: Testing Experience (2011), 12, Nr. 16

3ATAMI 2012, © Markus Rentschler

Industrial Ethernet Produkte

FiberINTERFACES

Control Room Switches

RuggedizedSwitches

Wireless LAN Backbone Switches

Security IP67-Industrial Switches

Control Level Switches

Network Management

Field Level Switches

4ATAMI 2012, © Markus Rentschler

In der Automatisierungspyramide

5ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Definition

„DFT is a design characteristic that enables the diagnosis and/or test of a product to be accomplished easily, in a timely fashion, and costeffectively.“

Ziele

- Kosten und Aufwand für das Testen und die Diagnose senken (und zwar in allen Lebenszyklusphasen)

Vorgehensweise

- Technische Möglichkeiten aufzeigen � Methoden definieren- Umsetzung erzwingen � Prozesse definieren

Design for Testability

ALANEN, J. ; UNGAR, L.Y.: Comparing software design for testability to hardware DFTand BIST. In: AUTOTESTCON, 2011 IEEE, 2011. – ISSN 1088–7725, S. 272 –278

6ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Produktlebenszyklus

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Programmierung

Produktion

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

7ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Testaktivitäten im Produktlebenszyklus

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Produktion

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

Programmierung

Tests

8ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Testarten Definitionen 1

KomponententestTest einer einzelnen Softwareeinheit

SystemtestTest eines integrierten Systems, um sicherzustellen, das es spezifizierte Anforderungen erfüllt.

RegressionstestErneuter Test eines bereits getesteten Programms bzw. einer Teilfunktionalität nach deren Modifikation mit dem Ziel, nachzuweisen, dass durch die vorgenommenen Änderungen keine Fehler eingebaut oder (bisher maskierte Fehler) freigelegt wurden. [Spillner]

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Produktion

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

Programmierung

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Produktion

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

Programmierung

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Produktion

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

Programmierung

9ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Testarten Definitionen 2

ProduktionstestAm Ende der Serienproduktion wird im Rahmen der Qualitätssicherung an jedem produzierten Gerät die Basisfunktionalität mittels in der Gerätesoftware implementierter Testroutinen getestet.

WartungstestIn der Betriebsphase des Produkts werden aus folgenden Gründen Tests durchgeführt:-Im Rahmen einer Neuinstallation-Reguläre Wartungsarbeiten-Nach einer Betriebsstörung-Erneuter Test nach Fehlerbehebung (Nachtest)

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Produktion

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

Programmierung

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Produktion

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

Programmierung

10ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Testkosten im Produktlebenszyklus

cGesamt = cKT + cST + cPT + cWTGesamtkosten für Tests(pro Feature)

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Produktion

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

Programmierung

Tests

11ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Return on Investment (ROI)

Ziele• Testkosten über alle Lebenszyklusphasen hinweg ermitteln. • Maßnahmen für Einsparungen ermitteln.• Investitionskosten für die Einsparungen ermitteln.• Nachweis eines signifikanten ROI (>>1).

Wirtschaftlichkeitskennzahl

nskostenInvestitio

nskostenInvestitioenEinsparungROI

−=

12ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Aufwand für einzelnen Test

13ATAMI 2012, © Markus Rentschler

Kostenfaktoren

Testkostenbeeinflussende Faktoren

Arbeitskosten (Arbeitszeit x Personalkostensatz)

Infrastrukturkosten (Hardware, Software, ...)

www.hirschmann.com

www.hirschmann.com 14ATAMI 2012, © Markus Rentschler

Wiederholungen im Lebenszyklus

End

of p

rodu

ctlif

e cy

cle

Entwicklungsphasen

Increment 1

j test cycles

Y varia

nts

Increment 2

Increment i

N = i * j * Y

Development

. . .

Wartungszklen

Maintenance

+ m * D

Maintenance

m maintenance cycles

D Dep

loym

ents

15ATAMI 2012, © Markus Rentschler

Kostenfaktoren

Komponententest

cKT = cTE,KT + n⋅ cTD,KT + cMD,KT( )

cWT = cTE,WT + j ⋅ cTD,WT + cMD,WT( )

)( ,, PTTDPTTEPT ckcc +=

cST = cTE,ST + m⋅ cTD,ST + cMD,ST( )

cTE,xx – Kosten für TestentwicklungcTD,xx – Kosten für TestdurchführungcMD,xx – Kosten für manuelle Diagnosen – Anzahl der Komponententests(m-1) – Anzahl der Regressionstestsj – Anzahl der Wartungstests

System - & Regressionstest

Produktionstest

Wartungstest

www.hirschmann.com

Kosten für Testdurchführung

j || k || n || m >> 1� Automatisierung ist

lohnend!

16ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

- Testautomatisierung-Lösungen meist nur auf den Ebenen des Modul-und Systemtests geeignet (nicht für Tests in der Produktions- und Betriebsphase)

- Leistungsmessung und Fehlerdiagnose wird in den unterschiedlichen Testphasen meist mit jeweils unterschiedlichen Werkzeugen durchgeführt

� Können hier Synergien geschaffen werden?

Lösungsanalyse

17ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

- Das zu erahnende Einsparungspotenzial, das durch „einheitliche“ Tests entstehen könnte, aufzeigen und beschreiben.

- Aufbauend auf dem Entwurfsansatz „Design for Testability“ (DfT) die Entwicklung des Ansatzes „Design for System Testability“ (DfST)

- Entwurfsmethoden für „einheitliche“ Testansätze definieren

- Im Entwurfsprozess diese Entwurfsmethoden verpflichtend machen

Lösungsansatz

18ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Einsparungspotenzial

Einsparungspotenzial durch den DfST Ansatz:

Die Testunterstützung muss nur noch einmal entwickelt werden � Einsparung von bis zu drei Testentwicklungen

• Produktionstests sind oft bereits BISTD-Ansätze , werden jedoch nur in einer Phase genutzt

� Für alle Phasen nutzbar machen !

Reduktion der Testzeiten � geringere Testdurchführungskosten

Bessere Diagnosefunktionen � Reduktion der Diagnosekosten

Reduktion der Durchführungszeiten erlaubt höhere Testrate �Steigerung der Produktqualität � weniger Wartungstests

cGesamt = cKT + cST + cPT + cWT

19ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Einsparungspotenzial ?

ROI >> 1 ?

Investition

-Höhere Kosten für BISTD-Testentwicklung

Einsparungen

-Weniger Testentwicklungen-Geringere Testdurchführungskosten-Reduktion der Diagnosekosten-Reduktion der MTTR

ROI = Einsparungen− InvestitionskostenInvestitionskosten

20ATAMI 2012, © Markus Rentschler

Technische Umsetzung von DfST?

21ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Betrachtung der Systemarchitektur

Technisches System

Gerät 1 Input

Gerät 2 Output

Gerät 3

Feature n

Input Output

Technisches System � System- feature

Feature 1

Feature 2

Feature n

Input Output

Blackbox-Ebene

Whitebox-Ebene

System-Ebene

Gerät � Lokales Feature

Feature 1

Feature 2

Feature n

Testobjekt Testobjekt

Testobjekt

22ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Testbarkeitsanforderungen

Technisches System oder Gerät

Feature 1

Feature 2

Feature n

Feature n

Testobjekt

PoC

PoO

Input Output

Blackbox-Ebene

Whitebox-Ebene

PoO

PoC

Point of Control (PoC) – Schnittstellen, über die das Testobjekt mit Testdaten versorgt wird

Point of Observation (PoO) – Schnittstelle, an der die Reaktionen und Ausgaben des Testobjekts beobachtet und aufgezeichnet werden

23ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Testautomatisierung

„Normale“ Testautomatisierung

Testautomatisierung

Testobjekt

Feature 1

Feature 2

Feature n

Input Output

PoO

PoC

Nur in den Entwicklungsphasen anwendbar

24ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Built In (Self) Test and Diagnosis (1)

Eingebaute „Testautomatisierung“

25ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Built In (Self) Test and Diagnosis (2)

„Verteilt“ eingebaute „Testautomatisierung“

Technisches System

Gerät 1

Input Output

Gerät 3

BISTD 1

Feature 1

BISTD 3

Feature 3

Feature m Gerät 2

BISTD 1

Feature 1

Feature 2

BISTD n

Feature n

www.hirschmann.com 26ATAMI 2012, © Markus Rentschler

SUTTA TA

Verteiltes System – Roundtrip Methode

Roundtrip Methode

Sub-feature n.1POC

Sub-feature n.2POO

POO

POC

Populäres Beispiel: PING

27ATAMI 2012, © Markus Rentschler

Für welche Tests ist der DfST-Ansatz geeignet?

Validierung funktionaler Anforderungen

Test von (Hardware-)Teilkomponenten in Embedded Systems

Nicht funktionale Anforderungen (z.B. Performance)

Regressionstest funktionaler Anforderungen

www.hirschmann.com

Einsatzm öglichkeiten

28ATAMI 2012, © Markus Rentschler

Einführung von DfST in den Entwicklungsprozess ?

29ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Produktentstehungszyklus

Entstehungszyklus Produktionszyklus

Abnahmetest Anforderungs-

analyse

funktionaler Systementwurf

technischer Systementwurf

Komponenten-spezifikation

Systemtest

Integrationstest

Komponententest

Fertigung

Betriebszyklus

Wartung/Support

Entwicklungszyklus Testzyklus

Weiterent-wicklung

Programmierung

Design Phase

30ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Entwicklungsprozesse

In der „Design Phase“ keine Testbarkeitsanalyse

PM

LE/ST

PL

CRS – Customer Requirement SpecificationPSS – Product Solution StudySAS – System Architecture Specification

PM – Project ManagerLE – Lead Engineer / Software ArchitectST – System Test ManagerPL – Project Leader

31ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Neuer Produktentwicklungsprozess

PM

LE/ST

PL

PM

LE/ST

PL

Neue „Design Phase“

www.hirschmann.com 32ATAMI 2012, © Markus Rentschler

DfST Elicitation & Management

Einfache Toolunterstützung:

33ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

„Design for System Testability“

• …ist ein vielversprechender systematischer Ansatz vor al lem für mechatronische Systeme mit eingebetteter Software

• …erlaubt die Entwicklung von gemeinsamen Testlösunge n für Entwicklung, Systemtest, Wartung

• Umsetzung in bestehender „Entwicklungskultur“ schwier ig

• Management-Unterstützung notwendig

• Kompetenter System -/Software-Architekt als Treiber notwendig

Fazit

34ATAMI 2012, © Markus Rentschlerwww.hirschmann.com

Vielen Dank für Ihre Aufmerksamkeit!

Fragen?