OGC SCIRA Public Safety Interoperability Pilot: Call for Participation (CFP)

OGC Pilots serve the role of testing and refining standards-based approaches to engineering and developing geospatial information systems. The SCIRA Pilot in particular is intended to prototype advances in public safety and reduction of risk through interoperable sharing of city data and flexible incorporation of inexpensive Web-connected sensors. The Pilot will run across multiple cities to refine elements of interoperable smart city architecture through implementation and testing in functional, ‘real world’ applications and services. This process of iterative refinement and interactive development will result in a reference architecture that is both feasible and effective for smaller municipalities to adopt. The pilot will also lead to improved deployment guides that reduce the risk that the reference architecture becomes simply ‘shelf-ware.’ Pilot participants will create prototype applications that help reduce implementation risks and illuminate usage opportunities for key parts of the architecture, while deployment guides updated from the pilot experience will provide to key Smart City staff useful, practical, and actionable direction that is consistent with the reference architecture.

The SCIRA Pilot will conclude with a demonstration intended to establish a reusable example of SCIRA-based deployment by demonstrating capabilities employed for a real-world scenario; the SCIRA trial deployment will show how cities can reap the benefits of standards-based interoperability. These benefits will be documented in public engineering reports as well as in refinement of the SCIRA architecture itself and accompanying deployment guides

The Smart City Interoperability Reference Architecture (SCIRA) is a project of the OGC Innovation Program. The project is sponsored by the US Department of Homeland Security (DHS), Science & Technology (S&T). The purpose of the SCIRA project is to advance standards for Smart Safe Cities and develop open, interoperable designs for incorporating Internet of Things (IoT) sensors into city services. SCIRA is providing free deployment guides, reusable design patterns, and other resources that municipalities can use to plan, acquire, and implement standards-based, cost-effective, vendor-agnostic, and future-proof Smart City IT systems and networks using technologies such as Internet of Things (IoT), Sensor Webs, and Geospatial Frameworks.

Lack of consensus on both common terminologies and smart city architectural principles can result in standards that are divergent, even contradictory. Often, they fail to provide sufficient interoperability and scalability of underlying Internet of Things (IoT), and Cyber-Physical Systems (CPS) technologies to provide a suitable foundation for many smart city applications. SCIRA has the objective to research, design, and test a Smart City Interoperability Reference Architecture (SCIRA) as a reusable design toolkit that shows how to integrate commercial proprietary IoT sensors into a common framework for public safety applications at the community level.

A clear characteristic of the Smart City enterprise and a significant challenge to the design of supporting information systems is the number and variety of stakeholders who need to be involved. This is even more the case with the SCIRA Pilot, where at least four groups of stakeholders are identified:

Concepts and concerns relevant to stakeholders include:

Engineering Reports (ER) and Change Requests (CR) will be prepared in accordance with OGC published templates. Engineering Reports will be delivered by posting on the (members-only) OGC Pending directory when each is complete and has achieved a satisfactory level of consensus among interested participants, contributors and editors. Engineering Reports are the formal mechanism used to deliver results of the Innovation Program to Sponsors and to the OGC Standards Program for consideration by way of Standards Working Groups and Domain Working Groups. NOTE: Participants delivering Engineering Reports should also deliver Change Requests that arise from the documented work.

Services, Clients, Datasets and Tools will be provided by methods suitable to their types and to stated requirements. For example, services and components (e.g. a Web Processing Service or WPS instance) are delivered by deployment of the service or component for use in the Initiative via an accessible URL. A Client software application or component may be used during the Initiative to exercise services and components to test and demonstrate interoperability; however, it is most often not delivered as a license for follow-on usage. Implementations of services, clients and data instances will be developed and deployed in all threads for integration and interoperability testing in support of the agreed-up thread scenario(s) and technical architecture. The services, clients, and tools may be invoked for cross-thread scenarios in demonstration events.

Developed implementations during the initiative might be closed source or open source. They will all be documented in the final initiative report. Open Source implementations should additionally be documented with:

Proposals will be evaluated according to criteria based on three areas: Technical, management, and cost. Each review will commence by analyzing the proposed deliverables in the context of the Sponsor priorities, examining viability in light of the requirements and assessing feasibility against the use cases.

The review team will then create a draft Initiative System Architecture from tentatively selected proposals. This architecture will include the proposed components and relate them to available hardware, software, and data. Any candidate interface and protocol specification received from a Bidder will be included.

At the Technical Evaluation Meeting (TEM), the IP Team will present Sponsors with draft versions of the initiative system architecture and program management approach. The team will also present draft recommendations regarding which parts of which proposals should be offered cost-sharing funding (and at what level). Sponsors will decide whether and how draft recommendations in all these areas should be modified.

Immediately following TEM, the IP Team will begin to notify Bidders of their selection to enter negotiations for potentially becoming initiative Participants. The IP Team will develop for each selected bidder a Participant Agreement and a Statement of Work (SOW). The IP Team will also notify bidders of unsuccessful proposals.

The OGC Reference Model (ORM) version 2.1, provides an architecture framework for the ongoing work of the OGC. Further, the ORM provides a framework for the OGC Standards Baseline. The OGC Standards Baseline consists of the member-approved Implementation/Abstract Specifications as well as for a number of candidate specifications that are currently in progress.

The structure of the ORM is based on the Reference Model for Open Distributed Processing (RM-ODP), also identified as ISO 10746. This is a multiple-perspective approach well suited to describing complex information systems.

The ORM is a living document that is revised on a regular basis to continually and accurately reflect the ongoing work of the Consortium. Bidders are encouraged to learn and understand the concepts that are presented in the ORM.

This appendix refers to the RM-ODP approach and will provide information on some of the viewpoints, in particular the Enterprise Viewpoint, which is used here to provide a general characterization of work items in the context of the OGC Standards portfolio and standardization process, i.e. the enterprise perspective of an OGC initiative participant.

The Information Viewpoint considers the information models and encodings that will make up the content of the information exchanges and supporting services to be extended or developed to support this initiative. Here, we mainly refer to the OGC Standards Baseline, see section Standards Baseline.

The Computational Viewpoint is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution across a network of service providers and consumers. It captures component and interface details without regard to distribution and describes an interaction framework including application objects, service support objects and infrastructure objects. The development of the computational viewpoint is one of the first tasks of the Pilot, usually addressed at the Kickoff.

The Engineering Viewpoint is concerned with the infrastructure required to support system distribution. It focuses on the mechanisms and functions required to:

It exposes the distributed nature of the system, describing the infrastructure, mechanisms and functions for object distribution, distribution transparency and constraints, bindings and interactions. The engineering viewpoint will be developed and tested during the Initiative, usually by means of Technology Interchange Experiments (TIE’s), where Participants define the communication infrastructure and assign elements from the computational viewpoint to physical machines used for demonstrating Initiative results.

The Technology Viewpoint is concerned with the realized physical components, technologies, and operational characteristics that comprise deployed initiative systems. This viewpoint typically represents the system components as they have been built and connected during the initiative and forms part of the initiative record captured in demonstrations, videos, and engineering reports.

The OGC Standards Baseline is the complete set of member approved Abstract Specifications, Standards including Profiles and Extensions, and Community Standards.

OGC standards are technical documents that detail interfaces or encodings. Software developers use these documents to build open interfaces and encodings into their products and services. Standards are the main "products" of the Open Geospatial Consortium and are developed by the membership to address specific interoperability challenges. Ideally, when OGC standards are implemented in products or online services by two different software engineers working independently, the resulting components plug and play, that is, they work together without further debugging. OGC standards and supporting documents are available to the public at no cost. OGC Web Services (OWS) are OGC standards created for use in World Wide Web applications. For this Initiative, it is emphasized that all participants will have access to the latest versions of all standards and related engineering reports.

Any Schemas (xsd, xslt, etc.) that support an approved OGC standard can be found in the official OGC Schema Repository.

The OGC Testing Facility Web page provides online executable tests for some OGC standards. The facility helps organizations to better implement service interfaces, encodings and clients that adhere to OGC standards.

OGC also maintains other documents relevant to Innovation Program initiatives, including Engineering Reports, Best Practice Documents, Discussion Papers, and White Papers.

The following scenarios will guide Pilot design and prototyping.

There are no defined pilot model deliverables; however any models and/or schemas to be created or refined in the course of the Initiative will be considered during the kickoff.

Interface and/or component specifications to be created or refined in the course of the Initiative.

An overview of the systems to be developed is as follows:

Pilot systems are roughly divided into 4 segments:

The overall prototype system has been divided into 6 individual systems that share some components but deliver distinct sets of functionality.

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 NGFR Integration Handbook.

The wiring of a SmartHub system is shown below:

and includes the following components

The Command Communication system establishes communications, a common operating picture, and tasking between first responders, incident commanders, city personnel, and city leaders. The structure of a command communication system is summarized in the following wiring diagram:

and includes the following components

The Indoor Navigation system enables first responders to navigate and be tracked inside of a building in the absence of GPS reception. System components are summarized in the following wiring diagram:

and include the following components

The Street Navigation system is summarized in the following wiring diagram:

and includes the following components

The Flood Sensing system provides both predicted and actual flood inundation regions and street blockages, summarized in the following wiring diagram:

and including the following components

The Road Sensing system provides road condition and traffic awareness for traffic monitoring and as input to response or evacuation routing. It is summarized in the following wiring diagram:

and includes the following components

Composite or ensemble sensor providing GPS, IGU, and RFID/BLE beacon location tracking in both indoor and outdoor environments. May be implemented as a smart sensor with Sensor Things API client interface, or integrated into a proposed SmartHub or Incident SensorHub. May be actuated (e.g. through STA Tasking) and/or have a configurable tracking rate / interval.

Composite or ensemble sensor providing responder health metrics (heart rate, skin response, temperature, movement activity, etc.). May be implemented as a smart sensor with Sensor Things API (STA)client interface, or integrated into a proposed SmartHub

Composite or ensemble sensor providing environmental information such as temperature, air quality (CO, CO₂, ozone, particulates), weather (vehicular), and so on. May be implemented as a smart sensor with Sensor Things API (STA) client interface, or integrated into a proposed SmartHub

Bespoke or phone / tablet based body-worn sensor hub device supporting connection of multiple body-worn sensor devices, multiple I/O devices, data +/- voice communications, exchange of sensor and other incident data with incident / cloud SensorHub nodes, and multiple applications for responder use.

An Incident SensorHub node is positioned either in a response vehicle or incident command post. It provides caching and exchange of sensor information with associated SmartHubs and Cloud SensorHubs, supports SmartHub connectivity and incident-specific sensors such as vehicle trackers or on-scene weather sensors.

A Cloud SensorHub registers and provides OGC interface data access to Incident SensorHubs and SmartHubs, other data pools, and model processing capabilities as well as legacy data zone systems equipped with their own OGC interfaces.

A First Responder HUD is a distinct wearable device or face mask integration that connects with a SmartHub (e.g. USB) and displays data, imagery, and/or experiences to support responder decision making.

A SmartHub supported application leveraging a Tracking Sensor, RFID/BLE beacon network, IndoorGML route network, and optionally cloud-based routing support to locate and direct first responders in appropriately equipped and mapped indoor building environments.

In-situ flood / inundation sensor providing water depth and velocity, either configured as a smart sensor (STA client) or integrated on a SensorHub compatible (e.g. smart lamp post) platform, with task-able and/or configurable measurement actuation.

In situ sensor package for vehicle and/or pedestrian traffic density / speed and road surface appearance / condition, either configured as a smart sensor (STA client) or integrated on a SensorHub platform, with taskable and/or configurable measurement actuation.

In situ or relocatable weather station sensor package for weather conditions (temperature, humidity, wind speed/direction, visibility, precipitation), either configured as a smart sensor (STA client) or integrated on a SensorHub platform, with taskable and/or configurable measurement actuation.

Desktop visualization / analysis application that utilizes a 3D city model in GlTF / 3DTiles and/or I3S format to portray a common operating picture for incident management. The 3D Dashboard works with sensor, traffic, incident, resource, and population information provisioned through a Cloud SensorHub and OGC conformant legacy systems (+/- system adapters).

Distributed command and communication system (DCCS) for messaging, alerting, tracking, and tasking among incident management personnel, city leaders, and community members. The DCCS will interoperate with / leverage SmartHubs, SensorHubs, and the 3D Dashboard, as well as provide mobility app support (phone, tablet, browser).

Component that leverages sensor observations, weather predictions, and 2.5 / 3D landscape data to make on-going predictions of timing, extent, and severity of stream flooding and land surface inundation, especially for use in determining street closures for navigation and traffic management. Provides an OGC compatible interface (SOS, STA, WPS) and interoperates with Cloud SensorHubs.

Component that leverages street / path networks, as well as closure, congestion, and public safety related zone data to compute optimal vehicle and pedestrian routes for one or more responder, city personnel, or community travelers. Provides an OGC compatible interface (e.g. WPS) and interoperates with Cloud SensorHubs.

Component that mediates between the data store tier of an existing public safety information system and Cloud SensorHubs by providing an OGC compatible façade such as SOS, STA, WFS, etc.

Smartphone +/- table application or app ensemble (could be browser based) that provides incident - aware trip navigation for incident avoidance or evacuation, supports location and community - aware alerts, and enables community members to provide their own observations of multiple categories ambient situations and conditions such as incident occurrences, flooding, etc. Optionally supports community contribution (opt-in) of observations from smartphone sensors. Should provide multiple privacy options (identified, anonymous, randomized, etc.)

Active beacon devices of sufficient number and range that prepare one or more buildings in each host city to support indoor tracking of suitably equipped first responders at 5m or better accuracy. Beacon network is to be installed and integrated with an IndoorGML routing network for each building.

Creation and provision of a building model encoded in IndoorGML that represents the navigable space network of each designated building. Model to be suitable for prototype tracking and routing of first responders. Optional provision of a 3D building model for visualization purposes.

Creation, transformation, and/or provision of a 3D city model covering a suitable region of each host city greater than 4 sq km for pilot scenario purposes. Model and encoding must be compatible with the selected 3D Dashboard application.

The Engineering Report deliverable comprises two roles. The principal role, ER Editor, is responsible for structuring the ER, delegating and scheduling contributions from other participants, then compiling and editing the complete document. The associate role, ER Contributor, is a participant who develops and contributes components of the ER under the supervision of the ER Editor that correspond to the participant’s own agreed deliverables.

A detailed design, ideally with associated open-source code, for implementation of a functional SmartHub on an Android-based smartphone or tablet platform. Optional deliverable is a detailed design, ideally with associated open-source code, for a functional wireless or USB Smart Sensor (STA MQTT client-equipped sensor device) on a Zephyr-based single—​board computer platform such as Arduino 101.

Development and delivery of a solution architecture document for each host city that is based on SCIRA design patterns and viewpoints, makes use of Unified Modeling Language (UML) for graphical representation, and describes the combination of legacy and prototype systems that has been designed and implemented for the purposes of this initiative. Intended to test the usefulness of the SCIRA design toolkit as well as inform revision and update of the SCIRA Deployment Guides.

Execution and report of a comparative analysis that examines the Smart City architectures implemented and documented for each host city with respect to the already implemented and documented architecture of a third city to be selected for the purposes of this deliverable.

Capture of content and production of a short (10min) video suitable for introducing a general audience to the goals, activities, and outcomes of this initiative. The video may include recorded and visual content contributed by participants and stakeholders as well as stakeholder interviews and relevant animated or static graphical content.