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?
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.
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.
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'.
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.
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.
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.
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.
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.
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.
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.
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.
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?
... 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.
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.
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.
... 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
autoentfernung=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.
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.
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.
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.
> 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
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?
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.
