OGC SCIRA Pilot Engineering Report

This engineering report (ER) captures Smart City Interoperability Reference Architecture (SCIRA) Pilot implementation outcomes and findings to demonstrate the risk mitigation and safety capability of the SCIRA interoperable and standard-based architecture. SCIRA Pilot is an OGC (Open Geospatial Consortium) Innovation Program project sponsored by the US Department of Homeland Security (DHS) Science & Technology (S&T) in collaboration with the city of St. Louis, Missouri. The purpose of this project is to advance standards for smart and safe cities and develop open, interoperable design patterns for incorporating the Internet of Things (IoT) sensors into city services.

A lack of consensus on both common terminology and smart city architectural principles can result in divergent, proprietary and even contradictory specifications. Often, they fail to provide sufficient interoperability and scalability of the underlying IoT, and Cyber-Physical Systems (CPS) technologies to provide a suitable foundation for many smart cities applications.

SCIRA provides free deployment guides, a reusable design toolkit, and other resources to plan, acquire, and implement standards-based, cost-effective, vendor-agnostic, and future-proof smart city Information Technology (IT) systems and networks using technologies such as IoT, Sensor webs, and Geospatial frameworks. The objective of this Pilot is to research, design, and test the SCIRA as a reusable design toolkit that shows how to integrate proprietary IoT sensors into a common framework for public safety applications at the community level.

This Pilot focused on the City of St. Louis, Missouri to refine elements of interoperable smart city architecture through implementation and testing in functional, ‘real world’ public safety scenarios. The SCIRA Pilot concluded with on-site exercises and then a demonstration intended to establish a reusable example of SCIRA-based deployment. The operational application of the SCIRA design toolkit showed how cities can reap the benefits of standards-based interoperability.

The following normative documents are referenced in this document.

All other references are listed in the bibliography.

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

The SCIRA Pilot includes various stakeholders, applications (App), data clouds and operational field sensors. A schematic overview of the SCIRA Pilot is shown in the following figure (Figure 1):

As shown in the above figure, the SCIRA Pilot systems are roughly divided into four segments:

The overall prototype system has been divided into six individual systems (listed in Table 1) that, while sharing some components, deliver distinct sets of functionality. In the second column, the list of deliverables from the SCIRA Pilot Call For Participation.

This ER is organized as follows:

The Solutions Architecture describes the use cases, scenarios and interfaces for the components developed and implemented for the SCIRA Pilot. This section provides a reference architecture to guide future implementations of Smart Cities and demonstrate the interoperability achievable using OGC standards. The St. Louis Pilot solution architecture, while specific to the St. Louis, MO municipality, constitutes many stakeholders and human interactions with redundant service implementations to provide sufficient confidence in the standards applied.

SmartHub systems center around supporting, accessing, and connecting body-worn sensors with personal applications, as well as incident scene and Emergency Operations Center information resources. Further background on SmartHub systems is found in the Next Generation First Responder (NGFR) Integration Handbook. The wiring of a SmartHub system is shown in the figure below (Figure 14):

The OGC® Sensor Web Enablement (SWE) and OGC® SensorThings API (Application Programming Interface) standards were both used in the SCIRA Pilot in support of the SensorHub. These standards provide an interoperable approach in support of virtually any sensor system. In essence, the suite of OGC® SWE and OGC® SensorThings API (STA) standards provide standard means for the discovery of sensors, tasking sensors and actuators, requesting robust descriptions of sensors and sensor observations, and for accessing real-time or archived observations and messages. Those standards can support sensor systems in a Cloud environment, within a field hub, or as part of the sensor itself or on the sensor platform ("on-the-edge").

OGC® SWE and OGC® STA standards can support the insertion of sensors and sensor observations through transactional mechanisms, thereby allowing small apps on the edge to push observations to sensor hubs residing in the cloud or on a field node. Some implementations of the OGC® SWE and OGC® STA standards enable the complete deployment of a SensorHub within any environment. One such implementation is OpenSensorHub (OSH) an open source software platform supporting OGC® SWE and OGC® SensorThings API standards. As depicted in the figure below (Figure 15), OSH can be fully deployed at all levels of the sensor environment, from the sensor or sensor platform itself to Android phones and tablets, to local workstations, and to the Cloud. This means that all functionality of the OSH platform, from storage, processing, real-time streaming of observations, and tasking of sensors can be supported on any of these devices.

Within the DHS domain, the SensorHub domain is often divided into three main components:

1) First Responder SmartHub: the personal mobile sensor hub, sometimes referred to as a SmartHub;

2) First Responder Incident SensorHub: the incident field hub domain supported by perhaps a laptop or desktop within a local network;

3) Cloud-based SensorHub & Catalog: the enterprise-level deployed in the Cloud.

Often there are restrictions in the network bandwidth within these three domains such that Cloud deployments support the widest breadth of connectivity and available resources. The incident field hubs support a local network shared with local devices (sensors, databases, and etc.) but may have limits to its connectivity to Cloud resources. Finally, the personal SmartHub may be body-worn, support sensors that are personal to the wearer (e.g., location, heartbeat, body-cam, and etc.), and may be limited in connectivity with a local team or squad. In some cases, the amount of data exchanged in real-time between these three domains may be limited, and may be configured to get only the most relevant data up to the Cloud or incident hub. Other times, connectivity may not be a challenge at all, allowing for complete exchange of observations between any parties who desire it.