Eclipse UPM

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.