Define monitoring variables for gemdaqmonitor package

[mexanick]

Brief summary of issue

Define a set of monitoring variables for gemdaqmonitor package in a following form:

Block	Name	Description	Possible Values	Importance	Actions
SYSMON	FPGA_CORE_TEMP	OH FPGA core temperature	30-50C	High	In case of overheating turn OFF LV for the affected detector, raise an alarm and propagated to TC, RC and DOC

This table should be added to the gemdaqmonitor documentation

Types of issue

• Bug report (report an issue with the code)
• Feature request (request for change which adds functionality)
• Documentation update

Need-by date

Apr 15, 2020

[lpetre-ulb]

This issue was maybe open as a test before the GitLab migration, although we can start sharing ideas.

First, a question: what is the meaning of "Block" in the table? Is it a firmware block? If yes, some metrics don't have a direct corresponding block...

Also, what do you think about generating the GEM monitor documentation? The firmware address tables proved to be very successful. The information from the table you suggest would be stored in the monitoring tables.

The monitoring data flow I'm considering is the following:

1. Data is readout from the hardware through RPC modules. Those modules fill a map with the metric name and the value. It may or may not correspond to a actual register. The hierarchical separator for the monitoring variables could be / not to confuse with the address table.

2. Once the data is retrieved it can follow different paths:

• DCS with filtering/name mapping,
• XMAS with filtering/name mapping,
• Simple Web display (with colors),
• ...

The second part is controlled mainly through the monitoring tables. Path-specific files can be generated from the main monitoring table(s): JSON file for the Web GUI, C++ filters, ... The documentation would be automatically generated for the monitoring table(s).

[mexanick]

Yes, the first idea behind was example, however I tried to do it realistic :)

First, a question: what is the meaning of "Block" in the table? Is it a firmware block? If yes, some metrics don't have a direct corresponding block...

I meant logical monitoring block. In most of the cases it will correspond to FW block, but as you correctly noted, not all the time.

Also, what do you think about generating the GEM monitor documentation?

This is fine to me, however there should be the starting point. Such table as I request can be generated from address table given that all the required attributes are present there and filled accordingly. A caveat: we do not want to monitor everything, so certain selection has to be applied somehow.

The data flow you propose sounds reasonable to me and provides a nice extension of the outcome of our discussion, I fully support it.

[lpetre-ulb]

Also, what do you think about generating the GEM monitor documentation?

This is fine to me, however there should be the starting point. Such table as I request can be generated from address table given that all the required attributes are present there and filled accordingly. A caveat: we do not want to monitor everything, so certain selection has to be applied somehow.

Generating the monitoring table from the firmware address might be a good first step, but, as you wrote, it will have to be pruned down. I was thinking more about creating different monitoring XML table(s) which would be under cmsgemos umbrella rather than the firmware umbrella.

On an organization point of view, the developers and release schemes are different between SW and FW. We are certainly going to have more flexibility and faster releases in software.

On a technical point of view, the monitoring variables will probably require much more parameters than want is currently in the firmware address table. I'm not sure it is worth cluttering the firmware address table with many more monitoring-only attributes. Particularly since some metrics won't be firmware registers.

[dteague]

Google sheet with table of variables (in progress still)

all of these values are pulled from the the ctp7_module code (develop branch), the block being the name of the function call and the name being the names of keys in the returned map. I'll have to look into finding out what these values are, but this is at least a full list of what is available in the code now.

[lpetre-ulb]

Issue moved to the GitLab project.