Kontakt · Newsletter · ENGLISH
Das RMG/941C bietet eine CAN-2.0A/2.0B- sowie eine 10/100 Mbps-Ethernet-LAN-Schnittstelle und ist auch in einer Variante mit 4G-LTE-Modem (RMG/941CL) oder mit NB-IoT-Wireless-Modem (RMG/941CN) lieferbar.
Mit der umfangreichen Softwareausstattung und den Funktionserweiterungen über nachinstallierbare Apps lassen sich CAN-Anwendungen und CAN-Baugruppen in das Internet der Dinge und Industrie-4.0-Umgebungen integrieren.
So lassen sich beispielsweise folgende Anwendungen mit dem RMG/941C realisieren:
Die im RMG/941C integrierten Laufzeitumgebungen für C/C++, Python, Node.js und Node-RED ermöglichen darüber hinaus viele weitere Anwendungen.
Das embedded Linux-Betriebssystem auf Debian-Basis erlaubt zudem die Installation weiterer Software (apt-get) sowie sichere Over-the-Air (OTA) Software-Updates.
Mit C/C++, Python, Node.js und Node-RED stehen verschiedene Möglichkeiten zur Verfügung, um eigene Anwendungen zu entwickeln und auf dem RMG/941C auszuführen. Dabei sind einige Besonderheiten zu beachten, die im Folgenden erläutert werden.
Da C/C++ eine Compilersprache ist, wird eine Cross-Entwicklungsumgebung benötigt. Damit wird der Quellcode auf einem PC editiert und mit einem Cross-Compiler in eine ausführbare Binärdatei (Binary) übersetzt. Dieses Binary wird anschließend in das Dateisystem des RMG/941C kopiert.
Als Cross-Compiler haben wir einen SSV-Crossbuild-Docker entwickelt, der über ein Docker Hub Repository zur Verfügung steht. Aus diesem Crossbuild-Docker können anwendungsbezogene Varianten erstellt werden, um z. B. spezielle Bibliotheken einzubinden.
Beides sind Interpretersprachen, bei denen der jeweilige Python- bzw. JavaScript-Quellcode auf einem PC editiert und dann als Textdatei mit entsprechender Dateiendung (also *.py bzw. *.js) in das Dateisystem des RMG/941C übertragen und dort ausgeführt wird.
Dabei ist zu berücksichtigen, dass auf dem RMG/941C weder der Python-Paketmanager PIP noch der Node.js-Paketmanager NPM zur Verfügung stehen. Diese Werkzeuge eignen sich nicht für den Einsatz in Embedded Systemen, da ansonsten die Kontrolle über die Bestandteile und somit die Integrität des Dateisystems verloren gehen kann.
Dieses grafische Entwicklungswerkzeug mit integrierter Laufzeitumgebung kann man ebenfalls als Interpretersprache einordnen, weil zur Ausführung der Node-RED-Flows Node.js genutzt wird.
Der Node-RED-interne Palette Manager zum nachträglichen Installieren weiterer Nodes lässt sich auf dem RMG/941C ebenfalls nicht nutzen, da die jeweiligen Abhängigkeiten analog zu PIP und NPM verschiedene Probleme im Dateisystem des Embedded-Linux verursachen können.
Für die Kommunikation der einzelnen Anwendungen untereinander steht ein In-System-MQTT-Broker (ISMB) zur Verfügung. Er ermöglicht den in einzelnen Prozessen isolierten Anwendungen einen bidirektionalen Datenaustausch per MQTT. Der ISMB ist über die IP-Adresse 127.0.0.1 (Local Host) und den TCP-Port 7883 erreichbar.
Per ISMB kann z. B. eine Python-Anwendung zur CAN-Datenerfassung mit einer Node-RED-Anwendung kommunizieren. Ein möglicher Anwendungsfall wäre ein Node-RED-Dashboard als Benutzerschnittstelle, um Konfigurationsdaten an die Python-Anwendung zu senden.
Eine Einführung in die SDKs inkl. Links zu den benötigten Ressourcen ist auf der GitHub-Seite von SSV zu finden: SDKs für das RMG/941C auf GitHub
Wir bieten auch ein einstündiges On-Demand-Webinar für den Einstieg in die Arbeit mit diesen SDKs an, welches über unseren Vertrieb angefragt werden kann.
Bestimmte Funktionen für das RMG/941C lassen sich auch ganz einfach und komfortabel als App über die Konfigurationsoberfläche (SSV/WebUI) nachrüsten, zum Beispiel ein Node für Node-RED zur Anbindung einer SQLite-Datenbank.
Das RMG/941CL kann als LTE-Router eingesetzt werden, zum Beispiel um Daten aus einem lokalen Netzwerk (LAN) in ein anderes IP-Netzwerk, in der Regel das Internet, zu übertragen.
Ein RMG/941CL als LTE-Router ermöglicht somit lokalen Netzwerk-Geräten den Zugriff auf das Internet und verhindert gleichzeitig aus Sicherheitsgründen den Zugriff aus dem Internet auf das lokale Netzwerk durch eine interne Firewall.
Die Controller unserer Frequenzumrichter sollen bei bestimmten Ereignissen über die PROFINET-LAN-Schnittstelle Messwerte an einem Datenbankserver im Internet schicken.
Der DNS-Name dieses Servers ist in den Umrichtern werksseitig vorkonfiguriert. Insofern benötigen wir nur einen Internetzugang per LAN.
Die sichere Internetverbindung für IoT-Anwendungen wird nur bei Bedarf entweder über die LAN-Schnittstelle oder über das 4G-Mobilfunknetz (LTE) aufgebaut, also wenn eine IoT-Anwendung bspw. per MQTT oder HTTP-Request Daten versenden möchte.
Das RMG/941C selbst ist quasi unsichtbar im Internet und für andere Anwendungen von außen nicht erreichbar.
Die Baugruppen unserer Wartungsvertragskunden übermitteln Systemmeldungen, Betriebsstundenzähler und Füllstandsmessungen zu einzelnen Betriebsstoffen an einen IoT-Service.
Damit planen und koordinieren wir die Wartungstermine, den Ersatzteilbedarf und andere Servicearbeiten.
Ein Virtual Private Network (VPN) ist eine speziell geschützte Netzwerkumgebung, auf die nur durch besondere Maßnahmen vorbereitete Systeme zugreifen können (z. B. durch die Installation spezieller Treiber plus gültiger Zugriffszertifikate).
In der Praxis nutzen VPNs häufig das Internet als Transportkanal. Durch die jeweils verwendeten VPN-Protokolle kommt eine Verschlüsselung zum Einsatz, die eine abhör- und manipulationssichere Kommunikation zwischen den VPN-Partnern ermöglicht.
Zur CAN-Sensorik unserer Anlagen gehört ein webbasiertes Konfigurations- und Monitoring-Dashboard, das direkt vor Ort auf dem Gateway läuft und auf das unsere Kunden über die LAN-Schnittstelle per Webbrowser zugreifen können.
Für unseren Service existiert über das Internet eine hochsichere VPN-Fernzugriffsmöglichkeit.
Wir haben für Test- und Evaluierungszwecke einen einfachen OpenVPN-Server in einem Docker-Container eingerichtet und mit einer Installationsanleitung auf GitHub veröffentlicht.
Für das RMG/941C wird ein aufgabenbezogener OTA-Update-Agent benötigt, der die Updates vom Server lädt und z. B. per ISO-TP (ISO 15765-2) an die einzelnen CAN-Geräte überträgt.
Um die nötige Cybersecurity einer solchen OTA-Update-Lösung zu gewährleisten, ist eine Public-Key-Infrastruktur (PKI) mit digitalen Signaturen erforderlich.
Als Update-Server für eine OTA-Update-Lösung lässt sich ein SSV-Secure-Device-Update-(SDU-) Server einsetzen.
Auf GitHub finden Sie eine API-Beschreibung zum SDU-Server.
Unsere Batteriemonitoringsysteme besitzen eine extern zugängliche CAN-Schnittstelle, über die sich Firmware-Binärdateien in den Flash-Speicher der Mikrocontroller dieser Baugruppen programmieren lassen. Bisher wird diese Update-Möglichkeiten von unseren Servicetechnikern mit Hilfe eines PCs plus einem USB-CAN-Adapter genutzt.
Mit dem RMG/941C werden wir diese Update-Aufgabe automatisieren. In Zukunft erkennt ein Software-Agent auf dem Gateway, dass ein Update für eine bestimmte Baugruppe vorliegt, lädt die Update-Datei aus dem Internet und programmiert sie in den Flash des Mikrocontrollers.
Um die CAN-over-IP-Bridge zu nutzen, sind zwei RMG/941C erforderlich, auf denen jeweils die can2udp-App installiert sein muss.
Die notwendigen Einstellungen bei der Inbetriebnahme (CAN-Bitrate, UDP-Port, IP-Adressen) erfolgen über das SSV/WebUI.
Wir haben auf unserem Gelände in mehreren Gebäuden zahlreiche CAN-Sensornetzwerke für die Gebäudeautomatisierung im Einsatz.
Diese einzelnen CAN-Segmente möchten wir gerne mit Hilfe von Ethernet-LAN-Netzwerken miteinander verbinden, um die Daten zentral erfassen zu können.
Die Anzahl der Baugruppen einer Automatisierungslandschaft, die lokal per MQTT kommunizieren, nimmt beständig zu. Der erforderliche MQTT-Broker wird allerdings häufig in der IT-Welt oder auf einer High-End-Edge-Plattform betrieben.
Durch den RMG/941-internen Mosquitto-MQTT-Broker und entsprechender Interface-Agenten lassen sich die Daten verschiedener Protokolle direkt in MQTT-Topics umwandeln und in Automatisierungsanwendungen integrieren.
Wir haben verschiedene Baugruppen in unseren Anlagen, die per MQTT kommunizieren. Der erforderliche Broker befindet sich allerdings in unserer IT. Dadurch ergibt sich nun ein Sicherheitsproblem, da OT und IT unterschiedliche Netzwerksegmente bilden und über eine intelligente Firewall voneinander getrennt werden.
Wir benötigen einen MQTT-Broker direkt vor Ort in der Anlage. Darüber hinaus wäre es wünschenswert, wenn wir auch noch eine Verbindung zwischen den CAN- und Modbus-Schnittstellen einiger Steuerungsbaugruppen und den MQTT-Datenpunkten unserer Visualisierung herstellen könnten.
Durch die Verknüpfung eines RUL-Lebensdauermodells mit den periodischen Echtzeit-Sensordaten eines USV-Systems (USV = Unterbrechungsfreie Stromversorgung), ist der digitale Zwilling in der Lage, die verbleibende Zeitspanne bis zum Ausfall einer Komponente zu bestimmen und beim Unterschreiten bestimmter Grenzwerte ein Serviceticket zu erzeugen.
Es gibt in der Stochastik bzw. Statistik mehrere Verfahren, um den Einfluss verschiedener Variablen auf die verbleibende Lebensdauer eines physischen Objekts zu ermitteln. Hierzu gehören z. B. die Cox Regression (Cox Proportional Hazards Regression) und das AFT-Modell (AFT = Accelerated Failure Time).
Wir sind Hersteller von Batterie-basierten industriellen USV-Systemen, die als Notstromversorgung in Schaltschränken zum Einsatz kommen. Um die Zuverlässigkeit unserer USV-Lösungen zu erhöhen, wollen wir unseren Kunden einen vollautomatischen Monitoring-Service anbieten, der auf einem digitalen Zwilling basiert.
Wir haben zu unseren Produkten in den vergangenen Jahren mit Hilfe eines einfachen Condition Monitorings ausreichend Lebenszyklusdaten gesammelt und ausgewertet. Dadurch sind wir mittels mathematischer RUL-Modelle (RUL = Remaining Useful Life, Restnutzungsdauer) nun in der Lage die noch verbleibende Zeit bis zum nächsten Wartungstermin unter Berücksichtigung des jeweiligen Nutzungsszenarios relativ genau vorherzusagen.
| Single Board Computer | |
|---|---|
| Modell | DIL/NetPC DNP/9535 |
| Prozessor | |
| Hersteller / Typ | Atmel ATSAM-A5D35 SoC |
| Taktgeschwindigkeit | 528 MHz |
| Speicher | |
| RAM | 256 MB SDRAM |
| Flash | 4 MB NOR |
| Speichermedium | 1x interner SD-Karten-Halter |
| Schnittstellen | |
| Ethernet | 1x 10/100 Mbps (RJ45) |
| CAN I/Os | 1x CAN 2.0A/2.0B (Schraubklemme) Unterstützte Bitraten (Kbps): 50/100/125/250/500/1000 |
| COM (Service-Port) | 1x 6-Pin-Connector |
| Antenne | 1x SMA-Anschluss für LTE/NB-IoT-Antenne |
| Spezialfunktionen | |
| Echtzeituhr (RTC) | 1x Echtzeituhr mit internem Batterie-Backup |
| Watchdog | 1x Timer Watchdog (Hardware-basiert, Software-konfigurierbar) 1x Power Supervisor (Hardware-basiert) |
| SIM-Karte | 1x Halter für Mini-SIM-Karten (von außen zugänglich) |
| LTE-Modem (RMG/941L) | |
| Mobilfunkstandards | GSM/UMTS/HSPA+/LTE |
| Übertragungsraten | 100 Mbps max. Download, 50 Mbps max. Upload |
| Frequenzbänder | LTE: B1/B3/B5/B7/B8/B20 WCDMA: B1/B5/B8 GSM/GPRS: GSM850/GSM900/DCS1800/PCS1900 |
| Authentifizierung | PAP, CHAP, CHAT, none |
| Unterstützte APNs | Telekom, Vodafone, 02, E-Plus, benutzerdefiniert |
| NB-IoT-Modem (RMG/941N) | |
| Mobilfunkstandards | GSM/LTE |
| Übertragungsraten LTE Cat M1 | 375 Kbps max. Download, 375 Kbps max. Upload |
| Übertragungsraten NB-IoT (LTE Cat NB1) | 32 Kbps max. Download, 70 Kbps max. Upload |
| Übertragungsraten GSM | GPRS: 107 Kbps max. Download, 85,6 Kbps max. Upload EDGE: 296 Kbps max. Download, 236,8 Kbps max. Upload |
| Frequenzbänder LTE Cat M1 | LTE FDD: B1/B2/B3/B4/B5/B8/B12(B17)/B13/B18/B19/B20/B26/B28 LTE TDD: B39 |
| Frequenzbänder NB-IoT (LTE Cat NB1) | LTE FDD: B1/B2/B3/B4/B5/B8/B12(B17)/B13/B18/B19/B20/B26/B28 |
| Frequenzbänder | GSM/GPRS: GSM850/GSM900/DCS1800/PCS1900 |
| Authentifizierung | PAP, CHAP, none |
| Unterstützte APNs | 1nce |
| Anzeigen / Kontrollelemente | |
| LEDs | 1x Power 1x Systemstatus (programmierbar) 2x LAN LED für Ethernet-Schnittstelle |
| Elektrische Eigenschaften | |
| Spannungsversorgung | 12 .. 24 VDC ±10% über externes Netzteil |
| Leistungsaufnahme | < 15 W |
| Mechanische Eigenschaften | |
| Schutzart | IP20 Industriegehäuse für 35 mm Hutschiene |
| Masse | < 150 g |
| Maße | 112 mm x 100 mm x 22,5 mm |
| Betriebstemperatur | 0 .. 60 °C |
| Lagertemperatur | -40 .. 85 °C |
| Standards und Zertifikate | |
| EMC | CE |
| Umweltstandards | RoHS, WEEE |
| Bezeichnung | Ausstattung |
|---|---|
| RMG/941C | Ohne LTE-Modem, ohne Antennenanschluss |
| RMG/941CL | Mit LTE-Modem und Antenne, ohne SIM-Karte |
| RMG/941CN | Mit NB-IoT-Modem und Antenne sowie vorinstallierter SIM-Karte |
SSV SOFTWARE SYSTEMS
Dünenweg 5
30419 Hannover
Fon: +49(0)511 · 40 000-0
Fax: +49(0)511 · 40 000-40
Impressum · Datenschutz · AGB
© 2024 SSV SOFTWARE SYSTEMS GmbH. Alle Rechte vorbehalten.
ISO 9001:2015
