• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • UNTERNEHMEN
  • PRODUKTE
  • HEICON BLOG
  • Deutsch
    • Deutsch
    • English
  • Menü Menü
Du bist hier: Startseite1 / FuSi_Automotive2 / Re-Use Szenarien in der ISO26262 (Teil 1)

Re-Use Szenarien in der ISO26262 (Teil 1)

FuSi_Automotive

Warum ist die Wiederverwendung von Software, Hardware oder kompletten Steuergeräten ein zentrales Thema? Zwei wesentliche Aspekte sind hier ausschlaggebend:
Die Entwicklungskosten können deutliche reduziert werden, d.h. die Wiederverwendung von Komponenten ist unter wirtschaftlichen Gesichtspunkten sehr attraktiv.
Aber auch aus Sicherheitsgründen, kann die Wiederverwendung von Komponenten deutliche Vorteile bieten. Ein Steuergerät, welches bereits seit Jahren im Feld eingesetzt wird und keine sicherheitsrelevanten Ausfälle zeigt, kann im Vergleich zu einer Neuentwicklung mit deutlich reduziertem Risiko eingesetzt werden.
Um aber diese Vorteile wirklich zur Geltung zu bringen, muss man sich der vielfältigen Re-Use-Szenarien insbesondere in der Automobilbranche bewusst sein. Als zweiten Schritt, muss man die Besonderheiten des zur Diskussion stehenden Wiederverwendungsszenarios identifizieren und entsprechende Maßnahmen ergreifen.
Der Blog teilt sich dabei in zwei Teile. Im ersten Teil geht es um Vielfalt möglicher Wiederverwendungsszenarien sowie die entsprechenden Anforderungen die sich aus der ISO 26262 ergeben. Im zweiten Teil des Blogs werden konkrete Maßnahmen für ausgewählte Re-Use-Szenarien diskutiert.
Die Vielfalt der möglichen Szenarien wird durch nachfolgende Grafik angedeutet. Nicht alle Pfade treten dabei gleich häufig auf. Genauso wie nicht sämtliche Möglichkeiten, die in der Praxis vorkommen können, in dieser Grafik repräsentiert werden:

Szenarien

Wenn wir die erste Ebene betrachten, dann geht es hier um die Festlegung, was wiederverwendet werden soll. Software, Hardware oder das komplette Steuergerät stehen hier zur Auswahl. In der zweiten Ebene geht es um die Betrachtungen der Funktionalen Sicherheitsanforderungen an das wiederzuverwendende Element. In der dritten Ebene wird festgelegt, ob das System unverändert wiederverwendet wird oder ob Anpassungen notwendig sind.

Anforderungen die sich aus der ISO 26262 ergeben:

Im Teil 8 der Norm (Supporting Processes) beschäftigen sich zwei Kapitel mit speziellen Formen der Wiederverwendung von Systemen, SW oder HW (Re-Use Szenarien in der ISO26262).

Kapitel 12: „Qualification of Software Components“ definiert das Vorgehen für die Wiederverwendung von Software Komponenten, die bereits nach ISO 26262 entwickelt wurden. Für Elemente, die in Übereinstimmung mit der ISO 26262 entwickelt wurden, soll der Beweis zur Eignung für eine Wiederverwendung erbracht werden. Die Wiederverwendung qualifizierter Softwarekomponenten vermeidet die Neuentwicklung von Softwarekomponenten mit gleichen oder ähnlichen Funktionen.

 Kapitel 14: definiert das Vorgehen, für die Verwendung des „Proven in Use Arguments“. Hier geht es um die Verwendung von Komponenten die bereits im Feldeinsatz sind und für die genügend Daten über Ausfälle vorliegen. Wenn die in der Norm definierten Voraussetzungen erfüllt sind, kann das „Proven in Use Argument“ als alternative Methode zur Erfüllung der ISO 26262 angewandt werden.
Folgende zwei Kriterien müssen betrachten werden, sobald ein „Proven in Use Argument“ vorbereitet wird:
1) die Relevanz der Daten aus dem Feld während des Beobachtungszeitraumes
2) die Änderungen am Produkt, sofern vorhanden, seit Beginn des Beobachtungszeitraumes
Mit Blick auf die Relevanz der Daten aus dem Feld, ist das „Proven in Use Argument“ dafür vorgesehen, systematische und zufällige Fehler der ECUs zu benennen. Es benennt keine Fehler, die auf das Alter der ECUs zurückzuführen sind.

Neben den oben beschriebenen Kapiteln für die Wiederverwendung von Software, gibt es natürlich noch jede Menge Szenarien bei denen Punkte aus verschiedensten Teilen der Norm zur Anwendung kommen. Dies sind u.a. Einflussanalysen, Integrationsstrategien, Verifikationsstrategien etc.

Fazit:

Es gibt sehr viele Facetten bei der Wiederverwendung von sicherheitsrelevanter Software, Hardware oder Systemen. Sich dieses bewusst zu machen, ist der erste Schritt um eine erfolgreiche Strategie für die Wiederverwendung von Software, Hardware oder Systemen zu entwickeln. Im zweiten Schritt müssen die für das konkrete Projekt relevanten Re-Use Szenarien  in der ISO26262 identifiziert werden. Mit diesen beiden Schritten sind die Voraussetzungen dafür geschaffen, die Wiederverwendung von Software, Hardware oder Systemen zu einem wirtschaftlichen und sicherheitstechnischen Erfolg zu machen.
Im zweiten Teil des Blogs werde ich konkrete Maßnahmen für ausgewählte Wiederverwendungsszenarien diskutieren.

Ihre individuellen Fragen zur praktischen Umsetzung der ISO 26262 beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).

25. Juli 2015/0 Kommentare/von HEICON Global Engineering GmbH
Schlagworte: Funktionale Sicherheit, ISO26262, ISO26262 Verification, ISO26262 Verifikation, Proven in use, Wiederverwendung von Software
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
https://heicon-ulm.de/wp-content/uploads/2020/03/DI1A6086_klein_Automotive-1.jpg 533 684 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2015-07-25 23:10:332021-06-06 22:02:12Re-Use Szenarien in der ISO26262 (Teil 1)
Das könnte Dich auch interessieren
Funktionale SicherheitCompiler für sicherheitsrelevante Software – Was ist zu tun?
Funktionale SicherheitGuter Safety Software Entwicklungsprozess – Was ist das?
Funktionale SicherheitFunktionale Sicherheit und agile Entwicklungsmethoden – Ein unüberbrückbarer Gegensatz (Teil 2)?
Requirement EngineeringWieviele Requirements Ebenen sind sinnvoll?
Funktionale SicherheitStrukturelle Source Code Überdeckung – Aufwand ohne Nutzen?
Funktionale SicherheitFunktionale Sicherheit und Pragmatismus geht das?
0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kategorien

  • A_Requirement Engineering
  • B_Validation und Verifikation
  • C_Konfig-/ Änderungsmanagement
  • D_Security
  • FuSi_Allgemein
  • FuSi_Automotive
  • FuSi_Bahn
  • FuSi_Industrie
  • FuSi_Landwirtschaft
  • FuSi_Luftfahrt

Kontakt

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRESSUM  |  DATENSCHUTZ

EN 50128 Funktionale Sicherheit in der BahnindustrieBahnISO26262Re-Use Szenarien in ISO 26262 (Teil 2)
Nach oben scrollen