MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: FW: [emergency] CAP Visualization (was RE: CAP Developers' Forum...)
> BTW: where is the CAP source or who is it's provider?
Theoretically, anyone, correct? For our implementation the source can be
local or remote (pushed, pulled, or aggregated/translated data sources).
Due to the whole seemingly nebulous/moving target nature of alerting, we
went for a model whereby a single system core is fed by plugin modules,
each either transmitting, monitoring, ingesting, originating, or
aggregating data based on a common API. Broadcasters like to cherry pick
- giving them a single monolith server application will work for some
but the requirements are always so subtly different that one will end up
making each implementation a project and not a product delivery.
In terms of implementation, I'm a strong believer in the minimal boat
factor - we're using assembly code, c, and other low-level stuff to
streamline the data manipulation. Our webserver fits on a floppy. And
the system is built so that one can pull the plug on the server and it
will come back up and run. Ofcourse a lot of this is based on the
broadcast approach of 'I need to be able to plug your stuff in and just
have it run - I don't have time to manage your databases or fix anything
since I have a thousand other fires to fight'.
> We were discussing this over lunch. In a typical 911
> system, say a kidnapping occurs, the 911 center dispatches
> the police officer to investigate and he reports on
> the incident. Then the provider is the police records
> management system. Given a weather alert, the provider
> is possibly the National Weather Service. On the other
> hand, as in Huffines's case, the local TV stations are
If one takes the web entry/login approach, any provider can have their
own customized interface to the system. For us, by default the entire
CAP spec is implemented, allowing folks to throw out pieces they don't
specifically need. CAP alerts generated by different entities can be
stuffed in a single queue, prioritized within the queue, or separated
into multiple parallel queues in the transmission system. The content or
pipe itself can be encrypted to ensure everyone or only intended
recipients receive the data.
> sitting on a lot of radar equipment but may not be
> authorized to issue an alert even when they can
> plainly see the hook return. So they 'advise'
This type of data is aggregated and reformatted so it can be passed as
IP/MPEG packets. It is strictly hands-off - but its reformatting is
automated (else it can't pass through the system). On the receiver it is
depacketized to files or fed back to applications that can only parse
the native format.
> their viewers. Obviously, the closer one gets to
> real time events, the situation as to which feed a
The very first demo we gave had a few FEMA folks telling us that
anything above a 5-second delay was unacceptable. Luckily we implemented
translation in memory-mapped files for speed. Usually latency is under 1
second to reformat. End to end delivery through a DTV system or
satellite system can be up to a second (600ms+ roundtrip, give or take,
plus buffering and latency through the digital transmitter and
receiver).
> subcriber wants to see changes, and I guess that is
> a reason for the TV feed you have in the corner.
The feed is a low bitrate WMV9 feed of the current station feed. Due to
the fact that there can be up to 19Mbits open on the DTV transmitter,
one can provide for multiple video feeds.
In terms of realtime changes, the GUI can update itself as new data
arrives. This is useful for hands-off viewing of events as they roll in.
Ofcourse my comments are from a broadcast delivery perspective, and
there are no doubt better ways to implement a lot of these features when
one has the luxury of a two-way network.
Cheers
Kon
***********************************************************************************
Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@nds.com and destroy the original message.
***********************************************************************************
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]