SV: Generating metrics for IOC applications

[Anders Lindh Olsson via Tech-talk <tech-talk at aps.anl.gov>]

Hi Ralph,

We get most of this from our infrastructure: we have an IOC management toolchain ("controls ecosystem") that keeps track of all of our IOCs, we use ChannelFinder for record counts but also to carry other metadata of interest (e.g. record type and access group), and we get the EPICS modules used by an IOC from require. We store all metric data in prometheus. We cannot (yet) do bullets 2 and 3, but I think it should be technically doable. We occasionally "grep" through IOC and/or EPICS module repositories to generate reports. I can show you some of this if you are interested.

In your case, I think manual reports from text search in IOC repositories might be the way to go. You could also build some sort of crawlers - collection scripts on/targeting the hosts whose data is aggregated in some centralised db.

HTH

A

---

Från: Tech-talk <tech-talk-bounces at aps.anl.gov> för Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Skickat: den 1 mars 2024 18:38:25
Till: Stephane Tzvetkov
Kopia: tech-talk at aps.anl.gov
Ämne: Re: Generating metrics for IOC applications

 

Hi Stéphane,

Thanks a lot for your detailed explanations!

I know some of the tools (we're even using a few of them), but there were a lot of new ideas and pointers. Cool!

My interest in this case, however, is really focused on obsolescence management. Completely off-line, no running system needed.

We will have 170 separate EPICS applications and need to decide where to start our maintenance: updating OS version, updating EPICS Base, updating Device Supports, re-writing user-supplied code.

What I'm searching for is between simple record counts and static code analysis, for an EPICS application.

Intermediate metrics could be things like

• total number of records
• number of links between records
• number of links connected to hardware
• which hardware (list of device support modules needed)
• number of calc/calcout records
• number of subroutine records and number of lines of code connected to them
• number of state machines and number of lines of SNL code they run
• ...

And then some magic formulas that spit out some size, complexity and quality indices for each of the applications and - obviously - the number of man-months needed to bring them up to the "current" standard (whatever that is).

There will always be a lot of manually collected data, factors based on experience, and additional personal judgment necessary in such a planning process, that's very clear.

But I would like to get as much data as possible out of the applications themselves. To help the judgment and allow better comparison between applications. Base things on data.

Cheers,
~Ralph