Ich denke, es gibt einige technische Maßnahmen in ISO26262-6:2018, bei denen viele wegschauen oder sogar manchmal „unter den Teppich gekehrt“ werden. Ich möchte hier hauptsächlich auf Tabelle 3 „Prinzipien des Softwarearchitektur-Designs“ hinweisen

Ich persönlich habe selten ein Unternehmen gesehen, das einige Software-Metrik-Werkzeuge und Referenzwerte verwendet, um die Einhaltung der Methoden 1d oder 1e zu behaupten, zum Beispiel. Software-Metriken, so fragwürdig sie in der „Software-Welt“ auch sein mögen, liefern eine gute Idee zur Code-Qualität. Was ist damit gemeint? Die Software muss korrekt (um den Spezifikationen zu entsprechen), zuverlässig (Wahrscheinlichkeit, dass sie für einen bestimmten Zeitraum ohne Fehler ausgeführt werden kann), kostengünstig und pünktlich geliefert werden. Die letzten beiden Parameter werden hier durch seine Komplexität, Wartbarkeit und Wiederverwendbarkeit bedingt und bestimmt.
Es ist erstaunlich, wie ein 1976 geschriebenes Buch, wie Myers: „Software-Zuverlässigkeit: Principles & Practices“, als die Sprache C noch in den Anfängen stand, heute nicht nur gültig ist, sondern auch eine Referenz, die in der IEC61508-7:2010 zitiert wird, und eine Quelle für 1b, 1d und 1e in der obigen Tabelle.
Code-Kohäsion und -Kopplung sind, obwohl qualitative Parameter, Schlüsselindikatoren für den Grad der Komplexität und Wiederverwendbarkeit. Erstere beschreibt, wie verwandt die Funktionen innerhalb einer einzigen sind, und letztere bezieht sich auf die Interdependenzen zwischen den Modulen innerhalb der gesamten Software.

Sie wurden in den späten 60er Jahren von der „Yourdon, Myers, Stevens, Constantine“ Informatik-„Denkschule“ erfunden und später auch in dem oben erwähnten Buch ausgearbeitet.
Ist nicht der Zweck des vorliegenden Textes, die Code-Stärke (Kohäsion) oder Kopplung im Detail zu beschreiben, sondern die Aufmerksamkeit auf eine sorgfältigere Behandlung solcher Maßnahmen wie die in Tabelle 3 zu lenken. Eine große Initiative in diesem Sinne war in der Automobilindustrie die Veröffentlichung eines Papiers (Link zum Exida-Blog-Posting, das das Papier kommentiert) über Software-Metriken durch den ehemaligen HIS-Verband.
Tatsächlich zielt dies eher auf Modellierungs- und Kodierungsrichtlinien ab (so Tabelle 1 in ISO26262-6) als auf Software-Modularisierung und Komplexitätsmanagement, aber es ist zumindest ein Beispiel dafür, wie dieses Thema berücksichtigt werden kann.
Vielleicht ist eines der ungeschickten Dinge an der ISO26262, dass sie keinen Überblick oder eine gründlichere Erklärung ihrer in den Tabellen über alle Teile aufgelisteten Methoden und Maßnahmen bietet und keinen Teil 7 (Überblick über Techniken und Maßnahmen) wie in IEC61508 hat. Er gibt nur die Mittel an, die zur Erreichung einer bestimmten Sicherheitsintegrität eingesetzt werden sollen, gibt aber keine Anleitung, wie sie zu verwenden sind.