Lieber Leser, vielen Dank für ihre Geduld. Tut uns leid, dass während der Mittagspause gerade kein Redakteur zur Hand war, um ihren Kommentar sofort freizuschalten. Mit freundlichen Grüßen, die Redaktion

Danke für den guten Artikel. Die letzte Anmerkung Sorry, aber das ist eine rein theoretische Auseinandersetzung, ... kann ich überhaupt nicht nachvollziehen. Der Artikel zeigt sehr klar an, dass alles weg, neu schreiben letztendlich wieder zu Legacy code führt. Es wiederholt sich immer wieder - ich kann es besser - und dann doch nicht. Das konsequente Refactoring erhält die guten Bestandteile. Letztlich ist daa Neuschreiben aber auf der Basis der Kenntnis der alten Codes auch ein Refactoring. Hinweis: Dabei darf nicht krampfhaft an allen früher wichtigen Features festgehalten werden, diese müssen bewertet werden aus neuer Sicht der Requirements, aber mit Überblick. Die Manager, die diese Arbeit aus Kurzzeitsicht nicht bezahlen wollen, sollten sich mit diesen Thematiken einmal wirklich auseinandersetzen, wozu auch dieser Artikel dient.

Todesstoß für Apollo 11! Ihr Redakteur (oder derjenige, der das Material fabriziert hat) hat selbst einen unverzeihlichen Fauxpas, quasi ein Eigentor mit dem Schema der Mondmission auf Seite 5 (Rubrik Sonntag) produziert! Das 1. Keplersche Gesetz besagt nämlich, dass sich die Planeten/Satteliten auf Ellipsen bewegen, in deren einem Brennpunkt die Sonne steht (bezüglich des Mondes die Erde steht) (siehe gängige Kompendien zur Physik oder zur Astrophysik). Im besagten Schema/Bild auf Seite 5 wird offensichtlich aber eine Acht gezeigt. Dazu wäre übrigens ca. das 1,4-Fache der Treibstoffmenge (bei einem Einmündungswinkel von 45° →√2≈1,4) zum Abbremsen erforderlich gewesen, um in die Mondumlauf zu gelangen. Insgesamt wäre für dieses Manöver eine Treibstofftonnage bei einer Gesamtmasse des Kommandomoduls/ Servicemoduls mit der angekoppelten Mondlandefähre von insgesamt 45,3 t 17 t Treibstoff erforderlich (MMEM = Mo1,41[1-1:evb/ve] =45,3 t1,41*[1-1:2,720,8:2,6]=63,870,267≈17 t). Damit hätte Apollo 11 aber sein Pulver fast verschossen gehabt, da ja nur ca. 19 t Raketentreibstoff im CSM gebunkert waren (die ursprüngliche Quelle nannte sogar nur 4 t). Der Hammer aber ist: Mit der gezeigten Raumschiff-Mondlandefähre-Konfiguration konnte Apollo 11 gar nicht in die Mondumlaufbahn einmünden, da sich ja die Düse links am Servicemodul montiert befindet und somit das Raumschiff mit der Mondlandefähre nicht abbremst, sondern beschleunigt, wenn das Triebwerk eingeschaltet wird. Retour zur Erde wären noch einmal 11 t Treibstoff notwendig gewesen (M= 30 t1,41*[1-1:2,720,8:2,6]=42,3 t*0,267≈11 t). Damit würde bereits eine Negativbilanz beim Treibstoff von mindestens -9 t (19 t- 28 t) zu verzeichnen gewesen sein! Letztendlich wäre Apollo 11 bei einer Eintrittsgeschwindigkeit von 11, 2 km/s bei ca. 45.000 K in der Atmosphäre verglüht! Siegfried Marquardt, Königs Wusterhausen

Die beste Modellierungssprache, mit dem smartesten Tool und der ausgefeiltesten Methode helfen nicht wenn schlechtest Systems Engineering betrieben wird. Leider wird in vielen Projekten der Erhebung, Bewertung, Validierung, Abstimmung, etc. von Anforderungen zu wenig Raum eingeräumt. Anforderungen kann man schließlich nicht anfassen, ausliefern und fakturieren. Es soll jedoch vorkommen, dass gute Anforderungen helfen das Richtige zu implementieren und Kunden zufriedenzustellen. So verhält es sich auch mit modellbasiertem Systems Engineering. Schlechtes SE wird nicht besserm wenn man es mit Modellen tut. Wenn wichtige Stakeholder das Modell oder Sichten daurauf nicht mehr verstehen, dann hat man das Ziel die Kommunikation zu verbessern und zweifelsfreier zu gestalten definitv verfehlt. Das ist dann ein guter Moment den Elfenbeinturm herab oder auch hinauf zu kommen. Gute System Engieers treffen sich jedoch regelmäßig in der Mitte.

Danke für den Hinweis. Hier scheint uns unser CMS bei der Ausspielung des Artikels einen Streich zu spielen. Wir werden versuchen das zu beheben. Beste Grüße, Die Redaktion

Danke für die Hinweise. Wir nehmen uns die Kritik zu Herzen und werden in Zukunft stärker auf inhaltlichen Tiefgang achten. Mit freundlichen Grüßen, die Redaktion.

Wer darüber einer Praxisimplementierung sucht, der sollte sich mal die Firma IB-Embedded.de anschauen. Diese bieten genau zu diesem Zweck eine HW- & SW-Plattform, damit man diese Modelle schnell umsetzen kann. Gerade die flexibel einsetzbaren Funktechniken helfen da besonders, die ersten Prototypen zu bauen. Bei Bedarf individualisieren sie auch die komplette Schaltung, so wie bei uns geschehen.

Ich bin mir nicht sicher, ob es nicht auch bei Integer einen Fortpflanzungsfehler der kummulativen Summe gibt, weil der addierte Neuwert immer etwas weniger abgerundet ist als der dazu passende vorher addierte Altwert (in einem oszillierenden Signal). Das Problem liegt dann vor der Bildung des Integer-Inputs in der Messwertaufnahme. Für Gleitkomma gibt es jedenfalls eine einfache schnelle sichere Lösung: Immer wenn im Umlauf-Buffer am Anfang wieder begonnen wird, wird zusätzlich eine Neusumme gebildet, die dann bei Erreichen der notwendigen Anzahl Werte jeweils die kummulative Summe ersetzt. Damit ist die kummulative Summe eben nicht über Stunden, Tage, Wochen kummulativ mit Fehlerfortpflanzung, sondern nach wenigen Abtastschritten (1000 .. 10000 sind wenig) immer wieder frisch. Wenn man einen gleitenden Mittelwert auf eine oszillierende Schwingung anwendet, dessen Frequenz sich jeweils leicht ändert, dann ist bei Gleitkomma eine exakte Berechnung möglich auch wenn die Periodendauer nicht genau ganzzahlig einer Anzahl Werte entspricht. Das könnte aber bei Festkomma auch gehen. Für Rückfragen könnte ich auch zur Vefügung stehen. Hartmut Schorrig.

Der Programmierer ist doch nur ein winziges Glied einer komplexeren Kette, wozu Senoren (Eingebende Bauelemente wie Taster, Temperaturfühler, Optokoppler etc.) gehören, und eben Aktoren (Umsetzende Bauelemente wie Motoren, Monitore, Leuchtmittel etc). Er „schneidet“ den Arbeits-Ablauf nur so zu, dass ein physikalisches Gerät einlaufende „Pakete“ in ein vewünschtes auslaufende „Paket“ transformiert. Eine Veränderung von Parametern im durchlaufenden fixen Prozess geschieht durch einen Bediener, nicht durch den Programmierer. Der Programmierer ist lediglich ein nutzloser Texter, der einen Layouter, einen Designer, einen Buchdrucker, einen Übersetzer, einen Verleger und mindestens einen Leser benötigt, um nicht ohne Nutzen zu bleiben. Det Mechatroniker ist sozusagen der Regisseur, der anweist und sich anweisen lässt von „seinen“ Mechanikern, Beleuchtern, Elektrikern, Schauspielern, Akustikern, Pizza-Lieferanten, Hoteliers und Köchen und Fahrern, ohne die ein Regisseur kein Werkstück zusammen stellen kann.

Frage an das Auditorium: Ich kann mich erinnern, in der Vergangenheit das Problem gehabt zu haben, dass bestimmte Daten bestimmten Speicherbereichen eines embedded Prozessors zugeordnet werden sollen. Chipinterner /externer memory, auch insbesondere const in den Flash-Memory. Das ist zu erledigen mit Segmentzuweisungen beim Compilieren und einem Linker Description File, toolabhängig verschieden für die diversen Prozessoren. Nun ist in C ein const MyType data = { .... }; const int nr = 234; direkt in den Flash compilierbar, da die Initializer alle zur Compilezeit berechenbar sein müssen, bei C. In C++ ist die Arbeit mit const erweitert, man kann schreiben: const int nr = callAnyRoutine(); Diese Routine wird zur Runtime vor main() durchgearbeitet. Das bedeutet aber das das Datenelement nr und adäquat const Instanzen nicht direkt in den const-Speicherbereich (also flash) hineincompiliert werden können. Sie sind damit per se nicht schreibgeschützt. Falls dies wichtig ist, oder der Prozessor wenig RAM hat, aber viel FROM, sehr viele const-Daten, dann muss man für diese Teile C verwenden !? Damit ergibt sich aber eine sinnvolle Arbeitsweise: Teile in C compilieren, andere Teile in C++. Das arbeitet gut miteinander , extern C benutzen für C-like Definitionen im C++-compilier-Teil.

Die Lizenz zu vereinfachen ist keine Option die Kontroverse um GPLv3 zeigt. Egal was am Lizenz Text geändert wird führt zu einer Kontroverse. Niemand zwingt Ûnternehmen dazu ausgerechnet Linux zu verwenden. Es gibt auch andere OpenSource Betriebsystem/Kernel. Es gibt auch kommerzielle Betriebsysteme, wo man letztlich mittels der Lizenzgebühren gerade solchen Ärger vermeidet (und sich dafür anderen Einhandelt). Auch mit Microsoft kann man sich als Firma unglaublich Ärger einhandeln, wenn man sich nicht an die kostenpflichtigen Lizenzen und deren Bedingungen hällt. Linus Torvald als einzigen Urheber von Linux zu sehen ist einer Frechheit.

Teile und herrsche! (Das wussten schon die Römer) Der schnellste weg zum Erfolg ist es, sich überschaubare Zwischenziele (Milestones) zu setzen, die innerhalb definierter Zeit (Sprints) erreiht werden müssen. Auch nicht wirklich neu. Reduziert man den ganzen theoretischen Management-Overhead auf vernünftige Aufgabenteilung im Team, dann ist man (jetzt!) wieder da, wo (erfolgreiche!) Embedded-Entwicklungsteams schon immer waren. Aber schön beschrieben und zusammengefasst ist das hier schon. Chapeau!

Mit den freien Tools Doxygen und Dot bekommt man auch schon einen sehr guten Überblick über eigenen oder fremden Code und Zusammenhänge.

Ein weiterer Hinweis, zu Literaturhinweise [1], dynamische Speicherallokation. C++ hat einen sehr breiten Einsatz, für PC-Desktop-Programme. Dort ist die Speicherallokierung meist kein Problem, genügend Speicher da und die Applikation läuft nur eine begrenzte Zeit. Fragmentierung und knapper Speicher kommt nicht vor. Ich unterstelle, die C++-PC-Programmier-Community macht sich darüber wenig Gedanken (oder fast keine). Bei langlaufenden Applikationen (kein Neustart, jahrelang) mit nicht zu großem Speicher gibt es das Problem der Fragmentierung, wenn verschiedengroße Blöcke zu verschiedenen Zeiten allokiert und freigegeben werden. Das problem ist theoretisch und bei kurzer Laufzeit oft gar nicht zu merken. Schlussfolgernd: Dynamische Allokierung zur laufzeit war für solche Systeme, mit SIL-level, immer schon VERBOTEN. Aber die PC-getriebenen C++-Standards ignorieren dieses Problem, weil es dort nicht zutrifft. Daher ist Vorsicht geboten. Hilfreich ist, Allokierung nur wenn nötig (auch für Eventhandling), aber dann in immer gleich großen Speicherblöcken, diese vermeiden Fragmentierung. Diese sind per Default nicht allzu groß. Das reicht aber für Events und ggf. throw. throw nur mit Vorsicht verwenden, nicht alle Möglichkeiten ausschöpfen. Einfache Fehlerobjekte reichen in der Praxis. JcHartmut

Der introvertierte SW Entwickler, der im abgetrennten Büro allein ein Projekt stemmt, gehört wohl endgültig der Vergangenheit an. Selbst eher kleinere Projekte haben heute einen Funktions- und damit Code-Umfang, der ein koordiniertes Arbeiten mehrerer Entwickler unabdingbar voraussetzt. Dies ist in jedem Fall auch unter dem Aspekt des Gelingens des Projekts zu sehen, denn was passiert, wenn der (Allein)Entwickler unerwartet ausfällt? Somit gibt es zur Zusammenarbeit bei der SW Entwicklung gar keine Alternative mehr. Richtig ist, dass bei der eigentlichen SW Entwcklung die genannten Störfaktoren ausgeschaltet werden müssen, denn die wirken sich in jedem Fall für jeden Einzelnen negativ aus. Somit braucht es eigentlich dreierlei: eine ungestörte Umgebung für die Code-Generierung und deren Test, sowie eine Infrastruktur (Besprechungsräume, Tools zur gemeinsamen Projektbearbeitung, wie z.B. TFS), sowie die Etablierung einer entsprechenden Firmenkultur, die für beide vorgenannten Aspekte - ungestörte Arbeitsmöglichkeiten einerseits und genügend Austausch anderreseits - förderlich ist. Zum letzteren gehörten m.E. Flexible Arbeitszeiten mit Ausgleichsmöglichkeiten in der Entscheidung des Einzelnen Getrennte Räume, in die sich SW Entwickler zurückziehen können genügend Besprechungsräume mit Beamer / Whiteboard getrennter Bereich zum unkonventuionellen Austausch (Cafeteria) Angebot von Kaffee, Wasser,Obst (idealerweise gratis bereitgestellt) Absolut kontraproduktv dagegen sind Großraumbüros, bei denen es nur eine Kaffee-Ecke gibt. Mit beiden Modellen habe ich als SW Entwickler Erfahrung gemacht. Das Groraumbüro habe ich äußerst negativ in Erinnerung. Zum Glück bin ich heute bei dem ersten Modell und weiß das zu schätzen. Ja, auch das ist eine Möglichkkeit, Mitarbeiter dauerhaft zu binden!

Meine Bedenken gehen eher in die Richtung. Qualität , Brauchbarkeit. Ich habe leider schon zu viele übernahmen durch Microsoft gesehen bei denen die Brauchbarkeit rapide abgenommen hat und Produkte bis zur Unkenntlichkeit durch MS-Ideen verstümmelt wurden. Für mich keine gute Nachricht.

Hallo, als Autoren müssen nur Dr. Roman Nagy und Hermann Ilmberger zitiert werden. Der genannte Redakteur, Sebastian Gerstl, hat mit der Autorenschaft des Beitrags nichts zu tun. Beste Grüße, Sebastian Gerstl, Redaktion embedded-software.engineer

Das ist nicht die Frage. Die Frage ist, ob der entsprechende Vorgesetzte gewillt ist, daß sich der Mitarbeiter in eine neue Sprache einarbeiten soll und daran scheitert es in der Regel. Man sucht dann lieber auf dem Arbeitsmarkt nach jemandem, der so etwas kann ...

Ich finde den Beitrag sinnvoll und richtig, möchte aus eigener Erfahrung noch hinzufügen dass ein gutes Programm beim Lastenheft anfängt. In der Praxis zeigt sich leider immer wieder, dass der Erstellung des Lastenheftes zu wenig Aufmerksamkeit geschenkt wird. Olaf Viehmann

First of all thank you for your response. For the context. I want to (Security-) test and fuzz embedded systems, there i need to extract the important programs. I want to write a tool that automatically analizes the filesystem of an firmware image and automatically tries to bring it up and running (qemu...) Then finds the important binaries in filesystem for other tests. So i want to anaylse the init process, the autostart config files, the cron job files etc, for the automatically started programs. I am very new to linux and try to use your expert knowledge to find the ways embedded linux systems start their software. So my question is: Have I forgotten an important start way? How are the important programs in such a system normally started? What would be the expected and normal way in such systems to start their main applications after boot? Thank you very much. Helmut