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
Intelligenter Serviceassistent …

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



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 28.07.2022, 14:35    Titel: Intelligenter Serviceassistent … Antworten mit Zitat

Hallo Forum.

Für das RMG/941 entwickeln wir eine völlig neue Anwendungskategorie: den intelligenten Serviceassistenten für Maschinen und Anlagen. Eine solche Lösung besteht aus drei elementaren Funktionseinheiten:

1. Einem Zustandsagenten mit einer angepassten Sensorik sowie einer Verbindung zur lokalen Maschinen- bzw. Anlagensteuerung auf einem Edge-Gateway. Dieser Agent bestimmt mittels einer Datenanalyse periodisch den aktuellen Maschinenzustand, liefert Updates an den digitalen Zwilling des zuständigen Cloudservice und verschickt fortlaufend Zustands-Beacons per Bluetooth Low Energy (BLE).

2.) Der Assistenten-App für ein Smartphone. Sie dient als Schnittstelle zwischen dem Zustandsagenten und einer Person vor Ort. Diese App präsentiert nach einer erfolgreichen Datenauthentifizierung die im BLE-Zustands-Beacon enthaltenen Informationen. Des Weiteren wird durch die Nutzung eines Cloudservice ein erweiterter Zustandskontext hergestellt; beispielsweise durch Diagramme, die bestimmte Maschineneigenschaften über einen längeren Zeitraum visualisieren. Mit der App-Rückkopplung zum Cloudservice lassen sich aussagefähige Informationen zum aktuellen Maschinenzustand sowie weitreichende Wartungs- und Instandsetzungshinweise an den Benutzer weitergeben. Per App sind auch Wartungs- und Instandsetzungs- sowie Chat-Termine mit Experten reservierbar. Bei Bedarf kann der App-Nutzer auch Echtzeit-Fernzugriffe durch Servicefachkräfte auf die Maschinensteuerung autorisieren.

3.) Einem Cloudservice mit einem integrierten digitalen Zwilling. Dieser Cloudservice bietet des Weiteren kontextbezogene Datenanalysen zum Zustand von Maschinen und Anlagen sowie komplexe Unterstützungsfunktionen, die von externen Endgeräten verschiedener Teilnehmer über eine REST-basierte Serviceschnittstelle (API) angefordert werden.



(1) Zustandsagent mit Sensorik auf einem Edge-Gateway: Bestimmt mittels einer Datenanalyse periodisch den aktuellen Maschinenzustand …

(2) Übergabe der Update-Daten für den digitalen Zwilling einer Maschine an den zuständigen Cloudservice …

(3) Periodisches Aussenden des aktuellen Maschinenzustands als Bluetooth Low Energy (BLE) Beacon-Nachricht …

(4) Smartphone-App (Assistenten-App) empfängt die Beacon-Nachricht, authentifiziert die Daten und übermittelt den Maschinenzustand an den Cloudservice …

(5) Der Cloudservice antwortet der Smartphone-App mit kontextbezogenen Informationen sowie Wartungs- und Instandsetzungshinweisen …

Der Zustandsagent auf dem Edge-Gateway (1) wird durch eine Softwarefunktion gebildet, die praktisch den Input für die gesamte Assistentenanwendung liefert. Dafür ist der Agent mit einer geeigneten Sensorik verbunden und hat darüber hinaus noch Zugriff auf bestimmte Variable der jeweiligen Maschinensteuerung. Aus diesen Daten wird zyklisch ein Gesamtrohdatenbild erzeugt und automatisch analysiert, um den genauen Maschinenzustand zu bestimmen. Dafür werden u. a. Supervised-Maschine-Learning-Modelle (also KI-Algorithmen) zur Klassifizierung und Regression eingesetzt. Mit den Datenanalyseergebnissen lassen sich Informationen gewinnen, die von Zeit zu Zeit an den digitalen Zwilling in der Cloud übermittelt werden (2). Dazu gehören z. B. (virtuelle) Betriebsstundenzähler, die Anzahl der Motorenstarts und Störungen, Minimal-, Maximal- sowie Mittelwerte bestimmter Umgebungsbedingungen, verschiedene KPIs usw. Darüber hinaus wird bei jeder relevanten Veränderung eine neue BLE-Beacon-Nachricht zum aktuellen Zustand erstellt, mit einem Hash-based Message Authentication Code (HMAC) gekennzeichnet und über die Bluetooth-Nahbereichsfunkschnittstelle periodisch verschickt (3). Mit Hilfe der Beacon-Daten lässt sich die Frage „In welchem Zustand befindet sich meine Maschine?“ jederzeit beantworten.

Eine Smartphone-App (Assistenten-App) bildet die Benutzerschnittstelle zur Maschine bzw. Anlage und zu einem externen Cloudservice. Diese App visualisiert nach einer erfolgreichen Datenauthentifizierung zunächst die in der BLE-Beacon-Zustandsnachricht enthaltenen Informationen und erzeugt auf Wunsch mit Hilfe der Beacon-Daten eine Anfrage (4) für den Cloudservice. In der Cloud erfolgt eine umfassende Datenanalyse mit den Zustandsdaten des BLE-Beacon und den Informationen des jeweiligen digitalen Zwillings. Als Ergebnis erhält der App-Nutzer eine kontextbezogene Antwort (5) mit weitreichenden Nutzungs-, Wartungs- und Instandsetzungshinweisen, die von der Assistenten-App entsprechend präsentiert werden. Zur Visualisierung werden Textnachrichten, statische Abbildungen sowie Mixed Reality-Elemente verwendet. Die App unterstützt darüber hinaus auch Chat-Funktionen zwischen der Person vor Ort und einem Experten in einem Servicecenter.

Siehe auch https://www.ssv-embedded.de/produkte/rmg941#vsa

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



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 31.08.2022, 06:21    Titel: Wie wird getestet? Antworten mit Zitat

Hallo Forum.

Die einzelnen Softwarebausteine einer Serviceassistentenanwendung zu entwickeln und über den gesamten Lebenszyklus an die jeweiligen Anforderungen anzupassen, ist auf Grund der Gesamtkomplexität eine große Herausforderung. Besonders anspruchsvoll sind dabei die erforderlichen Tests. Damit ein Zustandsagent innerhalb einer Entwicklungsumgebung den Zustand einer Maschine oder Anlage bestimmen kann, sind geeignete Eingangsdatenströme erforderlich. Die Qualität dieser Eingangsdaten führt zu brauchbaren Zeitreihendaten im digitalen Zwilling und zum jeweiligen Zustands-Beacon, der periodisch per BLE verschickt wird.



Eine Möglichkeit für qualitativ hochwertige Tests innerhalb einer typischen Entwicklungsumgebung sind Hardware-in-the-Loop (HiL)-basierte Verfahren. Solche Testmethoden kommen seit einigen Jahren in größerem Umfang in der Automobilindustrie zum Einsatz, um beispielsweise die Software eines Steuergeräts bereits im Entwicklungsumfeld umfangreich auszutesten. Dafür werden Eingangsdatenbilder mit Hilfe spezieller (HiL-) Simulatoren quasi in Echtzeit an den Prüfling (also der Device Under Test, DuD) geliefert und das Verhalten der Ausgangssignale mit einem Modell abgeglichen. Ein HiL-Simulator dient somit als Nachbildung der realen Steuergeräteumgebung.

Die HiL-Methodik erlaubt es, dass steuernde Gesamtsystem nahezu vollständig über Modelle zu simulieren, um die korrekte Funktion des zu entwickelnden Steuergeräts auszutesten. Besonders hilfreich dabei ist, dass sich wiederkehrende Abläufe für eine Testautomatisierung schaffen lassen. Damit wäre z. B. eine neue Softwareversion unter den absolut gleichen Bedingungen wie die Vorgängerversion testbar, um herauszufinden, ob ein bestimmter Fehler erfolgreich beseitigt wurde.

Da unzählige IoT-Anwendungen inzwischen analog zu vielen Steuergeräten in der Automobiltechnik mit ähnlich komplexen Sensordatenbildern als Eingangsgrößen arbeiten, lässt sich die HiL-Testmethodik sehr effektiv auch für Softwareprojekte in der Automatisierungstechnik einsetzen. Besonders hilfreich ist ein HiL-Simulator, wenn Sensoren mit einem konstanten Datenstrom als Eingangssignale (Führungsgröße) sowie komplexe Algorithmen zur Bildung der Ausgangsgrößen (Stellgrößen) zum Einsatz kommen. Ein praktisches Beispiel wäre der 3-Achsen-MEMS-Beschleunigungssensor einer Maschine, der einen dauerhaften Messwertdatenstrom mit der X-, Y- und Z-Beschleunigung an ein Edge-Gateway liefert, um mit Hilfe eines Supervised Machine Learning-Algorithmus den jeweiligen Maschinenzustand in Echtzeit zu bestimmen. Ähnlich verhält es sich mit Datenströmen unterschiedlicher Kamera- und IR-Arrays- zur Objekterkennung bzw. Objekttemperaturmessung sowie laufzeitbasierte Sensoren (Time-of-Flight, ToF-Sensorik) für Abstandsmessungen oder Gestenerkennungsanwendungen. Auf Grund der vielfältigen Eingangsdatenvarianten, die eine Edge-Gateway-Software beim Einsatz einer solchen Sensorik auswerten muss, ist ein aussagefähiger Funktionstest innerhalb der Softwareentwicklungsumgebung eigentlich nur mit simulierten Daten möglich. In vielen Anwendungsszenarien dürfte ein HiL-Simulatoreneinsatz sogar die einzige echte Testmöglichkeit darstellen, da sich beispielsweise Sensordatenbilder zu bestimmten Maschinenfehlerzuständen in einer Anwendungsumgebung nicht so ohne weiteres erzeugen lassen.

In einer Beispielanwendung (siehe Abbildung) könnte der HiL-Simulator die Zustandsagenten-Hardware in der Testumgebung mit dem Vibrationsdatenstrom eines MEMS-Beschleunigungssensors versorgen, der den Schwingungsdaten einer bestimmten Maschine entspricht. Darüber hinaus existiert ein zweiter Datenkanal zwischen Simulator und Zustandsagenten, über den periodisch einige (simulierte) SPS-Variable abgefragt werden. Aus den MEMS-Sensor- und SPS-Daten erzeugt die Zustandsagenten-Software fortlaufend die Information für den Echtzeit-Zustands-Beacon, der per BLE versendet wird.

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



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 01.09.2022, 06:32    Titel: Cybersicherheit: STRIDE-Bedrohungsanalyse … Antworten mit Zitat

Hallo Forum.

Der hier vorgestellte Serviceassistent bietet aus dem Blickwinkel der Cybersicherheit zahlreiche mögliche Angriffspunkte. Insofern ist im Rahmen der Serviceassistentenentwicklung in jedem Fall eine Bedrohungsanalyse erforderlich. Die dabei gewonnenen Erkenntnisse müssen von Anfang an in die Hard- und Softwareeigenschaften einfließen. Da sich die Bedrohungslage fortlaufend verändert, muss die Analyse über die gesamte Lebensdauer eines Assistenten periodisch wiederholt werden, um die Schutzmaßnahmen an den aktuellen Stand der Dinge anzupassen.

Für das methodische Vorgehen bei der Risikoanalyse lässt sich STRIDE einsetzen. STRIDE ist ein etabliertes Modell für Cyber-Sicherheitsrisiken, das ursprünglich von Microsoft entwickelt wurde. Es basiert auf insgesamt sechs Risikokategorien.

1.) Identitätsverschleierung (Spoofing): Identitäts-Spoofing wäre beispielsweise der Zugriff auf eine Datenbank mit den Anmeldedaten eines anderen Benutzers.

2.) Manipulation (Tampering): Z. B. das Daten-Tampering, also die böswillige Veränderung irgendwelcher Daten mit dem Ziel, dem Datennutzer einen Schaden zuzufügen. Auch ein Software-Tampering ist möglich, um z. B. das Verhalten eines Systems zu verändern.

3.) Zurückweisung (Repudiation): Wenn ein Benutzer eine bestimmte Aktion in einem IT-System ausführt und dann abstreitet, dass er es gewesen ist, hat man ein Repudiation-Problem.

4.) Datenschutzproblem (Information Disclosure): Darunter fällt jegliche Form eines missbräuchlichen Datenzugriffs, also sowohl das unautorisierte Lesen irgendwelcher Nutzerdaten als auch das Abhören des Datenverkehrs in einer Kommunikationsverbindung.

5.) Dienstverweigerung (Denial of Service): Wenn durch gezielte (böswillige) externe Einwirkungen ein bestimmter Dienst (z. B. ein Cloudservice) für die normalen Benutzer nicht mehr nutzbar ist, hat man es mit einem Denial-of-Service-Angriff zu tun.

6.) Rechteausweitung (Elevation of Privilege): Verschafft sich ein nicht privilegierter Nutzer auf einem System unberechtigterweise die Administratorenrechte, liegt ein Elevation-of-Privilege-Problem vor.



Um die STRIDE-Methodik auf einen Serviceassistenten anzuwenden, ist ein geeignetes Team für ein Ursachen-Brainstorming erforderlich. Die Vorgehensweise beim Brainstorming ist vergleichbar mit einer Fehlermöglichkeits- und Einflussanalyse (FMEA). Statt dem Fehlerursachenrisiko wird allerdings nach einem Cyber-Bedrohungsrisiko gesucht. STRIDE liefert über die Kategorien sechs Denkanstöße hinsichtlich der Fragestellungen „Was könnte in einer IT-Anwendung passieren?“ bzw. „Wovor sollte ich meine IT-Anwendung schützen?“.

Die sechs möglichen STRIDE-Risiken bilden in einem Ursachen-Wirkungsdiagramm jeweils die (Aus-) Wirkung. Zu jeder Auswirkung existiert in einem Serviceassistenten mindestens eine Ursache in einer oder mehreren Funktionseinheiten, die vom Team im Rahmen des Brainstormings bestimmt werden. So entsteht nach und nach eine Sammlung möglicher Cybergefahren für den Praxiseinsatz des Serviceassistenten. Hier einige einfache Beispiele:



(1) Spoofing: Ist der Sensor wirklich der, für den er sich ausgibt? Gleiches gilt auch für die SPS. Hier lässt sich die Identität auch nicht sicher nachprüfen.

(2) Tampering: Können die Daten des digitalen Zwillings per REST-API manipuliert werden? Mit anderen Worten: Diese Daten müssen nicht unbedingt vom Zustandsagenten stammen.

(3) Repudiation: Die kostenpflichtige Vor-Ort-Instandsetzung, die sich aus den Daten des digitalen Zwillings ergeben hat, wurde von uns nicht bestellt?

(4) Information Disclosure: Kann ich an Hand der BLE-Beacon-Daten den Energiebedarf der Maschine erkennen (damit sind Rückschlüsse auf die Maschinenauslastung möglich)?

(5) Denial of Service: Lässt sich mit sehr vielen Anfragen der Cloudservice außer Betrieb setzen?

(6) Elevation of Privilege: Kann ich über das Cloudservice-API für den Assistenten-App-Zugriff die Zugriffsrechte eines Administrators erlangen?

Nachdem durch das Team-Brainstorming eine Liste mit den „Was kann durch welche Ursache passieren“-Fragestellungen vorliegt, kann man für jede Bedrohung nach geeigneten Gegenmaßnahmen suchen. Diese lassen sich in zwei Kategorien einteilen: 1.) Welche Systemanforderungen sind erforderlich, um die Auswirkung einer Bedrohung abzuschwächen (Mitigation) oder sogar vollständig zu vermeiden (Elimination)? Hierzu zwei Beispiel:

Mitigation: Eine bestimmte Bedrohung bzw. Gefahr abschwächen. Die Sensordaten werden mit einem Hash-based Message Authentication Code (HMAC) ergänzt, der über einen im Sensor gespeicherten geheimen Schlüssen gebildet wird. Der Zustandsagent kennt den geheimen Schlüssel und kann den in den Sensordaten enthaltenen HMAC nachrechnen.

Elimination: Eine bestimmte Funktion ausschalten. Die allgemeine Erreichbarkeit der Admin-Schnittstelle des Cloudservice wird deaktiviert. In Zukunft ist diese Schnittstelle nur noch über ein Virtual Private Network (VPN) zugänglich, zu dem die Smartphones mit den Assistenten -Apps keinen Zugang besitzen.

Bevor allerdings einzelne Gegenmaßnahmen zu den jeweiligen Bedrohungen in der Praxis umgesetzt werden, sollte man die Bedrohungen nach Prioritäten sortieren. Dafür wird eine Metrik benötigt. Man könnte z. B. zu jeder einzelnen Bedrohung das jeweilige Risiko bestimmen:

Bedrohungsrisiko = Eintrittswahrscheinlichkeit x Auswirkung

Das dabei entstehende Bedrohungsranking bestimmt die Umsetzungsreihenfolge der Gegenmaßnahmen. Man wird nicht immer für alle Bedrohungen geeignete Gegenmaßnahmen finden, die sich in der Praxis auch mit vertretbarem Aufwand umsetzen lassen. Zu den Bedrohungen mit dem größten Risiko sollten aber auf jeden Fall entsprechende Maßnahmen existieren.

VG KDW


Zuletzt bearbeitet von kdw am 18.09.2022, 18:38, insgesamt 15-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 12.09.2022, 06:30    Titel: Gegenmaßnahmen: Secure Boot … Antworten mit Zitat

Hallo Forum.

Ein Secure-Boot-Mechanismus muss sicherstellen, dass auf einem Rechnersystem nur vertrauenswürdiger Code gestartet und ausgeführt wird und keine kompromittierte Variante zum Einsatz kommen kann. In unserem Serviceassistenten-Anwendungsbeispiel soll der Secure Boot beispielsweise gewährleisten, dass die in der Sensorik, der SPS und dem Zustandsagenten ausgeführte Software nicht durch einen Angreifer manipuliert wurde (Tampering). Mit anderen Worten: Per Secure Boot wird die Integrität und Authentizität der Software bzw. Firmware in den einzelnen Komponenten bei jedem Systemstart geprüft. Ein solches Bootverfahren ist also ein wichtiger Baustein der Systemintegrität (dafür ist es allerdings notwendig, dass alle Systemkomponenten eine Secure-Boot-Fähigkeit besitzen; nur der Zustandsagent reicht nicht aus, Sensoren und SPS sind dann immer noch Tampering-gefährdet). Durch die Codeintegrität eines Boot-Image ist garantiert, das kein einziges Bit verändert wurde. Die Codeauthentizität belegt des Weiteren, dass der Code aus einer vertrauenswürdigen Quelle stammt.

Vereinfacht betrachtet lässt sich ein solcher Sicherheitsmechanismus mit Hilfe verschiedener kryptografischer Methoden realisieren. Man könnte sowohl dem Firmware-Autor als auch dem Bootloader einen geheimen kryptografischen Schlüssel zur Verfügung stellen, mit dem bei jedem Firmware-Release ein Hash-based Message Authentication Code (HMAC) mit Hilfe einer Hash-Funktion aus den Bytes des Firmware-Image plus dem Schlüssel errechnet und im Image gespeichert wird (siehe z. B. RFC 2104). Dieser HMAC wird beim Starten des Images vom Bootloader geprüft. Stimmt der HMAC, wird die Firmware zur Ausführung gebracht. Ansonsten wird die Codeausführung einfach angehalten.



Der große Nachteil dieses sehr einfachen Verfahrens mittels symmetrischer Kryptografie ist, dass die Schlüssel K zum Berechnen und Nachprüfen eines HMACs identisch sind. Gelingt es einem Angreifer den Schlüssel aus dem Bootloader eines Rechnersystems zu kopieren, kann er damit auch ein manipuliertes Firmware-Image mit entsprechender Codeauthentizität erzeugen. Des Weiteren ist es in der Praxis sehr schwierig, den Schlüssel K gegen eine neue Variante zu tauschen, z. B. weil der Firmware-Autor das Unternehmen gewechselt hat und der Nachfolger einen neuen Schlüssel erzeugt hat.



Weitaus sicherer ist da schon der Einsatz einer asymmetrischen Kryptografie, also z. B. ein Secure Boot mit einen Schlüsselpaar aus Private Key (PrK) und Public Key (PuK). Der Firmware-Autor erzeugt in diesem Fall mit Hilfe seines PrK eine digitale Signatur (DS) für das Firmware Image B, die innerhalb des Images gespeichert wird (ansonsten achtet der Firmware-Autor darauf, dass sein Private Key stets an einem sicheren Ort verwahrt wird und eine unautorisierte Nutzung auszuschließen ist). Mit dem im Bootloader A gespeicherten PuK lässt sich die digitale Signatur von B verifizieren, aber nicht erzeugen. Insofern hätte ein Angreifer keinen Vorteil, sollte es ihm gelingen, den Public Key (PuK) aus A auszulesen.

VG KDW


Zuletzt bearbeitet von kdw am 28.09.2022, 17:34, insgesamt 9-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 18.09.2022, 18:34    Titel: IoT-Bausteine … Antworten mit Zitat

Hallo Forum.

Insgesamt ist der hier vorgestellte intelligente Serviceassistent aus unserer Sicht eine industrielle IoT-Anwendung mit drei Funktionseinheiten. Ein solcher digitaler Assistent lässt sich in verschiedenen Marktsegmenten nutzen und durch Softwareweiterentwicklungen bis zur Augmented Reality (AR)-Anwendung ausbauen.

Die folgende Abbildung zeigt die drei Funktionseinheiten: 1. Device Condition Sensor (DCS, entspricht funktional dem Zustandsagenten des weiter oben beschriebenen Assistenten), 2. Device Assistant App (DAA) und 3. dem Assistant Service API (ASA), um mit einem Cloudservice zu kommunizieren, der u. a. einen digitalen Zwilling enthält.



Zur möglichst einfachen Realisierung einzelner Funktionseinheiten entwickeln wir gerade universell nutzbare Bausteine, die für eine Assistentenanwendung als Vorlage nutzbar sind und sich relativ einfach an die individuellen Anforderungen anpassen lassen. Auf der SPS 2022 (Nürnberg, 8. bis 10. November) können Sie sich den aktuellen Stand der Dinge anschauen. Wir zeigen dort mit der Hilfe von zwei Demonstratoren verschiedene Beispiele zu DCS, DAA und ASA. Nach dem Ende der Messe besteht bei Bedarf auch die Möglichkeit, sich die Beispiele nach Terminabsprache in einem Webmeeting gemeinsam anzuschauen.

VG KDW


Zuletzt bearbeitet von kdw am 30.09.2022, 09:47, insgesamt 4-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1409

BeitragVerfasst am: 29.09.2022, 11:27    Titel: Industrie 4.0 Innovation Award … Antworten mit Zitat

Hallo Forum.

Wir haben uns mit unserem Serviceassistenten um den Industrie 4.0 Innovation Award 2022 beworben. Die Abstimmung, um die Sieger zu ermitteln, läuft bis Ende Oktober 2022. Einen Link zur Abstimmung für unsere Bewerbung finden Sie hier (siehe QR-Code im PDF):

https://ssv-comm.de/forum/dokumente/Bewerbung_ISA.pdf

VG KDW
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 >>> RMG/941 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