Internet of Things
Why IoT systems need global and extensible standards
By Ken Figueredo, senior representative at oneM2M
B
y casting a spotlight on supply chain resilience, the current pandemic has highlighted the importance of remote monitoring capabilities and analytical insights using live data from connected objects. There has also been a shift in attitudes with business leaders valuing the benefits of engineering internet of things (IoT) technologies in industrial, supply- chain and transportation systems. However, a widespread appetite for change does not guarantee that organizations will make superior design choices. Many will fall to the temptation of bolt-on or quick-to- implement solutions rather than taking a systematic and long-term view of the firm’s wider requirements. For the latter to happen, each organization needs to frame its requirements through the following question. What is the best way to introduce IoT progressively into the operational environment, building its IoT capabilities and analytics skill sets, while enabling interoperability with supply-chain partners and between technologies from different vendors? This is a system-of-systems challenge that evolves over time as new applications and business partners are added to the mix. It is also one where open standardization offers long-term benefits and mitigates lock-in risks.
The journey from simple to complex IoT systems
A basic IoT system consists of several elements. Its technology stack includes devices and sensors, local and wide-area connectivity networks and, gateway or cloud- server platforms for managing communications. Elements higher up the stack include platform capabilities to transfer data and to handle actions triggered by applications. Buried in the technology stack are different approaches for transporting small data payloads and different schemes for representing data and information models. This combination of elements is required to build one application. It does not
www.cieonline.co.uk
deal with the elements that enable cross-silo interoperability between several IoT applications as might exist in a smart city or an intelligent factory, for example. Given these design parameters, it is no surprise that complexity and fragmentation are two barriers to adoption. To compound matters, growing interest in the IoT sector means an expanding supplier base which adds to industry fragmentation. To reduce implementation friction, many IoT solution providers operate partner ecosystems. They rely on systems integration approaches to build and deploy individual solutions.
device or data source to a network. The second is transport IoT data to an application, via a gateway or server, for analytical and decision-making purposes. A single-purpose connectivity approach is to develop software for cellular network technologies. There could be other variants for Bluetooth and Wi-Fi connectivity. Likewise, a developer might implement the CoAP protocol to transport IoT data. Other versions of this software might handle HTTPS, MQTT and WebSockets protocols.
A different approach is to develop a set of services to manage commonly occurring
and connectivity technologies. Middleware communications use a common API between applications, devices, and network connectivity technologies. The middleware comprises an extensible toolkit of common services. Developers can use as many services in this toolkit as needed, depending on the requirements for any given use-case. oneM2M operates on a release cycle, regularly updating its technical specifications and adding capabilities to address the needs arising from innovative use-cases and evolving market requirements. oneM2M’s impending Release 4 specifications will add
Unfortunately, as the number of permutations starts to rise, integration becomes another challenge.
A different approach is to work back from a generalised framework for end-to-end IoT systems. This framework should contain all the building blocks for simple as well as complex IoT systems. Similar to LEGO bricks, it relies on standardization to link individual elements into an overall solution. An open standard approach also caters for vendor interoperability. As the mobile communications industry has demonstrated, this approach can foster a competitive supply-side industry and deliver economies of scale. As a result, improved affordability drives adoption and innovation.
A toolkit of services for developer use There are two basic and recurring activities in building IoT systems. One is to connect a
processes. For example, an application developer could use a ‘Communication Management’ service, which covers a super- set of several different communications technologies. This service masks the complexity of each lower-level technology. The end result is that the developer can reuse the one ‘service’ to build solutions that might rely on different communications media. They can also re-use that service when building a second or third IoT system, minimizing the learning process and allowing IoT developers to focus their efforts on application logic issues where most value is created. The strategy of offering developers a suite of common and reusable services to manage different parts of the IoT stack is central to the oneM2M standard. oneM2M accomplishes this through an architecture that defines a middleware capability. This resides between an upper IoT application layer, and a lower layer comprising devices
three new common service functions to the existing family of fourteen.
Not everything about oneM2M is new. To avoid re-invention, oneM2M re-uses established industry standards, enhancing the utility of several legacy technologies. For example, a developer might combine cellular connectivity with oneM2M’s security service (which offers a choice of DTLS, TLS, PSK, PKI options), communication management service (HTTPS, CoAP, MQTT, WebSockets options) and device management service (OCF, LWM2M, Thread options). In this way, a few standardized services support a huge range of new and established technology stack permutations. This shrinks the learning hurdle for developer teams while allowing organizations to work with multiple vendors to enable interoperability and to mitigate supplier lock-in risks.
www.onem2m.org Components in Electronics October 2021 33
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54
