Demo overview:  The intended purpose of the new/improved demo is to provide compelling use-cases for CEP, and show the relative simplicity of the CCL language for complex tasks.  The tasks should be more than ‘toy’ and should easily relate to our customers.  In my opinion the most easily ‘sold’ use for CEP and one that can be adopted into existing systems is fault detection and isolation.  We have heard this as well from numerous sources.  In addition, also think showing ‘application’ based CCL is good step to show customers where than can take the tool.  To this end, there are two groups of CCL scripts.  One targeting fault detection based events, and another targeting track management based events.

 

DemoLayout:  Although the demo could be shown on a single computer, I think three machines is ideal.  Two machines (or more) running ShapesDemo.  Each node will also be running a statistics gathering application.  (Publishes CPU, I/O load and error, memory, etc. out every half second or so).  The third computer can run the Coral8 server.  A part of the demo would be running these things on any or all nodes.  Noting is coupled to a specific machine.

 

 

ShapeDemo GUI

-         Generally, want to use pretty much as is, same concepts, etc. need some new elements added.

-         Need to app some visualization elements to enhance the demo

o       Loiter areas (if a shapes stays in the area too long, and event is fired.  The area is defined by x,y,radius.  CCL is done and works with the ShapeDemo, need visualization.

o       Graphical concept of ‘OwnShip’  Can be done with the exiting capability to add Topics to the demo via the XML file.

-         One ShapeDemo app will need toggles to make it go rouge

o       Start burning CPU

o       Sending data to fast, creating/deleting instances real fast

o       Bad DDS memory management

o       Would love to set up and app to struggle with reliability – have to force packet loss.  Not sure how to do this.

-         Add to the ShapesDemo the statistics API.  Each app will publish a 1 HZ update on the DDS events collected…

-         1 week of work with someone good with Windows

 

Node Monitor App

-         Possible leverage Ken’s statistics gathering application built for the discovery testing.

o       IDL for the reports already exist, are contain more information than needed for the general purpose demo.  Not really supported on Windows. 

o       May be faster to write a simple windows application that use the Performance data Helper libraries in Windows.  (PDH).  Looks like what we need is pretty easy to get to.  (CPU load by app, network I/O load, UDP errors, and memory usage by app)  Don’t need much here to support a good CCL event query on fault detection.  Note that we want CEP to respond _before_ there is a fault.

-         1-2 weeks depending on how simple we make it.

 

Coral8 CEP

-         See figure below.  Each CCL script should be simple to explain and show as well as leverage ACTUAL Coral functionality and not just single stream filtering.

o       CPA: Closest point of Approach.  Compare each ‘track (square, circle, triangle) to each ShapeDemo’s ‘OwnShip’ topic for tracks that will come closer than the set amount – fire an event.  Not fireing an event when the get close, but before they do…

o       Collision:  Any square,circle, triangle hit.  Done with Windows

o       ConstantBearing: Similar to CPA

o       …

o       Vladimir  - maigt make sense to talk tomorrow any walk through each CCL use-case on the phone

-         Need to ping Dave at Coral8 for a few final pointer on how ‘best’ to do a few things.  I know how to hack it, fear bad bad performace.

-         Need to add my SampleInfo and Discovery code back into the adaptor after getting the final updates from Engineering.  (Thanks to Jens!)

-         Fault detection CCL could be written before the node monitor apps are done…  they are not that difficult to create

o       ApplicationMonitor: watches discovery traffic, complains about apps dropping in/out when they are a primary data source

o       CPULoadWarning:  Fires and event if the aggregate CPU load gets too high, when there isn’t a corresponding increase in the number of objects being published

o       EntityLifeCycle:  looks for unexpected creation/deletion of an instance (say red  Square crated and deleted over and over again) watch for instance that are not properly deleted and then seem to come back to life…

o       LoadMonitoring:  watch the network load, correlate the I/O errors with the amount of topics and their data rates, see if a I/O errors are coming from the machine with the high CPU (an expected case)

o       NetworkError:  Force packet loss, monitor the builtin statistics, and see the correlation between NACK/ACK/HB rates and the network I/O error, CPU load, etc.

-         5 days to wrap up the CCL

 

 

-