mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Nick M. (muellernick)
Datum:

Bewertung
1 lesenswert
nicht 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?

Autor: Bimbo. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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..

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Nick M. (muellernick)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Nick M. (muellernick)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Automotiv Entwickler (Gast)
Datum:

Bewertung
1 lesenswert
nicht 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.

Autor: kyrk.5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast vermutlich ISO 26262 gemeint, oder?

Autor: Nick M. (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kyrk.5 schrieb:
> Hast vermutlich ISO 26262 gemeint, oder?

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

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: A. S. (achs)
Datum:

Bewertung
1 lesenswert
nicht 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!

Autor: Timo (Gast)
Datum:

Bewertung
-3 lesenswert
nicht 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.
Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Auch Karl, ein anderer (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Einfach unverbesserlich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer C kann, der braucht den Mist nicht

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht 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

: Bearbeitet durch User
Autor: Quality first. Bedenken second. (Gast)
Datum:

Bewertung
1 lesenswert
nicht 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.

Autor: Nick M. (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Herren!

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

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
1 lesenswert
nicht 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.

Autor: Einfach unverbesserlich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Tja der wird es weit bringen.

Agil muss es sein.

Autor: Das soziale Kapital erhöhen (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Claus M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: meckerziege (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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)

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Paul (Gast)
Datum:

Bewertung
1 lesenswert
nicht 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

Autor: Claus M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meckerziege schrieb:
> while(1)

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

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht 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(;;).

Autor: Einfach unverbesserlich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas ist doch nur was für Beamte

Autor: Claus M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Nick M. (muellernick)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Claus M. (Gast)
Datum:

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

Autor: Meckerziege (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 😉

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.