SUBSCRIBE NOW
IN THIS ISSUE
PIPELINE RESOURCES

Advancing Public Safety with IoT Interoperability

By: Ken Figueredo

Many Internet of Things (IoT) systems solve a single problem. They are designed as standalone or one-off solutions because organizations are often under pressure to deploy a solution quickly. As a result, it is easier to adapt an existing system by bolting on the components that enable connectivity, for remote access and data gathering, and linking to a cloud-based data management system for analytics and visualization purposes. During the design phase, it is also easy to overlook how such a system might evolve or be supported in a lifecycle sense.

By way of example, take the case of a public safety scenario that involves the dispatch of alerts to citizens and business organizations. This may involve routine warnings about air-quality issues or disruptions to public transport services. There may also be highly localized emergency alerts, triggered by gunshot or ground-tremor sensors. The mix of information types and urgency of alerts presents a complex technical and operational challenge. One reason is due to the variety of connected sensors, automated equipment, and information display devices. Each of these represents an integration point to bridge proprietary technologies or to combine equipment from different vendors. It is therefore not surprising that many public-safety systems focus on single-purpose solutions, missing opportunities to design for cross-silo collaboration and interoperable services.

Beyond issues of technology, there might be operational complications because many different parties, and their respective systems, are involved. This is true even in simple scenarios. A road traffic incident might trigger an alert from a traffic flow sensor, for example. Other alarms might come from closed circuit television (CCTV) monitors, from in-vehicle emergency call systems and through social media reports from the traveling public. Each reporting channel belongs to a different service provider, adding to the systems integration challenge. For example, a simple system might begin with the infrastructure managed by public-sector, road transport agencies. One improvement could involve the addition of data from vehicle telematics service providers. Another would integrate live data from radio broadcasters and social media platforms. This progression illustrates the need to work with a growing number of data sources and their respective service providers.

General-purpose IoT systems

The public safety scenario points to the need for standardized communications and interactions between IoT devices, sensors, and data-processing applications. These involve many types of endpoint devices, gateways or edge nodes and servers. In all likelihood, they will be supplied by different developers and manufacturers and operate over multiple communications networks. There are also likely to be many users, some supplying data, and others consuming data for monitoring and decision-making purposes. This is not an uncommon scenario. The pattern comes up time and again in applications related to smart cities, industrial processing sites, multi-tenant buildings and transportation hubs.

Where there is a need to support multiple IoT applications, there are benefits in sharing infrastructure and data. Over time, the opportunities for innovation will encourage interactions across commercial, operational, and technical silos. One way to characterize this situation is via a general-purpose framework that allows for any-to-any interactions between technologies, suppliers, and users. As proven by the success of the mobile and Internet industries, standardization is a key ingredient in making such arrangements work.

Horizontal architecture and oneM2M standardization

In 2012, a group of national standardization bodies launched the oneM2M standardization initiative to establish a standard for end-to-end and interoperable IoT systems. These bodies wanted to avoid regional fragmentation and promote a global IoT market comparable with the mobile telecommunications industry.

The oneM2M standard addresses situations where one or more IoT applications consume data from devices and sensors associated with each application. Some of these are managed via a gateway, or edge-processing device, over a local network. Others involve direct communications between devices and applications through an intermediary platform. oneM2M defines a three-layer, horizontal architecture. The lower layer corresponds to devices and communications technologies. The upper layer corresponds to applications that process data from IoT devices and sensors for decision-making and control interventions. oneM2M’s technical specifications specify the common service elements that go into the middleware layer.

One way to think about these common services is as a set of technical tools that application developers can use to design and deploy IoT systems. Many of these tools are common to all IoT applications. Take the example of the registration tool. A developer could use this tool to establish the authorization and authentication relationships between different device, gateway, platform, and application entities in an IoT system.


FEATURED

Latest Updates





Subscribe to our YouTube Channel