Hallo Zusammen, Ich hab mich leider bisher noch nicht mit dem Thema Programmierung "Funktionale Sicherheit" auseinandersetzen können, umso besser, dass es jetzt dann der Fall ist... Meine Vorgehensweise war bisher bei verschieden anderen Programmier-Projekten eigentlich "immer": im WWW nach passenden Programmier-Beispielen suchen (& diese evtl. adaptieren aufs eigene Projekt), Videos schauen,... und so das Wissen aneignen. Leider fehlen mir aber genau diese Informationen im Bezug "Funktionale Sicherheit". Es gibt z. B. keine (für mich passenden) YT-Videos, die genau solche Beispiele einfach mal nachprogrammieren... Genau so z. B. auf Udemy. Lediglich die Konzepte werden hier vermittelt, aber nicht die Programmierung am realen uC. Meine Fragen sind hier: 1. Warum ist das so? --> zu schwer? --> zu speziell? --> NDAs bei FuSi Packages, (z. B. STM) und somit keine Chance einer Veröffentlichung der Videos? 2. Wie habt ihr eure ersten Projekte mit FuSi programmiert? Learning by doing + regelmäßige Absprache mit der Zertifizierungsstelle? Workshops? Das muss doch auch einfacher gehen... Grüße
Mein erstes "fusi" Projekt. Flugsteuerung. 3 Teams, 3 verschiedene Hardwaren, 3 verschiede Compiler. Das System fällt immer eine 2 von 3 Entscheidung. Dazwischen tausende Reviews mit den fusi Managern.
FuSi ist doch eher ein formaler Prozess und weniger ne Programmieraufgabe - für die Programmierung heißt's doch eher Reviews gegen formale Kriterien, hohe Testabdeckung und ein geeignetes Vorgehensmodell. Für die Entwicklung halt Tests schreiben auf Coverage, statische Codeanalyse, klar definierte Toolchains und je nach Safety-Integrity-Level entsprechende Maßnahmen.
Bevor man irgendwelche Reviews macht, sollte man doch die Methoden um diese Sicherheit zu erreichen kennnen.
Alexander M. schrieb: > Lediglich die Konzepte werden hier vermittelt, aber nicht die > Programmierung am realen uC. Eben, Sicherheit ist ein Konzept, das gesamte System muss darauf ausgelegt sein. Man kann keine Sicherheit (nachträglich) 'reinprogrammieren' oder Unsicherheit Komplett 'raustesten'. Wenn man eben das Gefährdungspotential durch Softwarebugs im mikrocontroller vermeiden will, dann meidet man eben Mikrocontroller und ersetzt die durch weniger komplexe Lösungen. (Handvoll Transistoren).
Lerninstructor schrieb: > Alexander M. schrieb: >> Lediglich die Konzepte werden hier vermittelt, aber nicht die >> Programmierung am realen uC. > > Eben, Sicherheit ist ein Konzept, das gesamte System muss darauf > ausgelegt sein. Man kann keine Sicherheit (nachträglich) > 'reinprogrammieren' oder Unsicherheit/bugs Komplett abschliessend 'raustesten'. > > Wenn man eben das Gefährdungspotential durch Softwarebugs im > mikrocontroller vermeiden will, dann meidet man eben Mikrocontroller und > ersetzt die durch weniger komplexe Lösungen. (Handvoll Transistoren).
Shit, es sollte heissen: Man kann keine Sicherheit (nachträglich) 'hinein programmieren' oder Unsicherheit/bugs komplett abschliessend 'raus testen'.
Die zu vermeidenden Zustaende sollten moeglichst frueh bekannt sein. Und die Mechanismen dazuu ebenso.
Als erstes solltest Du recherchieren, ob es für Deine Anwendungen Normen gibt die zum Beispiel Softwaresicherheitsstufen definieren. Je nach SIL Stufe legen solche Normen Arbeitsweisen fest. Wer darf welche Aufgabe erledigen, dürfen unterschiedliche Aufgaben von den selben Leuten erledigt werden. z.B. https://de.wikipedia.org/wiki/Sicherheitsanforderungsstufe für die Bahn gibt es eigene Normen 50128, 50129 In solchen Normen wird definiert was Du wie programmieren darfst, und es werden Empfehlungen hinsichtlich der Programmiersprache gegeben. Wählst Du C darfst du nur ein Subset der Sprache benutzen. z.B. Dynamische Speicherverwaltung ist verboten. Das ignorieren von Rückgabewerten ist verboten. Je nach SIL-Stufe ist die Verwendung mehrerer Task verboten. Es gibt also auch Aspekte die Du bei der Programmierung berücksichtigen musst.
Ansonsten sollte man sich einen Stil der defensiven Programmierung aneignen.
Und ja, eine frühzeitige Einbindung des Gutachters spart später einen Haufen Arbeit.
Lerninstructor schrieb: > Shit, es sollte heissen: > > Man kann keine Sicherheit (nachträglich) 'hinein programmieren' oder > Unsicherheit/bugs komplett abschliessend 'raus testen'. Genau. Der größte Alptraum für Funktionale Sicherheit bei SW ist: "Wir haben ja ein Funktionsmuster das Funktioniert, jetzt muß man nur noch die Sicherheit dazuprogrammieren. Das kann doch nicht so schwer sein.". Doch das ist schwer bzw. nicht möglich. Wie die Vorschreiber schrieben, braucht es von Anfang an ein tragfähiges Konzept mit überprüfbaren Anforderungen, welches dann vorzugsweise durch alle Schritte im V-Modell durchgezogen wird. Und SW alleine kann niemals FunktionalSafety sicherstellen. Es braucht auch immer passende Hardware dazu. Nicht ohne Grund gibts dafür Gesetze/Normen/Richtlinien. Mein Gefühl sagt, daß ein Youtube-Video dafür nicht ausreicht um KnowHow aufzubauen. Gruß
Fusi hat 2 separate SW-Aufgaben: A) die Funktionalität. Irgendwas überwachen, abschalten, ... . Die Funktion und Realisierung muss einfach und bekannt sein. Nicht fancy und kopiert. B) die Diagnose des Prozessors und seiner Peripherie. Das kann recht aufwendig werden, ist individuell auf deine HW und deinen Prozess anzupassen. Das erste ist quasi zu einfach für fertige Beispiele, das zweite zu individuell.
> Mein erstes "fusi" Projekt. Flugsteuerung. 3 Teams, 3 verschiedene > Hardwaren, 3 verschiede Compiler. Das System fällt immer eine 2 von 3 > Entscheidung. Dazwischen tausende Reviews mit den fusi Managern. I call BS. Wird schon seit Jahrzehnten nicht mehr so gemacht.
Ach komm Leute, der will euch nur verarschen. Niemand der derart naive Fragen stellt und sein Wissen aus dem Internet zusammenklauen muss ist auch nur im Ansatz dazu geeignet an einem SIL Projekt mitzuarbeiten. Olaf
Ernst gemeinte Frage: Wie gross ist dein Budget, Team, Zeit- und Nerven-Vorrat? Wenn man von der Hardware aus aufbauend auch Firmware für funktionale Sicherheit bauen möchte, sind diverse TÜV Termine und sehr sehr viel Papierkram (z.B. FEMA, Safety requirement specification, Testing, zertifizierte Hardware / Compiler, ...) nötig. Und eine Einzelperson für das alles zu entwickeln ist schon die falsche herangehensweise. Grundsätzlich ist die Norm 13849 hier auch sehr hilfreich / massgebend. Wir haben jeweils die Hardware und Software der SPS-Hersteller genutzt und eine Sicherheitssteuerung damit programmiert. Aber auch hier war es einen enormen Aufwand!
Alexander M. schrieb: > Meine Vorgehensweise war bisher bei verschieden anderen > Programmier-Projekten eigentlich "immer": im WWW nach passenden > Programmier-Beispielen suchen (& diese evtl. adaptieren aufs eigene > Projekt), Videos schauen,... und so das Wissen aneignen. Heißt für mich: Du kannst eigentlich gar nicht selbst entwickeln. Darum nun deine Probleme.
Moin, mit dem Thema habe ich mich aus. Gruenden betr. Haftung auseinandergesetzt und zunaechst mal die aufwendigen Standards aussen vor gelassen, sonst braucht man mit out-of-the-box-Denken gar nicht anfangen. Mein Fazit: - Kritische Logik in (auch formal) verifizierbarer Hardware implementieren - MISRA bringt wenig, da auch einem 'zertifizierten' C-Compiler einiges durch die Lappen geht. Klassiker: Uninitialisierte Hardware-Register. - Anstatt in C in Ada oder Rust entwickeln (geht auch auf einem uC gut). Wenns dann um Ausfall-Sicherheit und Fehlertoleranz geht, muss man weiter drillen und das ganze System in die Simulation stecken koennen, um alle moeglichen Fehlerszenarien durchzusspulen und mindestens formal zu beweisen, dass das System nicht bei Glitches oder nicht vorgesehenem Input irgend etwas unvorgesehenes tut. Das ist allerdings recht aufwendig. Andererseits ist bei vielem Standardkram wie auch SIL furchtbar viel Farce involviert. Habe da schon einige SIL-3 zertifizerte Systeme auf dem Tisch stehen sehen, fuer die ich niemals (trotz TueV-Signet) die Hand ins Feuer legen wuerde, bei der CPU-Architektur schon angefangen. So als Anekdote: In einer Firmware, die fuer die Sicherheit eines Geldkoffers zustaendig war, ist bei der Analyse u.a. (wie Klartext-codierte Keys) eine UART-Abfrage mit Endlos-While aufgetaucht. Deren Effekt: Ziehen der UART-Leitung auf Low fuer eine laengere Zeit (Anbohren der Platine...) haette den Watchdog ausgeloest und die Geschichte in den Reset gezwungen. Nach anfaenglichem Zertifikations-Geprolle wurde es von seiten der Entwickler dann ganz schnell still. Ist zwar mehr Security als Safety, aber die Vorgehensweise dieselbe. Man muss schlussendlich die meist-moeglichen Zustaende des Systems abklappern.
Was nützt die beste SW-Sicherheit, wenn die Hardware spinnt. Sie nützt gar nichts. Man muß sich auch Gedanken über die HW-Fehlermöglichkeiten machen, die genau aufschreiben und dann der Reihe nach implementieren und vor allem auch testen. Zum Test kann es notwendig sein, z.B. Drähte zu durchtrennen oder kurzzuschließen. Der Test muß also real erfolgen. Ein Testprogramm reicht nicht. Ich unterteile die Programme immer in 2 Tasks. Die Control-Task macht die ganze Steuerung und die Error-Task übernimmt die ganze Fehlererkennung und zwingt bei Bedarf die Control-Task in einen sicheren Zustand zu gehen. Diese Zweiteilung sorgt dafür, daß man sich nicht verzettelt und Fehler einbaut. Allgemein muß die Errortask davon ausgehen, daß sämtliche Eingangssignale korrumpiert sind. Sie muß also überprüfen, ob Grenzwerte überschritten werden, sie nicht zu stark schwanken, sie plausibel sind und auf Änderungen der Steuergrößen reagieren. Wenn z.B. ein Interlock schon ready meldet, obwohl die Kühlwasserpumpe noch stromlos ist, dann darf natürlich die Last nicht zugeschaltet werden. Redundanz ist ein schönes Mittel, um Meßwerte glaubwürdiger zu machen. Redundante Sensoren bedeuten ja, daß der Hardwaredesigner den Meßwerten eine besonders hohe Bedeutung beimißt. Daher muß die Software diese auch besonders genau prüfen. Solche Schlamperei wie bei der 737 MAX, daß einer der Sensoren einfach nach dev/null gelesen wird, geht gar nicht.
Ah okay, Danke! Ja so ungefähr dachte ich mir das auch... Nach bestem Wissen und Gewissen bzw. Normen programmieren, und gleichzeitig (wenn nötig) externe Unterstützung dazu holen (TÜV), der dann die Sicherheitsfeatures validieren kann. Grüße
Alexander M. schrieb: > Ja so ungefähr dachte ich mir das auch... Nach bestem Wissen und > Gewissen bzw. Normen programmieren, und gleichzeitig (wenn nötig) > externe Unterstützung dazu holen (TÜV), der dann die Sicherheitsfeatures > validieren kann. Äh, völlig daneben. Wenn erst mal programmiert wird, muß alles Wichtige zum Thema schon erledigt sein. Macht aber nichts, du wirst es ja eh nie brauchen. Oliver
Alexander M. schrieb: > Nach bestem Wissen und > Gewissen bzw. Normen programmieren, und gleichzeitig (wenn nötig) O Gott was für eine Fachbanause 😱, naja das verschafft wenigstens der Grablegerbranche Konjunktur ⚰️⚰️⚰️ Besuch wenigstens einen Grundkurs über Risikobewertung und Gefärdungsminimierung . > externe Unterstützung dazu holen (TÜV), der dann die Sicherheitsfeatures > validieren kann. Der wird bei dir nicht viel validieren, der checkt deine Qualifikation und Vorgehensweise (keine Risikobewertung zu beginn durchgeführt) und bricht dann die Zulassung als 'Hoffnungsloser Fall' ab.
> Kann man Functional Safety Programmierung auch mit Arduino?
Klar! Das heisst dann A-SIL.
Olaf
Peter D. schrieb: > Ich unterteile die Programme immer in 2 Tasks. Die Control-Task macht > die ganze Steuerung und die Error-Task übernimmt die ganze > Fehlererkennung und zwingt bei Bedarf die Control-Task in einen sicheren > Zustand zu gehen. Oha, das ist mutig. In der bitterbösen Realität ist es nämlich oft garnicht so einfach, aus jedem gegebenen Zustand in einen sicheren (oder zumindest sichereren Zustand zu wechseln. Dazu kommt: Falsche Eingaben (Sensorfehler) können leicht dafür sorgen, dass die Software eine völlig falsche Vorstellung darüber hat, was eigentlich die aktuelle Situation ist... Ein schönes Beispiel dafür, was da schon bei recht einfachen physischen Anlagen an Komplexität zusammenkommt, ist eine pneumatische Hebevorrichtung. Es gibt also eine Druckluftquelle, einen Zylinder und ein einfaches Ventil als Aktoren und einen Druckmesser und zwei Endschalter als Sensoren. So und nun durchdenke mal alles, was die beiden oben geäußerten Gedanken für diese sehr primitive Anlage umreißen und versuche das mit deinem naiven Konzept umzusetzen... Viel Spaß!
Alexander M. schrieb: > Ah okay, Danke! > > Ja so ungefähr dachte ich mir das auch... Nach bestem Wissen und > Gewissen bzw. Normen programmieren, und gleichzeitig (wenn nötig) > externe Unterstützung dazu holen (TÜV), der dann die Sicherheitsfeatures > validieren kann. > Nach der Eingangsfrage und dieser ersten Antwort könnte man fast meinen, das wäre ein Trollbeitrag. Da Du ein angemeldeter Benutzer bist glaube ich das allerdings kaum. Wie die Vorredner schon sagten, Du kannst keine FuSi per Software erreichen, das ist schon im Ansatz völlig falsch gedacht. Auch dann nicht, wenn Du den TÜV dazu nimmst.
Der Da schrieb: >> > > Genau. Der größte Alptraum für Funktionale Sicherheit bei SW ist: In der Tat! Wichtig ist auch, dass von Anfang an alles dokumentiert ist, alle Bugs die aufgetreten & repariert sind, alle Anforderungen und Aufgabenpakete. Wenn man erstmal munter drauf los programmiert ohne irgendwas niederzuschreiben und dann der Prüfer nach dieser Dokumentation fragt, kann es spaßig werden.
Die TÜVs bieten mehrtägige Kurse in funktionaler Sicherheit an. Danach hat man ungefähr eine Ahnung was auf einen zukommt: organisatorische Maßnahmen, Anforderungsmanagement, Dokumentationsmanagement, HW -Anforderungen, Diagnosen (HW-Selbstests), Auswahl ein-/mehrkanalig, Umgang mit den Normen, Berechnung der FIT Werte und SIL, SW Design, Validierung und Verifikation und, und, und ...
Harald A. schrieb: > Alexander M. schrieb: >> Ah okay, Danke! >> >> Ja so ungefähr dachte ich mir das auch... Nach bestem Wissen und >> Gewissen bzw. Normen programmieren, und gleichzeitig (wenn nötig) >> externe Unterstützung dazu holen (TÜV), der dann die Sicherheitsfeatures >> validieren kann. >> > > Nach der Eingangsfrage und dieser ersten Antwort könnte man fast meinen, > das wäre ein Trollbeitrag. Da Du ein angemeldeter Benutzer bist glaube > ich das allerdings kaum. Wie die Vorredner schon sagten, Du kannst keine > FuSi per Software erreichen, das ist schon im Ansatz völlig falsch > gedacht. Auch dann nicht, wenn Du den TÜV dazu nimmst. Nein, kein Trollbeitrag ;) Da hast du Recht... Nur leider 1. noch seehr wenig Ahnung von Funktionaler Sicherheit, deshalb die kompletten Einsteigerfragen ;) 2. wenig Ideen, wie ich an das Thema eigenständig herangehen kann. FuSi nur mit Software zu erreichen war ja nie die Hauptfrage, sondern lediglich, wie eine funktional sichere SW aussehen soll. Z. B. Watchdog, zyklischer RAM-Test, etc... Aber ich werde mich da vielleicht doch erstmal mit den prinzipiellen Konzepten vertraut machen, und dann mal weiterschauen ;) Aber schon krass, wie extrem sich manche triggern lassen hier im Forum, weil einer eine doofe Frage bezüglich FuSi stellt :D... Grüße
Fruchtgurke schrieb: > Die TÜVs bieten mehrtägige Kurse in funktionaler Sicherheit an. Danach > hat man ungefähr eine Ahnung was auf einen zukommt: organisatorische > Maßnahmen, Anforderungsmanagement, Dokumentationsmanagement, HW > -Anforderungen, Diagnosen (HW-Selbstests), Auswahl ein-/mehrkanalig, > Umgang mit den Normen, Berechnung der FIT Werte und SIL, SW Design, > Validierung und Verifikation und, und, und ... Danke! Halt seehr teuer... Genau das hab ich gehofft finde ich gebündelt im WWW, aber wohl nicht so einfach und mit viel Recherche verbunden :D
:
Bearbeitet durch User
Arbeite z.B. gründlich die Norm IEC 61508 durch. Da findest du die Antworten auf deine Fragen. Ohne wegweisende Schulung wird es allerdings frustrierend.
Alexander M. schrieb: > Aber schon krass, wie extrem sich manche triggern lassen hier im Forum, > weil einer eine doofe Frage bezüglich FuSi stellt :D... Naja bei funktioneller Sicherheit geht es um Leben und Tod, klar das man panisch wird, wenn ein 'verantwortlicher fachmann' naiv wie ein Kleinkind ist. 😊 -> 💀
Alexander M. schrieb: > Danke! Halt seehr teuer... Teuer wird es in jedem Fall. Falls du als Einzelkämpfer unterwegs bist, musst du je nach SIL eh Fremdfirmen mit den Aufgabenbereichen beauftragen, da du diese nicht in Personalunion ausführen darfst: insbesondere z.B. Reviews, Verifikation, Validierung.
Fruchtgurke schrieb: > Arbeite z.B. gründlich die Norm IEC 61508 durch. Da findest du die > Antworten auf deine Fragen. Ohne wegweisende Schulung wird es allerdings > frustrierend. Und dann stehen schon ganz vorne in der Norm so ein paar schöne simple Sätze, von denen man anfangs nicht mal weiß, wie man das je umsetzen soll (je nach Firmengröße)…
:
Bearbeitet durch User
Lerninstruktor schrieb: > Naja bei funktioneller Sicherheit geht es um Leben und Tod, klar das man > panisch wird, wenn ein 'verantwortlicher fachmann' naiv wie ein > Kleinkind ist. Keine Sorge. Ohne den Nachweis mehrjähriger praktischer Tätigkeit und entsprechender Qualifikation der beteiligten Mitarbeiter im Bereich funktional safety, gibt es sowieso keine Zulassung.
Alexander M. schrieb: > sondern lediglich, wie eine funktional sichere SW aussehen soll. Du hast vermutlich immer noch ein falsches Verständnis: Fusi sorgt nicht dafür, dass die Funktion der SW sicher ist. Oder dein Prozess. Fusi sorgt dafür, dass notwendige "Sicherheitsmaßnahmen" (z.b. gegen überhitzen abschalten) funktionieren, wenn sie gebraucht werden. Und davon nur die Maßnahmen, die durch "programmierbare" Elektronik realisiert werden, nicht z.b. Temperatursicherungen. In der Regel ist es weder möglich, noch gewollt, Funktion und Sicherheitsfunktionen zu vermischen. Also z.b. beide mit gleichen Ansprüchen zu entwickeln. Klar, misra und co sind für beides gut. Trotzdem sollte man das nicht vermischen. Vielleicht solltest du Mal sagen, wass Deine Sicherheitsfunktionen sein sollen und wie Du sie realisieren willst.
> Aber schon krass, wie extrem sich manche triggern lassen hier im Forum, > weil einer eine doofe Frage bezüglich FuSi stellt :D... Das verstehst du sobald so ein Projekt durchgezogen hast und dabei ein paar Jahre aelter geworden bist. .-) Olaf
Auf etwas tieferer Ebene. Bevor man einen Watchdog zuschaltet, sollte man das Geraet laengere Zeit getestet haben. Erst wenn man genau weiss weshalb der Watchdog kommen koennte, darf man ihn einschalten. Wenn der Watchdog zubeisst ist man nicht automatisch in einem sicheren Zustand. Und man weiss nicht woher man kommt, ausser man logt systematisch. Ich lasse meine Hardware mit der Firmware erst mal Wochen lang laufen, wobei jeder Neustart protokolliert wird. Wir hatten auch schon Wochen lang nach einem Software Fehler gesucht, und bei einem Review rausgefunden, dass es EMV war.
Pandur S. schrieb: > Erst wenn man genau weiss weshalb der Watchdog kommen koennte, darf man > ihn einschalten Aber mit Watchdog findet man solche Fehler ja überhaupt erst; wenn beim Testen sonst ein Programmteil etwas zu lange braucht merkt man das gar nicht. Ein vernünftig gebautes Programm sollte nie in den Watchdog laufen (keine Endlosschleifen), das ist wenn immer ein Softwarebug oder EMV-Problem, und damit halt nicht vorhersehbar.
>> Arbeite z.B. gründlich die Norm IEC 61508 durch. > von denen man anfangs nicht mal weiß, wie man das je umsetzen soll Wahrscheinlich liegt genau hier das Problem. In jedem anderen Ingenieurstudium wird den Studenten beigebracht, wie sich die Normen in der Praxis umsetzen lassen. Wir haben eine kontinuierliche Weiterentwicklung von den Dampfkesselüberwachungsvereinen zu den heutigen Normungsinstituten. Nur nicht in der Softwareentwicklung. Da saugt sich jeder Hobbyerfinder irgendwas neues aus den Fingern. > mit dem Thema habe ich mich aus. Gruenden betr. Haftung auseinandergesetzt Und hier liegt wahrscheinlich das andere Problem. Wenn ein Staudamm zusammen bricht, ist der Prüfingenieur persönlich verantwortlich, kommt in Untersuchungshaft. Wenn Software zusammen bricht, kommt niemand ins Gefängniss. Der Kunde kann höchstens die Firma auf Schadensersatz verklagen.
Noch ein Kommentar schrieb: > In jedem anderen Ingenieurstudium Informatik und Softwareentwicklung ist aber keine Ingenieurswissenschaft. Noch ein Kommentar schrieb: > Da saugt sich jeder Hobbyerfinder irgendwas neues aus den Fingern. Das können studierte Ingenieure, die professionell Software entwickeln, aber auch sehr gut. Noch ein Kommentar schrieb: > Wenn Software zusammen bricht, kommt niemand ins Gefängniss. Bei Staudämmen gibt es aber auch viel mehr Erfahrung. Software ist so komplex, dass es in der Praxis eben extrem schwer ist, sie wirklich sicher zu bekommen. Das ist kaum zu vergleichen.
Noch ein Kommentar schrieb: >>> Arbeite z.B. gründlich die Norm IEC 61508 durch. > Wenn Software zusammen bricht, kommt niemand ins > Gefängniss. Der Kunde kann höchstens die Firma auf Schadensersatz > verklagen. Und die Firma reicht die Schadensersatzforderung an das schlampenhaft arbeitende Codierschwein weiter. Abgesehen davon, das die Weiterbeschäftigungsmöglichkeiten als 'Mr. Therac25-Strahlentod" oder "Mister clicki.ariane5.-> kacki" reichlich begrenzt sind. https://www.deutschlandfunk.de/der-absturz-der-ariane-100.html
> Informatik und Softwareentwicklung ist aber keine Ingenieurswissenschaft.
War ja in den 80ern durchaus sinnvoll. Als wir noch in Kilobyte und
Kiloherz rechneten war Softwareentwicklung ein Kunsthandwerk. Trotz
vollkommen unzureichender Hardware baute ein guter Softwareentwickler
mit unverstehbaren Tricks ein nützliches Programmpaket.
Aber heutzutage kann ein einzelnes Genie die Gigabytes gar nicht mehr
überblicken. Die heutige Komplexität bekommen wir nur mit den Methoden
der Ingenieure und Bürokraten in den Griff.
Warum ist Informatik immer noch kein Ingenieurstudium?
Noch ein Kommentar schrieb: > Warum ist Informatik immer noch kein Ingenieurstudium? Weil sie eine Wissenschaft ist, daher ja auch M.Sc. / B.Sc. Böse Zungen würden sagen, dass eine Umstellung auf Ingenieurs-Studium ein Abstieg wäre! Jedenfalls lernt man im Informatik-Studium sehr wohl die Organisation und Beherrschung komplexer Strukturen. Dazu gibt es ja auch Dinge wie Model Checking. Das wird in traditionellen Unternehmen, gerne auch Ingenieurs-geführten, aber wenig gelebt; auch weil die Ingenieure das in ihren Programmier-Kursen eben nicht gelernt haben. Und Ingenieure glauben Informatikern sowieso nicht - sie wollen ja sogar die Informatik zum Ingenieurs-Studium umbauen!
Fpgakuechle K. schrieb: > Noch ein Kommentar schrieb: >>>> Arbeite z.B. gründlich die Norm IEC 61508 durch. >> Wenn Software zusammen bricht, kommt niemand ins >> Gefängniss. Der Kunde kann höchstens die Firma auf Schadensersatz >> verklagen. > > Und die Firma reicht die Schadensersatzforderung an das schlampenhaft > arbeitende Codierschwein weiter. Geschäftsführer und leitende Angestellte sind dran, „Codierschweine“ haben i.d.R. nichts zu befürchten.
> dass eine Umstellung auf Ingenieurs-Studium ein Abstieg wäre!
Natürlich ist die Umstellung vom Kunsthandwerk der genialen Meister zur
schnöden Routine eines Ingenieurs, der nur Normen und Vorschriften
umsetzt ein Abstieg.
Aber auf allen anderen Gebieten wurden mit zunehmender Komplexität die
freien Meister durch an Normen und Vorschriften gekettete Ingenieure
ersetzt.
Nur die Softwareentwickler behaupten Programme währen zu komplex für die
Methoden der Ingenieure, sie müssen bei den Methoden der genialen und
freien Kunsthandwerksmeister bleiben.
Wieso klappt das? Wie schaffen das die Softwareentwickler?
Niklas G. schrieb: > Beherrschung komplexer Strukturen. Dazu gibt es ja auch Dinge wie Model > Checking. Das wird in traditionellen Unternehmen, gerne auch > Ingenieurs-geführten, aber wenig gelebt; Vielleicht wäre es dann Mal an der Zeit für Erfolge abseits von einer neuen Programmiersprache täglich.
Noch ein Kommentar schrieb: > Natürlich ist die Umstellung vom Kunsthandwerk der genialen Meister Informatik ist kein Kunsthandwerk, sondern Wissenschaft. Noch ein Kommentar schrieb: > Wieso klappt das? Wie schaffen das die Softwareentwickler? Durch brain.exe und Anwendungen von Methoden. Diese Methoden sind halt anders als die der Ingenieure. Und das ist auch nicht schlimm, man kann nicht alles auf der Welt mit ingenieursmäßigen Methoden angehen. Es ist eine ziemliche Arroganz der Ingenieure, zu behaupten, sie wären die besseren Informatiker oder sie könnten die Informatik umkrempeln... Scheint auch hier im Forum weit verbreitet zu sein: A. S. schrieb: > Vielleicht wäre es dann Mal an der Zeit für Erfolge abseits von einer > neuen Programmiersprache täglich.
Niklas G. schrieb: > Es ist eine ziemliche Arroganz der Ingenieure, zu behaupten, sie wären > die besseren Informatiker oder sie könnten die Informatik umkrempeln... > Scheint auch hier im Forum weit verbreitet zu sein: Oftmals ist es aber die "Ignoranz" der Softis, die nicht umsetzen können (wollen??), was der Ingenieur verlangt. Hatte das jahrelang und war echt froh, dies Aufgabengebiet irgendwann für immer verlassen zu können. Ist halt was ganz anderes, wenn man plötzlich beide zusammenfalten kann :-) Gruß Rainer
Rainer V. schrieb: > Oftmals ist es aber die "Ignoranz" der Softis, die nicht umsetzen können > (wollen??), was der Ingenieur verlangt. Aber ein Ingenieur könnte das unter den selben Umständen besser?
> Informatik ist kein Kunsthandwerk, sondern Wissenschaft.
Was bedeutet für dich das Wort "Wissenschaft"?
Als es das Wort noch nicht gab, umschrieb es Isaac Newton mit dem
Begriff "Mathematisch fundierte Naturphilosophie". Eine recht
verbreitete Definition: Die Wissenschaft findet mit Experiment und
Mathematik heraus, wie unsere Welt funktioniert. Das Ziel der
Wissenschaft ist eine konsistente Beschreibung, mit der sich alle
Erscheinungen in unserem Universum berechnen lassen.
Sicherlich gibt es auch in der Softwareentwicklung Wissenschaftler, die
mit Hilfe der Programme verstehen wollen, wie unsere Welt funktioniert.
Alen Turing, Stephen Wolfram .... Aber die meisten Softwareeinwickler
benutzen nur die Ergebnisse der Wissenschaft. Tragen nichts zum Ziel der
Wissenschaft bei. Genau so, wie die Ingenieure.
Wieso bist du der Meinung, die Arbeit eines Softwareentwicklers hat mehr
mit Isaac Newton als mit Gustave Eiffel zu tun.
Niklas G. schrieb: > Aber ein Ingenieur könnte das unter den selben Umständen besser? Mein Lieber...es geht nicht darum, ob der Ingenieur es besser kann....um Gottes Willen...es geht darum, dass die Software das nicht macht, was der Ingenieur möchte! Die daraus erwachsenen Diskussionen sind meist lächerlich, oftmals aber auch unterhaltsam...und enden oft auch in dem verzweifelten Versuch des Softi, dem Ingenieur zu verklickern, dass seine Anforderungen schlicht Blödsinn sind. Und damit wirds richtig lustig. Wer sagt, dass wär so nicht, hat wohl keine Ahnung... Rainer
Noch ein Kommentar schrieb: > Wieso bist du der Meinung, die Arbeit eines Softwareentwicklers hat mehr > mit Isaac Newton als mit Gustave Eiffel zu tun. Informatiker, und davon rede ich, lernen im Studium z.B. das Führen mathematischer Beweise, und müssen in ihren Abschlussarbeiten wissenschaftliche Erkenntnisse gewinnen. Das unterscheidet sie von Ingenieursabsolventen. Besuche mal eine Theoretische Informatik-Vorlesung und du wirst verstehen, was ich meine. Und diese Dinge sind sehr wohl relevant für die praktische Arbeit, z.B. für Compilerbau. Rainer V. schrieb: > und enden oft auch in dem verzweifelten Versuch des Softi, dem Ingenieur > zu verklickern, dass seine Anforderungen schlicht Blödsinn sind. Vielleicht versteht der Ingenieur auch nicht, dass der Informatiker nicht alles gelernt hat, was der Ingenieur weiß? Vielleicht wäre es nötig gewessen, etwas Domänen-Wissen weiterzugeben? Den umgekehrten Fall kenne ich übrigens auch zu Genüge, dass die HW-Entickler es nicht schaffen, ihre Platinen so zu planen, dass man sie vernünftig nutzen kann. Bei einer Reihe von unterschiedlichen Platinen war z.B. bei jeder einzelnen Platine der JTAG-Stecker auf eine bestimmte Art vermurkst, z.B. gedreht, gespiegelt oder so platziert dass das Kabel mit anderen Bauteilen kollidiert. Ich wollte doch nur jeden Controller mit dem selben Kabel an den Debugger anschließen können. Die Ings schaffen es auch oft nicht, Pinouts korrekt zu beschreiben. Als Software-Entwickler soll man halt mal eben die Anlage auseinander nehmen (wozu es natürlich wiederum an Doku mangelt) um zu schauen, was für ein Sensor da jetzt tatsächlich steckt. Die Sensorauswertung ist ja schließlich Software-Sache, oder?
:
Bearbeitet durch User
> Und diese Dinge sind sehr wohl relevant für die praktische Arbeit Jain. Seit 20 Jahre arbeite am Kern einer Layoutengine. Bin der einzige in der ganzen Firma, der die Theorien zu Compilerbau und Affine Transformationen braucht. Aber eigentlich wäre es für die Firma besser, die kauften eine der ausgereiften Engines. 9999 von 10000 Entwicklern bräuchten eigentlich zwei ganz andere Fähigkeiten. Aus den konfusen Anforderungen der Kunden ein konsistentes Konzept zusammen stellen. Und aus den unzähligen frei verfügbaren Konzepten und Komponenten das Brauchbare auswählen. Mag ja sein, ein Doktorand an der UNI muss eine wissenschaftliche Arbeit verfassen. Aber wie viele Entwickler haben sich habilitiert. Und wie viele davon machen danach einen dämlichen Job als Scrum Master? > Ich wollte doch nur jeden Controller > mit dem selben Kabel an den Debugger anschließen können. Ja! Ob ein Entwickler mathematische Beweise führen kann ist irrelevant. Ein Entwickler muss koordinieren. Ein Konzept ausarbeiten, das trotz verkorkster Hardware und utopischer Kundenanforderungen funktioniert. >> Dazwischen tausende Reviews mit den fusi Managern. Hier kommen wir der Sache schon näher. Ein einzelner genialer Entwickler kann die Aufgabe gar nicht bewältigen. Wie in anderen Bereichen braucht es Architekten, Konstrukteure, Prüfingenieure, Bürokraten und Manager.
Noch ein Kommentar schrieb: > Aus den konfusen Anforderungen der Kunden ein konsistentes Konzept > zusammen stellen Rein zufällig wird das im Informatik-Studium gelehrt, bezogen auf Software. Leider ist es schwierig Ingenieuren zu vermitteln dass das etablierte sinnvolle Methoden sind. Die müssen ja auch mitspielen, wenn sie ihre Anforderungen stellen. Leider kommt da oft nur "mach dass es funktioniert". Wenn man dann nicht mal Prozesse anwenden darf weil es die bei Ingenieuren nicht gibt wirds schwierig... Noch ein Kommentar schrieb: > Mag ja sein, ein Doktorand an der UNI muss eine wissenschaftliche Arbeit > verfassen Bachelor und Master auch. Noch ein Kommentar schrieb: > Und wie viele davon machen danach einen dämlichen Job als Scrum Master? Scrum wird auch im Informatik-Studium gemacht...
Niklas G. schrieb: > Wenn man dann nicht mal Prozesse anwenden darf weil es > die bei Ingenieuren nicht gibt wirds schwierig... > > Noch ein Kommentar schrieb: >> Mag ja sein, ein Doktorand an der UNI muss eine wisse Wirst dich halt mit deinen Prozessen begraben lassen müssen... Rainer
War/ist irgendwer von euch Diskutierenden in dem Bereich tätig? Ich verstehe die ganze Diskussion nicht... Vielleicht hab ich auch einfach Glück gehabt oder so. Bin Ingenieur, MSc der e-Technik. Wir haben natürlich Mathe 1-4 gemacht (zusammen mit den Physikern), Beweise geführt und ne Menge Theorie gelernt. Ich bin jetzt in der embedded SW Entwicklung tätig, Produktentwicklung, sehe mich mindestens zur Hälfte als Informatiker. Hier arbeiten Ingenieure und Informatiker zusammen und machen sich den selben Job. Prozessorientierte Produktentwicklung. Kein Frickeln, keine Kunst oder was auch immer da oben erzählt worden ist. Und wir machen ab und zu auch Mal Fusi. Ist halt etwas komplexer der Prozess.
Jojo schrieb: > Kein Frickeln, keine Kunst oder was auch immer da oben erzählt worden > ist. Klingt super, wo herrschen solche paradiesischen Zustände?
Jojo schrieb: > Kein Frickeln, keine > Kunst oder was auch immer da oben erzählt worden ist. Und wir machen ab > und zu auch Mal Fusi. Ist halt etwas komplexer der Prozess. Stimmt auch. Ist der Prozess erst einmal in der Firma fest etabliert, dann ist es tatsächlich einfach. Nur für Firmen, für die das Neuland ist, kann es ein sehr steiniger Weg werden. Längst überfällige Strukturen müssen mühsam nachgeholt werden.
Niklas G. schrieb: > Jojo schrieb: >> Kein Frickeln, keine Kunst oder was auch immer da oben erzählt worden >> ist. > > Klingt super, wo herrschen solche paradiesischen Zustände? Kann es sein, dass Du dem großen Verschwörungsmythos der Informatiker verfallen bist? Dass SW-Entwicklung viel, viel einfacher wäre, wenn man die großartigen Methoden der Informatik nur konsequent anwenden würde. Die nur deshalb von unfähigen Praktikern verhindert werden, damit diese sich ihre mühselige und vergebliche Arbeit erhalten. Dass Alles schon da ist: Modellierung statt Programmierung, Beweis der Korrektheit statt Fehlersuche, Formales Handwerk statt kreativer Akt. Ich habe z.B. die Entwicklung von Sprachen/Compilern ja selber angeführt als fruchtbare Kerndomäne der Informatik. Und trotzdem wird der linguistische Teil seit Chomsky irgendwie vernachlässigt. Nenn Du doch mal ein paar Beispiele, wie Du es Dir abseits von Programmiersprachen vorstellst.
A. S. schrieb: > Kann es sein, dass Du dem großen Verschwörungsmythos der Informatiker > verfallen bist? Ist es ein Mythos, wenn es Konsens unter praktisch allen Informatikern ist? A. S. schrieb: > Die nur deshalb von unfähigen Praktikern verhindert werden, damit diese > sich ihre mühselige und vergebliche Arbeit erhalten. Nein, einfach nur weil "das haben wir immer schon (nicht) so gemacht". Ist es wirklich so zweifelhaft, dass die Entwicklung durch Nutzung von Issue-Trackern, Projektplanung, Anforderungsanalyse, einem Entwicklungsmodell (Scrum, V-Modell etc) die Entwicklung vereinfacht? Ich habe beides schon gemacht und habe keine Zweifel was besser ist. A. S. schrieb: > Dass Alles schon da ist Es ist definitiv nicht alles schon da und erforscht. Deswegen gibt es ja auch neue Programmiersprachen, nur die typischen Ingenieure wollen auf alle Ewigkeit C89 verwenden. Es gibt etablierte Best Practices. Die gibt es bei Ingenieuren doch auch, nur halt andere. A. S. schrieb: > Modellierung statt Programmierung Gerade das ist doch eher der Liebling von Ingenieuren (Simulink...?). A. S. schrieb: > Beweis der Korrektheit statt Fehlersuche Jeder weiß, dass das für normale Projekte nicht realistisch ist. Fehler zu vermeiden ist aber besser als sie zu suchen. A. S. schrieb: > Nenn Du doch mal ein paar Beispiele, wie Du es Dir abseits von > Programmiersprachen vorstellst. Es ist sehr praktisch einem Kunden sagen zu können "nein, leider können wir nicht den kürzesten Weg durch alle Punkte berechnen, nicht weil wir unfähig sind, sondern weil es NP-vollständig ist". Numerische Verfahren, Filter-Berechnung, diskrete Algorithmen/Graphentheorie, allgemein Mathematik zu beherrschen ist schon sehr praktisch, z.B. auch bei 3D-Grafik oder GIS. Ich erinnere mich an eine lustige Situation, in der eine analoge Verstärkerschaltung berechnet werden sollte. Die ETechniker haben sie in Simulink gebaut, ich habs analytisch manuell berechnet. Wir waren gleich schnell, die Ergebnisse stimmten überein, aber meins war genauer und parametrisch in den Bauteilwerten. Kann Vorteile haben.
Niklas G. schrieb: > Informatiker, und davon rede ich, lernen im Studium z.B. das Führen > mathematischer Beweise, und müssen in ihren Abschlussarbeiten > wissenschaftliche Erkenntnisse gewinnen. Das unterscheidet sie von > Ingenieursabsolventen. Das müssen Ingenieure ebenso. Und wie oben schon von jemand anderes erwähnt teilweise mit Physikern zusammen, d.h. kein Schmalspurmathe. Niklas G. schrieb: > Noch ein Kommentar schrieb: >> Mag ja sein, ein Doktorand an der UNI muss eine wissenschaftliche Arbeit >> verfassen > > Bachelor und Master auch. Das wissenschaftliche Niveau von Bachelor- und Masterarbeiten von sowohl Informatik als auch Ingenieurwissenschaften ist bei beiden sehr niedrig obwohl beides Wissenschaften sind. Wirklichen Erkenntnisfortschritt gibt es erst ab Doktorarbeit. Vielleicht verwechselt da jemand Uni- und FH-Ingenieuren, deren Studium tatsächlich wesentlich praxisnaher ist. Wird für die FH-Informatiker genauso zutreffen. Niklas G. schrieb: > Es ist sehr praktisch einem Kunden sagen zu können "nein, leider können > wir nicht den kürzesten Weg durch alle Punkte berechnen, nicht weil wir > unfähig sind, sondern weil es NP-vollständig ist". Numerische Verfahren, > Filter-Berechnung, diskrete Algorithmen/Graphentheorie, allgemein > Mathematik zu beherrschen ist schon sehr praktisch, z.B. auch bei > 3D-Grafik oder GIS. Nichts was ein Etechnikingenieur nicht auch lernt, nur statt für 3D-Grafik oder GIS halt für Anwendungsgebiete wie Regelungstechnik oder Hochfrequenztechnik.
Blechbieger schrieb: > Das müssen Ingenieure ebenso. Und wie oben schon von jemand anderes > erwähnt teilweise mit Physikern zusammen, d.h. kein Schmalspurmathe. Physiker machen kein Schmalspurmathe? Der war gut! Blechbieger schrieb: > Das wissenschaftliche Niveau von Bachelor- und Masterarbeiten von sowohl > Informatik als auch Ingenieurwissenschaften ist bei beiden sehr niedrig > obwohl beides Wissenschaften sind. Kann ich nicht bestätigen. Ings können in ihrer Arbeit einfach etwas entwickeln, obwohl es das schon gibt. Wenn die Methode gut ist, haben sie bestanden. In Informatik und anderen Wissenschaften wäre das durchgefallen. Blechbieger schrieb: > Nichts was ein Etechnikingenieur nicht auch lernt ETechniker lernen Berechenbarkeit, Komplexität, Gruppentheorie, Graphentheorie, numerische Algorithmen, Statistik und Stochastik? Mir war als würden die nur ein bisschen Analysis machen. Naja, wenn es doch so ähnlich ist, irren sich wohl die Akkreditierungsinstitute welche den Ingenieuren nur M.Eng. statt M.Sc. geben...
Niklas G. schrieb: > Naja, wenn es doch so ähnlich ist, irren sich wohl die > Akkreditierungsinstitute welche den Ingenieuren nur M.Eng. statt M.Sc. > geben... Wie oben erwähnt stimmt das einfach nicht. Bin Ingenieur und MSc. Normale TU irgendwo in Deutschland. Kp warum du so auf Ingenieur Bashing steil gehst, wohl schlechte Erfahrungen gemacht. Ich kann sagen, dass requirement und issue Tracking, ci/cd, code reviews, Standardprozesse und was auch immer du oben noch angeführst hast täglicher Standard ist und wie ich das so höre ist das der Fall in den meisten Unternehmen, in denen meine Kommilitonen so arbeiten. Blechbieger schrieb: > Nichts was ein Etechnikingenieur nicht auch lernt, nur statt für > 3D-Grafik oder GIS halt für Anwendungsgebiete wie Regelungstechnik oder > Hochfrequenztechnik. Full ack. Beides hat es ordentlich in sich, und kann danach auch ganz gut (angewandte) Mathematik.
Jojo schrieb: > Wie oben erwähnt stimmt das einfach nicht. Bin Ingenieur und MSc. > Normale TU irgendwo in Deutschland. Ah, und gibt es einen Unterschied zwischen M.Sc. und M.Eng. Ingenieuren? Jojo schrieb: > Kp warum du so auf Ingenieur Bashing steil gehst, wohl schlechte > Erfahrungen gemacht. Schau dir doch nur diesen Thread an, oder viele andere in diesem Forum. Wie soll man auf dieses ständige "Ingenieure können alles besser und keiner braucht Informatiker" reagieren? Jojo schrieb: > Ich kann sagen, dass requirement und issue Tracking, > ci/cd, code reviews, Standardprozesse und was auch immer du oben noch > angeführst hast täglicher Standard ist und wie ich das so höre ist das > der Fall in den meisten Unternehmen, in denen meine Kommilitonen so > arbeiten Das ist schön. Für manche scheint das ja unnötiger Informatiker-Firlefanz zu sein. Jojo schrieb: > Full ack. Beides hat es ordentlich in sich, und kann danach auch ganz > gut (angewandte) Mathematik. Witzigerweise kann man im Informatik-Studium den Regelungstechnik-Teil AUCH noch dazu lernen, und Analysis hat man sowieso.
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.