Anforderungsmanagement

In den folgenden Kapiteln wird das Thema: Anforderungsmanagement erläutert.

Es werden die Vorgaben aus relevanten Standards und Normen sowie die praxisnahen Beispiele aus dem Automotive-Bereich dargestellt.

*1) Um Grafiken zu vergrößern, benutzen Sie die rechte Maustaste und die Option: “Bild in neuem Tab öffnen”.

In diesem Artikel werden die spezifischen Anforderungen an das Anforderungsmanagement aus dem Standard ASPICE und ISO 26262 kurz erläutert. Der Leser findet hier meine Methodik (SDEC-Dokompositionsprinzip), welche sich in einigen Projekten im Bereich Anforderungsmanagement gut durchgesetzt hat.

Die Anforderungsmanagement-Methode zeichnet sich durch die systematische Dekomposition eines Systems in kleinere Subsysteme und Systemelemente aus.

In weiteren Kapiteln findet man ein ausführliches Beispiel für ein paar Funktionen für die Anforderungen auf unterschiedlichen Entwicklungsebenen entsprechend ASPICE:

• SYS.2 System Requirements Analysis (Systemanforderungsanalyse)
• SYS.3 System Architectural Design (Systemarchitekturdesign)
• SWE.1 Software Requirements Analysis (Softwareanforderungsanalyse)
• SWE.2 Software Architectural Design (Softwarearchitekturdesign)

Die Definition des Anforderungsmanagements kann nachfolgend formuliert werden:

Das Anforderungsmanagement kann als das Erfassen, Zusammenfassen und Verwalten relevanter Informationen sowie als die Festlegung verbindlicher Umsetzungsrichtlinien für ein Produkt über dessen gesamten Lebenszyklus definiert werden.

Werden ergänzend zur Definition die Embedded und Automotive Gegebenheiten (Standards wie ASPICE und VDA) berücksichtigt, kann man diese Definition entsprechend mit Aufgaben aus diesen Standards ergänzen:

Anforderungserhebung und -analyse:

• Identifikation der Stakeholder-Anforderungen und deren detaillierte Analyse

Anforderungsspezifikation

• Detaillierte Dokumentation der Anforderungen in einer klaren und überprüfbaren Form

Anforderungsvalidierung und -verifikation:

• Sicherstellung, dass die Anforderungen korrekt und vollständig sind

Anforderungsmanagement:

• Verwaltung von Änderungen und Nachverfolgbarkeit der Anforderungen während des gesamten Entwicklungsprozesses

• [SYS.1] Requirements Elicitation (Anforderungsermittlung)
• [SYS.2] Requirements Analysis (Anforderungsanalyse)
• [SYS.2] Requirements Specification (Anforderungsspezifikation)
• [SYS.3, SWE.2] System/Software Architectural Design (System-/Softwarearchitekturentwurf)
• [SYS.4] System Integration and Integration Verification (Systemintegration und Integrationsverifikation)
• [SYS.5] System Verifikation (Systemverifikation)
• [SWE.4] Software Unit Verifikation (Softwarekomponentverifikation)
• [SWE.5] Software Component Verification and Integration Verification (Softwarekomponentverifikation und Integrationsverifikation)
• [SWE.6] Software Verifikation (Softwareverifikation)

Die Hardware-Disziplin ist ebenfalls betroffen, steht jedoch nicht im Fokus.

• [ASP.1] Anforderungen müssen vollständig, widerspruchsfrei und eindeutig formuliert sein.
• [ASP.2] Anforderungen sind auf verschiedenen Ebenen (System, Subsystem, Software) hierarchisch organisiert.
• [ASP.3] Jede Anforderung muss rückverfolgbar (traceable) zu ihren Quellen (z. B. Kundenanforderungen, Spezifikationen) und zu den implementierten Komponenten sein.
• [ASP.4] Nutzung von Verlinkungen und Traceability-Matrizen zur Darstellung der Beziehungen zwischen den Anforderungen auf unterschiedlichen Ebenen.

• [ASP.5] Separate Dokumente für jede Anforderungsebene, die durch eindeutige Identifikatoren und Verlinkungen miteinander verbunden sind.
• [ASP.6] Verwendung von Werkzeugen zur Unterstützung der Anforderungsverwaltung und -verfolgung.
• [ASP.7] Anforderungen müssen klar, präzise, überprüfbar und testbar sein.
• [ASP.8] Vermeidung von Ambiguitäten und Mehrdeutigkeiten.

• VDA 6.3: Prozessaudit für die Automobilindustrie.
• VDA 6.x: Erweiterte Standards zum Qualitätsmanagement und Prozessoptimierung.
• VDA: Oftmals ergänzend zu spezifischen Projektrichtlinien und -dokumentationen.

• [VDA.1] Anforderungen müssen klar strukturiert und hierarchisch gegliedert sein.
• [VDA.2] Verwendung von nummerierten und eindeutig identifizierten Anforderungen.
• [VDA.3] Ähnlich wie bei ASPICE werden Anforderungen auf verschiedenen Ebenen dokumentiert (System, Subsystem, Komponenten, Software).
• [VDA.4] Jedes Dokument repräsentiert eine Ebene und ist durch Verlinkungen (Hyperlinks) miteinander verbunden.
• [VDA.5] Sicherstellung der Rückverfolgbarkeit durch Verknüpfung der Anforderungen über die Dokumentenhierarchie hinweg.
• [VDA.6] Nutzung von Verweisen und Referenzen zwischen den Dokumenten zur Darstellung der Beziehungen.
• [VDA.7] Anforderungen müssen eindeutig, vollständig, konsistent und überprüfbar sein.
• [VDA.8] Vermeidung von Mehrdeutigkeiten durch präzise Formulierungen.

• [VDA.9] Einsatz von Tools zur Verwaltung und Verlinkung der Anforderungsdokumente.
• [VDA.10] Unterstützung bei der Pflege der Traceability und Konsistenz zwischen den Ebenen.

Die Vorgaben aus beiden Dokumenten für das Anforderungsmanagement überschneiden sich in fast allen Punkten. Allerdings fehlen hier nicht die Punkte bezüglich Anforderungsänderungen und Konfigurations-/Änderungsmanagement. Es gibt eine Prozessbeschreibung zur Freigabe von Requirements und zur Wechselwirkung mit anderen Prozessen. Diese Prozesse sind projektspezifisch und können flexibel gestaltet werden. Vielmehr geht es hier um die Festlegung der Anforderungsinformation, die in Anforderungsdokumenten dargestellt wird, um deren Strukturierung und um die Methodik zur Abstraktion.

• Teil 2 – Management der funktionalen Sicherheit,
  • Kapitel 6 – Planung der Aktivitäten für Funktionale Sicherheit
• Teil 3 – Konzeptphase,
  • Kapitel 7 – Konzept für Funktionale Sicherheit
• Teil 4 – Produktentwicklung auf Systemebene,
  • Kapitel 6 – Entwicklung des technischen Sicherheitskonzepts

• Teil 6 – Produktentwicklung auf Softwareebene,
  • Kapitel 6 – Spezifizierung von Functional Safety relevanten Softwareanforderungen,
• Teil 8 – Unterstützende Prozesse,
  • Kapitel 6 – Spezifikation und Management der Funktionalen Sicherheit relevanten Anforderungen,
• Teil 9 – Sicherheitsanalyse,
  • Kapitel 8 – Sicherheitsanalyse und Anforderungen

Ergänzend zu den Anforderungen für Anforderungsmanagement aus ASPICE und VDA kann man noch ein paar wichtige Anforderungen aus dem ISO 26262 ableiten.

• [ISO26262, Teil 3] Die Funktionale Sicherheit-relevanten Anforderungen sollen eine klare und eindeutige Rückverfolgbarkeit aufweisen über mehrere Dokumente: Safety Goals -> FSR -> TSR -> HW/SW
• [ISO26262, Teil 3] Die Dokumentation von Anforderungsänderungen muss strengen Richtlinien unterliegen (Rückverfolgbarkeit, Konsistenz etc.)
• [ISO26262, Teil 3 und Teil 6] Es wird empfohlen, spezielle Tools für Anforderungsmanagement zu benutzen (für nachvollziehbare und konsistente Rückverfolgbarkeit, Modellierung etc.)

• [ISO26262, Teil 4 und Teil 6] Alle Funktionale Sicherheit-relevanten Anforderungen sollen auf Korrektheit und Vollständigkeit überprüft werden (Reviews, Tests oder Analyse)

Im Rahmen dieses Dokuments kann ich leider nicht alle Punkte eingehen. In diesem Fall muss man auch die Rückverfolgbarkeit zu FSR und TSR zeigen, was den zeitlichen Rahmen sprengen würde. Wir werden uns aus diesem Grund auf die Anforderungen von ASPICE und VDA im späteren Verlauf konzentrieren. Im realen Projekt muss man sich darauf einstellen, alle Anforderungen aus dem ISO 26262 an das Anforderungsmanagement zu berücksichtigen.

Sobald die Kundenanforderungen weitestgehend geklärt und die Systemanforderungen abgeleitet sind, arbeitet parallel ein Systemingenieur an der Systemarchitektur und leitet (zusammen mit der Hardware- und Softwareabteilung) die High-Level-Systemarchitektur ab.

Da das zu beschreibende System bisher nicht vollständig definiert ist, existieren zu diesem Zeitpunkt nur wenige konkrete Systemanforderungen. An dieser Stelle ist es wichtig, dass die Teams (HW, SW, ME und Qualität) untereinander effektiv kommunizieren. Ohne diese Kommunikation und die definierten Prozesse kann es unter Umständen zu gravierenden Fehlern im späteren Verlauf eines Projekts kommen. Hier sind einige Beispiele für typische Situationen aus der Praxis:

• Lücken in Kundenanforderungen sind nicht geschlossen
• Reviewkriterien und Reviewprozesse nicht definiert
• Tailoring-Guideline nicht benutzt
• Falsche Zuordnung zu einer Abstraktionsebene
• Fehlende Beschreibung für die entwickelten Dokumente

Die Lessons-Learned liefern nicht alle relevanten Details zur Fehlerbehandlung, und es fehlt an einer abschließenden Bewertung der Kosten, die durch solche Fehler verursacht werden können. Aus meiner Erfahrung sind die Folgen jedoch verheerend

Auf dem Diagramm unten sind die Prinzipien von Anforderungsdekomposition nach einem “Strict Decomposition (SDEC)”-Prinzip beschrieben. Dieses Prinzip besagt, dass alle Abstraktionsebenen definierte Schnittstellen und spezifische Elemente haben, die beschrieben und zu einer eindeutigen Abstraktionsebene zugeordnet werden müssen.

Die Beschreibung der Funktion eines Elements erfolgt durch die Verhaltensbeschreibung des zugehörigen Interfaces. Der interne Aufbau und die konkrete Funktion des Elements werden dabei nicht erläutert; die Definition bezieht sich ausschließlich auf die Schnittstellen.

In diesem Prinzip kann man ein Muster erkennen, bei dem eine übergeordnete Abstraktionsebene mit definierten Schnittstellen und Funktionen beschrieben wird. Sobald alle Details festgelegt sind, wechselt man zur untergeordneten Ebene. Dort werden die Systemelemente identifiziert und ebenfalls mit ihren Schnittstellen und Funktionen beschrieben. Dieser Vorgang wird iterativ wiederholt, bis keine weiteren Elemente mehr aufgespalten werden können.

Auf diese Weise erhält das Anforderungsmanagement strikt getrennte Schichten, wodurch in unterschiedlichen Dokumenten ein- oder mehrere Systeme sauber beschrieben werden können.

Als Ausgangspunkt können wir das Beispiel aus dem Artikel: Systemarchitektur (in Praxis) nehmen. Die “Kundenanforderungen” für Fensterheber-ECU können im Kapitel: Funktionalität des Fensterheber-ECU (vereinfachte Funktion/Anforderungen) nachgelesen werden. Wir nehmen an, dass diese Beschreibung die Kundenanforderungen darstellt. Es gibt keine präzisen Angaben von dem Kunden, wie genau das System funktionieren soll. Wir gehen davon aus, dass ein Kunde unsere Systemanforderungen als seine eigenen Kundenanforderungen übernimmt.

In diesem Kapitel möchte ich meine Sichtweise auf die Methodik zur Implementierung des Anforderungsmanagements darlegen. In vielen Projekten habe ich Situationen beobachtet, in denen in dieser Disziplin erhebliche, unnötige Aufwände entstanden sind. Es traten zahlreiche Missverständnisse und widersprüchliche Meinungen auf. Meiner Einschätzung nach entstanden diese Probleme, weil die Prozesse in den Projekten unzureichend beschrieben waren. Die Projektstakeholder hatten kein Dokument, auf das sie sich beziehen konnten, in dem die Aufgaben und Verantwortlichkeiten klar definiert waren.

Es gibt unterschiedliche Einsätze, wie man das Anforderungsmanagement in einem Projekt realisieren kann. Besondere Herausforderung beim Anforderungsmanagement ist, eine Basis für alle Stakeholder zu erschaffen, bei der diese Stakeholder gleiches Verständnis für dieses Thema haben.

Des Weiteren gibt es Anforderungen aus manchen Standards, dass die Abstraktionsebenen (SYS.2, SYS.3, SWE.1, SWE.2) in getrennten Dokumenten (getrennte Ebenen: siehe oben [ASP.2], [ASP.5], [VDA.3], [VDA.4]) umgesetzt werden sollen, es wird von vielen Accessors verlangt. Die Kundenanforderungen sind oft nicht korrekt abstrahiert und beinhalten manchmal sogar Anforderungen aus der Ebene Detailed Design. Angesichts dessen ist es wichtig, saubere Implementierungswege über alle Abstraktionsebene zu erstellen und gut zu dokumentieren.

Hier ist ein möglicher Ansatz, welcher in vielen Projekten hervorragend etabliert hat. Obwohl dieser Ansatz für Automotive-Projekte gut geeignet ist, gibt es in jedem Projekt unterschiedliche Gegebenheiten. Es kann sein, dass alternative Lösungswege in bestimmten Fällen zu besseren Ergebnissen führen.

Auf dem Diagramm unten sieht man den FMS_PCB-Kontext und die Systemgrenzen. Des Weiteren ist auf dem Diagramm die Funktionszuordnung zu physikalischen Einheiten vorhanden.

Hier sehen wir die Systemgrenzen des FMS_PCB, welche durch folgende Schnittstellen (Ports) repräsentiert sind:

• DC-Motor, PWM-Ansteuerung (von H-Brücke)
• Hall-Sensor
• Stromsensor
• LIN-Interface

Die Systemanforderungen beschreiben das Verhalten des Systems anhand dieser Schnittstellen. Um eindeutig Anforderungen an die Schnittstellen zu formulieren, müssen diesen Schnittstellen ein Port (physikalischer Verbindungsweg zwischen Komponenten, z. B. zwischen Hall-Sensor und FMS_PCB) zugeordnet werden. Allerdings benötigen wir auch Signale (welche Dateninformation repräsentieren).

Beide können gleichnamig benannt werden: für den DC-Motor benötigen wir zwei Leitungen mit Signalen (Ports). Siehe das Diagramm: Systemarchitektur: Fenstermotorsteuerung (FMS_PCB). Somit ergeben sich die folgenden Signale (Ports):

• VBAT (Stromversorgung +12 V)
• GND (Masse)
• M1PCB (DC-Motorsteuerung Pin 1)
• M2PCB (DC-Motorsteuerung Pin 2)
• LIN (LIN-Bus Kommunikationskanal)
• USHHS (Hall-Sensor)

Die Systemanforderungen aus dem Beispiel FMS_PCB müssen beschreiben, welche Funktionen über diese Schnittstellen laufen und welchen Zusammenhang diese Schnittstellen untereinander haben.

Die Systemanforderungen sollen vollständig sein. D. h. dass alle zu einer Anforderung gehörende logisch verknüpfte Bedienungen in einem einzigen Anforderungsobjekt beschrieben werden (siehe Beispiel unten) sollen. Es gibt eine Möglichkeit, die Teilanforderungen separat anzulegen. Weitere Informationen hierzu finden sich im Kapitel: Erklärungen und Methodik für Anforderungsmanagement vorhanden.

Auf der Systemebene und Ebenen darunter beschreibt ein Anforderungsingenieur die Anforderung als eine Funktion der Eingangsinterfaces auf Systemebene (hier: Kontext vom Subsystem FMS_PCB) und der Ausgangsinterfaces. Diese Vorgehensweise hat einige Vorteile:

• Die Systemanforderungen können vollständig auf Systemebene getestet werden.
• Die Systemanforderungen beschreiben das „reine“ Verhalten des Systems, ohne in die Details zu gehen und aus einer anderen Ebene Informationen hereinzubringen.
• Die Verifikationskriterien können einfach in Tests umgesetzt werden, somit ist das Testen sehr einfach und deckend.

Angenommen, wir möchten jetzt eine Anforderung auf Systemebene für die Ansteuerung des Fenstermotors in Richtung “nach oben” abhängig von dem LIN-Signal vom Benutzertastenfeld formulieren.

Die Anforderungen aus: ISO 26262, VDA und ASPICE schreiben vor, dass die Anforderungen folgende Bedingungen für das formelle Erscheinen erfüllen sollen:

• Vollständigkeit,
• Konstistenz.

Daraus resultiert die folgende Anforderung:

Wenn das LIN-Signal: “HPCB_ComReq.UsrCmd” gleich dem Wert “FBNO” empfangen wird, dann soll FMS_PCB am Signalport:

• M1PCB das PWM-Signal mit Duty Cycle gleich dem Parameter: “duty_cycle_up” am DC-Motor für die Fensterbewegung nach oben liefern, und das Signalport M2PCB gleich GND setzen.

Auf einer Seite wird eine Anforderung definiert, um die Vollständigkeit eines Requirements zu gewährleisten. Allerdings muss diese Anforderung mit anderen Anforderungen der unteren Ebenen verlinkt werden, was unter Umständen zu Schwierigkeiten bei der Anforderungspflege führen kann. Der Übersichtlichkeit hilft es auch nicht.

Außerdem gibt es Situationen, in denen Schnittstellen, die unterschiedliche ASIL-Stufen aufweisen, in einer einzigen Anforderung zusammengefasst werden, sofern diese eine bestimmte Logik erfüllen.

Als Abhilfe kann man eine größere Anforderung in kleinere, klar abgegrenzte Anforderungen aufteilen (Beispiel: SYS2_REQ_6, SYS2_REQ_21).

Der Nachteil dieser Aufteilung ist, dass beim Verschieben einer Anforderung der Bezug zum Gesamtkontext verloren gehen kann. Um die Einordnung eindeutig zu gestalten, wird im Anforderungstext ein Hinweis eingefügt. (Beispiel: in SYS2_REQ_5, Fensterbewegung nach oben – SYS2_REQ_6 und SYS2_REQ_21 mit Information ergänzt, dass die Anforderungen logisch zusammen gehören.)

In einem realen Projekt sollten die Anforderungen mit zusätzlichen Attributen wie “Information, Zugehörigkeit etc.” ergänzt werden. Eine bessere Lösung besteht darin, ein separates Attribut für die Funktion anzulegen und den Funktionsnamen dort zu notieren. Hier mache ich dies ausschließlich, um die Breite der Tabelle übersichtlich zu halten.

Dasselbe gilt auch für das Attribut „Verifikationskriterium“.

Wie bereits früher erwähnt, gibt es in realen Projekten Parameter- und Speicherdaten, die von der Applikation verwendet werden. In unserem Fall sieht man Parameter wie “duty_cycle_up” und “duty_cycle_down”. Die Parameter, deren Parametrierung sowie die Speicherdaten werden hier jedoch nicht behandelt.

Die Definitionen vom “normal mode” und anderen Modi könnten zentral in diesem Dokument festgelegt werden, sodass nicht bei jeder Anforderung wiederholt werden muss, dass beispielsweise VBAT (Stromversorgung) und LIN-Kommunikation vorhanden sind.

Natürlich gehört zum Anforderungsmanagement viel mehr als nur die Erstellung und Verteilung der Anforderungen in Dokumenten. Die beschriebene Vorgehensweise und Vorgaben aus Standards und Normen oben helfen jedoch, weitere fehlende Punkte zu identifizieren und zu definieren.

Wir starten mit Systemanforderungen gemäß dem SDEC-Prinzip. Hier werden die Interaktionen der Schnittstellen, wie sie von dem FMS_PCB aus betrachtet werden, und deren Funktionen beschrieben.

Die Verlinkung zu Kundenanforderungen lassen wir an der Stelle aus. Im realen Projekt ist die Verlinkung aber ein Muss.

Bedeutung von Attributen in der Anforderungstabelle unten:

• Anforderungs-ID: einzigartige ID einer Anforderung
• Anforderungstext: textuelle Beschreibung der Anforderung
• Objekttyp: heading, fun_req (functional requirements) etc.
• Disziplin: Software (SW), Hardware (HW) und System
  • SYS: Systemanforderungsebene
  • HW und SW einer Dekomposition in Systemarchitektur
• Verifikationskriterium: Rahmenbedienungen für Test
• Verifikationsstrategie: Testtyp (Testabstraktionsebene)

Typische Anforderungen für das FMS_PCB könnten so aussehen (siehe Tabelle unten):

Die Hardwareanforderungen werden nicht in diesem Dokument betrachtet.

Wir haben jetzt ein paar Systemanforderungen definiert und können zur Systemarchitektur übergehen.

Im Diagramm: Systemarchitektur: Fenstermotorsteuerung und kritische Pfade sind die Informationen dargestellt, die für die Ableitung von Systemarchitekturanforderungen notwendig sind.

Hier wird der Kontext des Systems – also des gesamten FMS_PCB – und der jeweiligen Funktionen und deren Schnittstellen gezeigt, die zusammen ein übergeordnetes FMS_PCB-System mit kritischen Pfaden bilden.

Um die Systemarchitektur während der Systemintegrationstests zu überprüfen, können LIN-Debugging-Nachrichten definiert werden, die die internen Variablenwerte nach außen kommunizieren.

Diese Dienste sollten ausschließlich zum Testen verwendet und bei der Auslieferung an Kunden deaktiviert werden. Dieses Thema wird hier nicht im Detail erläutert; in den Verifikationskriterien wird vereinfacht festgehalten, dass die Variablen über den LIN-Bus ausgelesen werden können.

Ergänzend möchte ich betonen, dass ASIL-B-relevante Schnittstellen zusätzliche Tests in Richtung Fault-Injection und Diagnose benötigen, welche hier jedoch nicht vollständig erläutert werden.

In einem realen Projekt werden die TSC-Vorgaben in den SYS.3-Anforderungen berücksichtigt.

Es genügt, wenn in den Funktionen ausschließlich die Output-Signale getestet werden (nicht die internen Input-Signale). Hier habe ich absichtlich alle Signale mit Tests abgedeckt, damit man ein Gefühl dafür bekommt, wie die Tests aussehen und was genau während der Systemintegration geprüft wird. Außerdem war hier die Absicht, nicht alle Funktionen mit Anforderungen abzudecken.

Aus den Systemarchitekturanforderungen und Systemanforderungen können nun die Softwareanforderungen abgeleitet werden.

Auch hier ändert sich der Kontext, da die Software ausschließlich auf dem FMS-Mikrocontroller ausgeführt wird. Dies wird im nächsten Kapitel erläutert.

Die SW-SW-Interface-Tabelle beinhaltet das Mapping von Systemsignalen zu Softwaresignalen. Die Systemsignale für interne Zustände (z. B. HBRG_CURR_STATE), haben entsprechende Softwaresignale in Form:

• <Systemzugehörigkeit>_<Funktionsname>_<SW-Signal>.

In diesem Fall steht FMS für die Domäne “Fenstermotorsteuerung“, DC für die Funktion “Diagnostic Control” und HBrCurr_State für das Softwaresignal “H-Bridge Current State” (FMS_DC_HBrCurr_State).

.

Später werden in der Softwarearchitektur nur Softwaresignale zusammen mit AUTOSAR-Syntax verwendet

Die Statussignale sind hier nicht aufgelistet, damit das Dokument nicht zu groß wird. Diese Statussignale sind aber für die Diagnose und für die Funktionale Sicherheit wichtig.

Die Softwareanforderungen werden im Kontext des FMS-PCB-Mikrocontrollers zusammengefasst. Die Softwaresystemgrenzen sind die Mikrocontroller Pins. Die Hardware- und Softwareabteilung stellt Informationen für Schnittstellen des Mikrocontrollers nach außen im Dokument: Hardware-Software-Interface (HSI). Dort findet man Informationen über die nötigen ADC-Auflösungen, Pin-Zuordnung und entsprechende Softwaresignale.

Anschließend wird ein SW-SW-Interface-Dokument erstellt, welches die internen Softwaresignale für die Funktionskommunikation definiert.

Die Softwareanforderungen beschreiben das Verhalten der Eingangs- und Ausgangssignale des Mikrocontrollers.

Ein weiterer Punkt ist die Definition von internen Signalen für die Kommunikation zwischen Softwarekomponenten. Da wir bereits auf Systemarchitekturebene einige Softwaresignale definiert haben, die für die Kommunikation zwischen einzelnen Funktionen zuständig sind, fehlen uns noch einige Softwaresignale, die speziell für die Kommunikation zwischen einzelnen Softwarekomponenten benötigt werden.

Hier ist die abgespeckte Signalliste für die Kommunikation zwischen zwei Softwarekomponenten: WINC und APIF. Die Signale auf System-, Systemarchitektur-, Software- und Softwarearchitekturebene sind eindeutig miteinander gemappt.

Somit gibt es hier keinen weiteren Bedarf, die Signale untereinander in einem übergreifenden Dokument zu verlinken. Um die Anzahl von redundanter Information zu verringern, kann man alle Signale über alle Ebenen in einem Dokument speichern. In DOORS besteht die Möglichkeit, unterschiedliche Ansichten für verschiedene Ebenen zu erstellen, sodass man für System und Software spezielle Ansichten anlegen und nutzen kann.

Die Softwarearchitektur beschreibt im Folgenden zwei Softwarekomponenten: Window Control und Anti-Pinch Function. Die Software-Integrationstests sind als die Verifikationsstrategie gewählt.

Die Tests können mit Google-Test-Framework durchgeführt werden, die Input-Signale werden durch Stubs simuliert. Spezielle Performance-Anforderungen wie Ressourcennutzung (RAM, ROM etc.) werden hier nicht angesprochen.

Jetzt haben wir einen Teil der Anforderungen für zwei Funktionen: Anti-Pinch (APIF) Control und Window Control (WINC).

Mit SDEC-Vorgehensweise kann man die fehlenden Punkte wie die Funktionale Sicherheit, Fehlerbehandlung, Diagnose und weitere Funktionalitäten ausarbeiten und dokumentieren, aber zumindest zu dieser Untermenge kann man schon eine Konformitätsmatrix zu Standards wie ASPICE, VDA und ISO 26262 erstellen.

Die unten zusammengestellte Tabelle zeigt, wie die Anforderungen aus beiden Normen – APSICE und VDA – über Dokumente aus unterschiedlichen Ebenen abgedeckt sind.

Wie man aus dieser Matrix erkennt, sind alle aufgeführten Punkte im realen Projekt realisierbar.