100 likes | 223 Views
The ECS project. ECS “culture” in ALICE Some initial ideas on the ECS architecture Project scope Development method People involved Tools Schedule. ALICE-ECS culture. Discussions and attempts made between 1997 and 1999 jointly by the DCS and DAQ.
E N D
The ECS project ECS “culture” in ALICE Some initial ideas on the ECS architecture Project scope Development method People involved Tools Schedule ALICE Technical Board
ALICE-ECS culture • Discussions and attempts made between 1997 and 1999 jointly by the DCS and DAQ. • Some early prototypes in 1999: times were not mature. • New DCS group continued the reflection. • New thrust coming from TPC. • The basic principles are broadly shared in ALICE • We do not start from scratch 1999 2002 ALICE Technical Board
The ECS principles • The control architecture is hierarchically structured in layers. • The ECS is the top supervisory layer but... • The system is not monolithic. Each application is autonomous. • Each layer is in control of the layer below(authority and responsibility). ECS • No cross-level control path • No level hopping • Well-defined inter-level interface is necessary • The ECS project starts on these assumptions DCS Trigger CS DAQ run control HLT control Pixel Muon TPC Pixel Muon TPC Pixel Muon TPC CTP HV Gas Pixel lTU Muon LTU TPC LTU LDC 1 LDC 2 LDC 216 ALICE Technical Board
Initial ideas on ECS tasks • Manage system partitions A partition is a set of owned resources that constitute a usable system, where operations involving trigger, DCS and DAQ can take place. Resources may be detectors, machines, network channels, recording devices. • Maintain a resource database. • Allocate the resources to a partition and manage the resource sharing. • Create a partition run-time environment encompassing the available resources. • Manage partition operating modes The operating mode is the collection of working conditions. • Maintain a database of settings and actions to be performed. • Take actions for setting-up. • Supervision of data-taking in partitions Data taking are periods of time where the operating mode must be stable. They have a beginning and an end. • Maintain a database of actions to be performed and conditions to be met. • Take actions to begin and end data-taking. • Perform surveillance on condition stability and alarms. • History • Keep track of past operations. • Log book. ALICE Technical Board
Initial ideas on ECS architecture ECA Experiment Control Agent Maintains resource and partition database. Allocates resources to partitions. Partition Control Agent Creates the partition environment. Database Database Resources, partitions, modes, actions and relations. Partition Control Agent Handles partition configuration. Performs setting-up procedures. Supervises data-taking. Partition A Partition B PCA PCA DCS Trigger control DAQ run control DCS Trigger control DAQ run control ALICE Technical Board
Project scope The ECS project aims at the following deliverables: • To define the schema of the ECS database - describing resources and partitions. • To develop the ECA, which interactively manipulates the database. • To elaborate the concept of partition environment, where applications run transparently. • To develop the PCA, which creates the partition environment. • To develop the control functions of the PCA: configuration, setting-up and data-taking supervision. This is the module in control of DCS, trigger control and DAQ run control, but preserves their autonomy. The actual implementation may proceed bottom-up. ALICE Technical Board
The development method • Agile method based on cyclic development of prototypes • Low ceremony, lean development. • Working system v/ documents production. • Maximize work not done. • Adaptive v/ predictive • Incremental and iterative (fast cycles). • S/w writing is creative: system not fully-specified after design. • No fear of changes. • People oriented v/ process oriented • Use the right know-how. Self-organising teams. • Pair programming - never leave developers alone. • Core team. • Involvement of end-users in the development • They bring requirements and set goals. • They participate in the development. • They test prototypes and bring feedback. ALICE Technical Board
People involved Core team belonging to the DAQ group Franco Carena Jean-Claude Marin Sandro Vascotto DCS André Augustinus Giacinto de Cataldo Peter Chochula Lennart Jirden TPC Uli Frankenfeld Reiner Renfordt Trigger David Evans Anton Jusko Ivan Králik Roman Lietava Orlando Villalobos Baillie Other detectors will be contacted in due time ALICE Technical Board
Tools ECA The database is the core of the system. No ad-hockery. Standard DBMS needed. A good candidate is MySQL. Finite state machines are the most appropriate paradigm to represent the system behavioural aspects. SMI++ is already in use by all the people involved. The communication between the PCA and its lower layer is critical to assure the autonomy of the applications. The SMI paradigms (object-status-action and domain visibility) are preferred by all the people involved. Human interface. Some like Tcl/Tk, some PVSS. The human factor has top priority. Database PCA DCS Trigger control DAQ run control ALICE Technical Board
Activity and schedule From now to end 2002 (core team available 25 %) Setting the scene Setting-up development environment and tools Brainstorming and early prototypes January to March 2003 (core team available 80 %) Development of TPC partition prototype (PCA) April 2003 (core team available 100%) Commissioning TPC partition Development of HMPID partition prototype (PCA) 28 April - 7 May 2003 TPC test May - June 2003 Test of HMPID partition Integration of trigger control June 2003 onward Develop partitioning (ECA) End 2003 Deliver full prototype ALICE Technical Board