In the first two posts of this three-part series, we looked at the current state of open source offerings in the IoT space and then described a proof of concept automotive IoT solution.
While satisfying in many ways, the task highlighted the need for IoT frameworks that handled common tasks such as software updates, device registration, advanced networking features like network microsegmentation and Quality of Service, and more security. In this blog, we’ll share how we plan to extend EdgeX Foundry in addition to how our Automotive IoT Samples may be used for teaching purposes.
Enhancing EdgeX Foundry:
- Our team will be contributing two new device models for the OBD and GPS sensors.
- Further, crucial for mobile IoT applications is the ability to handle intermittent network connectivity, either because it is congested, unreliable or too costly. This could be supported with a combination of local data persistence and data export retry loops.
- EdgeX has more recently incorporated a data persistence abstraction layer to support the use of different storage solutions based on user needs and preferences. This enables the use of a simple filesystem as in the sample edge solution we engineered.
- Integration with Precaution to catch security anti-patterns at code pre-commit time.
- Power-off and time. Oftentimes edge nodes may be powered-off to conserve power. When they come back up, their time needs to be synchronized with the network. On GPS-enabled devices, the GPS should be used as the time source. We are considering supporting the same when GPS is available.
- More use of read-only container volumes to ensure no tampering of configuration values.
- Lighter-weight Rules Engine. The current Java-based rules engine significantly adds to the code footprint when compared to the other golang based components. While not pressing, replacing it with something leaner will ensure support for small form factor edge nodes.
EdgeX supports encrypted storage and configuration, which lends itself well to the automotive IoT needs of handling configuration data such as vehicle ownership, safety thresholds and cloud endpoints.
The Sample as a Teaching Tool
The sample code, even as it demonstrates the automotive IoT use case, begs for more test cases and documentation, handled corner cases, increased security and additional domain knowledge to capture more events of interest. Further speed limits typically vary along a route. A caching mechanism to save speed limits along oft-used routes would enable providing feedback to the driver without constant network connectivity, in addition to reducing the cost of using Speed/GPS API services from third-party vendors. Last but not least, we never handled any actuation, such as emitting a beep should the vehicle be speeding.
Students could enhance the web user interface, address input validation before inserting any data in the database, specify firewall rules to prevent denial of service attacks at the cloud application and more. We list several learning/teaching opportunities in the context of the code/application, spanning container technology, security, user interfaces and IoT at Teaching Vehicle. Do also consider contributing your data from a drive as well.
We hope to have piqued your interest in open source IoT and that you might want to contribute to EdgeX Foundry. If you are a teacher, we welcome you to explore the sample code and use it with your class. Do reach out to us if you have questions.
Stay tuned to the Open Source Blog and follow us on Twitter (@vmwopensource) for more on open source IoT.
