Systems Engineering
When it comes to make industrial automation equipment even smarter and more intelligent, the ability to post notifications in case of a failure is indispensable. Most modern PLCs, which are available nowadays, support this feature and can send mails using an SMTP server. This is also the case for the Controllino Maxi & Controllino Mega, the mail server settings can be set easily in a simple C++ function. The function can be called whenever an event occurs.
To make mail transfer easier and more controllable it is recommended to use an internal mail gateway instead of connecting the Controllino to the internet directly. In this post I will show you everything you need to know to enable your Arduino/Controllino to send e-mails using a local mail gateway. This post covers:
- Setting up a mail gateway based on Embedded Linux (OpenWrt)
- Programming/Configuring a Controllino/Arduino to send mails via the smtp gateway
When it comes to make industrial automation equipment even smarter and more intelligent, the ability to post notifications in case of a failure is indispensable. Most modern PLCs, which are available nowadays, support this feature and can send mails using an SMTP server. This is also the case for the Siemens Simatic S7-1200 CPU, the mail server settings can be set easily using a function block. When the user program is running, a rising edge will trigger the function and the PLC posts a message to the SMTP server.
This is the basic idea, but -- as you may have guessed -- we have to cope with some limitations. Some compact PLCs (including the Simatic S7-1200) support mail servers listening on port 25 (SMTP) only. And this is where the trouble comes in:
- SMTP/25 is used for unencrypted (plain text) communication between the SMTP client and server
- plain text communication is undesired (and is bad practice, just don't do it) in public networks, such as the internet
- SMTP/25 would expose your credentials (username, password, message, etc.) to someone sniffing the traffic
- these are the reasons why most (serious) public e-mail providers do not accept SMTP on port 25, they block this port or do not listen on it
To circumvent the limitations described above, we need to extend our project, to ensure a secure and reliable solution in the end.
Recently, I bought a 7" touch screen from 4D Systems (4DCAPE-70T) for my Beaglebone Black to use it in a new project. I really like this one, because it is designed as a cape, you just mount the Beaglebone beneath it and that's it. It is automatically recognized by the OS (I prepared the BBB with Debian 9.3) and also the touchscreen is working out of the box. At least, this is what I have thougt. It turned out that the touchscreen calibration is not as easy as expected, not because the "process itself" is complicated, rather the required information is potentially hard to find. This is also the reason why I am writing this down here, it is intended to be a reminder for myself rather than something spectacular.
Mbedtls provides functions to access symmetric and asymmetric cryptography algorithms, it is licensed under GPLv2 and Apache 2 License and is maintained by ARM mbed. The library does not have any external dependencies, the compiled binary has a size of 60 KB and requires only 64 KB RAM when executed. This makes it an ideal solution to run on a bare-metal embedded system, such as the Arduino Primo (nRF52832).
Mbedtls needs to be configured for the target, this can be done by deactivating platform unsupported build options. The following configuration options were disabled, because the corresponding (hardware) modules are not present on the traget platform (ARM-based Arduinos): MBEDTLS_NET_C, MBEDTLS_TIMING_C, MBEDTLS_ENTROPY_PLATFORM, MBEDTLS_FS_IO, MBEDTLS_HAVE_TIME_DATE, MBEDTLS_HAVE_TIME
MBEDTLS_NET_C requires the BSD sockets API, which is obviously not present on a bare-metal system. MBEDTLS_TIMING_C, MBEDTLS_HAVE_TIME\_DATE, MBEDTLS_HAVE_TIME need to be deactivated because no RTC is present. MBEDTLS_FS_IO is also not available because a POSIX like filesystem is not present on the Arduinos. MBEDTLS_ENTROPY_PLATFORM is important for random number generation but must be deactivated because it implements a POSIX API and uses /dev/urandom as a seed, which is not present on the Arduino (and on other bare-metal embedded systems). When a RNG (random number generator) is important for the project it must be implemented differently. A lot of ARM based microcontrollers provide embedded hardware RNGs. See my other blogpost to make use of the Arduino Primo RNG.
The Arduino Primo is a quite new board which was introduced by arduino.org and delivers a wide range for sensor networks, IoT applications and prototyping.
It features three microcontrollers:
- nRF52832 - by Nordic Semiconductor
- ESP8266 - by Espressif
- STM32f103 - by STMicroelectronics
The nRF52832 is used as the main CPU for program execution, it includes BLE and NFC hardware for communication. WiFi is managed by the ESP8266 CPU, which can be used with the provided libraries. The STM32f103 is used as a service microcontroller and is therefore responsible for flashing the executable onto the previous named CPUs and allows extended debugging. Additionally it features a connected infrared receiver and transmitter. Beside the obvious possibilities of peripheral interconnections the nRF52832 offers more benefit for wireless sensor networks and security related applications. It has an integrated hardware Random Number Generator (RNG) whose output is suitable for cryptographic tasks. A hardware implementation of the Advanced Encryption Standard in Electronic Code Book working mode (AES-ECB) and AES-CCM is also available. Real-time applications will benefit from the integrated Real-Time-Counter.
