Softwareentwicklung

Qualifikationen auf einen Blick:
  • Als promovierter Experimental-Physiker und langjähriger IT-Experte bekommen Sie mit mir zwei Experten in einem!

  • Sie profitieren von meinem Wissen und meiner Erfahrung aus mehr als 20 Jahren erfolgreicher Tätigkeit als professioneller Softwareentwickler und Freelanceer. Davor habe ich bereits einige Jahre in Studium und Forschung programmiert.

  • Sauber erstellte Software ist Ihre solide Basis für die Zukunft. Weder Perfektionismus noch das rücksichtslose Eingehen technischer Schulden sind akzeptabel: wie ein immer weiter wachsender Schuldenberg belastet es die Entwicklung der Firma. Stattdessen ist es wünschenswert, übersichtliche, zuverlässige und leicht wartbare Software zu entwickeln.

  • Ich biete Leistungen in Analyse, Design, Implementierung, Dokumentation, Tests und auch Benutzertraining an, zugeschnitten auf Ihren Bedarf.

  • C/C++, Java, Skriptsprachen (Python, shell, awk, Perl, make, Ruby), html und xml, Versions- und Änderungsmanagement, auf UNIX, Linux, Windows

  • Spezialwissen: Universitäts- und Industrieforschung, Logistik, Automobil, Produktionssteuerung, Bildanalyse in schwierigen Szenen, Röntgen- und Millimeterwellen-Optik, Performance Tuning, Softwarequalität, Softwareanalyse von Motorsteuergeräten (z.B. MSG von Dieselmotoren), Reverse Engineering




Softwareanalyse von Diesel-Motorsteuerungen
In Zusammenhang mit der Thematik der Abgase von z.B. Dieselmotoren (öfters als "Dieselgate", "Dieselskandal" oder "Abgasskandal" bezeichnet) führe ich Softwareanalysen von Motorsteuergeräten durch, meist für Dieselmotoren. Heute hat ein Automotor einen solchen eigenen, kleinen Computer, auf dem eine eigene Software läuft, welche den Motor regelt.

Als "Geprüfter und anerkannter Sachverständiger für Softwareentwicklung (DESAG)" werde ich dazu von verschiedenen Gerichten mit Gerichtsgutachten beauftragt. Inzwischen wird recht häufig ein Sachverständiger für Software zusammen mit einem KFZ-Sachverständigen für Abgasmessungen beauftragt, um interdisziplinär an die Beweisfrage heranzugehen.

Dabei kommen von meiner Seite verschiedene Methoden der Softwaretechnik/Informatik zum Einsatz, z.B. Reverse Engineering und statistische Analysen.

Model Engine Luc Viatour Akustikbedingung: Moritz Contag, Guo Lit et. al., How They Did It: An Analysis of Emission Defeat Devices in Modern Automobiles, 2017-05-01, 
          2017 IEEE Symposium on Security and Privacy, 10.1109/SP.2017.66

Dieselmotoren verschiedener Hersteller kamen in die Schlagzeilen, weil ihre Fahrzeuge zwar die vorgeschriebenen Tests der behördlichen Typzulassung nach Abgasnorm Euro5 oder Euro 6a, 6b, 6c bestanden hatten, jedoch bei abweichenden Fahrzyklen oder bei Straßenfahrten deutlich höhere Schadstoff-Emissionen des reizenden Gases "Stickoxide (NOx)" aufwiesen.
Die Typprüfung verwendete zur Messung der im Abgas emittierten Schadstoffe einen einfachen, "neuen europäischen" Fahrzyklus NEFZ auf einem Rollenprüfstand. Der Ablauf der Testfahrt ist dabei genau vorgegeben, um gute Vergleichbarkeit zu sichern. Leider nutzte z.B. der Hersteller Volkswagen mit dem Motor EA189 dieses Wissen, um den Testablauf zu erkennen und die Motorsteuerung daran anzupassen, so dass sich der Motor in diesem Test anders verhielt als in Realität.

Inzwischen wird ein verbesserter Fahrzyklus WLTP auf dem Rollenprüfstand verwendet, der realistischere Anforderungen an den Motor stellt. Außerdem wird seit Abgasnorm Euro 6d auch eine reale Fahrt auf der Straße mit einem mobilen Messystem (PEMS) durchgeführt (RDE-Testfahrt). Das hat zu einer besseren Kontrolle und dadurch zu einer starken Verbesserung der Abgase im Praxisgebrauch geführt.
Dazu mussten die Motor-Hersteller allerdings auch beträchtlichen Entwicklungsaufwand treiben, denn die Reduktion von NOx steht in einem gewissen Konflikt mit dem Wunsch nach geringem Kraftstoffverbrauch, geringer Feinstaub-Enstehung, und niedrigen Kosten (einfachem Motoraufbau, niedrigen Herstellungs- und Wartungskosten). Moderne Fahrzeuge halten die gesetzlichen Grenzen jetzt auch in der Praxis gut ein; dazu ist nun meist hinter dem Motor ein zusätzlicher NOx-Speicherkatalysator, ein SCR-Katalysatorsystem (verwendet AdBlue-Zusatzmittel) oder beides verbaut.




Kleine Betrachtung: Wie erreicht man eine übersichtliche, zuverlässige und leicht wartbare Software?

Wann hatten Sie zuletzt dieses Gefühl / Gedanken?

  • "Hier sollte man eigentlich mal aufräumen, das gibt bestimmt mal Ärger."
  • Diese Schnittstelle sollte klarer dokumentiert werden
  • Diese Quellcode-Module sind viel zu eng verknüpft, geradezu "verwurstelt"
  • Unser Coding Standard hilft uns, übersichtlichen Code zu schreiben und ist gut verständlich.
  • Dieser Teil ist schlecht getestet. Die vorhandenen Tests sind nicht aussagefähig genug
  • Die Dokumentation ist veraltet, wichtige Konzepte sind nicht dokumentiert und stehen nur irgendwo in Emails.
  • Jetzt habe ich ewig gebraucht, um diesen Fehler zu finden. Das hätten wir uns sparen können wenn wir ...
  • Das Projekt war so chaotisch, wir hatten so viele unvorhergesehene Schwierigkeiten, und nur um es fertig zu bekommen, haben wir gepfuscht.
  • Dieses Ereignis hat der Firmenkultur und dem Team nicht gut getan.
  • Alle stehen unter Druck, deswegen gibt es häufig Streit.
  • Ich bin dankbar für die offene Kommunikation und die vertrauensvolle Zusammenarbeit in meinem Team: dieses Problem war sehr schnell und unbürokratisch zu lösen

Technische Schulden sind eine in der Informatik gebräuchliche Metapher für die möglichen Konsequenzen "schlechter" Software: man versteht darunter den zusätzlichen Aufwand, den man für Änderungen und Erweiterungen einplanen muss. In einem positiven Bereich zu bleiben und nicht in technische Schulden zu rutschen ist Aufgabe nicht nur der Software-Entwickler, sondern auch der Projektmanager. Sie versuchen, auch in Zeiten schwieriger Randbedingungen eine positive Arbeitskultur im Team aufrecht zu erhalten:

  • Befolgen gängiger Designprinzipien nach dem Stand der Technik
  • Ein durchdachtes Konzept von Code Standards, das von den Entwicklern auch gelebt wird
  • Sinnvoller Level von Dokumentation, die regelmässig gepflegt wird und allen Team-Mitgliedern zugängich ist
  • Gute Infrastruktur
  • Ausreichende und sinnvolle Tests
  • Übersichtliche Struktur des Quellcodes
  • Gemeinsame "best-practice" Strategien sind allen Mitgliedern des Teams vertraut
  • Statische Quellcode-Analyse und Beachtung von Compilerwarnungen
  • Offene und vertrauensvolle Zusammenarbeit im Team und gute Fehlerkultur
  • Ein Gleichgewicht von agilem Vorgehen und Vorausschau auf zukünftige Anforderungen
  • Sinnvolle Gewichtung von kurzfristigen Anforderungen des aktuellen Projekts und langfristigem Erfolg
  • Angenehme äußere Arbeitsbedingungen: Klima, Helligkeit, kein Lärm, genug Arbeitsplatz
  • Continuous Integration (CI) Prozess und Gebrauch von Software-Metriken







Bildquellen:
Funktionsdiagramm-Ausschnitt aus Moritz Contag*, Guo Lit et. al., 2017-05-01, 2017 IEEE Symposium on Security and Privacy, 10.1109/SP.2017.66
Ansonsten eigenes Bildmaterial, sofern nicht (Maus drüber halten) eine Quelle direkt beim Bild angegeben ist.