(1)

CESAR the Cern Ea SoftwAre Renovation

Project

Vito Baggiolini, SL/CO

(2)

Outline• Organizational Aspects

– Requirements– Project phases and milestones– Methods– People

• Technical Aspects– Architecture– Java 2 Enterprise Edition– Design– Current state of work

• Conclusions

Vito

Ba

gg

iolin

i SL

/CO

(3)

Outline• Organizational Aspects

– Requirements– Project phases and milestones– Methods– People

• Technical Aspects– Architecture– Java 2 Enterprise Edition– Design– Current state of work

• Conclusions

Vito

Ba

gg

iolin

i SL

/CO

(4)

The SPS Experimental Areas• ~ 2000 physics users• ~ 6.3 km of beam lines

( SPS circumference)• ~ 1000 pieces of physics

equipment• Frequent changes

– Settings – Installations– Users

• The only place for HEP in CERN until LHC

Vito

Ba

gg

iolin

i SL

/CO

(5)

Our Users and their Requirements• EA Physicists

– Preparation & tuning of beamlines

– Maintenance of beamline settings database

– Expert troubleshooting

• Experimental Physicists– Apply beamline settings

– Collect information about machine and beamline state

• Operators– Monitoring and troubleshooting– Helpdesk, problem follow-up– Communication with all users– Admin of Experiment database

(members/privileges)

• HW Specialists & Piquet– Hardware installation, test and

diagnosis– Maintenance of hardware

infrastructure database

• All users– Take safe access to experimental zones– Browse through log files– Want secure computer access from outside

CERN

(6)

Project Phases & Milestones

Start-up 2001: “We know how to build the system”Full slice through control system in new software;

Nodal for mission critical parts and “normal” users

Start-up 2002: “We control a Beam line”New software for physicists and selected usersNodal for North Area and specialists

Start-up 2003: Production release Full functionality in new software; Nodal totally phased out

Start-up 2004: End of CESAR Project

After a 1 year of validation, amendments,polishing documentation, preparation of long-term maintenance

Vito

Ba

gg

iolin

i SL

/CO

(7)

Methods and Tools• Methods

– “Goal Directed Project Management” for organization– “Unified Software Development Process” for software– Object-oriented Methodology

• Tools– Java Enterprise Platform (same as used for E-Commerce)– CERN supported development tools and infrastructure (e.g.

PS-SL Middleware)

• Principles for choosing methods & tools– Integrate products, avoid reinventing wheel – (Industry) standards– Mainstream technology to attract good & motivated people– Support is vital

Vito

Ba

gg

iolin

i SL

/CO

(8)

People• 7 CESAR developers (30-90%)

– SL/EA: 3 operators, 1 fellow– SL/BI: 1 technical engineer– SL/CO: 1 technical engineer, 1 engineer (myself)

• 2 other team members:– 2 domain experts (EA and BI) very actively participating

• Excellent collaboration with Users/Experts– EA physicists (representing end-users)– Operators– HW specialists, Piquet

Vito

Ba

gg

iolin

i SL

/CO

(9)

Collaborations• Cesar is a collaboration between

four SL groups: EA, CO, BI, PO

• But also collaborations with– PS-SL Middleware Project– AS/IDS (“EDH people”), PS/CO: Java Tools– SL/BI: Server framework for Front-ends– Helix: Operator W2K console + Java Servers – SL/MR: help for database design

(10)

Outline• Organizational Aspects

– Requirements– Project phases and milestones– Methods– People

• Technical Aspects– Architecture– Java 2 Enterprise Edition– Design– Current state of work

• Conclusions

Vito

Ba

gg

iolin

i SL

/CO

(11)

CESAR Architecture

Beamline

Graph. UserInterfaces

Scripting Facility

Se

rve

rF

ront

end

sU

ser

PC

Middleware

Middleware

Collim. MagnetWire-

chamber

Co

mp

ute

r S

ecu

rity

Motor Data Mod.

MageaData Mod.

WireChData Mod.

Timing

TimingModule

“3-Tier Architecture

”

Settings & ConfigDatabase

TuningTasks

Surveillance Programs

Expert Programs

Access Programs

(12)

Java 2 Enterprise Edition (J2EE)• What is J2EE?

– The standard way of building 3-Tier Java applications– A recommended architecture + development guidelines– Aimed at electronic commerce applications– A “container” in which to run your application – The container does all the “difficult things”…

…developers concentrate on domain-specific functionality

• The “difficult things” you don’t need to develop– Integration Objects + Relational Databases– Automatic persistence– Resource management (memory, threads, DB connections, …) – Security + Access control

• J2EE is “The” Open Industry Standard for Enterprise Applications

– “Application Servers” are available from over 30 vendors– All major players + Open source initiatives

(13)

Middleware

Middleware

Recommended J2EE ArchitectureS

erv

er

Fro

nte

nds

Use

r P

C

Appl Server (“Container”)

EJBean 1 EJBean 2

Web Browser

Web Server

Relational

DataBase

Existing Applications

Graphical UserInterface

(14)

Appl Server (“Container”)

CESAR J2EE Architecture

Beamline EJBean

Graph. UserInterfaces

Scripting Facility

Se

rve

rF

ront

end

sU

ser

PC

Middleware

Middleware

MotorEJBean

MagnetEJBean

Wirech.EJBean

Motor Data Mod.

MageaData Mod.

XWCAData Mod.

TimingBean

TimingModule

Relational

DataBase

(15)

Glossary• J2EE: Java 2 Enterprise Edition

– Standard Java Platform to build 3-Tier applications

• 3-Tier Application -- an application in 3 layers: – Graphical User Interface on User PCs– Stable Core functionality on Servers – Hardware access on Front-end computers

• J2EE Application Server– A software platform that implements the J2EE Standard

• Enterprise Java Beans (EJB) or simply “Beans”– Software components running on Application Servers

• Bean Container– The part of the application server that contains the Beans

(16)

Graphical UserInterface

WC 2Config

App Server (Container)

Middleware

WireCh D.M.

Physics User

Lets work with

WireCh 2...

Middleware

HV Controller 2HighVolt

Wirechamber Graphical User Interface

Start WireCh. GUI Panel

WireCh 2setHv()getHv()

getProfile()

CreateWireCh. Bean

Work!

Connect toContainer

Persistence

E.g. check/updateHardwareConfiguration

Load its settings RefHighVolt

(17)

App Server (Container)

Extrapolation to Beamline Settings

Middleware

MotorDataMod.

MageaDataMod.

MotorDataMod.

Middleware

Beamline Control Graphical User Interface

HardwareConfig

Beamline Settings

Beamline Layout

Work onH2...150 GeV e-

Beamline H2 Layout = [ Tax1,Bend1, Coll3, …]

H2 = [ Tax1, Bend1, Coll3, …]

150 GeV e-

Mot5

Tax1 Bend1 Coll3

Mot3 Mot4

150 GeV e- = [ ]

(18)

Extrapolation to Beamline Settings

App Server (Container)

Middleware

MotorDataMod.

MageaDataMod.

MotorDataMod.

Middleware

Beamline Control Graphical User Interface

HardwareConfig

Beamline Settings

Beamline Layout

Beamline H2

Layout = [ Tax1,Bend1, Coll3, …]

H2 = [ Tax1, Bend1, Coll3, …]

150 GeV e-

Mot5

Tax1 Bend1 Coll3

Mot3 Mot4

150 GeV e- = [ ]

(19)

Middleware

WC 2Config

Claude, HW Specialist

Login: ClaudePassword: ******

WireChamber Graphical User Interface

WireCh D.M.

WireCh 2setHv()getHv()

restoreHv()

Middleware

RefHighVolt

HV Controller 22HighVolt

Security Service

Claude is is a known user;Role: Specialist

Specialistsare allowed touse setHv()

Set Hv to 2 kV!

Access Ctrl (1)Tune

WireCh 2

(20)

Middleware

WC 2Config

Jean, Observer

Login: JeanPassword: ******

WireChamber Graphical User Interface

WireCh D.M.

WireCh 2setHv()getHv()

restoreHv()

Middleware

RefHighVolt

HV Controller 22HighVolt

Security Service

Jean is is a known user;Role: Observer

Observersare not allowed to use setHv()

Set Hv to 20 kV!

Access Ctrl (2) Play with WireCh 2

STOP

(21)

3rd Party Products• J2EE Application Server

– Now: Borland Application Server (for ~ 1 year)– Soon: Oracle Application Server (same as EDH)

• Oracle database• Framework for building GUIs

– Based on “Netbeans” Framework (open source)

• PS-SL Middleware• Biscoto server framework + BI expert panels

(22)

Design• Simple concepts

– intuitive Architecture– simple development guidelines

• Strongly typed– Class hierarchy with few base classes at the top– Many classes ~300 (many related classes)– Equipment-specific classes

• Applying Design Patterns

(23)

Equipment-specific Classes

MagnetPanel(GUI)

MagnetStatus(information)

MagnetEJB(persistence)

MagnetDm(Eq access)

uses

uses

creates MagnetTable

displays

persistence

(24)

Current State of Work (1)• Requirements

– List of all (?) use cases – Relevant use cases described in detail– GUI sketches

• Analysis & Design– Relevant use cases analyzed – Architecture mostly described in UML– “Base classes” agreed on and documented in UML

• Miscellaneous– Coding conventions– Glossary

(25)

Current State of Work (2)• Prototypes

– EJBs + Database tables for 80% of equipment (physics functionality only)

– Access system (second prototype)– GUI Panels for status display and surveillance– GUI Framework + First Explorer prototype

• Operational products– Spectrometer with Momentum analysis– Timing distribution via Middleware– Direct equipment access from Java– Scripting language (Jython)

(26)

Conclusions• Excellent team spirit and collaborations• Good progress

– Architecture settled– Prototypes for functionality due in May– No delays for start-up milestones foreseen (yet ;-)

• Using Mainstream technology – Object methodology and Design Patterns– Java 2 Enterprise Edition

• And existing products– J2EE Application Server, Oracle, Netbeans, Jython– Middleware, Biscoto, …

(27)