- Details
- Geschrieben von Joel Peretz
- Kategorie: Telemetrik
- Zugriffe: 2149
Telematik-Steuergeräte im Fokus: Herausforderungen und Lösungen in der Entwicklung Teil I
Wo Aspekte in der Entwicklung herkömmlicher Datenverarbeitungssysteme wichtig sind, erlangen sie bei Telematik Systemen eine entscheidende Bedeutung. Darüber hinaus erfordert dies ein tiefes Verständnis der Entwicklungsprozesse und der Architektur. In diesem Artikel behandeln wir die Aufgabe, die besonderen Herausforderungen und ihre Ursprünge zu identifizieren und Anforderungen an Projektleiter, Architekten und Entwickler in diesem Bereich zu stellen.
 |
 |
 |
 |
Was sind Telematik Systeme?
Wenn von Telematiksystemen gesprochen wird, handelt es sich um die Integration von Technologien, die Telekommunikationstechniken verwenden, um erfasste und gesammelte Daten über Entfernungen zu übertragen. Diese Systeme finden Anwendung in verschiedenen Branchen, darunter Fahrzeugherstellung, Logistik, Gesundheitswesen, Landwirtschaft, Versicherung und viele andere. Die erfassten Daten können an ein zentrales Steuerungssystem übertragen und dort weiterverarbeitet werden.
Ein entwickeltes System, das Telemetrik verwendet, kann sehr komplex sein. Dort, wo elektronische Telematik-Steuergeräte integriert sind, sind auch weitere fortschrittliche Komponenten vorhanden, wie Gewichtssensoren, CCTV-Geräte und Sensoren für Temperatur, Sound, Geruch oder alles, was physikalische Messeinheiten hat. Dies ist beispielsweise in Zügen und Lokomotiven zu finden.
Solche Systeme sind auch in der Medizin und in der Produktion im Einsatz. Alarmsysteme überwachen beispielsweise Farbänderungen, die auf einen möglichen Feuerausbruch hinweisen könnten. Es gibt auch Roboter, die in Wasser oder in Rohren mit Flüssigkeit eingesetzt werden, um nach Gegenständen oder Rissen zu suchen oder auf Veränderungen zu reagieren. Diese Systeme senden alle erfassten Informationen zur weiteren Verarbeitung und gegebenenfalls zur Speicherung, je nach Anwendungsfall.
Die Liste könnte sehr lang werden, und wir werden sie nicht weiter ausbauen. Der Punkt ist jedoch klar: Telemetrie-Steuergeräte sind bereits in vielen Lebensbereichen eingebettet.
 |
 |
 |
 |
Was sind Telematik-Steuergeräte?
Telematik-Steuergeräte sind elektronische Komponenten, die Befehle an die Maschine übertragen. Obwohl die Ausfallwahrscheinlichkeit gering ist, besteht dennoch ein Risiko. Die Robustheit muss hoch sein, und Fehler sollten trotz Redundanz während des Betriebs, oder besser gesagt, während der Fahrt, abgemildert werden können. Eine hohe Effizienz und Leistung können bei der Entwicklung durch den Einsatz geeigneter System-Bus, Echtzeitmethoden und entsprechender Mikroprozessoren erzielt werden.
Wenn wir von Telematik-Steuergeräten sprechen, beziehen wir uns auf wichtige Module, die eine entscheidende Rolle in modernen Fahrzeugen spielen. Diese Module sind entscheidend für die Erfassung, Verarbeitung und Übertragung von Daten sowie für die Kommunikation. In einigen Systemen, wie autonomen Fahrzeugen, dienen sie zur Kommunikation zwischen den Fahrzeugen. Darüber hinaus gibt es Systeme für Fahrzeugortung und -verfolgung, Fahrzeugdiagnose, Notrufsysteme, Telematik-Versicherungen, Flottenmanagement, Infotainment und V2X-Kommunikation, um mit verschiedenen externen Systemen und autonomen Fahrfunktionen zu kommunizieren. Der Anteil der OAT (On Air Transfer) Kommunikation ist groß, daher sind die Sicherheitsrisiken höher, da die übertragenen Daten potenziell von Unbefugten gelesen werden können. Eine detaillierte Spezifikation dieser Gefahren würde den Rahmen dieses Artikels sprengen. Es sollte jedoch erwähnt werden, dass Funksignale gestört und manipuliert werden können, was im schlimmsten Fall zu erheblichen Schäden führen kann.
 |
 |
 |
 |
Zu autonomen Fahrzeugen
In vielen Ländern sind Diskussionen darüber, ob es erlaubt sein sollte, dass Fahrzeuge autonom auf den Straßen fahren dürfen, längst keine Seltenheit mehr. Es hat bereits Unfälle gegeben, die genauer untersucht werden müssen, und es gab Fehlfunktionen, die näher analysiert werden sollen. Aber auch ohne diese Vorfälle ist es leicht nachvollziehbar, dass es notwendig ist, die entwickelten Systeme sorgfältig zu testen. Die Herausforderungen sind physischer Natur, da die Fahrzeuge unter widrigen Umständen sicher fahren müssen, ohne Personen- oder Sachschaden zu verursachen. Wenn Menschen Fehler machen, kann dies oft als "Menschenversagen" bezeichnet werden. Doch was passiert, wenn die Maschine versagt? Was passiert, wenn die Software ausfällt? Wer trägt dann die Verantwortung? Wie kann man dies verifizieren? In welchem Umfang wurden die Hardware und Software getestet?
Die meisten Aspekte, die berücksichtigt werden müssen, sei es in der Fahrzeugtechnik oder im medizinischen Bereich oder in Bereichen, in denen Maschinen und Prozesse gesteuert werden, sei es mit KI oder ohne, sind identisch. Der Unterschied besteht darin, dass Maschinen, die sich in der öffentlichen Umgebung bewegen, besonders zuverlässig und sicher sein müssen. Dies betrifft nicht nur die Steuerungselektronik, sondern auch die Software selbst und deren Anfälligkeit für Ausfälle und Manipulationen. Das Testen hat hier höchste Priorität, und das Thema IT-Sicherheit nimmt eine andere Dimension an. Stellen Sie sich beispielsweise vor, dass die Kontrolle über einen mit Gefahrgut beladenen LKW übernommen wird und er in empfindliche Bereiche gelenkt wird. Dann wird die immense Bedeutung der Absicherung solcher Systeme deutlich. Im medizinischen Bereich kann auch die Anfälligkeit für physische oder OAT-Manipulation in lebenskritische Bereiche eindringen.
Allgemein zur Entwicklung, Architektur und Integration auf dem neuesten Stand der Technik
Man kann viele Jahre in der Entwicklung verbringen, ohne alles wissen zu können, insbesondere da sich das IT-Feld rasant entwickelt. Schon allein der Ausdruck 'alles wissen' ist in jedem Fachgebiet fraglich und könnte die Seriosität des Artikels beeinträchtigen. Es ist sehr verständlich, dass niemand alles wissen kann. Selbst bei sehr einfachen Systemen kann man sich der Materie annähern, aber dann handelt es sich um einen eng spezialisierten Bereich.
Der Versuch, in der IT immer auf dem neuesten Stand zu bleiben und alles Neue zu kennen, ist zwangsläufig zum Scheitern verurteilt. Täglich werden zahlreiche Programme, Methoden und Skripte in verschiedene Bereiche entwickelt und auf verschiedenen Plattformen bereitgestellt.
Die Geschäftsprozesse aus der realen Welt, die in der Umgebung des zukünftigen Systems ablaufen, werden durch Steuerungslogik umgesetzt, die auf Korrektheit und Qualität angewiesen ist. Diese Logik soll in einer bestimmten Reihenfolge ausgeführt werden. Das Ergebnis wird bestimmen, ob sie erfolgreich verlaufen sind. Technisch gesehen jedoch operieren Systeme in einer technischen Umgebung, und die Anforderungen an sie basieren darauf, dass sie unter bestimmten Voraussetzungen funktionieren. Diese nicht funktionale Anforderungen sind vielfältig und müssen bevor der Aufbau Arbeit beginnt, sehr gut durchdacht und überlegt. Von der Auswahl der Methodik über dem technologischen Stack bis zu den Entwicklungswerkzeugen und dem vorhandenen Know-how sollte es richtig konzipiert und umgesetzt werden.
Unter den nicht-funktionalen Anforderungen (NFAs) gibt es einige, die je nach Anwendungsbereich und -art wichtiger sind als andere. Wenn es beispielsweise um die Leistung und Latenz bei der Visualisierung von Daten auf dem Bildschirm oder bei der Internetrecherche geht, sind diese weniger kritisch. Im Gegensatz dazu kann es bei autonomen Fahrzeugen entscheidend sein, dass Daten für das Bremsen pünktlich und zuverlässig übertragen werden. In diesem sicherheitskritischen Bereich der Telematik im Automobilsektor ist es von entscheidender Bedeutung, dies nachzuvollziehen.
Einige solcher Anforderungen beeinflussen die kritischen Aspekte, sodass beispielsweise die Skalierbarkeit die Leistung und Latenz beeinflussen kann. Wenn die Architektur und das Design nicht robust konzipiert sind, kann dies auch die Verfügbarkeit und Ausfallsicherheit beeinträchtigen. All dies hat Auswirkungen auf die Konsistenz und Sicherheit des Systems. Einerseits möchten wir verhindern, dass Befehle aufgrund von technischen Fehlern nicht ordnungsgemäß an ihr Ziel gelangen. Statt beispielsweise grob und demonstrativ die Anweisung 'Lenken Sie nach rechts bis zum Anschlag' auf einer langen Brücke über Wasserstraßen zu erhalten.
Die komplexe Integration erhöht die Ausfallwahrscheinlichkeit, wenn viele Schnittstellen und bewegliche Teile in einem begrenzten Raum zusammenarbeiten und um Ressourcen konkurrieren. Viele Prozesse werden im Echtzeitverarbeitungsmodus durchgeführt, und die Delegation (das Dispatching) auf niedriger Ebene muss einwandfrei funktionieren.
Solange die Daten innerhalb des Fahrzeugs übertragen und die Funktionen ausgeführt werden, bleiben die Anforderungen und der erweiterte Bereich noch überschaubar, auch wenn die Komplexität bereits hoch ist. Es gibt nicht nur Module zur Steuerung des Fahrzeugs im System, sondern auch andere für Infotainment und Navigation. Durch die Modularität und die Trennung der Komponenten in separate Bereiche, zwischen sicherheitsrelevanten und nicht sicherheitsrelevanten, können unterschiedliche Sicherheitsstufen gewährleistet werden, um sicherzustellen, dass die Prozesse sich nicht gegenseitig beeinflussen. Ein Fehler in der Navigationsfunktion sollte beispielsweise nicht dazu führen, dass die Bremsen blockiert werden. Eine Entkopplung der Komponenten und Module ist unerlässlich. Auch die Analyse, ob Daten über gemeinsame physische Medien im Fahrzeug übertragen werden, ist wichtig. Schließlich möchten wir sicherstellen, dass die oben beschriebenen Aspekte nicht negativ beeinflusst werden. Diese Beschreibung diente lediglich zur Demonstration einiger Aspekte und ging nicht in die Tiefe, da sie nicht spezifisch für Telematik ist und somit auf allgemeinen Kenntnissen basiert.
Damit kommen wir näher zu unserem eigentlichen Thema: Wie betrachten wir die Anforderungen an Projektleiter, Architekten und Entwickler?
Wir erkennen die üblichen Gefahren im Fahrzeug und haben auch einen flüchtigen Blick auf die Telematik und Steuergeräte geworfen, jedoch noch nicht im Detail über das Netzwerk im Fahrzeug gesprochen. Man möchte Systeme entwickeln, die offen sind, aber so interoperabel wie möglich. Dies gewährleistet Kosteneffizienz und Zukunftssicherheit. Das bedeutet, dass es mehr Schnittstellen und Sockets gibt, um sich mit dem System zu verbinden und anzudocken.
Standardarchitekturen
Standardarchitekturen sind in allen Bereichen wichtig, in denen Telematik-Steuergeräte in das System integriert sind, sei es im Fahrzeugbereich oder im medizinischen Bereich. Während AUTOSAR im Bereich der Fahrzeugtechnik eine Standardarchitektur darstellt, finden sich in der Medizintechnik beispielsweise die e-Health-Architektur und das KIS (Krankenhausinformationssystem). Im Bereich der Fahrzeugtechnik erhöht der Einsatz von AUTOSAR die Modularität und Wiederverwendbarkeit entwickelter Komponenten sowie die Interoperabilität zwischen verschiedenen Herstellern. Der Einsatz von AUTOSAR bietet zudem die Plattformunabhängigkeit.
Methodik und Prozess
Der Projektleiter sorgt für die Durchführung des Projekts und ist an wichtigen Entscheidungen beteiligt. Der Architekt, ähnlich wie beim Entwerfen eines Hochhauses, legt fest, wie die Grundelemente gestaltet sein sollen. Er sollte so viel wie möglich über das System wissen. Dies umfasst die Festlegung von Grenzen, Limits, technischen Spezifikationen, Lastanforderungen, Mengengerüsten, erforderlicher Kohäsion zwischen den Domänen und Integrationsmöglichkeiten sowie Informationen zum Ressourcenverbrauchsverhalten und den Bausteinen für das Design. Der Architekt sollte auch Verständnis für Tests und Qualitätssicherung haben, auch wenn in diesen Phasen Spezialisten bei der Umsetzung unterstützen. Sofern keine vorgegebenen Umgebungen, Werkzeuge oder Methoden vorhanden sind, sollte der Architekt dies auch vorbereiten. Es sollten Machbarkeitsstudien durchgeführt, mehrere Lösungsansätze in Betracht gezogen und Prototypen erstellt werden, um frühzeitig Hinweise auf mögliche Probleme, Schwachstellen und Risiken zu erhalten.
Bis hinunter auf die Ebene des Low-Level-Codes sollten Überlegungen angestellt werden, welche Bibliotheken verwendet werden können. In Bezug auf Programmiersprachen sollte erwogen werden, wie die Sicherheit erhöht werden kann, beispielsweise durch eine sichere Speicherverwaltung und Sicherheitsmaßnahmen für einzelne Funktionen in den Code-Modulen. Als Beispiel kann die C++-Version in Betracht gezogen werden, einschließlich der Speicherzuweisung und -freigabe sowie möglicher Angriffsmöglichkeiten auf geschützte Speicherbereiche durch sogenannte Pointer. All dies sollte bei der Entscheidung, ob Smart Pointer verwendet werden sollen und welche, in Betracht gezogen werden.
In fortgeschrittenen Architekturentwürfen oder Entwicklungsphasen kann jede Änderung einen exponentiell höheren Aufwand bedeuten oder manchmal sogar unmöglich sein.
Unabhängig von der gewählten Entwicklungsmethode, sei es agil oder beispielsweise das V-Modell mit RUP, handelt es sich immer um eine Abfolge von Prozessschritten wie Business-Analyse, Fachkonzeption, Design, Umsetzung, Testen und Bereitstellung. Natürlich gibt es auch eine technische Phase, in der die Komponenten zuvor im Labor zusammengesetzt und getestet werden.
In Telematik-Anwendungen, bei denen Fahrzeuge nicht nur untereinander kommunizieren, sondern auch mit anderen Systemen in der umgebenden Infrastruktur oder in der Cloud, ist es wichtig, dass Projektleiter und Architekten über Kenntnisse oder eine starke Affinität zur Datenverarbeitung in TCP-Netzwerken verfügen. Häufig werden skalierbare und leistungsstarke Server, Middleware und Datenbanken benötigt, um die Datenmengen und die Anzahl der zu verarbeitenden Prozesse zu bewältigen. Auch wenn die direkte Entwicklung im Fahrzeug dies nicht unbedingt erfordert, wird die Fehleranalyse dies notwendig machen, zum Beispiel, wenn Kafka- und Cassandra-Cluster, S3-Buckets und das ESK-Stack sowie viele andere Technologien im Einsatz sind.
Techniken zur Erhöhung der Sicherheit und zur Reduzierung der Gesamtkosten, wie die Versionskontrolle von Quellcode, die Durchführung von CI/CD mit passiver und dynamischer Codeanalyse sowie die Automatisierung von Tests, sollten ebenfalls bekannt sein. Themen wie Funkkommunikation und IT-Sicherheit im Allgemeinen sollten nicht fremd sein. Ideal ist es, wenn man mit Schwachstellenanalysen vertraut ist und über mehrere zuverlässige Quellen Bescheid weiß, die solche Schwachstellen melden und dokumentieren. Darüber hinaus sollte man sich mit Techniken zur Codeanalyse vertraut machen, indem man Dokumentationen nutzt und manuell die Softwareversionen der tatsächlich in den Artefakten und Binärprogrammen verwendeten Komponenten überprüft.
Ebenso ist die Projektplanung und -ausführung mit PSP und Gantt-Charts oder ähnlichen Werkzeugen zu begleiten. Es ist wichtig, sich über die Vorgänge, ihre Abhängigkeiten und Reihenfolgen bewusst zu sein. Schließlich können Entwicklungsunterbrechungen und ineffiziente Zeiten auftreten, wenn man auf ein Modul warten muss und nicht vorankommt. Zeitdruck ist ein Faktor, der zu einer Verringerung des Umfangs von Tests führen kann. Der Architekt sollte in der Lage sein, bereits in einer frühen Phase mehrere Lösungsansätze vorzubereiten und die Vor- und Nachteile sorgfältig abzuwägen. Breite Kenntnisse über Server, Frameworks und Programmiersprachen sollten bereits vorhanden sein, aber ebenso wichtig ist es, dass man eigenständig nach weiteren Funktionen sucht, die möglicherweise verbessert oder sicherer sind. Man sollte sich mit dem Einsatz von Design-Patterns auskennen und gute Arbeitsgewohnheiten sowie Regeln wie 'Keep It Simple', 'SPICE', 'ACID', 'PIMPLE' usw. befolgen.
Idealerweise sollte er sich auch mit Echtzeitbetriebssystemen (RTOS) wie VxWorks oder ähnlichen auskennen. Andere Tools für die Entwicklung im Embedded-Bereich können hilfreich sein, sind jedoch nicht zwingend erforderlich.
Außer den üblichen IDEs wie VSCode und Eclipse können auch Keil uVision, IAR Embedded Workbench, PlatformIO, Code::Blocks oder SEGGER Embedded Studio von Vorteil sein.
Im Echtzeit-Embedded-Bereich können Architekturmuster wie Echtzeit-Monitor (Real-Time Monitor), Schichtenarchitektur (Layered Architecture), Echtzeit-Pipeline (Real-Time Pipeline), Publish-Subscribe (Pub-Sub), Zustandsautomat (State Machine), Client-Server, Komponentenbasierte Architektur (Component-Based Architecture) und Microservices verwendet werden. Die Vorbereitung zur Verwendung in Form von Kontextdiagrammen auf Level 0 und Komponentendiagrammen kann hilfreich sein.
Für die Kommunikation zwischen Prozessen und als Nachrichtenbus könnte man D-Bus mit GLib einsetzen, aber auch MQTT, je nach Anwendung und Notwendigkeit. In diesen Fällen kann es hilfreich sein, das Knowhow zu haben. Aber auch Serviceorientierte Architektur (SOA) mit Messaging und Bus-Einsatz könnte ausreichend sein, denn die Prinzipien, auch wenn die Umgebung unterschiedlich ist, sind identisch.Andere leichtgewichtige und skalierbare Messaging-Kenntnisse wie Kafka sind ebenfalls äquivalent.
Es ist wichtig, die Modellierung von Prozessen sowie Daten und deren Kommunikation und Formate zu beherrschen. Modellierungsstandards wie UML oder SysML sollten eingesetzt werden, um an einigen kritischen Stellen eine gemeinsame Verständigungsbasis mit den Stakeholdern und dem Entwicklungsteam zu schaffen. Bis hierhin handelt es sich um die üblichen Anforderungen an Architekten und Projektleiter, die den Prozess begleiten und die Abläufe jederzeit nachverfolgen und steuern können.
In den vorherigen Artikeln über die Themen 'Funk' im Blog (Funk1, Funk2, Funk3) , konnten wir bereits die allgemeinen Risiken und Gefahren bei der Nutzung von Funktechnologien zur Netzwerkkommunikation behandeln. Unter Funk sind die gängigen Protokolle wie WiFi, Bluetooth und GSM zu verstehen, obwohl es auch spezielle Signale gibt, die für die Avionik oder andere Einsätze reserviert sind und möglicherweise auch in Telematik Anwendungen für Fahrzeuge verwendet werden. Dies könnten wir in zukünftigen Artikeln genauer untersuchen und darüberschreiben.
Fazit
Das Thema ist umfangreich, aber es ist erkennbar, dass die Anforderungen an Projektleiter und Architekten ähnlich sind wie bei herkömmlichen EDV-Systemen, jedoch mit einer höheren Komplexität aufgrund der Vielzahl konkurrierender Geräte und Kommunikationsrisiken. Es ist erforderlich, eine breite Palette von Techniken zu beherrschen und sauberen Code gemäß den Standards zu schreiben.
Im nächsten Artikel werden wir uns ein Showcase ansehen, bei dem wir die Gelegenheit haben werden, konkrete Herangehensweisen und spezifische Merkmale zu betrachten. Wir werden nicht alle Fragen beantworten können, da ich kein Experte bin, aber wir werden uns auf die Suche machen und dabei einiges lernen, vor allem darüber, was auf einen zukommt, wenn man sich mit dem Thema PL oder Architektur in der Praxis auseinandersetzen möchte.
