Real-Time Situational Awareness: Today’s Holy Grail

So, I have heard this expression before, but what does it really mean?

Holy Grail: something that you want very much but that is very hard to get or achieve.

Well, that seems about right, as “real-time situational awareness” or a “common operating picture” are goals that are often bandied about in public-safety and emergency-management circles. Presumably, it is something desirable in order that those in charge have an accurate understanding of what is going on around them, so that they may be prepared to respond or react.  After all, how do you know you have to react, if you don’t know that something has gone awry?

While I come to this issue from an emergency-management/public-safety perspective, I have seen this desire for real-time situational awareness (RTSA) present itself in several other disciplines. For example, RTSA in a cyber environment means knowing the status of your network, in terms of its traffic vis-a-vis the normal “pattern of life,” in order to detect anomalies and attacks.

RTSA in a manufacturing environment manifests itself as the need to know the status of “the line” (i.e., production line). That is, is the line running smoothly, or is there an interruption? In public health, what is the emergency-room status? Are they still accepting patients, or should an ambulance on the way be diverted?  In the transportation world, is the highway free flowing, or is there a breakdown that is stopping traffic?  Or, in the transit industry, are the trains on a particular rail line operating on schedule?

So, there is a demand for RTSA in various industries; it just may manifest itself a bit differently as to what the key data elements are, in order to understand the “system status” (e.g., the network, the production line, the hospital, the highway route/transit line, the “public safety” environment).

Based on the widespread desire for RTSA across industries and agencies, why is it so elusive (aka the “Holy Grail”)?

Given the fact that we have so much data available to us today (the advent of the Internet has unlocked huge troves of data worldwide), why does achieving RTSA remain so difficult? That is because the mere availability of data does not guarantee that we have actionable information.

In fact, while we have more accessible data than ever before (in the history of mankind), one might argue we have less useful information than ever. We are swimming in a sea of data that we cannot see in context (i.e., spatially, temporally, and relationally with other relevant data), such that it is actionable.

This problem is accelerating, given the number of devices that are being connected to the Internet (i.e., the “Internet of Things” – IoT). The challenge, as articulated in the public-safety world, is to provide “the right information to the right person at the right time,” so first responders may take the appropriate action. RTSA solutions are positioned to be the mechanism to deliver on this mantra.

If RTSA is the desire, and the data exists, then what are the obstacles that must be overcome in order to achieve this? The issue is seeing individual data elements in context in order to obtain actionable information.

For example, a security-door alarm, in and of itself, may or may not be a cause for concern. But seeing where that door is on the campus (say the basement of the engineering building), to what room it provides access (the chemical lab), and when an event occurred (at 2 a.m.), along with the video footage from the camera trained on the door, will provide the necessary context to conclude it is a very real problem.

But in that hypothetical example, each of the various data elements (location, time, access, camera footage) would need to be consolidated to form a coherent whole and brought to the attention of the relevant party(ies) for evaluation and (possible) action.

This illustrates the conundrum that, while we have a wealth of data, they exist in separate systems (from an Information Technology – IT standpoint) as well as different departments/agencies/jurisdictions (from a policy standpoint). These are the so-called “silos” that exist in every agency.

There are technical challenges to sharing information (e.g., different data formats, network/communication gaps, different data standards) as well as policy challenges (e.g., no process for sharing, no agreement/MOU in place, different sensitivity classifications for the information). In prior work, I have introduced the concept of “people/process/technology” alignment in order to have project success. (See graphic below).

The people must come together to agree they have a problem (the need to share information in order to achieve RTSA) and be willing to commit to working toward solving. But that agreement is not enough, in and of itself. That group of people must work through a process of consensus building to develop a product (e.g., a CONOPS, specification, action items, governance structure, legal agreement) that will provide substance and direction to the agreement they have reached.

Finally, after the people and process steps have been engaged, the group can turn to the technical aspects of solving the data-sharing effort—how to discover, access, and publish the right information in a timely fashion with the relevant context to the people who need to know.

Thus, RTSA is not solely a technical matter of figuring out how to apply the right technology to share the data. It involves commitment from the people involved, as well as a clear procedural path to doing so.

But the technical issues are not insignificant. One of the reasons organizations find themselves in the position of not being able to achieve RTSA (even if they may possess all the necessary data, which is unlikely) is that their IT systems and data sets don’t share information easily across platforms.

This is often because the systems were originally procured with a particular business purpose in mind, which usually did not include sharing information with other systems or other outside agencies. This can be compounded by a lack of network connectivity or bandwidth, varying and/or incompatible file formats, and a lack of data exchange protocols.

The result of these issues is a lack of data interoperability.  Consequently, a major obstacle to achieving RTSA is the lack of data interoperability, which is not only a technical problem but also a people and process matter.

In a previous work, I introduced the concept of the “three-layer cake” view of data interoperability.  It is a pragmatic construct that presumes there are three layers – the Data layer (where the data resides in its original system/format), the Integration layer (where the data is accessed, normalized and aggregated), and the Presentation layer (where the data is presented in context as information to the end user/recipient). Moreover, there is overarching transport of the data across these layers. The graphic below illustrates the concept.

This construct accepts the fact that both the data layer and presentation layer are both “what they are”—meaning the data layer includes data sets that are not interoperable or shareable, due to the technical reasons cited above.

Further, the presentation layer destination is increasingly a smartphone or tablet in which the information has been transported wirelessly to an application. Consequently, to deal with the lack of data interoperability, one must create the integration layer to discover/access/exchange and analyze the data, so it can be presented in context to the end user in the presentation layer. This all must be done securely across a transport network (wired and wireless) that may impose its own constraints and limitations.

So, what are the takeaways from the above discussion for the public-safety agency or any agency which desires RTSA? There are at least three:

1. To achieve real-time situational awareness, one needs to overcome the data-interoperability problem.
2. The interoperability problem is not solely a technical one; rather, it involves (significant) people and process issues.
3. Lastly, an agency must take steps to put in place integration-layer tools (hardware/software/middleware) to share data with the agency’s own end users, as well as others outside their agency.

Stated differently, the ability to achieve RTSA requires that data interoperability within and between agencies be addressed. This does not “just happen” without taking the necessary steps to enable data sharing from a people/process/technology standpoint. Instead, it takes dialogue between agencies, and the expenditure of funds to construct the necessary tools in the integration layer to facilitate data sharing.

Public-safety agencies need to recognize this challenge and embrace the discussions needed to determine what data needs to be shared (e.g., Geographic Information Systems – GIS, Computer Aided Dispatch – CAD, voice, video, sensors, messages), what governance needs to be established, and what technology needs to be applied.

Ideally, agencies will find a technology vendor who understands this subject and will propose standards-based/open architected solutions that will promote interoperability. Similarly, future procurements ought to be structured in such a way as to comport with the three-layer model and further promote interoperability by making it a requirement.

There is no more difficult a challenge facing public safety today, and the ability to meet this will determine whether we reap the benefits of IoT, or if we fall further behind in cross-discipline/cross-jurisdictional information sharing. Lives of citizens literally may be hanging in the balance.

**John Contestabile is Director of Public Safety Solutions for Skyline Technology Solutions.  He is a public-safety and transportation technologist with more than 40 years of experience at the Maryland Department of Transportation (MDOT), Johns Hopkins University/Applied Physics Laboratory (JHU/APL) and, most recently, with Skyline Technology Solutions. Contestabile served as the first Statewide Interoperability Coordinator (SWIC) for the state of Maryland, where he initially developed the interoperability concepts outlined in this article and refined them in subsequent projects with JHU/APL and Skyline.