1 Control Room Model 4 Types of control rooms  Field Control Room (FCR): for example operating near the equipment in USA15. Expected to be needed throughout the whole commissioning phase and, in reduced mode, later as well (e.g. test a ROD crate).  Detector Control Room (DCR): for example operate a detector partition from a room on the surface (a barrack) during stand alone detector commissioning. The main functional difference with respect to the FCR is that the DCR may include multiple workstations (Pcs) in order to support multiple humans working concurrently as a team.  ATLAS Control Room (ACR): the main control room in SCX1. It will be used to operate combined detector operations, the whole experiment and to access the safety and external systems (e.g. CCC), the access control system as well as any other service that is NOT partitioned (= of which a single copy must be run)  Remote Control Room (RCR): with a twofold purpose R/O access (e.g. web based) to control/operational information it may be envisaged that some of the ACR functions may be exported to locations remote to IP1 (e.g. elsewhere at CERN or to an external laboratory).

2 Functions Categories of functions [non exhaustive examples]  Infrastructure/Data bases  DCS  TDAQ Needed at different control room levels  Core --> always available  Detector level --> add functionality releveant to a sub-detector  ACR level -> full functionality  Remote -> controlled export of functionality  Web R/O -> Authorized R/O access to information Needed with different “privilege” [non exhaustive examples]  R/O privilege, get status information  Write privilege: use application to execute a modification  Execute privilege: start a run In different contexts [Non exhaustive examples]  A ROD crate  A detector partition  Overall experiment

3 Functions

4

5 Ingredients: network ATLAS Technical & Control Network at P1 (ATCN) Spans underground & surface buildings Architecture features:  Redundant backbone between underground & surface  Sub-networks (e.g. sub-system oriented) Connecting to backbone Factorize traffic on sub-network basis by means of e.g. local servers  Isolated, better “isolatable” Gateways to CTN, CPN, Tier-0 (this latter with caution) Connectivity rules  Regulate which machine can connect (e.g. a machine connects if it has a function)  Provide “standard” laptops, to users, with free connectivity

6 Ingredients: Authorization Simple authorization: user login  Identify user. Not enough Multi-dimensional problem:  Who the user is  What is her function today (see underground access problem)  E.g. On operational shift  What is the context E.g. On shift for the Tiles calorimeter Allowed to use “detector” functions limited to “Tiles” context

7 Ingredients: Authorization Default: Allowed to use “detector” functions limited to “Tiles” context However:  May need additional functionality E.g. now I need to operate the HV  Which could be granted dynamically E.g. by the shift leader Similarly, remote users may be identified and granted the capability of executing functions

8 Ingredients: User interface Once authorized, what does the user get?  Not a “login” Access to a standard console interface, through which the authorized functions can be accessed  E.g. active buttons for authorized functions (viz. Logbook)  E.g. inactive buttons for unauthorized functions (viz. DCS) What follows is JUST AN EXAMPLE FOR THE PURPOSE OF ILLUSTRATION

9 LHC SPS DAQ Access DSS DCS CPS calendar manualsTO DO LogBook TOOLsTOOLs PLOTsPLOTs ALArMsALArMs

10 Control rooms

11 Beyond brainstorming. A shopping list Control room architecture  To be defined in a coherent high level design Including a plan of when to provide what feature Ingredients  To be addressed seriously: requirements than designs Network gateways Functions & categories of functions Authorization system Existing applications: to be retrofitted into the model (authorization in particular) Console organization: the core, the laptop Console software Prototype:  The FCR, I.e. the laptop for the early commissioning work  needed with some urgency

12 Beyond brainstorming Expertise is “scattered” in various activities, sub-systems There is a, certainly non exhaustive, shopping list Form a working group, with  participants from those activities where expertise is located  Participants interested to join the control room activity Neither a “design group” nor an implementation group Bring in expertise from a project/sub-system Improve on the model/architecture/list Take out (to the project/sub-system) the development  Which could also include the design “commissioning” would be the initial, main customer  Commissioning would also be a driver for the implementation schedule From “simple”, early, commissioning work To the operational experiment