Transcript Development of Front End Software for RadMon

RadMon Software –
From Lab to LHC
Laura Wright
Technical Student – TS/LEA
Email : [email protected]
In this Presentation…
Introduction and Overview
 RadMon Device and Tap Calibration
System
 RadMon and FESA
 RadMon Displays
 The Future of RadMon
 Conclusions

Introduction and
Overview
What is the RadMon??
The RadMon system has been designed to measure the
radiation levels at the location of equipment to :
Provide an early warning if levels are high
Identify radiation induced failures
Study variation of radiation levels
Improve shielding
Schedule preventive maintenance
Estimate remnant dose rate equipment
Adapted from slides by T. Wijnands
The life of a RadMon device…
RadMon Software in a nutshell
Needed through out the life of RadMon
Devices
 Reduces inconsistencies and work load for
testing and configuring devices
 Helps integrate with other LHC systems
for data logging and post run analysis.

RadMon Device and
Tap Calibration
System
What is it?
A web application designed to store
configuration data for RadMon devices.
 Provides tools for viewing multiple/specific
RadMon devices.
 Generates the configuration files for
RadMon FESA system.

Why do we need it?
Single point of data storage
 Reduces generation time and potential for
inconsistencies when generating
configuration files.
 Accessible from entire CERN network.

What can it do?









Add new Taps and Devices
Edit Tap and Device Records
Remove Taps and Devices
Edit multiple devices
Associate tap and device records
Create numerous reports (by point etc)
Advanced search for single/multiple devices
Tap name to binary converter
Generate and manage configuration file.
Technical Bits and bobs
Uses PHP for “active content”
 Oracle 9 backend with PL/SQL
commands.
 HTML and CSS for page formatting and
ease of maintenance.
 Centralized CERN network security and
backup procedures.

How does it work ??
7
1
HTML
2
PHP
5
3
SQL
Database
4
How does it work?
TAPDEVICEREG
PK
RMDEVICE
PK,FK1
DEVICE_NAME
SECOND_DEVICE
HW_ADDRESS
FIP_ADDRESS
WATCHDOG
RADFET_1_TYPE
RADFET_2_TYPE
RF1_CAL
RF1_OFFSET
RF2_CAL
RF2_OFF
SEU_CURRENT
SEU_CAL
SEU_OFFSET
ALARM_LEVEL
ALARM_THRESHOLD
PIN_DIODE_CONFIG
TAP_NAME
RMTAP
PK,FK1
TAP_NAME
TAP_NUMBER
LHC_POINT
SINGLE_MULTI
EXPAREA_MACH
LEFT_RIGHT
CHANGELOG
PK
ID
CHANGEDATE
CHANGE
STATISTICS
PK
ID
CURRENTACCESS
LASTACCESS
NUMBEROFUSES
LASTCONFIG
Brief Demonstration
RadMon Tap and Device Calibration System
More info sources
Technical Manual :
 (How it works and how to fix it)
 User Manual:
 (How to use the system)

RadMon and FESA
What is FESA





Integrated development framework designed and
controlled by AB.
Allows for the declaration of devices and their associated
characteristics, real time and server events and their
timing.
Automatically generates code and outlines to ensure that
systems developed on it share the same stable base.
Once declared it is the programmers job to implement
the code behind all the declared actions.
Used by many different systems inc. BLM etc.
Outline of Software Requirements





Communicate with and retrieve data from RadMon
devices located throughout the LHC and experimental
areas.
Display this data in a manner that is readable in the
Control Room
Maintain a level of stability consistent with that required
for long term usage with the LHC.
Communicate and Update displays at a rate suitable for
monitoring and detection of anomalies.
Produce a “Post Mortem” report on software failure, user
defined shut down or other predefined event.
Outline of Software Requirements (2)




Store enough data so that processing can chart tunnel
events leading up to beam dump.
Create on demand reports of radiation conditions for the
last X amount of time.
Allow “warm resets” of RadMon devices.
Allow for easy maintenance and upgrading in future
months/years.
Why do we need it?




Provide an interface between the RadMon
devices in the experimental areas/tunnel and the
Control Room
Monitor and Record the changes in Radiation
detected.
Provide a (semi) Real time display of radiation
conditions
Create “Post Mortem” reports of the radiation
conditions prior to a beam dump/ failure /
change in conditions.
Functionality
►Ongoing
► Complete
Requirement
S Comment
Communicate with
Devices
► Version for Lab which communicates with 32 devices
Display the data in
Format suitable for
Control Room
► Displays include : on screen, Mike Lamont fixed
Stability
► Depends on system use. Stability for data acquisition
and version in TCC2 which runs with 1.
display, FESA updating display. Final changes to
FESA display and ML/NH displays will be finished on
completion of specification.
and logging 1 week + , stability with logging and
subscribing – variable *.
Data Acquisition Rates
► 2hz
Post Mortem Reports
► Generated successfully- human readable form and
useful time and date stamped file name. To be
connected with PM system asap.
Current Status (2)
Data Storage over Run
► Logging files containing a percentage of all the data
received. Subscribe from FESA and ML/NH.
On Demand Status Reports
► To be confirmed as a centrally distributed system and
implemented with all other teams.
Maintenance and Upgrade
► Fully commented and D’Oxygen documented.
Timing and Synchronization
► Fully synced and timing stable at 2hz. Small sync
errors with subscription while in logging mode due.
More info sources
D’Oxygen documentation
 Generated from comments within the
code.
 Presentation :
 “Development of Front End Software for
RadMon”

Brief Demonstration
Software not available on meeting room
computer.
 Demonstrations available on request.

RadMon Displays
Types of display
Fixed Displays
 Real Time interactive displays
 On demand reports
 Application displays

Special Mentions
Nicolas Hoibian and Mike Lamont
 Generation of fixed displays
 Clients including Power converters and
RadMon

Examples.
Future of displays
Full FESA displays
 Displays in the control room
 Post run displays/application for data
analysis ??

The Future of
RadMon
Remaining issues
Timing Cards
 Post Mortem Full Integration
 Alarms
 Data Logging to LHC Database
 On Demand Reports

Where next?
For me : University to finish my degree
 For RadMon : Integration with centralized
systems
 Installation of all devices in ring
 Sector tests
 ….

Conclusions
Summary




RadMon has made a lot of progress this year.
Two very different sorts of systems developed.
Strong links built with other departments for
centralized systems.
We’ve come a long way – but still a little way to
go!!
I would like to thank the following
people…
Thijs and Christian – for being the best
team I could have hoped for.
 All the people I have had coffee with –
who have helped keep me sane when
code isn’t working exactly as intended ;)
 FESA-support and all those in AB controls
that have answered my questions (no
matter how silly they were)

Any Questions ???
Alternatively:
Email your questions to:
[email protected]