Transcript GAN: Hardware considerations - MDI

GAN: remote operation of
accelerator diagnosis systems
Matthias Werner, DESY
MDI
GAN challenges for
hardware remote service
Question: why the expert has to be himself at the site to
commission his component? Because he has to…
• reboot the system, monitor error messages during the reboot
process while remote access is not yet running
• change software, CPU settings (e.g. IP address) and FPGA
configurations
• change jumper settings
• calibrate offsets or amplification factors
• do oscilloscope measurements: at inputs and outputs, sometimes at
internal test points
• check temperature and operating voltages
• replace hardware components
• analyze electromagnetic interference from / to other devices
• Look, feel and listen: correct cable type? Correct cabling? Fan
running? Dust? Vibrations? LEDs on front panel flickering or
displaying a certain state?
Hardware components
• Use remote controllable elements for
trimming (avoid mechanical
potentiometers)
• Replace jumpers by electronic switches
• Implement selftest if possible
Remote Software and FPGA
configuration upgrades
• Make remote software and FPGA upgrades
possible
• Proposal: if the system is rebooted after a
change and it is not validated as „good“ by the
specialist during a certain time, it should fall
back automatically to a defined software state to
guarantee accessibility – see comparable
Microsoft feature after changing the computer
display resolution
• Other methods to guarantee accessibility?
Remote: CPU reset, power on /
off, serial monitor
• Extra web server which is able to reset the
CPU and hardware and/or to switch the
crate power on and off
• This web server should provide a serial
connection to monitor the CPU startup
process before the CPU can communicate
over the network – only applicable to
CPUs with serial monitor interface.
Internal and external status
Implement remote check of:
• Temperature
• For special cases: noise, vibrations (use microphone)
• Supply voltage (absolute value, ripple)
• Supply current
• Presence and structure of input signals
– External clock (frequency?)
– External triggers (rep. Rate?)
• Important internal signals:
– Internal clock running
– Others, depending on system
Internal data logging
• Log commands from and data to the control
system including timestamps
• Log all(?) input and output signals (analogue
and digital)
• If possible, log backplane and bus signals (VME,
CAN)
• If possible, use an extra analyzer FPGA (with
enough memory) for analysis and combination
of inputs, outputs, commands, data
• Memory contents must not be erased by reboot!
Post mortem recorder
• If applicable, implement a circular buffer
recording relevant data which is stopped
when beam is lost to allow diagnosis about
beamloss reason
Oscilloscope interface
• If the device deals with fast signals,
implement a dedicated oscilloscope
interface (with trigger and reference
signals and monitor outputs) for remote
analysis under unknown conditions,
operated by a non-expert.
Need for a contact person
Contact person has to
• Speak a language known to the developer
• Know the system roughly
• Be interested that the system is operational
• Normally be near the place where the system is
located
• Have enough time to service the system if
necessary
• Be able to operate tools like oscilloscopes
needed for service
Human communication
• Video conference?
• Video communication for 2 persons?
• Special document exchange (2 persons
writing on a common drawing area on the
computer screen?)
• Phone calls?
• Photos of the environment?
• Short videos?