OASIS Open Command and Control (OpenC2) TC

During our OpenC2 TC discussion today, I forgot to bring up a use case for the automation village. Would it be possible to make a JADN use case associated with the work Toby mentioned in previous meetings on with smart buildings/cities?

Would an OpenC2 use case for those scenarios also be possible?

Note these can be all new use cases – we don't have to follow the threat crowd use cases, and the village is allowed to have as many use cases as we want.

 

My reason for asking is purely awareness and adoption. I think making the wider CASP community aware of our work with the 'smart-building' people would actually get the CASP community more OC2/JADN aware since they'll want to show off their stuff to those people as well.

 

 

There should be.  We have been looking at the setup so far, but in my head the IM use cases include:
1) define the "connection profile" document IM
2) negotiate a connection profile between system controllers, using "CP negotiation" messages
3) register negotiated CPs with repositories, using "CP publication" messages
4) conduct system-to-system operations according to a CP using "operational" messages

It would help to make a list of some representative conceptual operational messages: "room xyz is occupied", etc.  Cyber physical systems is the ideal demo use case because, unlike setting blinky lights or firewall rules, with buildings and people the concepts are real scenarios that are easy to draw on a whiteboard.

Here are the slides I used at the Jan 7 conversation starter.

The scenarios described here align with those the C4SB is having after that meeting.

 

Looking forward to engagement between JADN and NIEMOPEN, it would seem that JADN is being, or will be, proposed as the canonical means to define IEPDs. When we look to smart communities/villages/cities, the communication between government systems and smart buildings seem a natural use case of IEPDs/JADN. The story that was told about these use cases in the Digital Twin Consortium involved twinning venues with large crowds. The turn-styles or the sports scoreboard or the opera house or even the legislature all have a simple message (Connection Profile): I have x thousand people here, I expect them to exit over 35 minutes, and they are beginning to exit now.  On the NIEM side, the IEPD consumer could be the traffic light control system, the mass transit system, or even the police dispatch function, with a goal to get the bolus of people and cars out of town as quickly as possible, and get the village/city/district back to normal as fast as possible. This is as David K describes

 

JADN pulls together connection profiles and IEPDs.

 

One notion that the C4SB crowd has that we do not yet is an open registry of machine-readable message definitions, ideally in JADN. A system of systems integrator selects a Connection Profile from the registry (however defined) and chooses the Connection ends to expose to the system of systems. Under the C4SB model, the broker matches connection ends that share a matching context to create Connections.

 

It is not hard to map the other direction. Two decades ago, when the Emergency Management Communications group was exploring EDXL (emergency distribution elements, in the same envelope as a CAP alert) there were meeting about whether a Facility could consume a CAP alert directly. One scenario was a poisonous gas/bio-agent is released. A smart office building might lock its doors and go to a positive internal air pressure. A sports arena might forward the information to the scoreboard, adding its own context and discussions. An open air Arena with no way to isolate the air, might instead counsel people to leave as rapidly as possible through the Nort exit only – not the South where the gas was released. (FWIW, I have been asked to present next week on JADN and IEPD to the technical subgroup of the Emergency Management Communications TC).

 

But what if the communications are more tactical? Could Police Dispatch send an IEPD (Connection) not only to the traffic control system that they (the city) already manage, but to buildings?

These systems are too hard to integrate into tight, likely brittle, complicated systems. The full breadth of the domain-specific NIEM vocabularies makes integration difficult. Profiling those down into actionable information, IEPDs, defined in JADN, to enable complex systems seems a better path.

 

The rather amorphous CAP alert is the most used product of the EMTC. The second most used communication is likely HAVE, Hospital Availability Exchange. When moving from a disaster, natural or otherwise, dispatchers can exchange abstract information about wait times in hospitals, including for specialty treatment (surgeries and ICUs), beds available, and so on. Triage teams use this information, with their own assessment of urgency for a particular patient, to dispatch patient care over a wide area. I have seen HAVE also used to direct busses to concentric sets of emergency shelter facilities following a hurricane.

I don't think that the EM groups have had much communication with the NIEM folks, but should they? Is a JADN version of HAVE the natural next IEPD for NIEM?

 

Looping back to cybersecurity, and to IADC thinking, each JADN/IEPD becomes the potential basis for Small Language Model (SML) AI. Meta-analysis of the SML messages, as defined in JADN, becomes the potential basis for detecting cyberphysical attacks on infrastructure. Financial markets moved to small, closely defined messages long ago. A malformed message can be rejected before it gets on the wire, as well as at the receiving end. A well-formed message may be considered malformed it sent to the wrong market end-point. Because their messages are strongly typed, they can create triggers to suspend or slow trading to minimize market manipulation. JADN and SML-AI could present a means to generalize such capabilities.   

 

There have been many interesting conversations in the last two weeks.

 

tc