# Challenges and problems to solve.
## Introduction
- As climate change creates increasingly harsher conditions, the criticality of natural disasters demands the involvement and coordination of more and more diverse emergency response agencies.
- A Common Operating Picture (COP) is fundamental for situation awareness, coordination and ultimately the success of the mission.
- As of now, there are challenges in the formation and consumption of this real-time Common Operation Picture. We enumerate some of these challenges in more detail as follows.

## Challenges creating the Common Operation Procedure.
### Diversity in the response teams
- The response to a major disaster event requires the involvement of multiple and diverse response agencies.
- The complexity of coordination increases as more actors come into the scene coming from heterogeneus agencies.
- These can even cross boundaries between military and civilian institutions.
- This diversity resides in, among other things, in:
- the type of emergency response teams they are (firefighters, police, national guard).
- technology.
- communications media.
- semantics (Debris removal means different things in different contexts).
- budgets.
### Data distribution challenges
- At a local logical operational level (a single team), the distribution of data can even be assumed to be ubiquitous, not only regarding the transport of raw data, but also the interpretation of such data. E.g.
- Communications over radio will be done over an agreed range of channels and encryption constructs.
- Images will be shared using a format supported by the team's devices.
- As the scope of the data distribution increases, more integration challenges arises, as different technology choices have been made by different actors.
- Especially in the military, advanced sensor systems are used to perform remote sensing and analysis of the situation. Such technologies sometimes produce data deliverables that are not easily consumed by non-specialized tools.
- Information categorization depends on the origin. Data not only comes from sources plentifully identified and authenticated. Some data entering the systems comes in varying degrees of trustworthiness. Some examples that have disparity in their trust level:
- Data generated from a device owned by the data consumer.
- Reports from news agencies.
- Reports from people calling the police.
- Another aspect of information categorization reported by our mentors was that information and data coming from military sources and permeating into civilian consumption needs to be properly sanitized to ensure no classified data is disseminated.
- The process of data sanitation does not occur in a timely fashion, or at least at the pace demanded by an emergency situation.
- This results in some the data arriving at a moment in time in which is no longer actionable or relevant.
- At the same time, information overload should be avoided. As well as successfully distinguish between noise and useful information.

### Logistical challenges
- According to our mentors, one of the biggest challenges is tracking of elements on the range. To cite some examples:
- Vehicles on ground, air and water.
- Supplies (water, cans of soup, fuel, medkits).
- People (first responders, general public, victims).
- Hospital beds.
- ID of who is behind each vehicle (Is this an AirForce or a Navy aircraft?)
- Spatial awareness and mapping.
- Of fire (origin, boundaries, velocity of advance).
- Critical infrastructure.
- Treats and/or dangers (toxic smoke, explosive facilities).
- Marking of evacuation routes.
- Reliability of the systems supporting the operations in the face of the harsh conditions encountered in an emergency situation, specially those such as a wildfire, in which fixed communication infrastructure will become unavailable as the fire progresses.
- One of our contest mentors has declared that the one of the most critical problems is alerting the people in danger.
- Our mentors also highlighted the need of communication of needs.
- E.g. Requesting a MedEvac.
- Our mentor representing FEMA made us aware of the challenges in the financial aspects of the logistics. The role of FEMA, among others, is less the tactical and frontline coordination and more the financing of the different agencies acting in response to a disasters. In a lot of cases, these first responders are local fire departments small in size and their resources are limited. Providing them access to moneys and a process to submit claims is paramount for their operational continuity.

### Challenges in the usage of different COP solutions
- There are several solutions for having a Common Operating Picture. Some of them are very comprehensive and up to the satisfaction of their highly demanding users.
- Mainly 3 Solutions have been consistenly mentioned by mentors:
- TENA
- Test and Training Enabling Architecture
- Developed by the US DoD
- Code, binaries and infra available for civilian use upon acceptance of license.
- Used by several military institutions under the DoD.
- ATAK
- Android Tactical Assault Kit - Military version.
- Android Team Awareness Kit - Civilian version.
- Developed by Air Force Research Laboratory, now maintained by a joint group.
- License: Government off-the-shelf. Civilian version is GNU v3.
- Used across multiple military institutions, DHS, and the civilian emergency response community.
- Web EOC
- Web Emergency Operations Center
- Developed by Juvare
- Proprietary.
- Used by FEMA, States including Washington, Idaho, Connecticut, etc...
- In addition to the expected interoperability challenges between the different systems, it has been reported by our mentors that even between instances of the same solution there are challenges on their integration.
- e.g even when the WebEOC solution is deployed by the State of Colorado and the State of Wyoming, conducting an operation or exercise that spans across state lines would not be possible.
- According to the mentors, these restrictions have also prevented the execution of much needed exercises at a greater scale than the ones they are capable of doing.
- Our mentors have also mentioned that if they need to pull information from each other system, they have to do it through a manual process.

# How would your solution work
- Give technical details on your solution here
- After conferencing with our mentors and evaluating different solutions we have come to the conclusion that the solution resides in complementing existing systems that are approaching the desired outcome with the last mile to become fully integrated.
- If you’re using an existing piece of technology, or changing a part of it, explain how it would address the problem
- After analyzing multiple systems we have concluded that TENA (Test and Training Enabling Architecture) would be the solution that satisfies most of the success criteria and its availability, support and the relationships that we have formed along our hacking journey are putting us on track to accomplish _Beat the Blaze_'s ultimate goal.
- TENA has been battle-tested (literally!) with success and counts with support of the DoD. The criticality of the operations supported by TENA ensures its upkeeping to the highest standars of reliability and performance.
- Additionally to the feature-rich suite of applications comprising the TENA ecosystem, there is a common data model, as well as middleware and SDKs (Software Development Kits) to develop bridges and gateways to interface with external systems. __This is a critical tenet of the solution, as this would enable different systems talking to each other__.
- As part of the ecosystem, TENA has not only the aforementioned capability for logical integration, but it does provide the foundation to support different transport media, __meaning it can be carried over a wide range of comms tech and be tolerant to different levels of availability__.
- What sort of resources would it take to make this solution work?
- Open-Range.org will exist to coordinate the efforts of bringing TENA to civilian use, as TENA is a government development program, as well as the development of components and modules to aid on the integration with existing systems.
- It is worth mentioning that the part of *"coordinate the efforts"* of bringing TENA to civilian use, deliberately establishes a distancing from executing a lot of the technical work that would be necesary to be done inside TENA. Given that TENA's code and some of its infrastructure is under DoD support, it would be the responsible choice to let the experts in TENA be the experts in TENA.
- However, the provision of an SDK enables the general public to extend TENA rather than modify it, as well as serving as a custodian to prevent misuse of the platform, either by the lack of expertise or a deliberate attempt to compromise the emergency response infrastructure.
-
- If you’re worried about sharing intellectual property, give a high-level overview on the technology.

## Concerns
As cloud developer at Microsoft (9 years) my greatest technical concerns were:
- A. Ability to modify the platform for adjusting or adding anything necesary to achieve feature completeness, as well as support from the maintainers to ensure correctness and stability.
- B. Adequate interfaces for intra and cross-perimeter communication that would provide flexibility of integration while maintaining the stability and security of the platform.
- C. A loosely coupled and extensible data model that would not restrict the inclusion of heterogeneous data sources and objects.
- D. Tolerance for low availability of high-bandwith communication media. Essentially considering that a stable internet connection cannot be guaranteed in an emergency situation.

## Addressing the concerns
- To address (A) we confered with DoD's Chris Juszack and confirmed that there are SDKs to serve as a custodian to prevent unintended misuse of the platform, as well as an offer of support and training.
- The documentation (p90 and p113) describes the different protocols used to interface with other instances, modules and systems, satisfying my concerns described in (B).
- In regards to (C), through the technical documentation we learned about the TENA meta-model (p86 and 95) having as design objectives addressing my concerns.
- As part of our conversation with Mr. Juszack, he was able to demonstrate, using a very simple homemade Rpi setup capturing civilian aircraft location data (ADS-B) over the air, that the TENA system can easily receive input from different transport media, including low-frequency RF signals, addressing (D).

x,y,z,q. For X The TENA techical documentation review verified the data interoperability and interchange was superior and proven, For Y we had a Teams meeting with DoD's Chris Juszack, responsible for TENA support and training, which is available. For Z he demonstrate his home setup runing on a laptop and takes in multiple feeds from Arduino devices and public aircraft data feeds and display it in SIMDIS. For q, we discussed at length the TENA license requirements and how the GOTS Open Source works.

# Raw notes

## Notes from mentor sessions
Data classification depends on the origin, bridge between military and civilian.
how to sanitize data that is classified to be exposed.
Common operating picture is not resonating with
classification does not work in timely fashion in an emergency situation/
You don't want data overload
Fast decision making.

Top 5 information.
Resources in the ground
Resources inbound - these things are not simple, this is the core of this problem.
Battlefield operations.
Realtime
Fire boundaries
Weather conditions.
Is it FEMA is it Air force

What are the problems

They have wargame style things but they haven't been done it at a scale that they should.

incident action plan
incident command system
every operational period (1 hour, 8 hours depending of the scale of the problem). they buid an incident action plan.
ICS

Coommon operation picture, (COP) everyone understands it.

WEB EOC Emergency operation center.

E.g. Colorado and Idaho are contiguous and they use Web EOC
If they need to comm each other each has to pull information from each other.
There is a manual process to do this.

Problem is data trustworthiness, data integration.

Twitter, Facebook, what alerts them?

How do I validate this data?

There is problem also in the language used. "Debris removal",
There should be a standard language.

ERWIN - Federal information definition. There is an effort.

Mine: Also how to pass messages and broadcasting information.

Critical infrastructure - exploding material.
Fire generation
Evacuation routes

A big problem is tracking
- Logistics
- Resources (including cans of soup etc.)

MQ drones are the gold standard to determine fire perimeter.

Detecting aand modeling fire is not a feasible problem (at least for this hackathon)

Emphasize also the needs.

Problem statement to include the reliability of the systems.

# Raw ideas toward solution
- Ability to replay the events.
- At any speed.
- Immutable but cloneable.
- Sanitized.
- Filter
-
- Highlight the ability to introduce new types of events without approval.
- Contains data as well as metadata about it.
* E.g. Contains location information including the projection used.
* Where to request more information about this
- To enable a point to provide more information about an object, we can either provide tools to expose generic information, or it can be something done in-house.
- Creation of a market place of data exposers and consumers.
- Support for multiple event types.
- Including a site to browse past event data.
- Provide tools to expose and consume the information. Including cellphone apps.
- Fault tolerance: Being able to use any degree of availability but have toleracne to failure:
* Low level VHF systems.
* 5G system deployment.
* Use of future
- Dynamic schema.
- Publication of a data schema, extensible. With the existing information.
- Use an agreed upon language and data schema, but that it can be extensible.
- The live hub can have a data dictionary for the data that is entering the hub.
- However, after the fact or in development time, there must be agreed upon event types and so on.
- Resource library.
- Ability to request help.
- Ability to request resources and have a system for "booking" or "reservations"
- All the system is modeled in a decoupled way, so anything can be replaced for experimentation, testing, simulation.
- Messaging and broadcasting.
- Scalable into partitions but still united.
- Inclusion in the system itself of data mappings from the common data model to specific vendors.
- Consider this a digital twin of the range.
- Open to the development of devices that connect to the network.
- Tollerance to high and low availability.
- Graph like architecture (?).
- Location of the resources. Also include information of utilization. E.g. How much bottles of water have been used.
- Identity of the actor behind each object.
- Types of objects:
- Actor, equipment etc.
- Trustworthiness.0
- How to contact.
- Resource.
- Request for help.
- Information.
- Communication.
- SitRep.
- Prediction.
- Metadata:
- Trustworthiness
- Type of object.
- Two levels of trustworthiness. Eg.
- Information can come from a reliable source, e.g. 911 dispatch.
- however, the source that notified 911 is not as reliable.

- Capability of curation.
- Actors with a level of worthiness can assign certain levels of worthiness to others.
- Processes in place to monitor, running diagnostics and antivirus in the event hub.
- Notification assurance, since the first notification just triggers the awareness and starts looking for confirmation.
- Also by putting the message out there multiple times we are increasing redundancy and reliability and increasing the chances that people see the warnings.
- This approach also can be provisioned as a bridge between different comms transport media, such as UHF/VHF/HF through regular GRMS radios or through mesh networking solutions such as
- Kiosks with live information?
- Is not offered as a replacement to existing systems, but as an addition to the current systems to provide more and enrich existing information.
- This leads to lower onboarding costs and almost no learning curve to the majority of the operators.

- At the same time, it can be used as a full backend replacement for existing systems or enable buiding solutions on top of that.
- Offer situational awareness and serve as a directory of further information by pointing to the source of the data.
-
-
## Values
- No-hassle onboarding.
- Loose coupling.
- Use of a common language, but tolerant to real-time extension.
- Being able to deploy quickly, but allow to deeper integration as the customer learns more about the platform.
- Tollerance to dynamic situations.
- e.g. the clients will read the metadata from the live hub.
- Support for multiple points of entry:
- VHF receiver.
- Satellite.
- Web.
- Serverless.
- Maximize fidelity when availability is high, but unlike TCP/IP, when availability is degraded, instead of failing altoghether, switch to a "best effort" mode and lower the fidelity to match the availability of the transport media.

## Client characteristics
- Tollerant to change. Reads metadata from the hub to support most of the stuff. Minimum client updates are necesary.
- Ability to filter through the noise.
- Quick deployment and ability to send information right away.
- Put the client in simulation mode.
- Support for different signals.
-

## TODO
- Get the story of the Paradise fire.
- Demo over radios.
- Integrate with ATAK and other. Both for publisher and subscriber.
- Demo participation of the open intelligence community, such as in creating GIS markers from imagery or calculating the trajectory of an airplane.
- Field devices.
- Putting out an ATAK version preconfigured?

## Notes
Event
An event is a lightweight notification of a condition or a state change. The publisher of the event has no expectation about how the event is handled.

A command is raw data produced by a service to be consumed or stored elsewhere. the publisher of the command has an expectation about how the consumer handles the message.

You can use the analogy of a sushi conveyor belt.

https://www.youtube.com/watch?v=WXuQERL_e8M <---- call for action.

https://en.wikipedia.org/wiki/NATO_Joint_Military_Symbology