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?
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..
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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
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.
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.
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.
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!
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.
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)
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.
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
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(;;).
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?
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.
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 ?
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.
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.
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.
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.
Jörg W. schrieb:> Aber nur in einem freestanding environment.
Ich sehe keine speziellen Einschränkungen für ein hosted Environment,
nur Mindestvorraussetzungen.
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 …
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.
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.
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.
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. :)
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!
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
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. :-)
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.
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.
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
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.
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.
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.
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.
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.
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?
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.
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.
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.
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...
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.
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.
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
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).
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.
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
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.
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
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.
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.
