Building systems that scale is becoming critically important as the power grid undergoes a rapid transformation to meet the challenge of renewables and climate change. Software architecture is crucial to scaling communications solutions for emerging applications like distributed energy resources (DERs). This blog post discusses how software architecture affects the scalability of communication protocols and provides performance data for our protocol offerings. Parallelism vs Concurrency The Internet experienced its largest growth in user base from 1995 to 2000.
Rust on Embedded Linux
We made the pragmatic decision early on to build our libraries on top of Tokio, which supports common operating systems like Linux, Windows, and MacOS. Although Rust can target bare metal, the async and library ecosystem for no_std is still rapidly evolving. Embedded Linux Despite this limitation, our libraries are still great for resource constrained environments by deploying on embedded Linux. Every release of our software includes pre-compiled libraries for popular embedded Linux architectures such as ARMv6/v7 and ARM-64.
We’ve released the 1.0.0 version of our Modbus library. This release adds a number of important items to make the library feature complete including: RTU (serial) support Secure Modbus - TLS support including the X.509 role extension handling Dynamically controllable protocol decoding C++ bindings API Stability The Rust community strictly adheres to the semver specification. Prior to 1.0, pretty much anything goes in terms of breaking changes. After 1.
We released the first external version (0.9.0) of our Rust-based DNP3 library about one year ago. Since then, our customers have deployed the library in production using all our available language bindings. During this time, there have been zero runtime failures reported in release versions. I’m proud of this simple fact. It indicates to me that we’ve made sound toolchain and engineering decisions. Our decision to use Rust for our next-gen libraries is paying dividends.
OpenDNP3 was released as open source over 10 years ago. This post describes where I believe the project has succeeded, where it hasn’t, and why Step Function I/O is using a different licensing model for our new libraries going forward. In many ways, OpenDNP3 has been a success. We are constantly learning of new companies that have successfully used the library to add DNP3 functionality to their product or service offering.
CVE-2020-10611 - RCE in a flawed DNP3 Implementation
S4x20 hosted the Pwn2Own Miami hacking competition this year, and one of the more interesting and impactful results was a bug chain leading to remote code execution (RCE) in the Triangle Microworks (TMW) SCADA Data Gateway. The Zero Day Initiative who puts on these competitions recently released a detailed writeup (and video) of the bugs and the exploit. Achieving code execution on the Triangle MicroWorks SCADA Data Gateway - details (and video!
Binding Rust to other languages safely and productively
When we made the decision to write our next generation of libraries in Rust, we knew we needed a solid approach for binding them to other languages. It may be some time before we have customers purchasing our libraries to use them in a Rust-only codebase. The majority of our customers will want to use the libraries in C/C++, .NET, or Java. Writing the core implementation in Rust means more productivity, fewer errors, and certain safety guarantees compared to writing it in C++.