O'Reilly logo

Automotive SPICE in der Praxis: Interpretationshilfe für Anwender und Assessoren by Jörg Zimmer, Lars Dittmann, Klaus Hörmann, Markus Müller

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

2 Interpretationen zur Prozessdimension
60
Softwareanforderungen entsprechend eindeutig untergliedert werden, damit die
Zuordnung zu diesen klar ist.
BP8: Kommuniziere Softwareanforderungen. Etabliere Kommunikationsmecha-
nismen für die Verbreitung der Softwareanforderungen und Aktualisierungen
von Anforderungen an alle relevanten Parteien.
Die Ausführungen zu ENG.2 BP7 gelten hier analog.
2.6.4 Ausgewählte Arbeitsprodukte
13-22 Traceability record – Traceability-Aufzeichnung
Siehe bei ENG.2
17-11 Software requirements – Softwareanforderungen
Softwareanforderungen sind Vorgaben für die Softwareerstellung, die die Quali-
tät und Brauchbarkeit der Software wesentlich beeinflussen. Dabei werden u.a.
berücksichtigt: die Kundenanforderungen, Systemanforderungen, Systemarchi-
tektur, zu beachtende Normen, Einschränkungen, Beziehungen der Software-
elemente zueinander, Performanzcharakteristiken, erforderliche Softwareschnitt-
stellen, Sicherheitscharakteristiken, das Verhalten in Fehlerfällen und die
Wiederherstellung nach Fehlerfällen (bezüglich der Struktur eines Anforderungs-
dokumentes in Anlehnung an IEEE Std 830 siehe Abb. 2–4).
2.6.5 Besonderheiten Level 2
Die Aussagen im korrespondierenden Abschnitt bei ENG.2 gelten hier analog.
2.7 ENG.5 Softwaredesign
2.7.1 Zweck
Zweck des Prozesses ist es, ein Softwaredesign bereitzustellen, das die Anforde-
rungen an die Software umsetzt und das gegen die Softwareanforderungen verifi-
ziert werden kann.
Mit dem Softwaredesign wird dargestellt, wie die Softwareanforderungen im
Code umgesetzt werden sollen und aus welchen Bestandteilen die Software
besteht. Funktion, Wirkungsweise und Interaktion der Bestandteile werden
beschrieben. Das Softwaredesign setzt auf den Softwareanforderungen auf und
liefert die Vorgaben für die Codierung. Der Designprozess verläuft oft in mehre-
ren Iterationsschritten, in denen das Design von der Softwarearchitektur ausge-
61
2.7 ENG.5 Softwaredesign
hend bis hin zum Feinentwurf mehrfach detailliert und weiter ausgearbeitet wird.
Zwischen Systemarchitektur und Softwarearchitektur gibt es einen Überlap-
pungsbereich, da z.B. Bestandteile der Softwarearchitektur in der Systemarchi-
tektur aufgeführt werden und umgekehrt.
In vielen Fällen ist die zu erstellende Software eine Kombination aus Platt-
formbestandteilen (wiederverwendetem Code) und neuem Code. Häufig wieder-
verwendete Design- und Codeelemente müssen erhöhte Anforderungen erfüllen,
was zum Beispiel im Rahmen von Designreviews überprüft werden kann. In
Designreviews können auch designrelevante Fragen zur Fehlertoleranz betrachtet
und beantwortet werden:
Werden Fehlerzustände erkannt und wie?
Wie werden Fehlerzustände klassifiziert?
Wie verhält sich das System im Fehlerfall?
Aussagen zur Robustheit des Designs können spätere Stresstests liefern wie z.B.
hinsichtlich Sensorausfällen, Kabelbrüchen, Startup-Verhaltens oder dem sprung-
haften Anstieg der Interrupts. Hardwarenahe Tests können sinnvollerweise erst
im Systemtest (siehe ENG.10) durchgeführt werden.
2.7.2 Besonderheiten in der Automobilindustrie
Die Softwareentwicklung in der Automobilindustrie erfolgt oft sehr hardware-
nah, d.h., es müssen auch weitere, über die reine Funktionsentwicklung hinaus-
gehende Punkte im Design berücksichtigt werden, z.B. das Zeitverhalten (Inter-
rupts und Zeitscheiben) und Kommunikationsprotokolle. Beim Zeitverhalten
sind u.a. die Reaktionen und das Zusammenspiel der beteiligten Komponenten
wie z.B. der Prozessoren, Speicherbausteine und Buscontroller zu beachten.
Dabei werden mögliche Zustände beschrieben (z.B. von der Initialisierung über
den Betrieb bis hin zum Erreichen des Sleep-Modus) und bei Bedarf auch Fehler-
szenarien
35
. Beim Kommunikationsverhalten werden im Wesentlichen die Abfolge
und Inhalte von Kommunikationsbotschaften festgelegt und in Abhängigkeit von
Ereignissen beschrieben. In der Praxis erfolgen die Designbeschreibung und
-modellierung (z.B. mittels Zustandsdiagrammen) immer häufiger toolbasiert.
Das bietet mehrere Vorteile. Zum einen, falls das Tool dieses unterstützt, können
formale Kriterien (wie z.B. Konsistenz des Designs) sichergestellt werden, ande-
rerseits können bestimmte Funktionen und Zustände bereits vor dem eigent-
lichen Codiervorgang am PC simuliert und bewertet werden. Zudem unterstüt-
zen neuere Werkzeuge in der Regel auch Codegenerierung.
35. Design-FMEAs liefern typischerweise einen Input für Fehlerszenarien, dabei wird die Auf-
trittswahrscheinlichkeit von Fehlern unter den zugehörigen Randbedingungen betrachtet und
bewertet.
2 Interpretationen zur Prozessdimension
62
2.7.3 Basispraktiken
BP1: Entwickle die Softwarearchitektur. Benutze die funktionalen und nicht
funktionalen Softwareanforderungen, um eine Softwarearchitektur zu entwi-
ckeln, die die oberste Struktur
36
und alle Softwarekomponenten inklusive der
für Wiederverwendung verfügbaren Softwarekomponenten beschreibt.
Anmerkung: Siehe auch REU.2 Wiederverwendungsmanagement
Die in ENG.4 ermittelten Anforderungen an die Software werden in eine Soft-
warearchitektur (auch Grobdesign genannt) als Beschreibung auf oberster Ebene
überführt und dokumentiert. Hier werden die notwendigen zentralen Entwurfs-
entscheidungen vorgenommen. Idealerweise sind die Komponenten der Soft-
warearchitektur stabil über den Entwicklungsverlauf, sodass sie bzw. ihre
Schnittstellen im Verlauf der weiteren Entwicklung nicht mehr geändert werden
müssen. Dieser Schritt ist die Vorstufe zum Softwarefeinentwurf (siehe BP6) und
muss zu diesem konsistent sein.
In der Praxis sind meist mehrere Sichten auf die Softwarearchitektur zur voll-
ständigen Abbildung notwendig. Das können z.B. folgende sein:
Struktursicht (Architektur, verwendete Architektur-Pattern)
Verhaltens-/Zustandssicht (Sleep-Modus, Startup, Shutdown, Beschreibung
Bootblock, Monitoringtechniken usw.)
Use-Case-Sicht (Umsetzung der Use Cases in der Architektur)
Prozesssicht (Taskdesign, Timing, Speicherlayout)
BIOS- und Services-Sicht (CAN- und LIN-Treiber, Hardware Abstraction
Layer, Watchdog, Betriebssystemintegration usw.)
Aufrufhierarchie z.B. als Blockschaltbild
Ressourcensicht (geplanter RAM/ROM-Verbrauch)
Bei schwierigen oder folgenschweren Architekturentscheidungen ist es sinnvoll,
mehrere Architekturvorschläge zu erstellen und nach den genannten Kriterien zu
bewerten. Getroffene Architekturentscheidungen sollten dann nachvollziehbar
dokumentiert werden, sodass diese zu einem späteren Zeitpunkt im Projekt nach-
vollzogen werden können und erneute Revidierungen vermieden werden. Zuneh-
mend an Bedeutung gewinnende Kriterien sind der Wiederverwendungsanteil bei
der Architektur sowie die Eignung zur Wiederverwendung für die Zukunft.
BP2: Weise die Softwareanforderungen zu. Weise alle Softwareanforderungen
den Softwarekomponenten aus der Softwarearchitektur zu.
Alle für die Softwarearchitektur relevanten Softwareanforderungen werden den
Softwarekomponenten der Softwarearchitektur zugewiesen, z.B. Anforderungen
bezüglich Bedatung, der Forderung nach einer Startup-Task, Schnittstellenanfor-
36. Sogenannte Top-Level-Architektur.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required