Choose timezone
Your profile timezone:
JCOP FWWG 25 January 2018
→
Europe/Zurich
CERN
CERN
40-R-C10
Description
We would like to discuss:
1) the kickoff for the "New Alarm & Event Screen" project (Rafal)
2) the new "fwWebBrowser" subcomponent (uses WebView embedded in the panels to display web pages) - proposal to include into fwGeneral component (Damian)
3) changes in fwConfigs (and possibly also fwConfigurationDB) leading to improved performance
Present: LHCb, ALICE, ATLAS, BE-ICS
Absent: CMS, EP-DT, NA62, Compass
1) News about WinCC OA and JCOP Framework
- next WinCC OA patch P008 is scheduled for end of January (already in testing at ETM). Will be repackaged and made available for broader testing as soon as we receive it. We expect important bug-fixes to be released there
- Some releases of individual components planned at the time scale of next 2 weeks; namely, FwCore and FwConfigurationDB (with performance enhancements commented in the presentation below), FwDeviceComment, and probably also FwCaen (to be confirmed).
2) Proposal to include the new "fwWebBrowser" into the Framework Core
- Damian presented the motivation for the component (quicker, lighter way to display web content in WinCC OA, with better integration and unified look-and-feel across platforms). Demonstration was also shown. It was proposed as a common way for opening help pages, etc, not relying on external web browser.
- Concept found support from FWWG members and was approved to be included as a part of fwGeneral subcomponent of fwCore, once reviewed and outstanding requests are treated
- Request: make it possible to also hide the URL bar (ie. be able to hide all the navigation elements and only see the content)
- Proposal for enhancement: instead of double-clicking in the URL bar to open in external browser, make a context-menu allowing to also copy it to clipboard
- Request: the external browser should be configurable; [PG addition] one should use the setting for the fwCore that already exists, to define the help browser
- Review and document the security implications; what happens to cookies; what happens to "local storage"; are they kept somehow or left after the window (or the UI?) closes?
- Question about integration with CERN login pages (a kind of "Auto login") - at a first glance seems impossible to achieve. CERN SSO would however likely work
2) Performance enhancements in fwConfigs/fwConfigurationDB
- Piotr presented the proposed changes that lead to measurable improvements when configuring large amount of devices (up to 30% of speedup for the whole device-configuration process with fwConfigurationDB)
- Pointed out that the new implementation of the function that checks whether driver is running by using dpConnect should properly treat cases of remote systems that are not connected. A fallback to dpGet is proposed.
- As a general remark it was proposed that a good and generic implementation of Dp-caching mechanism would be welcome in future to avoid endless duplication of this functionality; PG clarified that such mechanism already exists in WinCCOA (dpGetCache), yet the robustness/diagnostics/limitations would need to be reviewed before recommending it; to be followed up in FWCORE-3224.
3) Presentation of the new project for the future Alarm and Event Screen
Rafal presented the concept for the project, explaining the reason being the un-maintainable state of the currently used alert table and aes.ctl. He reviewed briefly various alarm and event screens used at CERN; the ones used by the PSEN application seem to be most feature-rich. Rafal explained the key requirements and enhancements, pointing to the need for a powerful filtering mechanism that could use meta-data, and the reasons for the approach of developing a dedicated table widget based on Qt rather than proceeding with HTML5 (as was shown in the proof of concept in FWWG around 1 year ago)
The project was agreed with ETM, yet at the moment ETM cannot spend any resources on it; still it is envisaged that ETM might take it over at some stage and continue the development and maintenance. The project will be held with the help of a fellow starting at 1st of March. It is expected to have the first version with key features available in around 1 year from now.
- It was asked whether the approach of implementing all the most complex features is achievable at all. Rafal explained that the complexity or rather "richness" of features comes from the filtering mechanism, which will be required and re-implemented for proper performance anyway. In addition, if performance would be a concern, unused features should be easy to deactivate.
- It was expressed that ATLAS has its own mechanisms for filtering alarm instances between alarm screens, and it is absolutely essential to have this functionality (otherwise they would not be able to use the new alarm screen). Agreed that it would be sufficient that the functional requirement would be implemented, not necessarily using the exact implementation and mechanisms currently used by ATLAS.
- It was assured that even though many of the requirements presented are based on the alarm and event screens of the PSEN application, a round of requirements gathering will be held to determine detailed feature required by the users, with particular attention to the custom extension they implemented.
- It was reminded that in the past there were some studies of the alarm-filtering mechanisms of WinCC OA, with some documents left in various places without a real follow-up. It would be welcome to have the summary for requirements and the findings of these other documents available publicly as a EDMS document.
Next meeting: 6 February 14H00 (to be confirmed) dedicated to the status report on OPC-UA testing platform (VENUS) as well as other OPC-UA updates.
There are minutes attached to this event.
Show them.