System Monitoring and extended Diagnostics

For enhanced diagnostics of embedded frontend computers system monitoring can be helpful. System monitoring should cover running processes, the CPU load, the memory consumption, the state of the FESA software running on a FEC, the SCU bus, etc. .

Here is a collection of

• what should be monitored and
• how the FESA based system monitoring can be realized

What?

• state of running processes
• CPU load, total and per processor (Here an example implementation)
• memory consumption to monitor for memory leaks (Here an example implementation)
• FESA software status
• FESA software restart / start / stop
• SCU bus data transfer
• SCU bus component list, bus slave list, firmware version, temperature sensors, tag programming, ...
• firmware update
• WR timing receiver, status, tag programming, ...
• Programmierung der lemo-Buchsen auf SCU-Frontplatte
• ...

How?

Several approaches already exist on how to realize system monitoring for diagnostics. E.g.

• integration as standard property info FESA software
• separate FESA software which is launched in parallel to other FESA software on a FEC

To be able to decide which approach should be looked more closely at in the future this table summarizes advantages and disadvantages:

FESA Property		FESA Class
Advantages	Disadvanatges	Advantages	Disadvantages
uses global device nomenclature	Not possible to use in japc when global device is used		must be provided per FEC - would be good to automate release process
built-in per FESA class		Possible to use on FEC's which dont have real FESA devices (yet)
simple GET possible	subscriptions?	FEC Name could be used as Nomenklature
	The user needs to know which real Fesa device runs on the FEC to monitor / configure FEC parameters	No need to know about real Fesa devices to monitor / configure FEC parameters

-- SolveighMatthies - 17 Aug 2020