Der Vortrag von Stanislav Flígl und Janos Koppany auf der Euroforum-Jahrestagung behandelt die Optimierung von Entwicklungsprozessen und Konfigurationsmanagement durch Softwarequalität und Testing in der Automobilbranche. Er fokussiert sich auf angewandtes Software-Engineering, funktionale Sicherheit sowie die Verwaltung von Anforderungen und Testtools in einem verteilten Entwicklungsumfeld. Zudem wird die Bedeutung von Versionskontrollsystemen und deren Implementierung im Entwicklungsprozess hervorgehoben.

1. Optimierte Entwicklungsprozesse &
Konfigurationsmanagement durch
Software Qualität und Testing
11. EUROFORUM-Jahrestagung
Software im Automobil
Ein Vortrag von:
Stanislav Flígl
und
Janos Koppany

2. Agenda
• Angewandtes Software-Engineering und funktionale
Sicherheit
• Verwalten von Anforderungen, Testspezifikationen und
Integration mit Testtools
• Verteilte Versionskontrollsysteme: Einsatz im
Entwicklungsprozess

3. Angewandtes Software-Engineering und
funktionale Sicherheit

4. SW Entwicklungsprozesse
V-Model in der elektrischen Traktion

5. IEC 61508 Sicherheit sicherheitsbezogene elektrische /
elektronische /programmierbare elektronische Systeme
IEC 61508 ČSN EN 61508 Basisnorm
Einige Fachspezifische Normen:
IEC 61511 Prozessindustrie
IEC 61513 Kerntechnik
ISO 26262 Straßenfahrzeuge bis 3500 kg
EN 50128 Eisenbahn
DO 178 Flugzeugtechnik
(ED-12)

6. IEC 61508 Sicherheit sicherheitsbezogene elektrische /
elektronische / programmierbare elektronische Systeme
IEC 61508 ČSN EN 61508 Basisnorm (IEC 61508:2000, ČSN EN 61508:2002, IEC
61508:2010, ČSN EN 61508:2011)
Einige Fachspezifische Normen:
ISO 26262 Straßenfahrzeuge bis 3500 kg (ISO 15504:1998, ISO 15504:2003-2008,
MISRA:1994, MISRA-C:1998, MISRA-C:2004, ISO 26262:2009, ISO
26262:2011?)
EN 50128 Eisenbahn (EN 50128:2001, ČSN EN 50128:2003, EN 50128:2011?)
DO 178 Flugzeugtechnik (DO178A-1985, DO178B-1992, DO178C-2011?)
(ED-12)

7. ISO 26262 und EN 50128
ISO 26262
EN 50128

8. EN 50128:2001 und EN 50128:2009 draft
EN 50128:2001 EN 50128:2009

9. Aufgabe für die Implementierung
SW Development
Software VAL Software
VER Requirements Validation
Phase Phase
Software VAL Software
VER Architecture & Integration VER
Design Phase Phase
Software VAL Software
VER Component Component VER
Design Phase Testing Phase
Kódování SW
VER modulu
Component Design Coding & Testing Phase

10. Implementierung in bestehende Dokumentensysteme
START KONEC
Schválení Schválení
1 - DI 2 - VAL 3 - VER 1, 2 4 - TMP 1, 3 19- VAL 20- VAL 1, 19 21- TMP 1
Specifikace Specifikace Zpráva o Kontrola Plán Zpráva o Kontrola
požadavků testování ověřování 3 validace & validaci 19, 20 a
na SW požadavků požadavků a SW SW schválení
na SW na SW schválení 19, 20
Ověření Ověření 1, 2, 3 Ověření
Etapa požadavků na SW Etapa validace SW
Schválení Schválení
5 - DI 6 - VER 1, 5 7- VAL 5, 6 15- DI 16- DI 1,5,15 17- VER 15,16 18- VAL 15,16
Specifikace Zpráva o Kontrola 6, Plán Zpráva o Kontrola Schválení
architektury ověřování a testování & testování 15, 16 15, 16
a návrhu architektury schválení integrace integrace
SW a návrhu 5, 6 SW/HW SW/HW
Ověření SW Ověření Ověření
Etapa architektury a návrhu SW Etapa integrace SW/HW
Schválení Schválení
8- DI 9- DI 10- VER 11- VAL 12- VER 13- VER 14- VAL
8 8, 9 8, 10 5,8,12 12,13
Specifikace Zpráva o Zpráva o Kontrola Plán Zpráva o Kontrola
návrhu SW testování SW ověřování 10 testování testování 12, 13
modulů a modulů SW modulů a integrace integrace a
Specifikace a a schválení SW SW schválení
testování Zdrojový Zpráva o 8, 9, 10 12, 13
SW kód ověřování
modulů Ověření zdroj. kódu Ověření Ověření
Etapa návrhu, kódování a testování SW modulů Etapa integrace SW
Schéma procesu vývoje SW

11. Software Engineering
■ 1968 – NATO Software Engineering Konferenz in Garmisch-Partenkirchen
■ Krisis der Software definiert als:
* Projects running over-budget.
* Projects running over-time.
* Software was very inefficient.
* Software was of low quality.
* Software often did not meet requirements.
* Projects were unmanageable and code difficult to maintain.
* Software was never delivered.
■ Die Einführung eines neuen Begriffs: „Software Engineering“

12. Über 40 Jahre Erfahrung / produzierte neue Werkzeuge
Viele Werkzeuge stammen ursprünglich nicht aus dem Embedded Bereich.
Die Verbindung der Norm mit der Vielfalt ist schwierig.
Erst in der letzten Jahren ist SW Engineering an Universitäten ein etabliertes Fach
geworden.
Viele Werkzeuge sind als OpenSource Produkte erhältlich – einige in sehr hoher Qualität.
■
Versionskontrolsysteme
■
Buildsysteme
■
Kontinuierliche Buildserver
■
Issue Tracking Systeme
■
Requirement Management Werkzeuge
■
Wiki-Systeme
■
Testwerkzeuge
■
Simulationswerkzeuge
■
RT-Simulationsumgebungen
■
Domain Specific Languages
■

13. Versionkontrollsysteme und IssueTracking Systeme
■ Entwickler sind oft während der Endphase des Projekt unterwegs - in Versuchshallen oder
an Teststrecken – oft mit schlechter oder keiner Netzanbindung.
■ Klassische Methoden scheitern.

14. Verwalten von Anforderungen,
Testspezifikationen und Integration mit
Testtools

15. codeBeamer
"codeBeamer", Intlands voll
integrierte Plattform für die
embedded Software Entwicklung,
begleitet geografisch verteilte
Projektteams während des
gesamten Entwicklungsprozesses
– vom Requirements Management
bis zum Application Lifecycle.

16. Verwalten von Anforderungen, Testspezifikationen und
Testtool Integration
CB WIKI,
CB WIKI Baselines
CB
CB Reporting
CMDB Testtools: (z.B)
Vectorcast, HP
QC
CB
Projects
CB SCM
und Hg

17. Entwicklungsprozess mit Mercurial und codeBeamer
SW Rquirements SW Validation
Specification
SW Design SW Integration
Spec.
Component Component
Spec. Test
Code

18. Entwicklungsprozess mit Mercurial und codeBeamer
SW Requirement Specification
Wiki
Exprot PDF
Approval
Tracker

19. Entwicklungsprozess mit Mercurial und codeBeamer
SW Design Specification

20. Entwicklungsprozess mit Mercurial und codeBeamer
SW Component Design

21. Entwicklungsprozess mit Mercurial und codeBeamer
Code
Sourcecode Entwicklung mit Mercurial, HgEclipse, Mylyn und Eclipse Helios

22. Entwicklungsprozess mit Mercurial und codeBeamer
Component Test & SW Integration
CB REQ CB TEST
HP QC
Creation of REQ or
Change request
Transfer to HP QC
CB Releases
Testspezifikation After testing,
Test Status
über CMDB can be shown
transfer of results
in codeBeamer test
Eintrag in releases
Tracker
Reports über Testergebnisse und After review of test Beispiel für
results, change of HP QC
Ausführungsgrade erstellen und REQ or CR status
Ablage in Dokumentenmanagement Integration

23. Entwicklungsprozess mit Mercurial und codeBeamer
Software Validation
Version/ Release Übersicht
über Bugs, Test, REQ,
Tasks
Release Notes für
Kunden
Dokumentation in Wiki+Baselines

24. Verteilte Versionskontrollsysteme:
Einsatz im Entwicklungsprozess

25. Versionkontrolsysteme - Geschichte
■ SCCS (Source Code Control Systems) – Marc Rochkind, Bell Labs
– Anfang 70. Jahre (Konzept – Dateienabschliessen)
■ RCS (Revision Control System) – Walter F. Tichy – Anfang 80. Jahre
■ CVS (Concurrent Version System) – Brian Berliner
– 1989 (zentralisiert Klient / Server)
■ ClearCase
– ursprünglich Atria Software 1992, später auch Rational, ab 2003 IBM
■ TeamWare – Sun Microsystems
– Anfang 90. Jahre (verteiltes System, atomic commits)
■ Visual SourceSafe – Microsoft 1995
■ Team Foundation Server – Microsoft 2006
■ Subversion – SVN (zentralisiert) – als Ersatz für CVS entwickelt – CollabNet 2000
■ Mercurial – HG (verteilt) – inspiriert durch Monotone (SHA-1 2003) und TeamWare
– Selenic 2005
■
Git (verteilt) – inspiriert durch BitKeeper (2002) – Linus Torvalds 2005

26. Versionkontrolsysteme – Auswahlverfahren
■ 2008 – Suche nach einem besserem Versionkontrolsystem und möglichen Alternativen
für die Verwaltung von SW Lebenszyklus nach EN 50128
■ Herbst / Winter 2008 – erste Experimente mit Subversion und nachträglich mit Mercurial
■ April 2009 – Auswahl eines Projektes für den Ersteinsatz von Mercurial
■ Juli 2009 – Auswahl von codeBeamer unter mehreren Tools als geeignetes alternatives
Verwaltungssystem zu vorhandenen ALM Lösungen
■ August 2009 – Errste Konversion von älteren Versionkontrolsystemen in Mercurial
■ Dezember 2010 – Beenden der Konversion von älteren Projekten von CVS in Mercurial
■ Januar 2011 – alle neue Projekte unabhängig vom Prozesssteuerungssystem
mit Mercurial verfolgt.
■ Januar 2011 – Installation von codeBeamer 5.5.1
■ Februar 2011 – Auswahl der ersten Projektes
■ März 2011 – Übergang und Vereinheitlichung zu Mercurial 1.7.5
■ April 2011 – Milestein – Requirements

27. Warum Distributed Version Control Systeme
•Ein zentrales Repository •Verteilte Repository
•Ständige Netzwerkkonnektivität •Netzwerkunabhängige Entwicklung
benötigt •Branching und Merging sind
•Branching/ Merging schwierig natürlicher Bestandteil
•Workflow Gestaltung nach neuen ISO •Abbildung von Workflows und
Normen begrenzt/ komplex Integration von QA Tools möglich.

28. Beispiel Workflow für Bremssystem mit DVCS
car main
brake system repository
QA
Check
untrusted-
•open-source repository
compliance check
•code review
Brake system Distance control
system
Supplier 1 Supplier 2 Supplier 3 Supplier 4

29. Danke schön für Ihre Aufmerksamkeit
Vielen Dank für Ihre Aufmerksamkeit
Für weitere Informationen besuchen Sie bitte
unsere Homepage:
www.skoda.cz/en www.intland.com
www.javaforge.com
Stanislav Flígl1
und
Janos Koppany2
1stanislav.fligl@skoda.cz 2janos.koppany@intland.com