TOP
SSV Software Systems Registrieren  Registrieren
Einloggen, um private Nachrichten zu lesen  Einloggen, um private Nachrichten zu lesen
Startseite FAQ Suchen Mitglieder Profil  Login 
SSV Support-Forum
2. Anwendungsschwerpunkt (SSV vSoM) ...

 
Neues Thema eröffnen   Neue Antwort erstellen    SSV-Forum Foren-Übersicht >>> DNP/8331
<<< Vorheriges Thema - Nächstes Thema >>>  
Beiträge der letzten Zeit anzeigen:   
Autor Nachricht
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 12.08.2022, 16:05    Titel: 2. Anwendungsschwerpunkt (SSV vSoM) ... Antworten mit Zitat

Hallo Forum.

In industriellen IoT-Anwendungen nutzen viele Baugruppen unterschiedliche System-on-Module (SoM)-Konzepte, um eine Laufzeitumgebung für die Anwendungssoftware zu schaffen. In der Regel werden dazu Module externer Anbieter dazugekauft und in die jeweilige IoT-Baugruppe gesteckt oder aufgelötet. Mit dem SSV Virtual System-on-Module (vSOM)-Konzept steht nun eine Alternative zur Verfügung, die sich direkt in die eigene Schaltungsentwicklung integrieren lässt



Ein DNP/8331 ist im DIL-40-Modulformat und als Altium-CAD-Funktionsblock verfügbar, der sich von den vSOM-Lizenznehmern vollständig in eigene Schaltungen einbetten lässt. Eine vSOM-basierte Lösung bietet daher zahlreiche Vorteile im Vergleich zum klassischen SoM-Einsatz. Abgesehen von den Kosten für die SoM-Beschaffung zur Serienfertigung der eigenen Baugruppe sind größere Probleme in der Praxis durch die immense Abhängigkeit vom SoM-Hersteller zu erwarten. Auslöser sind in der Regel die Veränderungen in der Zulieferkette eines SoM-Herstellers, aber auch fehlende Migrationsprozesse. Ein sehr gutes Beispiel ist die aktuelle Chip- und Lieferkettenkrise. Dadurch sind zahlreiche SoMs überhaupt nicht mehr oder nur mit extremen Lieferzeiten verfügbar. Teilweise haben sich die Preise verzigfacht. Auch komplette SoM-Produktabkündigungen trotz Langzeitverfügbarkeitsgarantien sind an der Tagesordnung. Insgesamt addieren sich die Probleme der Chip- und SoM-Hersteller für den SoM-Anwender. Beim vSOM-Konzept ist das nicht der Fall.

VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 19.08.2022, 06:22    Titel: Ein vSOM-Anwendungsbeispiel ... Antworten mit Zitat

Hallo Forum.

Um etwas detaillierter auf die vSOM-Möglichkeiten einzugehen, stellen wir uns einfach mal den folgenden Anwendungsfall vor:

Ein Unternehmen produziert seit vielen Jahren ein hochwertiges Messsystem, um abrechenbare Durchflussmengen flüssiger und gasförmiger Betriebsstoffe in Produktionsumgebungen zu ermitteln. Die Baugruppe besitzt einen internen Steckplatz für ein GSM-Kommunikationsmodul, um Messwerte als SMS an eine Serviceplattform zu schicken. Durch die weltweiten Veränderungen in den Mobilfunknetzen (GSM- und UMTS-Netze werden bzw. wurden bereits abgeschaltet) soll ein IoT-Retrofit mit einem 4G-fähigen Kommunikationsmodul erfolgen, um die Messsysteme im Feld vor Ort durch geschulte Servicetechniker umzurüsten und alle Neulieferungen ab Werk mit einer 4G-basierten Mobilfunkschnittstelle auszuliefern. Statt einer SMS werden zukünftig Messdatenpakete an marktübliche IoT-Plattformen geschickt. Aus rechtlichen Gründen sind die Messwerte zusätzlich mit einer digitalen Signatur zu sichern. Für spätere Erweiterungen ist die Integration in ein Blockchain-basiertes Framework vorzusehen (z. B. zum Supply Chain-Management per Hyperledger Fabric). Darüber hinaus muss die Retrofit-Neuentwicklung hinsichtlich der Mobilfunkschnittstelle international einsetzbar sein.

Der SMS-Versand über die GSM-Funkschnittstelle wird vom Host-Prozessor des Messsystems über AT-Befehlssequenzen ausgelöst und gesteuert. Da die gesamte Firmware dieses Prozessors nicht verändert werden kann, muss die 4G-Kommunikationsmodul-Neuentwicklung die AT-Befehle emulieren und in die jeweils benötigten Funktionen umsetzen. Dabei wird z. B. die Telefonnummer des SMS-Zielsystems mit Hilfe der jeweiligen Retrofit-Baugruppen-Konfigurationsdaten in den DNS-Namen einer IoT-Plattform umgewandelt und aus dem SMS-Versand eine MQTT-Datenübertragung mit einem einstellbaren Topic-Namen. Zur Verbindungssicherung wird TLS eingesetzt. In den MQTT-Daten ist neben dem Messwert auch eine digitale Signatur enthalten, die per Elliptische-Kurven-Kryptographie erzeugt wird. Des Weiteren muss ein sicherer Fernzugriff auf die 4G-basierte Retrofit-erweiterung möglich sein, um internationalen Kunden z. B. bei der Anbindung an verschiedene IoT-Plattformen die erforderliche Hilfestellung zu bieten. Die Übersicht liefert eine beispielhafte Zusammenfassung der wichtigsten Anforderungen inklusive der Kommunikationsfähigkeiten und Sicherheitsaspekte. Zur Umsetzung wird im vSoM des 4G-Kommunikationsmoduls eine Embedded-Linux-basierte Laufzeitumgebung eingesetzt.


VG KDW


Zuletzt bearbeitet von kdw am 19.08.2022, 06:38, insgesamt 2-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 19.08.2022, 06:27    Titel: Anforderungsübersicht ... Antworten mit Zitat

Hallo Forum.

Um den zuvor beschriebenen Anwendungsfall in der Praxis umzusetzen, lassen sich die hier folgenden Anforderungen definieren:

Anforderung 1: Das neue 4G-Modul muss mechanisch, elektrisch sowie hinsichtlich der Umgebungsbedingungen und AT-Kommandos vollständig kompatibel zum bisher eingesetzten GSM-Kommunikationsmodul sein.

Umsetzung: Die Abmessungen und Befestigungsbohrungen entsprechen dem Vorgänger. Der baugleiche Steckverbinder besitzt dieselbe Position, identische Signale und Versorgungsspannungseingänge. Der Arbeitstemperaturbereich ist identisch. Die AT-Kommandos werden über einen anpassbaren Interpreter nachgebildet.

Anforderung 2: Das Endprodukt wird weltweit eingesetzt und muss sich überall problemlos mit dem jeweiligen 4G-Netz verbinden.

Umsetzung: Um den weltweiten Einsatz unter Beachtung der verschiedenen nationalen Vorgaben zu ermöglichen, wird ein für den Zielmarkt zugelassenes 4G-Modem in einem M.2-Steckplatz plus eine externe Antenne genutzt.

Anforderung 3: Es ist der Messdatenversand an marktübliche IoT-Plattformen zu ermöglichen.

Umsetzung: Die Messdaten lassen sich z. B. mittels TLS, HTTP (REST), MQTT, JSON, XML und Google Protocol Buffer verschicken.

Anforderung 4: Die Datenauthentizität der Messdaten ist mit digitalen Signaturen zu sichern.

Umsetzung: Es wird eine PKI mit X.509-Zertifikaten sowie eine Elliptische-Kurven-Kryptographie (ECC) implementiert.

Anforderung 5: Es sind geeignete Fernwartungs- und Fernkonfigurationsmöglichkeiten vorzusehen.

Umsetzung: Für die 4G-Schnittstelle wird ein VPN-Client realisiert, der entsprechend autorisierte Fernzugriffe ermöglicht.

Anforderung 6: Die gesamte Software muss stets dem neusten Stand entsprechen.

Umsetzung: Die Wartung des Software-Stacks erfolgt mit Hilfe eines vollständig automatischen OTA-Update-Konzepts. Zur Pflege und Weiterentwicklung wird ein geeigneter DevOps geschaffen.

Anforderung 7: Die IT-Sicherheit gegen externe Cyberangriffe muss sich am neusten Stand der Erkenntnisse orientieren.

Umsetzung: Es wird ein A/B-Bootkonzept implementiert. Im Fall eines Totalverlusts der Software oder ungültiger X.509- Zertifikate wird ein Notfallplan entwickelt.

Anforderung 8: Die IT-Sicherheit der 4G-Schnittstelle muss sich in Kundenaudits überprüfen lassen.

Umsetzung: Es werden sowohl ein Sicherheitshandbuch als auch Testprotokolle erstellt. Dabei dient die EN 62443 als Orientierung.

Anforderung 9: Die Inbetriebnahme der Baugruppe muss für den Anwender vor Ort so einfach wie möglich sein (Zero Config Deployment.)

Umsetzung: Es erfolgt ein Werkssetup hinsichtlich der SIM-Karte und der Zugriffsrechte auf das Fernzugriffs-VPN. Die Inbetriebnahme der jeweiligen IoT-Plattform-Anbindung erfolgt mittels eines VPN-Zugriffs.

Anforderung 10: Bei Kommunikationsproblemen wird dem Anwender über ein geeignetes Support-Konzept durch qualifiziertes Personal geholfen.

Umsetzung: Es wird ein First Level- und Second-Level-Support-Konzept entwickelt. Dazu gehören auch eine Q&A-Datenbasis plus Schulungsvideos für das Support-leistende Personal.

Anforderung 11: Es ist eine technische Unterstützung für den Export in verschiedene Länder mit speziellen Anforderungen an die 4G-Funkschnittstelle erforderlich.

Umsetzung: Um die verschiedenen nationale Regeln zu erfüllen und mit einer IoT-Baugruppe das jeweilige 4G-Netz nutzen zu dürfen, wird ein spezieller Support durch erfahrene Experten angeboten.

Anforderung 12: Es ist eine Zukunftsfähigkeit mittels Blockchan-basierter Frameworks zu vorzusehen.

Umsetzung: Die gesamte Software wird in einer Embedded-Linux-Laufzeitumgebung ausgeführt, die sich durch zusätzliche Bibliotheken erweitern lässt. Sogar das Betriebssystem selbst ist vollständig austauschbar.


VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 19.08.2022, 11:10    Titel: Coming soon … Antworten mit Zitat

Hier folgen nun nach und nach einige Details zur Umsetzung einzelner Anforderungen aus der „Anforderungsübersicht“ …

Beispiel "IT-Sicherheit mit A/B-Bootkonzept verbessern" (Anforderung 7):

Zu den Standard-Softwarefunktionen eines vSoM gehört ein Bootloader mit einem A/B-Bootkonzept. Dafür wird das bootfähige Flash-Speichermedium jeweils in eine A- und B-Partition unterteilt. In jeder Einzelpartition lässt sich ein vollständiges Firmware-Image mit einem Linux-Betriebssystem und dem Anwendungscode ablegen. Innerhalb des Bootloaders existiert eine Umgebungsvariable, über die sich steuern lässt, welches Image (A oder B) beim nächsten Bootvorgang jeweils gestartet wird.



Anmerkung zur Abbildung: Der vSoM-Bootvorgang wird durch eine Bootloader-Umgebungsvariable gesteuert (fw_active). Diese Variable lässt sich durch die Anwendungssoftware z. B. von A auf B umschalten. Mit dem dann folgenden Reboot (System-Warmstart) wird das jeweils andere Firmware Image gestartet.

Mit Hilfe der beiden Partitionen A und B sind gleichzeitig zwei vollständige und voneinander unabhängige Firmware-Versionen in einem SoM-basierten System verfügbar. Firmware Image A lässt sich beispielsweise für den „Alltagsbetrieb“ einsetzen. Image B wird bei Problemen als Notfallsystem gestartet, um das Image A wieder in einen stabilen Zustand zu versetzen. Über eine solche Vorgehensweise sind Notfallpläne umsetzbar, um bei einer durch externe Einwirkungen beschädigten Softwarekonfiguration oder Cloudverbindungsproblemen auf Grund ungültiger X.509-Zertifikate automatisch einen stabilen Ausgangszustand herzustellen.

Alternativ lässt sich ein A/B-Bootkonzept auch für Over-the-Air (OTA)-Updates nutzen, die vollständig im Hintergrund ablaufen. Dazu wird z. B. das Image A gestartet und parallel zum normalen Systembetrieb ein Update des Firmware Image B ausgeführt. Dieses Update kann, sofern es die OTA-Kommunikationsverbindung zulässt, in einem einzigen Schritt erfolgen. Alternativ sind allerdings auch über einen längeren Zeitraum verteilte inkrementale Updates einzelner Speicherbereiche im Image B möglich. Unabhängig von den OTA-Download-Details: erst nachdem ein Update vollständig durchgeführt wurde, kann die jeweils laufende Anwendungssoftware des Image A einen Reboot erzwingen, um das neue Image B zu starten. Anschließend gilt die umgekehrte Reihenfolge. Es wird Image B ausgeführt und die OTA-Updates beziehen sich auf das Firmware Image A. Solange nach dem Neustart der neuen Firmware-Version keine OTA-basierten Veränderungen an der älteren Version vorgenommen wurden, ist sogar noch ein Fall-back möglich.

In der vSoM-Roadmap sind darüber hinaus auch sogenannte Vertrauensanker (Root of Trust, RoT) sowie darauf aufbauende Vertrauensketten (Chain of Trust, CoT) vorgesehen, um einen Secure Boot zu ermöglichen. Des Weiteren arbeiten wir an einem A/B/P-Bootkonzept mit einem dritten „P = Protected-Bereich“, der nicht ohne weiteres verändert werden kann.



...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    SSV-Forum Foren-Übersicht >>> DNP/8331 Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Sie können keine Beiträge in dieses Forum schreiben.
Sie können auf Beiträge in diesem Forum nicht antworten.
Sie können Ihre Beiträge in diesem Forum nicht bearbeiten.
Sie können Ihre Beiträge in diesem Forum nicht löschen.
Sie können an Umfragen in diesem Forum nicht teilnehmen.

SSV Software Systems GmbH

Dünenweg 5
30419 Hannover

Fon: +49(0)511 / 40 000-0
Fax: +49(0)511 / 40 000-40

sales@ssv-embedded.de


Impressum    ·    Datenschutz    ·    AGB

© 2022 SSV Software Systems GmbH. Alle Rechte vorbehalten.

ISO 9001:2015