100 likes | 250 Views
PVSS Alert Screen. Provides filtering for: Short sign & Priority (to filter for severity e.g. W, E, F) Description Alert Text DP List/Group System Name Summary alerts shown or not Needs to be extended to filter for: DP Type DP Name DP Alias. Filtering Methods.
E N D
PVSS Alert Screen • Provides filtering for: • Short sign & Priority (to filter for severity e.g. W, E, F) • Description • Alert Text • DP List/Group • System Name • Summary alerts shown or not • Needs to be extended to filter for: • DP Type • DP Name • DP Alias
Filtering Methods • GOAL: Put matching items in AES config DP • What does this mean? • DPs that match criteria • AES check all DPEs automatically • DPEs of DPs that match criteria • Allows for filtering at DPE level • DPEs that contain alerts that match criteria • Reduces amount of DPEs to monitor by AES – quick drawing • Hard to obtain • DPEs that contain active alerts that match criteria • Smallest amount of DPEs to monitor by AES – quick drawing • Does not show “live” state of alerts on all matching DPs • Smaller list passed = Quicker AES • Best case is to pass the filter directly to AES – e.g. CAEN/*
Methods under test • Method 1 • Use CTRL script to get a list of DPs that match criteria • Method 2 • Use dpQuery to get all DPEs that have active alerts that match criteria • Method 3 • Use dpGroups to get all DPEs that have active alerts that match criteria
Just-in-time vs. Pre-filter • Methods 1 & 2 perform all the filtering at the moment the result is needed • Method 3 involves a pre-stored list (DP Group) which contains the items to filter • A hierarchy of DP Groups is created which matches the hierarchy of the devices in a tree • DP Groups can contain child DPs and DP Groups (like the way summary alerts work)
Limitations of Method 2 & 3 • dpQuery’s return lists of DPEs (not DPs) • Lots of data for AES to handle • Reduced to return just active alerts • Currently are not “Live” (only shows alerts of DPEs that had active alerts when screen is shown) • dpQueryConnectSingle • Can be notified of new alerts • But, no access to add a new row in AES • Must redraw screen which is slow
Test cases • DP Name = CAEN/* • Repeat 1 on local & remote system • DP Name = CAEN/crate1/board01/* • Repeat 3 on local & remote system • DP Name = CAEN/* and DP Alias = Channels/* • Repeat 5 on local & remote system • DP Name = CAEN/*, DP Alias = Channels/*, DP Type = FwCaenChannel • Repeat 7 on local & remote system • Repeat 7 on remote system only
Test Case 7, 8 & 9 Local System Remote System Both Systems
Conclusions • Method 1 provides only method to show real “live” alert data • Method 2 is quickest but hard to extend to show “live” alert data • Method 3 is slow, but provides a possible solution for trees such as FSM tree • Method 3 could be modified to return all DPs in a group, but the PVSS function to do this groupGetFilteredDps() is too slow and limited
Proposal • Use AES directly for trivial filters – only DP Name OR DP Alias • Use Method 1 for complex filtering in Hardware AND/OR Logical view • Use Method 3 for filtering in FSM tree and others • Ask ETM if improvements can be made in DP Groups • Faster groupGetFilteredDps() • Embedding of remote system groups in local system groups • “Artificial” limit of 20 embedded groups • Poor performance to set up DP Groups – adding items 1-by-1
Next Steps • Implement prototype filtering and display for Logical and Hardware views • Before end of the year • Discuss dpGroup problems with ETM • If OK, then I produce the FW tools required to build dpGroups to match a given hierarchy • Is there a gain over traversing the hierarchy by hand?