Forum: Ausbildung, Studium & Beruf MISRA C / ISO 62262 in der Praxis?


von Nick M. (Gast)


Lesenswert?

Hi!

Ich kenne MISCA C und ISO 62262 in der Theorie, aber nicht in der 
Praxis.
MISRA C hat ein paar "lästige" Regeln, kann man aber hinnehmen.

Was ich mich frage, wie formal das ganze Umfeld in der Praxis dann ist 
("automotive", ASIL levels nicht bekannt). Bekommt man einen Stapel 
Vorgaben und hat die dann sklavisch zu erfüllen, überlegt sich Tests, 
führt die aus und schreibt dann einen doppelt so hohen Stabel Doku wie 
der Eingangsstapel.
Spricht, ist die Arbeit vorwiegend Verwaltung und Formalismen, endlose 
Meetings und Besprechungen?


Coding styles gab es bei mir bisher keine (ausser meinen eigenen), 
leserlichen code hab ich mir angewöhnt weil ich sonst mein Zeug selbst 
nicht mehr verstehe. Und ganz grundlegend hab ich nichts dagegen, sich 
auf Regeln zu einigen und die Software peinlich zu testen. Auch gegen 
TDD hätte ich nichts (leider keine reale Erfahrung).

Ich kann es mir nicht vorstellen wie das in der Praxis abläuft.
Muss man dazu eine Beamtenmenthalität haben?

von Bimbo. (Gast)


Lesenswert?

Nun, dazu musst du wohl im Konzern landen. Da ist alles durchgereglt vom 
Dresscode bis zum Coding Style. Aber wenn du nur inner KMU oder 
sonstigen Mittelstand programmierst, ja dann begegnet man dem eher 
selten..

von Martin S. (strubi)


Lesenswert?

Nick M. schrieb:
> Ich kann es mir nicht vorstellen wie das in der Praxis abläuft.
> Muss man dazu eine Beamtenmenthalität haben?

Ich kenn's so: lint-checker oder irgend eine irgendwann mal 
zertifizierte Compiler-Suite nutzen, die das 'eingebaut' hat.
Dann feststellen, dass das gesamte Compilat in der Simulation doch 
grundsaetzliche Bugs hat, und einem MISRA da nicht grundsaetzlich hilft.
Wo es vielleicht hilft, ist, gewisse Fluechtigkeitsfehler anzumeckern 
(was ein aktueller GCC auch schon tut). Manche Regeln wiederum sind 
wiederum sinnlos und man waehnt sich zu schnell auf der sicheren Seite.
Andere sagen wiederum: Nimm Ada, inzwischen vielleicht Rust.

Meine Erfahrung ist, dass mit dem MISRA-Anhaenger eine Menge 
Augenwischerei betrieben wird und die Security&Safety fuer die Katz ist, 
weil nicht alle Szenarien geschweige denn das System "Software plus 
Hardware" simuliert wurden oder man sogar einen buggy Prozessor einsetzt 
(schon bei einem Kunden gesehen). Also muss man einfach eine Menge 
Logorrhoe/Papierkram relativ stoisch ertragen und den Code halt so 
schreiben, dass es einer mit Beamtenmentalitaet dann absegnen darf. Oder 
gleich Ada nehmen.

Grundsaetzlich wuerde ich einem openSource-System mit offengelegten 
Test-Units mehr vertrauen als dem MISRA-Stempel.

von Nick M. (Gast)


Lesenswert?

Konzern, ja. Aber am Standort Größe "Mittelstand". Ich komm da ab und zu 
mal vorbei und hab mir angesehen, wie die Leute da rumlaufen. Ganz 
normal. :-)

Und ja, ich hab "nur" einen Backgrund von Firmen bis maximal 20 Leuten. 
Da gab es tw. auch Formalismen (Bugtracker, RCS) aber genervt hat mich 
das nie. Im Gegenteil, die hab ich eingeführt. :-))
Ist halt was, was zur Struktur beiträgt und daher sinnvoll.

von Nick M. (Gast)


Lesenswert?

Martin S. schrieb:
> Meine Erfahrung ist, dass mit dem MISRA-Anhaenger eine Menge
> Augenwischerei betrieben wird und die Security&Safety fuer die Katz ist,

Gut, das glaub ich dir gerne. Durch solche Regeln alleine wird nie 
irgendwas funktionieren.

Und ja, lint (hab PClint) ist mir ein Begriff und den nehme ich her. 
Nicht ständig aber ich lass halt mein Zeug da durchlaufen und überleg 
mir die Warnungen sehr wohl (und pass auch an, der hat schon Recht).
Compiler ist immer auf -wAll, einfach weil es hilft blöde Fehler zu 
minimieren.

von Automotiv Entwickler (Gast)


Lesenswert?

Nick M. schrieb:
>Ich kenne MISCA C und ISO 62262 in der Theorie, aber nicht in der
>Praxis.
Du meinst vermutlich ISO26262 ?

> Ich kann es mir nicht vorstellen wie das in der Praxis abläuft.
> Muss man dazu eine Beamtenmenthalität haben?
Es ist eine Mischung aus beidem gefordert. Man sollte einen Hang zur 
Genauigkeit haben, die sich auch auf Dokumentation und die geforderten 
Nachweise bezieht. Man braucht aber auch Leute, die das System im Detail 
kennen und die entsprechenden Fusi Funktionen ordentlich entwickeln.

Mal ganz grob für ASIL B:
-------------------------
Es fängt mit der Hardware an. Die muss den geforderten ASIL Level 
nachweislich unterstützen, Sensorik ggf 2-kanalig. Die FIT-Raten der 
verwendeten Bauteile müssen passen. Da 2-Kanaligkeit fehlt muss die 
Software nachhelfen wenn möglich - siehe unten.

Ausgehend von einer zu erstellenden G&R wird dann eine Item-Definition 
und ein funktionales und technisches Sicherheitskonzept geschrieben. Ggf 
muss eine Strategie entwickelt werden, um 1-kanalige Sensorik mit Hilfe 
von anderen Signalen auf das geforderte ASIL-Level zu heben 
(Dekomposition). Basierend darauf wird dann das Software-Design 
konzipiert. Dann folgt die Software-Implementierung. Parallel muss eine 
Testspezifikation erstellt werden.

Für alle(!) Arbeitsprodukte müssen Reviewkriterien aufgeschrieben 
werden. Alle(!) Arbeitsprodukte müssen gereviewt werden. Am Ende muss 
man nachweisen können, dass alle(!) Anforderungen aus den 
Sicherheitskonzept umgesetzt sind. Man muss nachweisen können, dass die 
Testfälle geeignet sind, um die Anforderungen abzutesten. Man muss 
nachweisen können, dass alle Anforderungen abgetestet wurden.

Für ASIL C kommen noch externe unabhängige Audits hinzu.

von kyrk.5 (Gast)


Lesenswert?

Hast vermutlich ISO 26262 gemeint, oder?

von Nick M. (Gast)


Lesenswert?

kyrk.5 schrieb:
> Hast vermutlich ISO 26262 gemeint, oder?

Ja!
Hätte mir das jetzt nicht passieren dürfen? :-))

von A. S. (Gast)


Lesenswert?

Keine Angst vor misra/sil.

Misra: Kauf dir ein Exemplar, kostet weniger als selber ausdrucken. 
Arbeite das durch, schreibe auf, welche Regeln du befolgen willst, 
welche nicht und warum und mach ein Formular für Ausnahmen.

Dann setze Pc-Lint entsprechend auf, gibt entsprechende configs dafür.

Sil: mach einen 2-3-tage Kurs beim TÜV, mit Prüfung.

Zuhause dann 2-3 Formulare je 2 Seiten.
Vermeide zuviel Formalismus. Du bekommst sonst die Informationen nicht 
wieder aus den Docs raus.

Wenn Du in einem 10-seiten Dokument meinst, ohne Sil hätten 6 gereicht, 
dann ist das zuviel Formalismus.

von Nop (Gast)


Lesenswert?

MISRA C hat den Hauptzweck, daß man Leute embedded C programmieren läßt, 
die C nicht verstehen. Also sollen sie C möglichst Pascal-artig 
programmieren.

Man kann von den Regeln abweichen, wenn es Begründung und Analyse gibt, 
d.h. wenn sich das jemand angesehen hat, der C beherrscht. Das ist mit 
entsprechenden Formularen nachzuweisen. Die natürliche Faulheit der 
Programmierer wird von selber dafür sorgen, daß sie den Zirkus nur 
machen, wenn es wirklich unumgänglich ist.

von A. S. (Gast)


Lesenswert?

Lass Dir vor allem keine Tools andrehen, die den Code checken und 
Berichte ausspucken. Gimpels Pc-Lint ist da für kleines Geld noch immer 
führend. Und auch kein Doors für ein backtracing, wenn ihr nur eine 
handvoll Leute seid.

Es geht bei allem nur darum, dass ihr wisst, was ihr tut. Also, dass 
nicht irgendwas vergessen bleibt, weil es nicht notiert würde und dass 
ihr den Quellcode lesen könnt. Die formalismen (misra, V-Modell) können 
dabei helfen, aber sie sind kein Selbstzweck! Nachträgliche Dokumente 
(Anforderungen, Ausnahmen oder alles in schön umbauen) nützt niemandem. 
Niemals mehr als nötig!

von Timo (Gast)


Lesenswert?

Bimbo. schrieb:
> Nun, dazu musst du wohl im Konzern landen. Da ist alles
> durchgereglt vom Dresscode bis zum Coding Style. Aber wenn du nur inner
> KMU oder sonstigen Mittelstand programmierst, ja dann begegnet man dem
> eher selten..

Ja im KMU wird auch nur rotzige Software erstellt. Wenn du denen mit 
misra und coding styles kommst gucken die nur dulle.

Beitrag #6027743 wurde von einem Moderator gelöscht.
von Karl (Gast)


Lesenswert?

A. S. schrieb:
> Lass Dir vor allem keine Tools andrehen, die den Code checken und
> Berichte ausspucken. Gimpels Pc-Lint ist da für kleines Geld noch immer
> führend. Und auch kein Doors für ein backtracing, wenn ihr nur eine
> handvoll Leute seid.
>
> Es geht bei allem nur darum, dass ihr wisst, was ihr tut. Also, dass
> nicht irgendwas vergessen bleibt, weil es nicht notiert würde und dass
> ihr den Quellcode lesen könnt. Die formalismen (misra, V-Modell) können
> dabei helfen, aber sie sind kein Selbstzweck! Nachträgliche Dokumente
> (Anforderungen, Ausnahmen oder alles in schön umbauen) nützt niemandem.
> Niemals mehr als nötig!

Hast Du mal einem ISO26262 Assessment teilgenommen?
Die Sachen müssen schon Hand und Fuß haben.
Der Autor hat nicht beschrieben was er entwickelt aber ich bezweifle 
stark, dass man mit 2-3 Formularen a 2 Seiten auch nur dargestellt 
bekommt in wieweit der eigene Entwicklungsprozess die Anforderungen der 
ISO erfüllt und  da sprechen wir noch lange nicht von den eigentlichen 
Inhalten der Requirementspezifikation, Designspezifikation, 
Testspezifikation, Test reports, Review Protokollen,...

Bezüglich der Tools stimme ich Dir aber zu.
MISRA bringt aus Fehlervermeidungssicht wenig und für die 
Spezifikationen und Traceability lieber selber was textbasiertes 
schreiben.

von Auch Karl, ein anderer (Gast)


Lesenswert?

Karl schrieb:
> Die Sachen müssen schon Hand und Fuß haben.
> Der Autor hat nicht beschrieben was er entwickelt aber ich bezweifle
> stark, dass man mit 2-3 Formularen a 2 Seiten auch nur dargestellt
> bekommt in wieweit der eigene Entwicklungsprozess die Anforderungen der
> ISO erfüllt und  da sprechen wir noch lange nicht von den eigentlichen
> Inhalten der Requirementspezifikation, Designspezifikation,
> Testspezifikation, Test reports, Review Protokollen,...

Zustimmung. War Jahre lang im ASIL C Umfeld unterwegs. Der Prozess und 
die empfohlenen Tools müssen schon im Einklang mit der ISO sein. 
Allerdings gilt wie so oft "Stop thinking, geht certified today!". Soll 
heißen, dass der Prozess geeignet sein muss für den gewünschten ASIL 
Level, aber die technische Umsetzung im Steuergerät schaut sich kein 
Prüfer in dem Detail an. Da hab ich schon Sachen erlebt, die will man 
nicht wissen wenn man so ein Auto fährt...

Manchmal dient MISRA und Co auch noch als Ausrede, warum man dies und 
das nicht oder nicht so wie erforderlich Umsetzen kann.

Unterm Strich bleibt eine gewisse Rechtfertigung für den nötigen Aufwand 
in sicherheitsrelevanten Anwendungen, wobei geschätzt 20% davon mit 
Sachverstand umgesetzt besser wären. Sad Story.

von Einfach unverbesserlich (Gast)


Lesenswert?

Wer C kann, der braucht den Mist nicht

von A. S. (Gast)


Lesenswert?

Karl schrieb:
> ich bezweifle stark, dass man mit 2-3 Formularen a 2 Seiten auch nur
> dargestellt bekommt in wieweit der eigene Entwicklungsprozess die
> Anforderungen der ISO erfüllt und  da sprechen wir noch lange nicht von
> den eigentlichen Inhalten der

War missverständlich: die leeren Formulare (aber mit Kapitel, Kopf, 
Änderungshistorie) sollen auf 2 Seiten passen. Bloß keine Absätze mit 
Allgemeinquatsch oder manuelle Kreuzreferenzen auf den Bäcker des 
revievers der fontgröße.

Du kannst dir kaum vorstellen, was für Häkchen, Kapitel oder Hinweise 
sich Leute im Vorfeld vorstellen können zu brauchen.

Aus den 2-3 Formularen (Templates) entstehen dann schnell 2 Dutzend 
Dokumente je 5 bis 50 Seiten.

Und nein, keine Erfahrung mit dem palindrom (26262), aber SIL 61508

von Quality first. Bedenken second. (Gast)


Lesenswert?

Einfach unverbesserlich schrieb:
> Wer C kann, der braucht den Mist nicht

Sagt Juniormanager auch immer. Der macht gerade ein Training zum Digital 
Acceleration Ambassador um mit seinem neuen Knowledge und dem freshen 
Mindset die New Work Transformation seines Konzerns zu facilitaten.

von Nick M. (Gast)


Lesenswert?

Meine Herren!

Ich danke euch für die (bis auf drei Ausnahmen) sinnvollen und 
hilfreichen Antworten.
Mal schaun was rauskommt ...

von Timo (Gast)


Lesenswert?

War mal in so einer embedded Software klitsche in Münster. Die meinten 
auch massiv auf Konzern machen zu müssen. War dann alles nur 
unterirdisch bis mittelmäßig.

von Cyblord -. (cyblord)


Lesenswert?

Quality first. Bedenken second. schrieb:
> Einfach unverbesserlich schrieb:
>> Wer C kann, der braucht den Mist nicht
>
> Sagt Juniormanager auch immer. Der macht gerade ein Training zum Digital
> Acceleration Ambassador um mit seinem neuen Knowledge und dem freshen
> Mindset die New Work Transformation seines Konzerns zu facilitaten.

Tja der wird es weit bringen.

von Einfach unverbesserlich (Gast)


Lesenswert?

Cyblord -. schrieb:
> Tja der wird es weit bringen.

Agil muss es sein.

von Das soziale Kapital erhöhen (Gast)


Lesenswert?

Einfach unverbesserlich schrieb:
> Cyblord -. schrieb:
>> Tja der wird es weit bringen.
>
> Agil muss es sein.

Der Juniormanager ist ein verdammt guter. Von dem kann sein Vorgesetzter 
noch richtig was lernen!

von Peter (Gast)


Lesenswert?

MISRA hat schon einige gute Regeln, an die ich mich auch halte.

Aber wie immer kann man Mist schreiben, der durch alle Codechecker 
kommt, aber halt nur Mist macht.
Ohne Verstand  und Handwerkliches Können hilft kein Tool.

von Claus M. (Gast)


Lesenswert?

Einfach unverbesserlich schrieb:
> Wer C kann, der braucht den Mist nicht

Ich würde eher sagen wer C kann, für den ist MISRA kein Problem.

von meckerziege (Gast)


Lesenswert?

Nick M. schrieb:
> Ich kann es mir nicht vorstellen wie das in der Praxis abläuft.
> Muss man dazu eine Beamtenmenthalität haben?

Nein, MISRA ist weitgehend sehr sinnvoll. Ich programmiere mittlerweile 
auch privat nach MISRA da ich deutlich weniger Fehler mache und die 
Wartung des Codes einfacher ist.
Schlimm wirds erst durch firmeninterne Vorgaben wie Variablen etc. zu 
bennen sind. Ich hatte mal nen AG, der wollte den Firmennamen in 
Typedefs haben...

Studis werden bei mir auch dazu angehalten, MISRA konform zu 
programmieren. Besonders nach meiner studenlanger Fehlersuche aufgrund 
unnitialisierter Variablen bei nem Studi eines Kollegen ging mir fast 
mal die Hutschnur hoch... Der übrigens MISRA ablehnt.

Ach ja: NIEMANDEN kenne ich, der 100% MISRA befolgt, das geht oft gar 
nicht. (Viel Spaß mit while(1) in der int main...). Es wird immer ein 
Subset definiert das für die aktuelle Anwendung sinnvoll ist. Teils mit 
strikteren Regeln, teils werden Regeln entfernt. NUR SO funktioniert das 
sinnvoll. Und genau so ist das auch gedacht!

(Alternative: Gefühlt jede zweite Zeile nen Justification-Kommentar für 
den automatischen Checker schreiben, damit er zu meckern aufhört... 
Dieser Code ist nicht mehr anständig lesbar! Leider aber auch schon 
gesehen)

von Nop (Gast)


Lesenswert?

meckerziege schrieb:

> Ach ja: NIEMANDEN kenne ich, der 100% MISRA befolgt, das geht oft gar
> nicht. (Viel Spaß mit while(1) in der int main...).

Die von K&R gewählte Form mit for(;;) geht auch durch Lint durch.

von Paul (Gast)


Lesenswert?

Quality first. Bedenken second. schrieb:
> Der macht gerade ein Training zum Digital
> Acceleration Ambassador um mit seinem neuen Knowledge und dem freshen
> Mindset die New Work Transformation seines Konzerns zu facilitaten.

... I should not have googled that...

das gibs ja wirklich

von Claus M. (Gast)


Lesenswert?

meckerziege schrieb:
> while(1)

Das heißt ja auch while(true) wenn es Misra 2012 konform sein soll.

von A. S. (Gast)


Lesenswert?

Claus M. schrieb:
> Das heißt ja auch while(true) wenn es Misra 2012 konform sein soll

Konstante in Conditional Expression. Genau dafür gibt es ja for(;;).

von Einfach unverbesserlich (Gast)


Lesenswert?

Sowas ist doch nur was für Beamte

von Claus M. (Gast)


Lesenswert?

A. S. schrieb:
> Claus M. schrieb:
>> Das heißt ja auch while(true) wenn es Misra 2012 konform sein soll
>
> Konstante in Conditional Expression. Genau dafür gibt es ja for(;;).

Also bei meinem Misra checker geht es durch. Sicher, dass es eine Misra 
Verletzung ist, oder ist es eine PC lint Warnung? Welche MISRA Regel 
soll das sein?

von Nick M. (Gast)


Lesenswert?

A. S. schrieb:
> Genau dafür gibt es ja for(;;)

Ich schreib immer die Variante. Das sind so synonyme die man schnell 
erkennt und immer verwendet. Es get mir darum, dass der code schnell 
erfassbar ist und ordentlich strukturiert.
Und wenn eine Funktion fertig ist, fällt mir gelegentlich auf, dass die 
wirr aussieht. Was dann dazu führt, dass ich sie umstrukturiere oder 
zerteile.

Die Benamserei muss bei mir klar sagen, was das soll. Machmal dauert die 
Namenssuche auch länger, oder ich stell später fest, dass der Name 
ungeeignet ist. Dann gibt es halt ein rename. Ist aber nicht Teil von 
MISRA und oft genug nicht von style guides.

Die Lektüre von "Literate Programming" hatte da einen großen Einfluss 
auf mich.


Ich bin jetzt mit dem MISRA C so halb durch. Da war nichts dabei was 
mich erschreckt. Eher oft Stirnrunzeln warum das eine Regel ist, mach 
ich doch sowieso so.
Gut, es gibt paar Kleinigkeiten, bei denen ich mich "umerziehen" muss. 
Aber nichts tragisches oder nichts, das mir zuwieder ist.

von Claus M. (Gast)


Lesenswert?

Hab nochmal nachgeschaut, MISRA erlaubt while(true), siehe Ausnahme 1 
von Regel 14.3.

von Meckerziege (Gast)


Lesenswert?

Das Problem ist ganz ein anderes: int main muss ein int zurückgeben.

Also schreibst du unten, return 0,hin. Das return ist nun aber dead code 
weil die while oder for Schleife nie verlassen werden kann. Fehler.

Also lässt du es weg. Fehler. Eine Funktion die int zurückgibt braucht 
ein return ?

von Claus M. (Gast)


Lesenswert?

Kein echter embedded Programmierer schreibt int main hin, das heißt 
natürlich void main, scheiß auf den standard. Int main ist was für PC 
Programmierer.

von Clemens L. (c_l)


Lesenswert?

Claus M. schrieb:
> void main, scheiß auf den standard

ISO/IEC 9899:2018 und alle vorherigen Standards seit C89 sagen:
> 5.1.2 Execution environments
>
> Two execution environments are defined: freestanding and hosted. In
> both cases, program startup occurs when a designated C function is called
> by the execution environment. [...]
>
> 5.1.2.1 Freestanding environment
>
> In a freestanding environment (in which C program execution may take place
> without any benefit of an operating system), the name and type of the
> function called at program startup are implementation-defined. [...]
> The effect of program termination in a freestanding environment is
> implementation-defined.

void main(void) ist also standard-konform.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Clemens L. schrieb:
> void main(void) ist also standard-konform.

Aber nur in einem freestanding environment. Das wiederum verhindert 
jegliche Optimierungen von Bibliotheksfunktionen, die der Compiler 
ansonsten als “implicit knowledge” durchführen kann, darf und möchte. 
Wenn du dann also irgendwo `strlen("foo")' schreibst, zwingst du ihn zu 
einem Funktionsaufruf zur Laufzeit, obwohl er stattdessen eigentlich die 
Konstante 3 einsetzen könnte. Oder du fängst dann halt wieder mit 
solchen Krücken wie `sizeof("foo") - 1' an … Ich für meinen Teil 
definiere dann lieber, dass ich ein hosted environment habe, und dass 
main() vom Typ "int" ist, auch wenn dieser Wert nie zurückgegeben werden 
kann wegen der Endlosschleife.

von Claus M. (Gast)


Lesenswert?

Jörg W. schrieb:
> strlen("foo")' schreibst, zwingst du ihn zu einem Funktionsaufruf zur
> Laufzeit, obwohl er stattdessen eigentlich die Konstante 3 einsetzen
> könnte

MISRA will eh, dass man ohne Bibliotheksfunktionen auskommt. Ist auch 
richtig so, z. B. bei strlen weißt du nicht was passiert, wenn sie keine 
0 findet.

von Jemand (Gast)


Lesenswert?

Jörg W. schrieb:
> Aber nur in einem freestanding environment.

Ich sehe keine speziellen Einschränkungen für ein hosted Environment, 
nur Mindestvorraussetzungen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jemand schrieb:
> Jörg W. schrieb:
>> Aber nur in einem freestanding environment.
>
> Ich sehe keine speziellen Einschränkungen für ein hosted Environment,
> nur Mindestvorraussetzungen.

Dann lies dir bitte noch 5.1.2.2 durch.

Claus M. schrieb:
> MISRA will eh, dass man ohne Bibliotheksfunktionen auskommt.

Fahrräder nochmal erfinden. Meist langsamere und fehleranfälligere 
Fahrräder als die, die es „von der Stange“ gibt. Gut, dann weiß man 
wenigstens, dass alle Bugs die eigenen sind, auch wenn es mit hoher 
Wahrscheinlichkeit mehr Bugs sind als bei einer gut „abgehangenen“ 
Bibliothek …

von Bernd K. (prof7bit)


Lesenswert?

Claus M. schrieb:
> meckerziege schrieb:
>> while(1)
>
> Das heißt ja auch while(true) wenn es Misra 2012 konform sein soll.

Und es heißt while("my guitar gently weeps") wenn es überhaupt nicht 
konform sein soll.

von Walter T. (nicolas)


Lesenswert?

Jörg W. schrieb:
> Fahrräder nochmal erfinden. Meist langsamere und fehleranfälligere
> Fahrräder als die, die es „von der Stange“ gibt.

Ist halt die Denkweise: Für jede Komponente bedarf es eines 
Verantwortlichen, der im Falle des Falles in Regreß genommen werden 
kann. Dieser muß nachweisen, daß jede Komponente getestet wurd. Damit 
ist der Testaufwand deutlich größer als der Implementierungsaufwand. 
Also kann man die Komponente auch direkt selbst schreiben, dann weiß man 
zumindest, nach welchen Kriterien man testen muß.


Da steht die Automobilbranche im kompletten Gegensatz zu allen anderen, 
aber komplett dumm ist die Sichtweise nicht.

von Jemand (Gast)


Lesenswert?

Jörg W. schrieb:
> Jemand schrieb:
>> Jörg W. schrieb:
>>> Aber nur in einem freestanding environment.
>>
>> Ich sehe keine speziellen Einschränkungen für ein hosted Environment,
>> nur Mindestvorraussetzungen.
>
> Dann lies dir bitte noch 5.1.2.2 durch.

Und nun?
> or in some other implementation-defined manner.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jemand schrieb:

> Und nun?

>> or in some other implementation-defined manner.

Hmm, OK.

Gibt dann halt 'ne Warnung, wenn man mit -fhosted compiliert. Aber da ja 
MISRA offenbar sowieso keine Bibliotheksfunktionen will, kann man 
wirklich auch -ffreestanding nehmen.

Bloß gut, dass ich sowas nicht benutzen muss. :)

von UndNun (Gast)


Lesenswert?

meckerziege schrieb:
> Ich hatte mal nen AG, der wollte den Firmennamen in
> Typedefs haben...

Hmm, ich habe die Befürchtung das war hier bei mir i** e*******.
Total deppert!

von Roland F. (rhf)


Lesenswert?

Hallo,
Walter T. schrieb:
> Also kann man die Komponente auch direkt selbst schreiben, dann weiß man
> zumindest, nach welchen Kriterien man testen muß.

Mit dem Argument müsste man dann auch den Compiler der verwendeten 
Programmiersprache selbst entwickeln.

rhf

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Roland F. schrieb:
> Mit dem Argument müsste man dann auch den Compiler der verwendeten
> Programmiersprache selbst entwickeln.

Psst, nicht so laut sagen, sonst steht das in der nächsten 
MISRA-Revision drin. :-)

von Claus M. (energy)


Lesenswert?

Jörg W. schrieb:
> Roland F. schrieb:
>> Mit dem Argument müsste man dann auch den Compiler der verwendeten
>> Programmiersprache selbst entwickeln.
>
> Psst, nicht so laut sagen, sonst steht das in der nächsten
> MISRA-Revision drin. :-)

Ne, denn bei Misra geht es um C und nicht um Compiler. In Normen wie der 
ISO 26262 steht aber durchaus drin, dass der Compiler bzw. Tools 
allgemein qualifiziert sein müssen. Man kann also nicht einfach xyz 
verwenden ohne sich weitere Gedanken zu machen.

: Bearbeitet durch User
von Bernd K. (prof7bit)


Lesenswert?

Jörg W. schrieb:
> Roland F. schrieb:
>> Mit dem Argument müsste man dann auch den Compiler der verwendeten
>> Programmiersprache selbst entwickeln.
>
> Psst, nicht so laut sagen, sonst steht das in der nächsten
> MISRA-Revision drin. :-)

Lass sie doch machen, das stört doch keinen.

von Roland F. (rhf)


Lesenswert?

Hallo,
Claus M. schrieb:
> Ne, denn bei Misra geht ... nicht um Compiler.

Das gilt aber dann auch bei irgend welchen verwendeten Bibliotheken, die 
in irgend welchen Programmiersprachen geschrieben wurden.
Die Forderung keine Bibliotheken einzusetzen und alles selbst zu 
entwickeln  scheint mir daher nicht so ganz schlüssig.

rhf

von Claus M. (energy)


Lesenswert?

Roland F. schrieb:
> Das gilt aber dann auch bei irgend welchen verwendeten Bibliotheken, die
> in irgend welchen Programmiersprachen geschrieben wurden. Die Forderung
> keine Bibliotheken einzusetzen und alles selbst zu entwickeln  scheint
> mir daher nicht so ganz schlüssig.

Sehe ich nicht so.

von A. S. (Gast)


Lesenswert?

Roland F. schrieb:
> Die Forderung keine Bibliotheken einzusetzen und alles selbst zu
> entwickeln  scheint mir daher nicht so ganz schlüssig.

Die gibt es auch nicht. Sondern mit der stdlib vorsichtig zu sein. z.b. 
Strings: Printf oder strcpy sind halt fragile.
Und für SIL: bei anderen sicherzustellen, dass sie verlässlich sind: 
z.b. proven in use, Quelltext nach misra vorliegen oder durch den 
Hersteller .(vor-)qualifiziert mit safety Handbuch.

von Carsten Sch. (Gast)


Lesenswert?

Ohje ich hoffe hier sind nur hobbyprogrammierer und nichts von euch 
landet in einem erwerbbaren Produkt.

von Nop (Gast)


Lesenswert?

Roland F. schrieb:

> Die Forderung keine Bibliotheken einzusetzen und alles selbst zu
> entwickeln  scheint mir daher nicht so ganz schlüssig.

Man muß durchaus nicht alles selbst entwickeln. Was allerdings gar nicht 
geht, das sind Compiler-Libraries, die nicht im Source vorliegen. Weder 
kann man das auditieren, noch ist es einer Coverage-Analyse beim Testen 
zugänglich, und man weiß nichtmal, was exakt da eigentlich implementiert 
wurde.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Nop schrieb:
> Was allerdings gar nicht geht, das sind Compiler-Libraries, die nicht
> im Source vorliegen.

Ist das wirklich so? In letzter Konsequenz würde das ja bedeuten, dass
nicht einmal die Multiplikationsroutine aus der Laufzeitbibliothek
genutzt werden darf.

Verwendet man also einen Prozessor, der die Multiplikation nicht schon
hardwareseitig implementiert hat, müsste man eine entsprechende Routine
selber schreiben.

von Nop (Gast)


Lesenswert?

Yalu X. schrieb:

> Ist das wirklich so? In letzter Konsequenz würde das ja bedeuten, dass
> nicht einmal die Multiplikationsroutine aus der Laufzeitbibliothek
> genutzt werden darf.

Jein. Die ist erstens relativ simpel (jedenfalls für Integer) und 
zweitens aller Wahrscheinlichkeit nach eh in Assembler geschrieben. Da 
kann man auch einfach das Disassembly reviewen.

Bei z.B. printf oder qsort will man sich wohl eher nicht durchs 
Disassembly graben wollen.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Nop schrieb:
> Jein. Die ist erstens relativ simpel (jedenfalls für Integer) und
> zweitens aller Wahrscheinlichkeit nach eh in Assembler geschrieben. Da
> kann man auch einfach das Disassembly reviewen.

Es gibt ja nicht nur eine einzige Multiplikationsroutine, sondern eine
ganze Menge davon (für unterschiedliche Operanden- und Ergebnistypen).
Daneben gibt es viele weitere Rechenoperationen und Typkonvertierungen,
die oft ebenfalls als Bibliotheksroutinen implementiert sind.

So enthält bspw. die libgcc des AVR-GCC 9.2.0 nicht weniger als 836
Funktionen, die disassembliert insgesamt 41943 Zeilen reinen Code (ohne
Labels, Leerzeilen u.ä.) ergeben. Bei Closed-Source-Compilern wird das
nicht viel anders sein.

Das alles sorgfältig zu reviewen dürfte selbst für jemanden mit viel
Ahnung in der Assemblerprogrammierung auf dem entsprechenden Prozessor
mindestens eine Woche in Anspruch nehmen. Wenn der Compilerhersteller
ein Update liefert, geht der Spaß von vorne los.

Bist du sicher, dass man sich da nicht irgendwie drumherum mogeln kann,
ohne formal gegen die MISRA-Regeln zu verstoßen?

von Walter T. (nicolas)


Lesenswert?

Yalu X. schrieb:
> Das alles sorgfältig zu reviewen dürfte selbst für jemanden mit viel
> Ahnung in der Assemblerprogrammierung auf dem entsprechenden Prozessor
> mindestens eine Woche in Anspruch nehmen

Wie das auf dieser unteren Ebene praktisch abläuft, weiß ich nicht. Aber 
die Vorstellung, da da einfach zwei gutbezahlte Experten ein oder zwei 
Wochen lang die Köpfe zusammenstecken und Formulare ausfüllen klingt für 
mich jetzt erst einmal nach im Verhältnis zum restlichen Testaufwand so 
geringen Kostenfaktor, daß es im Hintergrundrauschen untergeht.

Zumal das ja auch in den Aufgabenbereich des Compilerherstellers fällt.

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

Walter T. schrieb:
> Zumal das ja auch in den Aufgabenbereich des Compilerherstellers fällt.

Ja, wenn das der Compilerhersteller übernimmt, ist das praktikabel, weil
dieser den Zugriff auf den kommentierten Quellcode hat und die Arbeit
dann nur einmal anfällt.

Wenn der Hersteller aber die Compilerbibliothek reviewt, ist es kein
großer Mehraufwand, das gleich auch für die Standardbibliothek (inkl.
der oben diskutierten strlen-Funktion) zu tun.

Damit wäre auch das von Claus ins Spiel gebrachte Verbot der Verwendung
von Bibliotheksfunktionen hinfällig.

von Nop (Gast)


Lesenswert?

Yalu X. schrieb:

> Das alles sorgfältig zu reviewen dürfte selbst für jemanden mit viel
> Ahnung in der Assemblerprogrammierung auf dem entsprechenden Prozessor
> mindestens eine Woche in Anspruch nehmen.

Eher einen Monat. Aber das ist halt auch ein Argument, sich gleich einen 
Prozessor zu nehmen, der Multiplikation und Division in Hardware kann. 
Bei solchen Produkten spielen die Kosten des Mikrocontrollers selber 
praktisch ohnehin keine wesentliche Rolle.

> Wenn der Compilerhersteller
> ein Update liefert, geht der Spaß von vorne los.

Was man mit eigenen Libraries eben nicht hat. Andererseits, nach einem 
Compiler-Update muß man ja ohnehin die komplette Software neu 
verifizieren. Mitsamt Coverage, je nach Anforderungslevel. Das ist ein 
Grund, wieso man Compiler-Updates nicht mal eben zwischendrin macht.

> Bist du sicher, dass man sich da nicht irgendwie drumherum mogeln kann,
> ohne formal gegen die MISRA-Regeln zu verstoßen?

Wenn der Compiler-Hersteller entsprechende Doku erstellt, geht das 
natürlich auch. Da sich dann die notwendige Arbeit auf viele Kunden 
verteilt und eine kommerzielle Lizenz ohnehin deutlich vierstellige 
Beträge kostet, ist das durchaus drin.

Zumal sich kommerzielle Anbieter ja mit irgendwas auch von der 
kostenlosen GCC-Konkurrenz abheben müssen.

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Claus M. schrieb:
> z. B. bei strlen weißt du nicht was passiert, wenn sie keine
> 0 findet.
Genau dafür wurde mal strnlen_s eingeführt:
https://en.cppreference.com/w/c/string/byte/strlen


A. S. schrieb:
> Printf oder strcpy sind halt fragile.
Und auch hier gibt es Nachfolgefunktionen die diese entschärfen:
strcpy_s: https://en.cppreference.com/w/c/string/byte/strcpy
printf_s: https://en.cppreference.com/w/c/io/fprintf
strcat_s, strncpy_s, sprintf_s, memcpy_s und noch einige weitere...


Man müsste diese neueren Varianten nur auch verwenden, aber dann könnte 
man ja nicht mehr so schön über die Mängel von C herziehen:-)

von Claus M. (energy)


Lesenswert?

Irgend W. schrieb:
> Man müsste diese neueren Varianten nur auch verwenden

Zeig mir erstmal den embedded Compiler, der C11 unterstützt. Bei den 
großen Herstellern ist C99 noch nicht so lange Standard...

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Claus M. schrieb:
> Bei den großen Herstellern ist C99 noch nicht so lange Standard...

IAR hat das praktisch schon fast seit 1999. Ist auch kein Wunder, die 
Bibliothek stammt von jemandem, der im ISO-C-Gremium teilnimmt. ;) 
Außerdem bekommt man (mit der Kaufversion) auch den Quelltext der 
Bibliothek.

von Claus M. (energy)


Lesenswert?

Jörg W. schrieb:
> IAR hat das praktisch schon fast seit 1999.

Das ist löblich. Allerdings spielen die im automotive Umfeld wohl kaum 
eine Rolle, da die typischen  MCUs wie Tricore meines Wissens nicht 
unterstützt werden.

von Walter T. (nicolas)


Lesenswert?

Claus M. schrieb:
> da die typischen  MCUs wie Tricore

Der V850 ist doch auch eine typische Automotive-MCU.

von Seppel (Gast)


Lesenswert?

Hallo,

in den letzten Jahren(ca. 7 Jahre lang) habe ich einiges an Safety-Code 
geschrieben. Aktuell schreibe ich QM Code und mache mehr 
Systementwicklung (Elektronik, Konstruktion,...), bin nicht traurig dass 
ich den Druck nicht mehr habe.

MISRA-C macht immer Sinn, der Standard ist echt gut und man vermeidet 
viele Fehler, die neuste Ausgabe hat auch viele Beispiele, sehr gut.

PC-Lint ist in der Autoindustrie kaum verbreitet, ich kenne niemanden 
der das im Safety-Umfeld nutzt. Klocwork, QA-Systems, Polyspace,... , 
wobei Polyspace meine klare Präferenz ist. Das Tool muss „Nachweise“ 
haben, Du musst eine Nachweisführung machen und die Abweichen zu MISRA 
begründen, jede einzelne, klappt mit den Tools auch gut. 
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Anforderungen sind extrem wichtig, Das was Du implementierst muss durch 
vorher geschriebene Anforderungen begründet sein. Und die Tests müssen 
den gesamten Code abdecken, selbst bei nicht  sicherheitskritischem Code 
wird fast 100% MC/DC gefordert, kommt im Detail etwas auf den OEM an. 
Das Testtool braucht auch „NAchweise“, Du musst auch hier Nachweise 
führen. VectorCAST ist gut, damit kann man ordentlich arbeiten.

Wir hatten einen mehrstufigen Prozess gehabt:

0) Statische Codeanalyse
1) Software Review
2) Software Modul Tests (SIL)
3) Software Integrations Tests (SIL)
4) Tests auf der Ziel-Hardware (PIL)
5) Systemtests (HIL)
6) Tests im Gesamtsystemdurch eigene Mitarbeiter
7) Tests im Gesamtsystemdurch durch externe Mitarbeiter (Assessoren)
8) Tests im Gesamtsystemdurch durch Zulassungsbehörden
9) Tests durch den Kunden

Safety ist ein Riesen Aufwand, aber ich wollte nicht verantworten dass 
jemand stirbt. Sicherheit ist am wichtigsten und da muss man auch mal 
den Großen Chef belehren.

Der Chef sagt was gemacht wird, ich bin der Ingenieur, ich sag wie's 
gemacht wird, niemand stirbt durch meine Software.

Das ganze kann strafrechtlich relevant werden, einige Ingenieure bei VW 
haben ihren Job verloren und Prozesse am Hals, ganz ohne „Safety“. Was 
man als Software-Ingenieur tut kann ganz erhebliche Konsequenzen haben.

Grüße

Seppel

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Seppel schrieb:
> MISRA-C macht immer Sinn

Das "immer" würde ich nicht gelten lassen – es gibt genügend 
Softwareentwicklung außerhalb sicherheitskritischer Bereiche, und 
MISRA-C ist schon ein heftiges Korsett.

Auch bei sicherheitskritischen Anwendungen darf man deren Regeln schon 
mal hinterfragen. Zumindest das letzte Mal, dass ich in diese Schwarte 
geguckt habe, waren da noch Dinge drin, die eigentlich schon seit 20 
Jahren keine Rolle mehr spielen.

Grundsätzlich ist es auf jeden Fall gut, einen Satz von Standardregeln 
für sicherheitskritische Software zu haben, aber auch das Einhalten 
derartiger Regeln befreit einen natürlich nicht davon, über sein 
Geschreibsel nachzudenken, noch garantiert es einen fehlerfreien Code 
(nicht einmal ansatzweise).

: Bearbeitet durch Moderator
von A. S. (Gast)


Lesenswert?

Seppel schrieb:
> PC-Lint ist in der Autoindustrie kaum verbreitet,

Ja, das ist Lobby-Arbeit. Die Tools z.B. von QA kosten, das stecken die 
halt in Marketing, Kundenkontakt und Impfen von z.B. Tüv auf deren 
Berichte (die das Tool generiert). Wenn ich mir seinerzeit deren 
Wikipedia-Seite angesehen habe: das strotze nur so von Fake-Infos, war 
anscheinend komplett selbst gezimmert. Dabei lagen sie (vielleicht nicht 
viel) aber merklich hinter PC-Lint.


Das ist in etwa so, wie (non safety) Keil- oder IAR-Kompiler dort wo es 
gute gcc-Backends gibt. Oder wie bei uns seinerzeit Tortoise/SVN gegen 
den Willen des Chefs eingeführt wurde, weil es nichts kostete.

von Seppel (Gast)


Lesenswert?

Hallo Jörg,

@Jörg: Vermutlich hast Du hast MISRA-C nicht richtig gelesen, denn von 
den Regeln darf abgewichen werden, wenn dies erforderlich sein sollte, 
es legitime Gründe gibt,… wird nicht alles so heiß gegessen wie gekocht. 
Es soll den „übelsten Hack“ von der Codebase fernhalten. Ich hatte nie 
Schwierigkeiten MISRA-C praktisch umzusetzen, ich finde es super und 
wenn der Checker meckert, dann schaut man hin, macht mal ein Walktrough 
mit Kollegen, MIRA-C macht Spaß.

@A.S.: Wenn mir ein Subcontractor mit PC-Lint ankommt, dann nehme ich 
ihn nicht, der ist sofort raus. Ein Bug kostet eventuell Millionen an 
Rückruf, da nimmt keiner „PC-Lint“.  Ich kenne keine professionelle 
Firma die guten Code schreibt und PC-Lint verwendet, die guten Firmen 
leisten sich auch ein gutes Tooling.

Grüße, Seppel

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Seppel schrieb:
> Vermutlich hast Du hast MISRA-C nicht richtig gelesen, denn von den
> Regeln darf abgewichen werden, wenn dies erforderlich sein sollte, es
> legitime Gründe gibt

Wie geschrieben, ist eine Weile her, dass ich das Ding mal zwischen den 
Fingern hatte. Durchgelesen habe ich das schon, aber manches eben 
kopfschüttelnd. Ich bezweifle, dass eine Begründung "diese Regel hat 
keinen Sinn und führt nur zu schwer lesebarem Code" jedoch als 
Abweichung akzeptiert würde. ;-)

ps: Ich habe natürlich absolut nichts gegen Code Reviews, sowas machen 
wir auch fernab sicherheitskritischer Anwendungen. Nicht für jede Zeile, 
aber bspw. wenn größere Code-Teile komplett neu verfasst worden sind. 
Auch konsistenter Programmierstil ist sinnvoll, sollte aber kein Dogma 
sein.

: Bearbeitet durch Moderator
von Roland F. (rhf)


Lesenswert?

Hallo,
Seppel schrieb:
> @Jörg: Vermutlich hast Du hast MISRA-C nicht richtig gelesen, denn von
> den Regeln darf abgewichen werden, wenn dies erforderlich sein sollte,
> es legitime Gründe gibt,… wird nicht alles so heiß gegessen wie gekocht.
> Es soll den „übelsten Hack“ von der Codebase fernhalten.

Ich verstehe es immer weniger. Einerseits wird ein Regelwerk eingeführt, 
das zu besserer Code_Qualität führen soll. Andererseits darf aber von 
den Regeln (beliebig?) abgewichen werden, wenn dies erforderlich sein 
sollte (im Prinzip könnte dann auch ein "übler Hack" als MISRA-Conform 
durchgehen).

Aber was ist denn dann MISRA-C wert? Im Prinzip steht MISRA dann 
praktisch auf einer Stufe wie das CE-Zeichen in der Elektrotechnik: 
suggeriert Qualität, hat aber eigentlich keinen Wert.

rhf

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Roland F. schrieb:
> wie das CE-Zeichen in der Elektrotechnik: suggeriert Qualität

Da hast du was falsch verstanden.

Es bezeichnet keine "Qualität", sondern es ist der (für den Kunden dann 
auch sichtbare) Ausdruck desjenigen, der es anbringt, dass er die 
Konformität des Produkts mit den zutreffenden Regelungen bestätigt (die 
er dann in der Konformitätserklärung genauer bezeichnen muss).

Das sind lediglich Mindeststandards bspw. für Einstrahlfestigkeit, 
Abstrahlung elektromagnetischer Felder oder Berührungssicherheit. Das 
ist also gewissermaßen die verpflichtend einzuhaltende unterste 
Qualitätsstufe, wenn du das auf Qualität beziehst. Die Geräte, die 
selbst das nicht einhalten, dürfen auf dem europäischen Binnenmarkt 
schlicht nicht in Verkehr gebracht werden.

von Nop (Gast)


Lesenswert?

Roland F. schrieb:

> Ich verstehe es immer weniger. Einerseits wird ein Regelwerk eingeführt,
> das zu besserer Code_Qualität führen soll. Andererseits darf aber von
> den Regeln (beliebig?) abgewichen werden

Abweichen darfst Du zwar, mußt dann aber je nach Schweregrad mehr oder 
weniger Aufwand zur Rechtfertigung betreiben. Sinn der Sache ist vor 
allem, daß man nicht mal eben aus Bequemlichkeit oder gar aus 
Ahnungslosigkeit leichtfertig abweicht, denn das sind genau die 
Situationen, die als fehlerträchtig erachtet werden.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.