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.
Es gibt auch zertifizierte Toolchains, die einem das Leben einfacher machen: https://www.iar.com/iar-embedded-workbench/certified-tools-for-functional-safety
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.
Beitrag #6543741 wurde von einem Moderator gelöscht.
Beitrag #6543744 wurde von einem Moderator gelöscht.
Beitrag #6543755 wurde von einem Moderator gelöscht.
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.
Beitrag #6544335 wurde von einem Moderator gelöscht.
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 | 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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.