Current day computing systems and devices distinguish themselves from past generation systems through autonomy, less user intervention. While the emergence of autonomous systems may be less relevant in the workstation space, due to the nature of computing on such systems, it is significant in the growth of Internet of Things (IoT) devices. Regardless of the use case, autonomous systems surface, from basic process automation to smart decision making systems, with the latter expressed as artificial intelligence (AI) or machine learning (ML). The current crop of single board computers (SBCs) running Linux* distributions generally show the benefits of deploying such algorithms. Often these SBCS support acceleration cards when additional performance is required. Most importantly, the boards connect to the sensors and actuators that produce the required data needed in developing smart IoT devices and solutions.
Application developers encounter difficulty in harvesting meaningful sensor data. In general, as the complexity of the sensing or actuating device increases, the number of steps required to obtain data readings increases. Peripherals directly connected to the system follow vendor specifications for basic I/O and bus level transactions. Dealing with wireless sensors is a twofold issue. First, support must exist in the system for the modem or radio implementing the technology. Second, the system must expose a sensor data collection interface at a software level, using the stack or protocol associated with the technology. In practice, support manifests as an API abstraction layer or the showcase of usage through clear device-specific examples.
The number of devices available nowadays is astounding, with tens of thousands of devices made available through popular suppliers, manufacturers, and vendors. These sensors fall within multiple well-defined categories that in some cases have been standardized for specific application areas or industries. The standards usually specify the sensor data formats and often leave the implementation choice to the developer, who is responsible for interfacing with the sensor devices and creating support for common, legacy networks.
For OEMs, ODMs, and established consumer products, firmware and system drivers offer sensing device access. However, this support results in rather slow turnaround in the operating system (OS) realm and does not address development difficulties around building new or custom IoT systems and solutions.
These problems give rise to a need for an abstraction layer for sensor data access that can simplify the developer effort required and reduce implementation time at all stages of an IoT product, from prototyping to deployments. An abstraction layer could speed up commercial/industrial application development.
Useful Packages for MRAA (UPM) is a user space collection of sensor and actuator libraries written in the C/C++ language. The Eclipse UPM project abstracts implementation details for reading sensor data and writing actuator commands through the use of consistent APIs and function names. The project focuses on multiple key features:
- Standardization of sensor classes: UPM standardizes sensor and actuator APIs based on type in order to create consistency between devices and vendors. The meaningful sensor data make it easy to consolidate data readings into other standardized frameworks and services.
- Portability and scalability: Applications using the UPM libraries are portable across any MRAA supported platform offering the same I/O capabilities with little or no changes required. UPM promotes scaling to different IoT systems if computational requirements for the application change.
- Industrial sensor and protocol support: UPM provides rich device and API abstractions for multiple industrial and wireless protocols such as BACnet*, Modbus*, CAN bus*, LoRa*, Zigbee* and Z‑Wave*. Nearly half of the devices currently on the UPM list are complex industrial-rated sensors, actuators, and radios.
- Solution design reliability: The UPM library doesn’t lock down application development to a single vendor for popular sensor types. When multiple vendors provide the same type of sensor, the generic UPM interfaces enable hardware replacement with little or no API changes.
- Device utilization examples: Every sensor driver in the UPM library comes with at least one usage example. They are generally provided for all the supported languages. Examples showcase initial device configuration and calibration where applicable.
IoT is a multi-faceted topic, seen by many as a much-needed redefinition of embedded computing. The efficiency and performance of current CPUs, along with a decreasing footprint, enable broader products and solutions across multiple domains, such as home, industrial automation, environment, agriculture, transportation, safety, security, control systems, robotics, wireless sensor networks, and wearables. Sensing devices manifest in various categories and applications. They are very easy to obtain, and they interface to open-chassis IoT boards or even I/O rich workstation systems. However, application developers and solution architects encounter unnecessary difficulty when programming these devices. Developers must consult vendor specification sheets and comprehend intricate protocols to read or write data to sensor devices in the absence of device driver support in the OS. This added burden results in multiple system level calls to different I/O protocols. It requires access to fast mathematical and utility functions that help convert readings to meaningful sensor data. To address the developer experience (DX) problem, the MRAA project provides easy platform-independent I/O access from the application level for Linux* IoT boards.
The Eclipse UPM project builds on the solutions of MRAA. While the MRAA project provides an abstraction layer for several IoT platforms, offering developer access to the physical pins and buses, UPM supplies developers with C/C++ sensor libraries with bindings to Java*, JavaScript* and Python*. UPM makes it easier to interface with the sensors bundled with the Intel® IoT Developer Kits and extends the MRAA library. The UPM sensor libraries use MRAA I/O classes in order to expose an API abstraction that simplifies the interaction between developers and peripherals. The UPM APIs provide consistent, standardized access to the supported devices with over 400 different sensors, actuators and radio modules currently supported.
An example illustrates the application of UPM. Imagine a design that requires a temperature and humidity sensor. UPM supports dozens of such devices, offering multiple connectivity options to the system, either directly through I/Os or wirelessly. This creates plenty of design choices. Once the application is developed, the code looks similar regardless of the sensor chosen. The task of reading temperature and humidity data remains identical, using the same consistently named function calls. The implementation and underlying sensor data access may vary based on the I/O type used, but the UPM APIs remain the same. This is the value added by the UPM abstraction. Furthermore, if the sensor part needs to change at a later stage in the design, the API standardization ensures that application changes remain minimal, leading to product reliability in the long run when components or suppliers may change.
When the UPM project started, the goal was to provide easy access to the most popular maker and hobbyist grade devices in the market. These are common types of sensors and actuators encountered at many IoT-oriented gatherings and events. Quickly the project started delivering on its goal and enabled hundreds of devices, some of which were generic in nature and design. Supporting these generic devices led to virtually supporting thousands of similar or related parts across vendors. Some of the first vendors in this category were Adafruit*, SparkFun*, Seeed Studio*, and DFRobot*. In many cases maker-oriented sensor breakout boards include ICs that have commercial or industrial variants. This allows for quick prototyping and an early start on application development as well as design validation well before a commercial product is finalized.
Recently, the UPM project has aimed its focus on the more specialized devices typically found in commercial and industrial deployments. These include various controllers and actuators, high precision and ruggedized sensors, along with several established and emerging radio devices or M2M protocol interfaces in use throughout IoT deployments worldwide. For instance, UPM saw plenty of adoption for IoT projects requiring LoRa* or 4G LTE connectivity, providing the opportunity to create a common interface for radio devices and modems. At this level, standardization is critical, since many established protocols and frameworks are already in use. The UPM project adds the needed abstraction to facilitate development time with these technologies. Some of the IoT chip manufacturers with devices supported by the UPM project include Bosch*, STMicroelectronics*, Honeywell*, Semtech*, Microchip Technology*, Maxim Integrated*, NXP Semiconductors*, Measurement Technologies*, Silicon Labs*, Analog Devices*, Aeotec*, Telit Communications*, Veris Industries*, Comet*, Omega*, and several others. Protocols and technologies supported include Modbus*, BACnet*, CAN bus*, WiFi*, BLE*, LoRa*, Zigbee*, Z‑Wave*, NFC*, GPS*, GPRS*, 4G LTE*, and LiDAR*, with planned support for others. For standards that are higher up the application stack, the project provides several integration examples that use UPM within OPC-UA or OCF (e.g., IoTivity*) solutions.
Find a comprehensive summary of UPM at Bring Your IOT Products to Life.
Figure 1. High-level layout of the UPM project.
As Figure 1 shows, the scope of the UPM project is vast and diverse. In order to help organize the various sensor and actuator types the UPM project recently introduced a highly flexibly sensor specifier based on JavaScript* Object Notation (JSON). This feature allows vendors to provide detailed information about the part, technical specifications, limits, links to reference documentation, and more. The field values can be exposed back to the developer through the UPM APIs to make decisions at runtime. They are also used by the upm-site project to generate the UPM sensor catalogue which helps solution architects choose the right components during the design phase. The project was created with an open-source mindset. OEMs. ODMs, and contributors benefit from a sensor template that generates code stubs, speeding up the process of a new sensor submission. On the Intel® Developer Zone website, Technical IoT Webinars explain how the UPM project is designed and used as well as how it can be extended.
A hard build and run-time dependency exists between the MRAA and UPM projects. The UPM project has few dependencies on other system packages, the most notable being the SWIG source translation framework. SWIG is necessary if bindings for other supported languages are desired. Other 3rd party library build dependencies are reflected at a module level and are optional. The supported Operating Systems are:
- Standard Linux* Distributions: Fedora*, Debian*, Ubuntu*, Ubilinux*, Arch Linux*, OpenSUSE*
- Embedded Linux* Distributions and Projects: Yocto Project*, OpenEmbedded, 01.org, Wind River Linux*, Wind River Pulsar Linux*, Android Things*
- Real-time Embedded OS: Zephyr*
- Windows*: Only using Docker* containers and the mock platform
Contributions are checked through the use of the Travis CI system, unit testing, and static code analysis. Packaging is done on demand on stable releases only. The community maintains most of the distribution channels for the supported OSs listed above.
Code contributors must provide examples, as a minimum requirement for valid code contributions, for every sensor or actuator library that is added to the UPM project. They are also used in the validation of the devices, and in most cases, supply developers with an easy to understand use case. When relevant, examples also include device calibration information or showcase configuration options. Multiple advanced examples based on the UPM project exist as full end-to-end open-source reference implementations. These implementations, part of the Intel® IoT Developer Kit, interweave numerous IoT frameworks, bringing them together in a solution with real world applications.
The documentation pages for the UPM project are customized, and there are two auto-generators associated with the project. A Doxygen* system generates API documentation in all supported languages based on code comments and special sensor tags that help group sensors by categories. The second documentation source is a GitHub* Pages website used as the main landing site for the project. This relies on the JSON sensor specification files to provide an open source, catalog style website template for sensor and actuator manufacturers to freely customize to their end user needs.
Figure 2. UPM integration with the Eclipse IDE.
A proven strong integration point for the UPM project is with the Eclipse* IDE. Used by Intel® System Studio, the UPM sensor libraries offer developers the ability to quickly add or remove components from the supported libraries to their current C++ or Java* IoT project. The documentation pages, sensor images where available, manufacturer and vendor product links, technical datasheets, and examples quickly become available through the Sensor Support tab in the Eclipse* IDE. Behind the scenes, automation updates projects settings for developers based on their selections, and the view is dynamically generated from the latest stable published version of the project.
Over the course of 2017, the project saw over 18K unique visitors and approximately 6K unique downloads according to GitHub* metrics. Good adoption occurred internally at Intel and externally by key companies and frameworks, such as IBM* (node-red), Linaro*/ARM* (96boards), Google* (Android Things*), Emutex* (Ubilinux*), Phytec*, GE*, Technexion*, Qualcomm*, STMicroelectonics*, u-blox*, Honeywell*, Siemens* (IOT2020), Mediatek*, and many others.
The project is still under active development by Intel and the developer community. There is a tight integration with the IoT application developer workflows and the sensor explorer in Intel® System Studio. UPM is also a key component of the OS images provided for IoT Developer Kits.
*Other names and brands may be claimed as the property of others.
We believe the UPM project exhibits great potential for integration with the Eclipse Kura* project and it would be a suitable choice for providing sensor and actuator access to end users. There is good synergy with multiple Eclipse* IoT projects such as Eclipse Mosquitto*, Eclipse Paho*, Eclipse Milo*, and other M2M projects. In fact, several Intel® IoT Developer Kit demos use UPM and the Eclipse* MQTT frameworks for aggregating sensor data across the web. Combined, they provide the ultimate IoT toolbox for end users to develop new end-to-end IoT solutions or extend existing ones.
Furthermore, there is a good integration between UPM and the Intel® System Studio, a free product that integrates multiple Intel® tools and libraries with the Eclipse* IDE. The UPM library covers sensors and actuators from numerous device manufacturers. The Eclipse Foundation* would encourage vendor neutrality and act as an arbiter during further development of the project.
Figure 3. Sensor framework.
The UPM project was publicly released under the MIT license.
The project contains images owned by Seeed Studio*, Adafruit*, and DFRobot* used with written permission for documentation, the upm.mraa.io open-source GitHub* Pages website (upm-site project), and the sensor explorer component in Intel® System Studio.
Images from SparkFun* are offered under CC-NA 2.0 and marked as such in the corresponding sensor libraries they show.
During the initial phases, the project pushed stable iterations of the framework to the general public at a fast pace, as new features and bug fixes were constantly becoming available. Currently, the release cadence has settled at two major releases per year, which include community contributions and fixes along with planned features and milestones from the project’s roadmap.
Library development plans for the upcoming quarters are illustrated in Figure 4.
Figure 4. Future UPM development.
Intel plans to continue submitting code improvements for the sensors bundled with the Intel® IoT Developer Kit. Future releases may involve these features:
- More standardized interfaces: Over several past months, the UPM project focused on delivering an enhanced set of refinements to the APIs and more generic sensor and actuator support within the APIs. The current number of interfaces will extend from 10 to approximately 30. Adding these to the project’s codebase will increase the likelihood of a stable 2.0 release.
- New industrial protocol support: For aiding industrial and commercial development with UPM, several examples of interaction with the open62541* framework have been developed and included. The examples can be used as means for adding an OPC-UA utility class to UPM. This example or a potential integration with Eclipse Milo* can enhance standard support directly from the UPM project. Upon completion, new protocol support should follow to help integrate with more existing IoT solutions.
- Generic abstraction for modems and radios: The project is investigating a more generic interface for radio and modem devices, as the ones currently supported by the project are rather custom. This along with the potential of adding some abstraction to PLC devices is planned following the next major release.
UPM latest source code base as available at https://github.com/intel-iot-devkit/upm.
UPM latest sources for the https://upm.mraa.io GitHub* Pages website: https://github.com/intel-iot-devkit/upm-site.
Intel® owns the copyright on approximately 90% of the library’s functional source code. This excludes 3rd party modules, collateral, integrations, tools and other supporting files that are included with the project.
The project includes 3rd party content under the following associated licenses:
- Adafruit* Sensor Board Image License
- DFRobot* Images License
- Seeed* Sensor Image License
- Creative Commons Attribution 2.0
- Boost Software License 1.0
- BSD 2-clause "Simplified" License
- BSD 3-clause "New" or "Revised" License
- MIT License
- Log in to post comments