Wie muß eine Level SIL 4 Programmiersprache aufgebaut sein?

_--

gibts iwo ein document, wo definiert ist welche anforderungen an eine level sil 4 programmiersprache gestellt werden? ich meine, dass die misra c regeln darin eher nicht vorkommen sollten ist klar. aber selbst dann schafft "misra c" ja "nur" SIL 2-3?

knivil

Ich habe kurz gegooglet, aber warum sollte das nur von der Programmiersprache abhaengen?

_--

knivil schrieb:

Ich habe kurz gegooglet, aber warum sollte das nur von der Programmiersprache abhaengen?

ja, dieses sil4 ist ja nur ein buzzword. natürlich ist die programmiersprache nur ein glied einer kette (es geht auch nicht so um diese super tolle sicherheit..). da ich mich zur zeit mit programmiersprachen beschäftige, würde mich interessieren ob es listen gibt was eine "sichere" programmiersprache so anbieten muß bzw. was die dann so sicher macht. oder sind das nicht vermittelbare erfahrungswerte

@edit: also vor menschlichem versagen wird einen keine schützen, und bei richtiger programmierung sollten alle gleich sicher sein? aber es muß doch was geben was den unterschied ausmacht

Klar: man kann in jeder Programmiersprache sicheren Code schreiben oder eben nicht. Die Frage ist nach dem Aufwand und danach, wie viele Fehler ein erfahrener Programmierer wirklich macht und warum er sie macht. Normalerweise werden auch keine Programmiersprachen mit SIL-Einstufungen versehen, sondern Systeme und das geht über Gefahren- und Risikoanalysen (also: Ausfallraten, Gefährung und Kontrollierbarkeit) und so'n Kram. Und dann gibt es "Empfehlungen", welche Sprachen man nicht nehmen sollte. Die findest Du im einschlägigen Standard (IEC 61508).

Es gibt ein Haufen Kriterien, die man üblicherweise auf Software anwendet. Das fängt an beim Spezifikation aufstellen bis zum Testplan und welche Programmiersprachen dafür geeignet sind. Die Kriterien, die man sich dabei üblicherweise ansieht, sind Typensicherheit, Möglichkeit das System in einen "undefinierten" Zustand zu bringen usw. aber eben auch, wie vertraut der Programmierer damit ist und ob zertifizierte, verlässliche Tools vorhanden sind (Compiler zB. korrekten Code erzeugen, usw.). Außerdem hat man ganz anständige Erfahrungswerte darüber, wie viele kritische Fehler sich hinterher noch im Code finden und was dazu geführt hat, das sie da sind.

http://aitc.aitcnet.org/isai/HISTORICAL-LINKS/Derek Reinhardt MSc SCSE Thesis (Release Version).pdf gibt eine ganz ordentlichen Literaturübersicht, auf der MISRA-Seite findet man mE. auch einen Haufen und sonst musst Du dir halt den Standard beschaffen.

ich sagte mir ist misra c zu wenig und du bringst mir nen "Use of the C++ Programming Language in Safety Critical Systems" text aber trotzdem danke. wieder ein paar mehr beispiele wie man es _nicht_ machen sollte

*john 0

_-- schrieb:

da ich mich zur zeit mit programmiersprachen beschäftige, würde mich interessieren ob es listen gibt was eine "sichere" programmiersprache so anbieten muß bzw. was die dann so sicher macht. oder sind das nicht vermittelbare erfahrungswerte

Eine sichere Programmiersprache sollte es möglichst einfach ermöglichen Programme auf ihre Korrektheit im Sinne "entspricht der Spezifikation" überprüfbar zu machen. Und das sind Programme in verschiedene Programmiersprache durchaus unterschiedlich gut überprüfbar.

Daniel E.

__-- schrieb:

ich sagte mir ist misra c zu wenig und du bringst mir nen "Use of the C++ Programming Language in Safety Critical Systems" text aber trotzdem danke. wieder ein paar mehr beispiele wie man es _nicht_ machen sollte

Die Begriffsdefinitionen und Literaturübersicht kommt *nach* der Überschrift. HTH.

Daniel E. schrieb:

__-- schrieb:

ich sagte mir ist misra c zu wenig und du bringst mir nen "Use of the C++ Programming Language in Safety Critical Systems" text aber trotzdem danke. wieder ein paar mehr beispiele wie man es _nicht_ machen sollte

Die Begriffsdefinitionen und Literaturübersicht kommt *nach* der Überschrift. HTH.

ja, schon klar. es ist auch mit das beste was mir derzeit zur verfügung steht.

knivil

Was willst du eigentlich wirklich wissen?

knivil schrieb:

Was willst du eigentlich wirklich wissen?

am besten alles also auch die lösung für ewiges leben :p

ich suchte einen text in dem steht: eine programmiersprache für sichere anwendungen muß folgende... anforderungen erfüllen. alles was ich bisher gefunden hab bezog sich idr. auf eine spezielle programmiersprache und was in dieser schlecht/unsicher ist. natürlich kann man daraus rückschlüsse ziehen was nicht so gut ist aber es ist dann doch noch nicht das was ich gesucht hab (einen text ohne bezug auf eine konkrete programmiersprache).

Wir wissen alle, dass unser C-Frickler den Thread nur erstellt hat, weil er allen zeigen will mit was er sich gerade beschäftigt und weil er denkt das das ganz ganz komplex ist und dann alle mega respekt vor ihm haben. So sind sie halt, die Cler

knivil

__-- schrieb:

eine programmiersprache für sichere anwendungen muß folgende... anforderungen erfüllen.

So ein Bullshit ... Suche mir doch mal eine Spezifikation fuer einen sicheren Hammer, eine Kettensaege, einen Schraubenzieher, ... ein Werkzeug, mit dem man sich z.B. nicht verletzten kann oder idiotensicher zu benutzen ist. Programmiersprachen sind auch nur Werkzeuge.

Und es ist auch voellig egal, ob mein Werkzeug sicher ist. Normalerweise ist man nur daran interessiert, ob ein damit erstelltes Programm "sicher" ist. Dafuer gibt es verschiedene Ansaetze, um nachzupruefen, ob es gewisse Eigenschaften und Qualitaetsmerkmale besitzt. Dabei kann die entsprechende Programmiersprache helfen, muss sie aber nicht.

hahahaaa schrieb:

Wir wissen alle, dass unser C-Frickler den Thread nur erstellt hat, weil er allen zeigen will mit was er sich gerade beschäftigt und weil er denkt das das ganz ganz komplex ist und dann alle mega respekt vor ihm haben. So sind sie halt, die Cler

ach du meinst mein angekratztes ego aufpolieren? eigentlich steh ich nicht auf solche schwanzvergleiche (gewinn ich eh immer :p) und es ist mir auch egal was ihr über mich oder meine codemonkey kenntnisse denkt.

Logikfehler->Laufzeitfehler->Übersetzungsfehler. Links stehen die am schwierigsten zu bewältigenden, daher müssen Fehlerquellen möglichst nach Rechts verschoben werden.

"Explizit statt Implizit" ist eines der Grundsätze dies zu erreichen. Man gibt dem Compiler mehr Informationen, dadurch kann er Fehler besser erkennen. Beispielsweise kann das Schreiben auf einem nur-lese-Parameter einen Fehler produzieren, wenn es denn die Möglichkeit gibt, Parametermodi anzugeben. Auch Arraygrenzen und Wertebereiche von Variablen können überprüft werden (manchmal statisch, häufig zur Laufzeit). Eine strenge Typisierung erlaubt das logische Trennen von einzelnen Objekten, so dass der Compiler "unlogische" Operationen finden kann.

So wird auch eine deutlichere Schnittstelle einzelner Module möglich. Eine Weiterführung dahingehend wäre auch echtes Design-by-Contract.

Aber auch eine Wasserdichte Spezifikation der Sprache gehört dazu. Ein Programmierer muss sich darauf verlassen können. Wenn er nur gegen einzelne Implementierungen testet, kann es schnell aus sein mit der Korrektheit. Besonders bei Interpretierten Sprachen ist das ein Problem, da hier die Implementierung auch mal ausgetauscht werden könnte.

Lies vielleicht auch mal:
http://en.wikisource.org/wiki/Steelman_language_requirements
Das ist zwar schon eine gute Zeit her, aber es gibt leider selten derartige Anforderungskataloge.

@Sicherdom

wieso find ich sowas nicht? scheinbar such ich mit den falschen keywords

*john 0

Sicherdom schrieb:

Lies vielleicht auch mal:
http://en.wikisource.org/wiki/Steelman_language_requirements
Das ist zwar schon eine gute Zeit her, aber es gibt leider selten derartige Anforderungskataloge.

Das Resultat dieses Lastenheftes kann auch benannt werden: Ada.

~john schrieb:

Sicherdom schrieb:

Lies vielleicht auch mal:
http://en.wikisource.org/wiki/Steelman_language_requirements
Das ist zwar schon eine gute Zeit her, aber es gibt leider selten derartige Anforderungskataloge.

Das Resultat dieses Lastenheftes kann auch benannt werden: Ada.

mich erinnerte es eher an c