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

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

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.

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.

Ich habe eben in der Design und Elektronik 11/2019-Printausgabe einen Beitrag über Kasperski gelesen, mit der Grundaussage zusammengefasst der russiche Weg, alles ist verboten, nur notwendiges wird erlaubt, ist richtig. Das scheint mir hier die richtige Antwort. Die IoT-Lösung gleich mit integriertem www-Anschluss vielleicht auf der Basis eines Raspi für unschlagbare unter 35 Euro ist wohl nicht die anzustrebende Plattform für Infrastruktur- und Industrieanlagen. Kostensparen in dieser Richtung rächt sich. Sondern: Grundsätzlich eine zwei-Geräte-Lösung: Die Hardware für die unmittelbare Prozesssteuerung soll so sein wie bisher, optimiert auf den Anwendungszwecke, sie braucht nicht upgedated werden. Diese Hardware hängt nicht direkt am www-Netz. Dazu gesellt sich ein möglichst standardisiertes PC-ähnliches Gerät (Industrie-PC, auch ein Raspi kostengünstig), das nicht für die Kernfunktionen notwendig ist und standardgemäß gepatched wird. Dieser PC hängt am www, um Daten zu senden und einen Servicezugang zu bieten. Die Verbindung zur Prozesssteuerung wird über ein eigenes Netzwerk geführt mit zweiter Schnittstelle, die nur von einem anlagenzugehörigen Spezialprogramm bedient wird. Über die zweite Schnittstelle laufen ausschließlich die dort programmierten Telegramme, die Integrität des Spezialprogrammes (auch dort könnte Schadcode eingeschleust werden) wird gesichert mit den üblichen Methoden von Standardbetriebssystemen. Diese Zweigeräte-Lösung kostet etwas mehr, aber die IoT-Sicherheit ist gewährleistet. Für einen Zugriff auf kritische interne Daten der Prozesssteuerung, wie es der Kollege im Vorbeitrag beschrieben hat, sollte es eine extra Kommunikationsverbindung geben, die manuell bei Bedarf gesteckt wird von einem Vor-Ort zuständigem Kollegen. Das braucht kein Spezialist für diese Software zu sein, sondern lediglich Maintenance-Personal das mit Netzwerkkabeln umgehen kann. Für den Zugriff kann ein Session-Passwort manuell festgelegt werden. Auch diese Person (erzeugt Lohnkosten) sollte nicht eingespart werden weil es billiger sein soll. Die Person ist nur temporär notwendig bei solchen Servicemaßnahmen, es kann sich also um eine Zuständigkeitsperson des Betreibers insgesamt handeln, keine ständige Bereitschaft für diese eine Anlage. Folglich ist IoT-Security in erster Linie keine technische Sache, sondern kaufmännisch zu betrachten, man darf nicht zu viel einsparen wollen. hartmut.schorrig, www.vishia.org

Angesichts der Existenz des lang bewährten IIO-Subsystems (aber auch des ähnlichen Comedi) müssen sich diverse Hersteller von DAQ-Hardware - wie zB. National Instruments - die Frage gefallen lassen, warum sie diese nicht nutzen, stattdessen aber die (nicht zu knapp!) zahlende Kundschaft ihren miserabel gepflegten, gigantisch großen und üblicherweise nicht funktionierenden proprietären Treiber-Stack aufnötigen wollen. Die Entwicklung von IIO- oder Comedi-Treibern ist nun wahrlich nicht aufwändig. Wie bei Linux so üblich, müssen sich die Treiber hier eigentlich nur um die tatsächlich hardware-spezifischen Dinge kümmern - generische Aufgaben, wie zB. Buffer-Management, Channel-Decoding, uvm. erledigt das Subsystem schon selbst. Evtl. könnten wir ja ergänzend zu diesem Artikel mal einen weiteren zum Thema IIO-Treiberprogrammierung schreiben. Gruß Enrico Weigelt, metux IT consult info@metux.net

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.

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.

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!

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

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.

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 ...