Contact · Newsletter · DEUTSCH
The RMG/941C offers a CAN 2.0A/2.0B as well as a 10/100 Mbps Ethernet LAN interface and is also available in a variant with a 4G LTW modem (RMG/941CL) or with an NB IoT wireless modem (RMG/941CN).
With the extensive software equipment and the function extensions via subsequently installable apps, CAN applications and CAN modules can be integrated into the Internet of Things and Industry 4.0 environments.
Thus, the following applications can be realized with the RMG/941C for example:
The runtime environments for C/C++, Python, Node.js and Node-RED integrated in the RMG/941C also enable many other possible applications.
The embedded Linux operating system based on Debian also allows the installation of additional software (apt-get) as well as secure over-the-air (OTA) software updates.
With C/C++, Python, Node.js and Node-RED, various options are available for developing your own applications and executing them on the RMG/941C. Some special features have to be considered, which are explained in the following.
Since C/C++ is a compiler language, a cross-development environment is required. This is used to edit the source code on a PC and translate it with a cross compiler into an executable binary file. This binary is then copied to the file system of the RMG/941C.
As a cross-compiler, we have developed an SSV cross-build Docker, which is available via a Docker Hub repository. Application-specific variants can be created from this cross-build Docker, e.g. to include special libraries.
Both are interpreter languages where the respective Python or JavaScript source code is edited on a PC and then transferred to the file system of the RMG/941C as a text file with the corresponding file extension (i.e. *.py or *.js) and executed there.
It should be noted that neither the Python package manager PIP nor the Node.js package manager NPM are available on the RMG/941C. These tools are not suitable for use in embedded systems, since otherwise, the control over the components and thus the integrity of the file system can be lost.
This graphical development tool with integrated runtime environment can also be classified as an interpreter language, because Node.js is used to execute the Node-RED flows.
The Node-RED-internal Palette Manager for the subsequent installation of further nodes cannot be used on the RMG/941C either, because the respective dependencies can cause various problems in the file system of the embedded Linux, analogous to PIP and NPM.
An In-System MQTT broker (ISMB) is available for communication between the individual applications. It enables the applications isolated in individual processes to exchange data bidirectionally via MQTT. The ISMB can be reached via the IP address 127.0.0.1 (local host) and the TCP port 7883.
Via ISMB, for example, a Python application for CAN data acquisition can communicate with a Node-RED application. A possible use case would be a Node-RED dashboard as a user interface to send configuration data to the Python application.
An introduction to the SDKs including links to the required resources can be found on SSV's GitHub page: SDK's for the RMG/941C on GitHub
We also offer a one-hour on-demand webinar for getting started with these SDK's, which can be requested through our sales department.
Certain functions for the RMG/941C can also be easily and conveniently upgraded as an app via the configuration interface (SSV/WebUI), for example a node for Node-RED to connect an SQLite database.
The RMG/941CL can be used as an LTE router, for example to transfer data from a local area network (LAN) to another IP network, usually the Internet.
Thus, an RMG/941CL as LTE router enables local network devices to access the Internet and at the same time prevents access from the Internet to the local network by an internal firewall for security reasons.
When certain events occur, the controllers of our frequency inverters are to send measured values to a database server on the Internet via the PROFINET LAN interface.
The DNS name of this server is preconfigured in the inverters at the factory. Because of this, we only need Internet access via LAN.
The secure Internet connection for IoT applications is only established when required, either via the LAN interface or via the 4G mobile network (LTE), i.e. when an IoT application wants to send data via MQTT or HTTP request, for example.
The RMG/941CL itself is virtually invisible on the Internet and cannot be reached by other applications from the outside.
The assemblies of our maintenance contract customers transmit system messages, operating hour counters and level measurements for individual operating materials to an IoT service.
We use this to plan and coordinate maintenance appointments, spare part requirements and other types of service work.
A virtual private network (VPN) is a specially protected network environment that can only be accessed by systems prepared by special measures (e.g., by installing special drivers plus valid access certificates).
In practice, VPNs often use the Internet as a transport channel. The VPN protocols used in each case employ encryption, which enables tap-proof and tamper-proof communication between the VPN partners.
The CAN sensor technology of our systems includes a web-based configuration and monitoring dashboard that runs directly on site on the gateway and which our customers can access via the LAN interface using a web browser.
A highly secure VPN remote access option exists for our service via the Internet.
For testing and evaluation purposes, we put a simple OpenVPN server into a Docker container and published it on GitHub.
For the RMG/941C, a task-related OTA update agent is required that loads the updates from the server and transmits them, e.g., via ISO-TP (ISO 15765-2) to the individual CAN devices.
To ensure the necessary cybersecurity of such an OTA update solution, a public key infrastructure (PKI) with digital signatures is required.
An SSV Secure Device Update (SDU) server can be used as an update server for an OTA update solution.
On GitHub you can find an API description for the SDU server.
Our battery monitoring systems have an externally accessible CAN interface that can be used to program firmware binaries into the flash memory of the microcontrollers of these assemblies. Up until now, this update possibility is used by our service technicians with the help of a PC plus a USB-CAN adapter.
With the RMG/941C, we will automate this update task. In the future, a software agent on the gateway will detect that an update is available for a specific board, load the update file from the Internet and program it into the microcontroller's flash.
To use the CAN-over-IP bridge, two RMG/941C are required, on each of which the can2udp app must be installed.
The necessary settings during commissioning (CAN bit rate, UDP port, IP addresses) are made via the SSV/WebUI.
We have numerous CAN sensor networks for building automation in use in several buildings on our premises.
We would like to connect these individual CAN segments with each other using Ethernet LAN networks in order to be able to collect the data centrally.
The number of components in an automation landscape that communicate locally via MQTT is constantly increasing. However, the required MQTT broker is often operated in the IT world or on a high-end edge platform.
Using the RMG/941 internal Mosquitto MQTT broker and corresponding interface agents, the data of different protocols can be directly converted into MQTT topics and integrated into automation applications.
We have various assemblies in our plants that communicate via MQTT. However, the required broker is located in our IT. This now results in a security problem, since OT and IT form different network segments and are separated from each other via an intelligent firewall.
We need an MQTT broker directly on site in the plant. In addition, it would be desirable if we could also establish a connection between the CAN and Modbus interfaces of some control modules and the MQTT data points of our visualization.
By linking a RUL lifetime model with the periodic real-time sensor data of a UPS-system (uninterruptible power supply), the digital twin is able to determine the remaining time until a component fails and generate a service ticket when it falls below specific limits.
There are several methods in stochastics or statistics to determine the influence of different variables on the remaining lifetime of a physical object. These include for example, the Cox regression (Cox Proportional Hazards Regression) and the AFT model (AFT = Accelerated Failure Time).
We are a manufacturer of battery-based industrial USV-systems that are used as emergency power supplies in control cabinets. To increase the reliability of our USV-solutions, we want to offer our customers a fully automated monitoring service based on a digital twin.
In the past years, we have collected and evaluated sufficient life cycle data on our products with the aid of simple condition monitoring. Using mathematical RUL models (RUL = Remaining Useful Life), we are now able to predict relatively accurately the time remaining until the next maintenance date, taking into account the respective usage scenario.
| Single Board Computer | |
|---|---|
| Model | DIL/NetPC DNP/9535 |
| Processor | |
| Manufacturer / Type | Atmel ATSAM-A5D35 SoC |
| Clock speed | 528 MHz |
| Storage | |
| RAM | 256 MB SDRAM |
| Flash | 4 MB NOR |
| Storage medium | 1x internal SD-card holder |
| Interfaces | |
| Ethernet | 1x 10/100 Mbps (RJ45) |
| CAN I/Os | 1x CAN 2.0A/2.0B (screw terminal) supported bitrates (Kbps): 50/100/125/250/500/1000 |
| COM (service port) | 1x 6-pin connector |
| Antenna | 1x SMA interface for LTE/NB-IoT antenna |
| Special functions | |
| Real time clock (RTC) | 1x RTC with internal battery backup |
| Watchdog | 1x Timer watchdog (Hardware-based, Software-configurable) 1x Power supervisor (Hardware-based) |
| SIM-Card | 1x Holder for Mini-SIM-cards (accessible from the outside) |
| LTE-Modem (RMG/941L) | |
| Mobile radio standards | GSM/UMTS/HSPA+/LTE |
| Transfer rates | 100 Mbps max. download, 50 Mbps max. upload |
| Frequency bands | LTE: B1/B3/B5/B7/B8/B20 WCDMA: B1/B5/B8 GSM/GPRS: GSM850/GSM900/DCS1800/PCS1900 |
| Authentification | PAP, CHAP, CHAT, none |
| Supported APNs | Telekom, Vodafone, 02, E-Plus, user-defined |
| NB-IoT-Modem (RMG/941N) | |
| Mobile radio standards | GSM/LTE |
| Transfer rates LTE Cat M1 | 375 Kbps max. download, 375 Kbps max. upload |
| Transfer rates NB-IoT (LTE Cat NB1) | 32 Kbps max. download, 70 Kbps max. upload |
| Transfer rates GSM | GPRS: 107 Kbps max. download, 85,6 Kbps max. upload EDGE: 296 Kbps max. download, 236,8 Kbps max. upload |
| Frequency bands LTE Cat M1 | LTE FDD: B1/B2/B3/B4/B5/B8/B12(B17)/B13/B18/B19/B20/B26/B28 LTE TDD: B39 |
| Frequency bands NB-IoT (LTE Cat NB1) | LTE FDD: B1/B2/B3/B4/B5/B8/B12(B17)/B13/B18/B19/B20/B26/B28 |
| Frequency bands | GSM/GPRS: GSM850/GSM900/DCS1800/PCS1900 |
| Authentification | PAP, CHAP, none |
| Supported APNs | 1nce |
| Displays / control elements | |
| LEDs | 1x Power 1x System status (programmable) 2x LAN LED for Ethernet interface |
| Electrical characteristics | |
| Supply voltage | 11 .. 28 VDC from external power supply |
| Power consumption | < 15 W |
| Mechanical characteristics | |
| Protection | IP20 industrial housing for 35 mm DIN-rail |
| Mass | < 150 g |
| Dimensions | 112 mm x 100 mm x 22,5 mm |
| Operating temperature | 0 .. 60 °C |
| Storage temperature | -40 .. 85 °C |
| Standard and certificates | |
| EMC | CE |
| Environmental standards | RoHS, WEEE |
| Name | Description |
|---|---|
| RMG/941C | Without LTE modem, without antenna connection |
| RMG/941CL | With LTE modem and antenna, without SIM card |
| RMG/941CN | With NB-IoT modem, antenna, and preinstalled SIM card |
SSV SOFTWARE SYSTEMS
Dünenweg 5
30419 Hannover
Phone: +49(0)511 · 40 000-0
Fax: +49(0)511 · 40 000-40
© 2024 SSV SOFTWARE SYSTEMS GmbH. All rights reserved.
ISO 9001:2015
