Hallo,

da ich mich für das Tec Tauchen interessiere habe ich mir mal diverse Computer für das Deko Tauchen angesehen. Ich bin Softwareentwickler (seit 35 Jahren) und arbeite seit mehr als 10 Jahren im Automotivebereich (aktuell f. autonomes Fahren -> ADAS) und bin daher mit Functional Safety bestens vertraut. Gerade deswegen habe ich erstmal von Haus aus ein ziemliches Mißtrauen gegen Computer von denen in kritischen Situationen mein Leben abhängig ist. Dazu würde ich in jedem Fall auch einen Deko-Tauchkomputer zählen. Ich find es daher sehr lobenswert das Heinrichs Weikamp Einblick in seinen Source Code gibt. Leider ist so etwas heutzutage nicht selbstverständlich.

Ich habe mir daher mal den Programm-Code näher angeschaut:

https://bitbucket.org/heinrichsweikamp/hwos_code/src

Hier mal eine kurze Einschätzung:

Der überwiegende Teil ist in Assembler geschrieben. Davon gibt es unzählige Source Files. Eine Modularisierung ist nicht Ansatz weise zu erkennen. Im Repo befinden sich keinerlei Unit-Tests. Sicherheitskonzepte (watchdog, Asil, etc.) sind ebenfalls nicht vorhanden. Weiterhin gibt es im Repo keine Scripte, die zeigen, wie die Software gebaut wird. Die Doku ist ebenfalls bis auf Inline nicht vorhanden (Design, Architektur). Außerdem scheint nicht die gesammte SW des Geräts im Repo veröffentlicht zu sein.

Meine Einschätzung:

Ich denke, ich muss nicht viel dazu sagen, dass Assembler auch im embeeded Bereich eigentlich (ausser vielleicht im Bootloader, fehlt übriges auch im Repo), keinerlei Berechtigung mehr hat und vom Sicherheitsaspekt vollkommen inakzeptabel ist und das aus mehreren Gründen: Der Aufwand solch einen Code einem Review zu unterziehen ist gigantisch hoch. Es finden keinerlei Typenchecks, wie bei höheren Sprachen statt, ja es gibt ja ausser Register und Speicherzugriffsbreiten ja auch keine. Assembler wurde auch schon in früheren Zeiten (80er) nur von HW-Entwicklern verwendet, die keine Softwareentwickler Ausbildung haben. Weiterhin ist in den Repos nicht mal ansatzweise zu erkennen welche Art von Qualitätskontrolle erfolgt. State of the Art ist erstmal eine ausführliche Dokumentation (Architektur, Design, Erläuterung der Functional Safety Massnahmen). Weiterhin sind automatisierte Tests auf verschiedenen Levels obligatorisch (Units-Tests, Systemtests). Hierfür sollte es Testsuiten geben.

Nur mal so zum Vergleich. Im Automotive Bereich werden bei Sicherheits-kritischen Anwendungen spezielle Microcontroller eingesetzt, die so z.B. solche Dinge mitbringen, wie Schutz vor Speicherüberschreiber, Redundante Cores etc., Watchdog-Timer, die das Einfrieren bei SW-Fehler verhindern etc.

Hier von einem OS (Operating System zu sprechen -> HWOS) lässt auch erhebliche Zweifel aufkommen, ob die Entwickler überhaupt wissen, was das ist. Ich konnte im Code nichts dergleichen finden. Es gibt nicht mal eine Modularisierung von Laufzeitbibliotheken, Treiber, UI oder User-Functions.

Kurzum der gesammte Code ist lässt an keiner Stelle erkennen, dass die Entwickler über irgendeine Qualifikation (Softwareentwickler-Ausbildung) verfügen.

Trotzdem finde ich es gut, dass die Entwickler trotzdem die Eier haben, so einen Code in ein öffentliches Repo hochzuladen. Die HW kann ich nicht beurteilen. Das Housing, Screen etc. macht auf mich aber einen guten Eindruck. Deswegen möchte ich hier nicht nur kritisieren, sondern den Entwicklern/Geschäftsleitung ein paar Empfehlungen geben, was zu tun wäre, damit man solch einem Gerät sein Leben anvertrauen kann:

Es sollte der gesammte Code veröffentlicht werden wie zB. der Bootloader, build-scripte. Open-Source bedeutet, dass jeder Entwickler in der Lage sein sollte die Software selbst zu bauen und zu flashen. Das ist hier erstmal so nicht möglich.

Der gesammte Code sollte nach C portiert werden. Hierfür sollten Coding-Styles verwendet werden.

Der nächste Schritt wäre dann, mal ein bischen Struktur in die Software zu bringen, um separat Test-bare Module zu bekommen, für die Unittestsuits geschrieben werden müssten. Es wäre dann eine Functional Safty Konzept (Minimum ASIL-B) erforderlich, da ich mal davon ausgehe, dass die derzeitige HW ein höreres Asil-Level, was aber dringend notwendig wäre (da Menschenleben an dem Gerät hängen), derzeit noch nicht zulässt. So ein Konzept löst z.B. so Fragen, was passiert bei Softwarefehler (Speicherüberschreiber, Freezes, Ausfall v. HW wie z.B. Sensoren, Display, Tastern, Selbstdiagnose, Plausibiliesierung, Redundanzen, Systemtests, Buildtoolchain) etc.

Zum UI könnte ich auch noch einiges Schreiben, aber gemessen an dem Gesamtzustand des Programmcodes, spielt das wohl keine grosse Rolle mehr.

Weiterhin sollten Code-Reviews stattfinden.

Ich kann verstehen, das Organisationen wie die GUE davon abrät, überhaupt Computer zu verwenden. Im Übrigen gehe ich davon aus, dass es bei den anderen Herstellern, wahrscheinlich genauso, wenn nicht, noch trostloser aussieht.

Beste Grüße an Alle von Frank