Forum: Ausbildung, Studium & Beruf Ist C++ in der Industrie im Bereich Funktionale Sicherheit etabliert?


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.
von abgehängt (Gast)


Lesenswert?

Hallo,

bei meinem Arbeitgeber (Maschinenbauer, Großunternehmen) wurde vor 
Kurzem ein großes, wichtiges Projekt gestartet (Nachfolger des 
Hauptprodukts). In dem Projekt kommen mehrere Cortex-M-Mikrocontroller 
zum Einsatz. Funktionale Sicherheit gemäß IEC 61508 bzw. spezifischeren 
Normen ist gefordert.


Es wurde entschieden, C++ statt C zu nutzen.


Das hat mich überrascht, denn ich war bisher der Überzeugung, dass an C 
kein Weg vorbeiführt.


Nun frage ich mich, ob ich bisher in einer Blase gelebt habe. Ist C++ im 
Bereich FuSi nicht doch nur eine Verirrung eines Projektleiters?


Wie sind eure Erfahrungen in der Industrie? Nutzt auch ihr C++ im 
professionellem Umfeld für funktional sichere Mikrocontroller-Software? 
Ist es bei euch bereits etabliert, im Kommen, oder nach schlechten 
Erfahrungen bereits wieder im Rückgang?

von Weich W. (Firma: Weichwarengesellschaft mbH) (hand_werker)


Lesenswert?

abgehängt schrieb:
> Das hat mich überrascht, denn ich war bisher der Überzeugung, dass an C
> kein Weg vorbeiführt.

Die Übergänge sind ja fließend. Man kann fast jeden C-Code mit wenig 
Aufwand auf C++ portieren.

von abgehängt (Gast)


Lesenswert?

Weich W. schrieb:
> Die Übergänge sind ja fließend. Man kann fast jeden C-Code mit wenig
> Aufwand auf C++ portieren.

Zugegenbenermaßen ist meine Meinung zu dieser Entscheidung aus meinem 
Text deutlich geworden. Die Frage, die ich mir stelle, ist, ob C++ - 
nicht zuletzt durch die neuen, häufig gelobten Erweiterungen in den 
Standards C++11/14/17 - in der Industrie im Bereich 
Mikrocontroller-Programmierung gerade durchsetzt und C verdrängt. So wie 
es Mitte der 2000er mal aussah, was dann aber auch schnell wieder 
abebbte.

von C. A. Rotwang (Gast)


Lesenswert?

abgehängt schrieb:
> Nutzt auch ihr C++ im
> professionellem Umfeld für funktional sichere Mikrocontroller-Software?
> Ist es bei euch bereits etabliert, im Kommen, oder nach schlechten
> Erfahrungen bereits wieder im Rückgang?

Funktionalle Sicherheit ist weniger/kaum eine Frage der 
Programiersprache als eine Frage der Qualität des Entwicklungsprozeßes 
und des gesamtsystems.

Ein Qualitätsmerkmal darin ist konsequente Umsetzung eines Codestyles. 
Mit diesem Codestyle können 'riskante' (aka Codierweisen deren 
Sicherheitsauswirkungen nicht einschätzbar sind oder als negativ erkannt 
worden) Codiervarianten ausgeschlossen werden. Damit kann man im Prinzip 
jede Programmiersprache in Richtung Sicherheit 'zähmen'.

Nach meiner Erfahrung baut man sicherheitssystem redundant, wenn bspw 
die Software (wieder mal) ausflippt, greift die Hardware (bspw CPLD, 
externe Watchdog-timer-reset) und zwingt das system in den 
'Safe-Harbour'.

von Heinz (Gast)


Lesenswert?

Es kommt eher darauf an, ob es für die gewählte Programmiersprache einen 
freigegebenen (zertifizierten) Compiler gibt. Weiterhin wichtig sind die 
oben schon angesprochenen Programmierregeln, die festzulegen sind. Wenn 
die mit C++ umzusetzen sind und C++ die Codemetriken nicht verletzt, 
spricht nichts dagegen aus meiner Sicht.

Bei uns wird C eingesetzt.

von Bastelmensch (Gast)


Lesenswert?

Wir entwickeln nach IEC61508 mit C++ und benutzen z.B. keine dynamische 
Speicherverwaltung. Die STL fällt damit schon mal raus. Eingesetzt 
werden ausschließlich selbst entwickelte Libraries die auch nach Norm 
getestet sind. Streng genommen ist es ein C mit Klassen.

von Bastelmensch (Gast)


Lesenswert?

Es gibt auch zertifizierte Toolchains, die einem das Leben einfacher 
machen: 
https://www.iar.com/iar-embedded-workbench/certified-tools-for-functional-safety

von abgehängt (Gast)


Lesenswert?

Heinz schrieb:
> Bei uns wird C eingesetzt.

Bastelmensch schrieb:
> Wir entwickeln nach IEC61508 mit C++

Bastelmensch schrieb:
> Streng genommen ist es ein C mit Klassen.

Das ist das Feedback, was ich mir erhofft hatte. Vielen Dank.

Dass C++ für FuSi verwendet werden kann, wollte ich gar nicht infrage 
stellen. Wie von euch beschrieben geht es bei FuSi viel um 
Entwicklungsprozesse und Redundanz im System. Natürlich kann und muss 
ein Coding Standard für C++ verfasst werden, der die erlaubten Features 
einschränkt.

Mein Wunsch ist es, entgegen meines Namens eben nicht im Laufe meines 
Berufslebens abgehängt zu werden. Und wenn da auf einmal C++ auftaucht, 
frage ich mich als professioneller Embedded Software Developer, ob ich 
die letzten Jahre mit einer Lame Duck namens C hantiert habe und in 10 
Jahren alles in C++ programmiert wird.

von Wayne (Gast)


Lesenswert?

abgehängt schrieb:
> Und wenn da auf einmal C++ auftaucht, frage ich mich als professioneller
> Embedded Software Developer, ob ich die letzten Jahre mit einer Lame
> Duck namens C hantiert habe und in 10 Jahren alles in C++ programmiert
> wird.

Im Embedded Bereich wird es denke ich weiterhin bei C bleiben, zumindest 
für den weit überwiegenden Anteil der Projekte. Aber selbst wenn nicht, 
kannst du mit 10 Jahren Berufserfahrung immer noch auf eine andere 
Programmiersprache umsatteln. Die erste ist die härteste. Danach wird es 
einfacher und schneller.

von GrüneNeune (Gast)


Lesenswert?

Heinz schrieb:
> Es kommt eher darauf an, ob es für die gewählte Programmiersprache einen
> freigegebenen (zertifizierten) Compiler gibt.

Man kann den Compiler aber auch mit entsprechendem Aufwand selbst 
zertifizieren. -> Der Aufwand dafür lohnt nicht, wenn man diesen nicht 
kommerziell vertreiben will :) (meine Erfahrung, auch wenn interessante 
Erfahrung).
Habe selbst schon einen GNU C Compiler für ein SIL3 Projekt verifiziert.

Habe auch schon C++ in SIL Projekten eingesetzt. Meiner Meinung ist hier 
C++ aber eher ein Klotz am Bein. Allerdings war es schon interessant 
sich das Exception Handling und andere Dinge einmal im Detail 
anzuschauen.

Ein C++ safety Programmierer muss mehr wissen als ein C Safety 
Programmierer und das bei einem zu geringen Paket an Benefits. Auch 
fallen mit C++ Anfänger öfter in Performance Fallen. Damit ist C++ ein 
kleines finanzielles/Projektzeit Grab.

Für mich ist C als Programmiersprache einfach mehr "KISS" als C++ und 
daher im safety Bereich vorzuziehen. Wenn man aber schon erfolgreich ein 
Projekt in C++ umgesetzt hat und damit 90% des Teams damit Vorerfahrung 
haben, ist zurück wechseln aber auch Schwachsinn. Dann nimmt man besser 
die Benefits mit und führt neue Kollegen über die Aufgabenauswahl 
langsam an das zusätzliche Wissen heran.

von abgehängt (Gast)


Lesenswert?

Wayne schrieb:
> Im Embedded Bereich wird es denke ich weiterhin bei C bleiben, zumindest
> für den weit überwiegenden Anteil der Projekte.

Ich denke auch, dass im hardwarenahen Bereich bisher nichts C das Wasser 
reichen kann. C ist seit Jahrzehnten etabliert. Die geringe Bewegung bei 
der Standardisierung im Vergleich zu C++ ist positiv zu sehen, weil C 
für ihren Zweck eben schon lange ausgereift ist. Die Probleme von C sind 
bekannt und werden durch Programmierrichtlinie, statische Codeanalyse 
und Reviews durch erfahrene Programmierer umgangen.

GrüneNeune schrieb:
> Für mich ist C als Programmiersprache einfach mehr "KISS" als C++ und
> daher im safety Bereich vorzuziehen.

KISS = Keep it simple, stupid! Genau das sollte im professionellem 
Umfeld die Einstellung sein.

GrüneNeune schrieb:
> Wenn man aber schon erfolgreich ein
> Projekt in C++ umgesetzt hat und damit 90% des Teams damit Vorerfahrung
> haben, ist zurück wechseln aber auch Schwachsinn.

Richtig. Wenn die Entwickler C++ können, dann sollte man C++ nehmen. 
Wenn sie nur C können, sollte man lieber bei C bleiben. V.a. bei einem 
großen Projekt mit FuSi-Anforderungen.

GrüneNeune schrieb:
> Habe auch schon C++ in SIL Projekten eingesetzt. Meiner Meinung ist hier
> C++ aber eher ein Klotz am Bein.

Schon der 2., der professionell C++ genutzt hat. Liest sich für mich 
aber so, als sei das eher die Ausnahme gewesen und vorher sowieo nachher 
wurde C verwendet.

Beitrag #6543741 wurde von einem Moderator gelöscht.
Beitrag #6543744 wurde von einem Moderator gelöscht.
Beitrag #6543755 wurde von einem Moderator gelöscht.
von A. S. (achs)


Lesenswert?

abgehängt schrieb:
> Ich denke auch, dass im hardwarenahen Bereich bisher nichts C das Wasser
> reichen kann. C ist seit Jahrzehnten etabliert. Die geringe Bewegung bei
> der Standardisierung im Vergleich zu C++ ist positiv zu sehen, weil C
> für ihren Zweck eben schon lange ausgereift ist

Das ist m.E. falsch. C ist einfacher, kleiner und alt. Das ist für SIL 
ein Vorteil. Für HW-nah oder Performance gilt das nicht. Da hat C++ vor 
Jahren pari gezogen und zieht seitdem davon.

Das einzige, was aus meiner Sicht gegen C++ für embedded spricht: wenn 
man die meisten Konstrukte eigentlich nicht braucht, kann der Code 
schnell unleserlich werden. vor allem wenn PC-Programmierer mit 
unterschiedlicher Erfahrung im Team sind.

von ... (Gast)


Lesenswert?

Es wundert mich sowieso, dass für sicherheitskritische Sachen C oder C++ 
verwendet wird. Eigentlich dürfte eine Programmiersprache, von der nur 
ein Teil verwendet werden darf, damit es sicher ist, nicht für 
sicherheitskritische Sachen verwendet werden.
Man bräuchte eigentlich eine Programmiersprache, wo die fehleranfälligen 
Konstrukte gar nicht möglich sind. Warum hat sich da nicht Pascal oder 
ADA durchgesetzt?

Also ich programmiere auch auf Mikrocontroller alles in C oder C++. Aber 
seltsam ist das schon, wenn man mal darüber nachdenkt.

von abgehängt (Gast)


Lesenswert?

A. S. schrieb:
> Das einzige, was aus meiner Sicht gegen C++ für embedded spricht: wenn
> man die meisten Konstrukte eigentlich nicht braucht, kann der Code
> schnell unleserlich werden. vor allem wenn PC-Programmierer mit
> unterschiedlicher Erfahrung im Team sind.

Das ist der wesentlich Punkt. In meiner Umgebung ist es so, dass 
Embedded Software Entwickler kein C++ können, PC-Programmierer keine 
Embedded Software Entwicklung, besonders im Bereich FuSi. Da sind die 
Probleme vorprogrammiert. Die PC-Fraktion packt das Gang of Four-Buch 
auf den Tisch und möchte die Hälfte der dort zusammengestellten 
Design-Patterns verwenden, um portable Software zu erstellen, der 
erfahrene Embedded Software Entwickler versucht, C++ auf "C mit Klassen" 
zu reduzieren.

... schrieb:
> Es wundert mich sowieso, dass für sicherheitskritische Sachen C oder C++
> verwendet wird. Eigentlich dürfte eine Programmiersprache, von der nur
> ein Teil verwendet werden darf, damit es sicher ist, nicht für
> sicherheitskritische Sachen verwendet werden.

Genau genommen wird normativ empfohlen, sowas wie Ada zu verwenden 
(siehe hier: 
https://www.embedded-software-engineering.de/software-entwicklung-gemaess-iec61508-a-921923/):

"Streng typisierte Programmiersprachen sind nach der IEC 61508 empfohlen 
(ADA, Pascal), C jedoch nicht (nur mit Einschränkungen)."

Tut aber niemand.

"Aber: C ist in der Softwareentwicklung von Embedded-Systemen de facto 
Standard."

Da stellt sich halt die Frage, ob das immer noch so ist.

... schrieb:
> Also ich programmiere auch auf Mikrocontroller alles in C oder C++.

Auch professionell mit normativen Anforderungen? Gibt es da eine 
Tendenz? 80% der Projekte in C, 20% C++. C++-Tendenz steigend?

von A. S. (achs)


Lesenswert?

... schrieb:
> Eigentlich dürfte eine Programmiersprache, von der nur ein Teil
> verwendet werden darf, damit es sicher ist, nicht für
> sicherheitskritische Sachen verwendet werden.
Das meiste wird ja durch z.b. Misra vorgegeben ...
> Man bräuchte eigentlich eine Programmiersprache, wo die fehleranfälligen
> Konstrukte gar nicht möglich sind.
 und durch statische Codeanalyse geprüft.

> Warum hat sich da nicht Pascal oder
> ADA durchgesetzt?
Weil die Werkzeuge (Compiler, statische Codeanalyse, IDEs) halt viel 
seltener, unbekannter und weniger erforscht sind. Das ist so, als würde 
man Sicherheitshinweise auf Latein verfassen, weil Deutsch 
missverständlich ist.

von Urlaubär (Gast)


Lesenswert?

Wie soll man denn mit C oder C++ überhaupt eine Sicherheit garantieren? 
Ein versehentlicher Buffer-Overflow und das ganze Programm kann verrückt 
spielen. Wenn es um Menschenleben geht, müssen professionelle Tools wie 
Ada eingesetzt werden.

Beitrag #6544335 wurde von einem Moderator gelöscht.
von Wayne (Gast)


Lesenswert?

Urlaubär schrieb:
> Wie soll man denn mit C oder C++ überhaupt eine Sicherheit garantieren?
> Ein versehentlicher Buffer-Overflow und das ganze Programm kann verrückt
> spielen. Wenn es um Menschenleben geht, müssen professionelle Tools wie
> Ada eingesetzt werden.

Wenn ein versehentlicher Buffer-Overflow dazu führt, dann haben von den 
Software-Entwicklern, System-Verantwortlichen, Qualitäter, FUSIanern bis 
zu den externen Auditoren eine ganze menge Leute ihren Job nicht 
gemacht. Stichwort: FTA, Fault Injection Tests, Daten- und 
Kontrollflussanalyse etc., dann ist das nicht fail safe und das 
technische Sicherheitskonzept passt vorne und hinten nicht.

Wie schon korrekterweise angesprochen wurde: Die Programmiersprache 
spielt für sicherheitskritische Systeme keine Rolle. C wird 
hauptsächlich genommen, weil es da schon viel gibt.

von Carl D. (jcw2)


Lesenswert?

... schrieb:
> Es wundert mich sowieso, dass für sicherheitskritische Sachen C oder C++
> verwendet wird. Eigentlich dürfte eine Programmiersprache, von der nur
> ein Teil verwendet werden darf, damit es sicher ist, nicht für
> sicherheitskritische Sachen verwendet werden.
> Man bräuchte eigentlich eine Programmiersprache, wo die fehleranfälligen
> Konstrukte gar nicht möglich sind. Warum hat sich da nicht Pascal oder
> ADA durchgesetzt?
>
> Also ich programmiere auch auf Mikrocontroller alles in C oder C++. Aber
> seltsam ist das schon, wenn man mal darüber nachdenkt.

Ada hat schon die feurige Gelegenheit genutzt zu zeigen , daß ihre 
Sicherheits-Features nicht gegen typische nicht-technische Fehler 
helfen. Z.B. ob man imperial oder metrisch aufgewachsen ist. C++ bietet 
Möglichkeiten diese Art von Fehlern zu umgehen.
Mir ist es auch ganz egal, wie kompliziert sowas wie <chrono> oder eben 
eine Einheiten-Lib intern aussehen. Wenn man damit aber
1
 auto entfernung = 5_miles + 47_m;
und als Ergebnis 5,0292044 Meilen rauskommen, dann ist das in jeder 
Hinsicht ein Fortschritt. Oder wenn der Compiler anhand der Typen 
feststellen kann, daß ein Ausdruck, der eine Geschwindigkeit ergeben 
soll, nicht "Zeit durch Länge" sein kann, dann erspart das manchmal 
teuere Feuerwerke zur Unzeit (nicht Silvester) am falschen Platz (nicht 
Paris). Ariane-Fireworks läßt grüßen.

von abgehängt (Gast)


Lesenswert?

Brückenstürzer schrieb im Beitrag #6544335:
> normen und dokumentenfriemlei

Das stimmt, sowas ist lästig. Im Berufsleben kann leider nicht alles nur 
Spaß bringen. Wenn man sich in das Thema FuSi erst eingearbeitet hat, 
verringert sich die Zeit, die mit dem Studieren von Normen verbracht 
werden muss. Bewährte Dokumente müssen auch nicht komplett neu verfasst 
werden. Dann hat man auch wieder mehr Programmieraufgaben. Und diese 
müssen dann zwecks Zertifizierungs-Anforderungen auf einem höheren 
Niveau bearbeitet werden als Nicht-FuSi-Software. Das ist das Reizvolle. 
Aber der Weg dorthin ist steinig, da hat man in der Tat öfters das 
Bedürfnis, sich selbst zu richten. Es lohnt sich aber, weiterzumachen. 
Kann ich nur empfehlen. Ist auch sehr gefragtes Know How.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Urlaubär schrieb:
> Wie soll man denn mit C oder C++ überhaupt eine Sicherheit garantieren?
> Ein versehentlicher Buffer-Overflow und das ganze Programm kann verrückt
> spielen. Wenn es um Menschenleben geht, müssen professionelle Tools wie
> Ada eingesetzt werden.

Ob die Steuerungssoftware einer Herz-Lungen-Maschine bei einen
Buffer-Overflow anfängt herumzuspinnen (in C) oder kontrolliert
abgebrochen wird (in Ada), macht für den betroffenen Patienten kaum
einen Unterschied. Bei der C-Software hat er immerhin die Chance, dass
sie auch nach Auftreten des Fehler noch wenigstens halbwegs das Richtige
tut, bei der mit einer Exception abbrechenden Ada-Software ist er sofort
tot.

Auch ich zitiere noch einmal das, was bereits mehrere geschrieben haben:

C. A. Rotwang schrieb:
> Funktionalle Sicherheit ist weniger/kaum eine Frage der
> Programiersprache als eine Frage der Qualität des Entwicklungsprozeßes
> und des gesamtsystems.

von Andreas (Gast)


Lesenswert?

Yalu X. schrieb:
> Bei der C-Software hat er immerhin die Chance, dass
> sie auch nach Auftreten des Fehler noch wenigstens halbwegs das Richtige
> tut, bei der mit einer Exception abbrechenden Ada-Software ist er sofort
> tot.

Das halte ich jetzt nicht für ein gültiges Argument. Exceptions kann man 
abfangen und z.B. in einen Failsafe-Modus gehen/auf Redundanz umschalten 
und Alarm schlagen. Jeder sicherheitsbewusste Entwicklungsprozess würde 
fordern dass jede mögliche Exception entsprechend abgedeckt wird.

Yalu X. schrieb:
> Auch ich zitiere noch einmal das, was bereits mehrere geschrieben haben:

Da gibt es natürlich wenig Einwände.

von Ratgeber (Gast)


Lesenswert?

> Es wurde entschieden, C++ statt C zu nutzen.
>
> Nun frage ich mich, ob ich bisher in einer Blase gelebt habe. Ist C++ im
> Bereich FuSi nicht doch nur eine Verirrung eines Projektleiters?
>
> Wie sind eure Erfahrungen in der Industrie? Nutzt auch ihr C++ im
> professionellem Umfeld für funktional sichere Mikrocontroller-Software?
> Ist es bei euch bereits etabliert, im Kommen, oder nach schlechten
> Erfahrungen bereits wieder im Rückgang?

Es sollte modellbasiert entwickelt werden. C oder C++ macht keinen 
großen Unterschied

von A. S. (achs)


Lesenswert?

Ratgeber schrieb:
> Es sollte modellbasiert entwickelt werden.

Und was soll das konkret bedeuten?

Dass man in einer anderen formalen Sprache modelliert als C und die dann 
C Zwischencode macht oder direkt Assembler?

Dass man bunte Bilder malt und die dann in C abschreibt?

Dass man UML oder Matlab Codegeneratoren nutzt weil die einfacher zu 
zertifizieren sind?

von A. S. (achs)


Lesenswert?

Andreas schrieb:
> Das halte ich jetzt nicht für ein gültiges Argument. Exceptions kann man
> abfangen und z.B. in einen Failsafe-Modus gehen/auf Redundanz umschalten
> und Alarm schlagen. Jeder sicherheitsbewusste Entwicklungsprozess würde
> fordern dass jede mögliche Exception entsprechend abgedeckt wird.

Die möglichen Fehler in C bei Code für 61508 sind eher trivial dagegen. 
Buffetüberläufe sollten nicht unerkannt auftreten können. Ein strlen 
oder sowas nutzt man da nicht auf unbekannte Strings.

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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