Status of the Brick Manipulation database development

1. Status of the Brick Manipulation database development D.Duchesneau LAPP, Annecy • Introduction: goal and principles • System analysis • The brick life • Manipulation procedures • Proposed design • Development phases • status • Conclusions OPERA collaboration meeting May 21st, 2003

2. Introduction:Goal • Main functions of the computing system under development should be: • To manage the life cycle of the bricks and the manipulation information • To save the relevant information into a database But the BMS will manipulate entities composed of a brick and a CS • The tracing and the control of the brick and CS manipulation: • Start: first entrance on the manipulator • Finish: when the brick is dismantled for development Multi localized activity: the system should take into account all the procedures occurring in different places!

3. Introduction:system main requirements • During initial SM filling: • To know the detector cell status: free or full • To know the presence of a filling basket to proceed • During OPERA data acquisition: • Communicate to the BMS the list of bricks for daily extraction • Keep track of the brick life from insertion to development • At any time: • To know status of any brick (position within the detector), actual manipulation…. • To get complete history of a given brick • To get complete history of a given detector cell • Display the wall content • To know the BMS status • To get the detector geometry and cell localization ?

4. The Brick life Loading station Load the replacement /new bricks Fill the walls Unload the bricks to analyse Extract brick for analysis; insert replacement brick BMS Target walls Unload the extracted brick Bring the bricks to reinsert CS separation Shielded area Stock of bricks to reinsert CS transport Brick waiting CS Analysis negative Add a new CS from the stock Development laboratory Scan results Scanning laboratory Scanning laboratory positive Brick emulsion analysis Brick transport Cosmic bench Development laboratory Analysis zone Brick Assembly machine Loading basket Transport to the support Physical place action results Physical movement

5. Brick and CS Manipulations occur • at many places • by different actors (humans, computer systems…) which should be identified as function of their actions • each time the brick status is changing or moved to an other place: • need to collect, incorporate, update brick and CS information….in the system and save in database the information • Important to: • define the procedures involved in manipulation • construct the use cases for each actor and the sequence of actions (sequence diagrams) • Define now the information to be provided and saved by all external users!

6. Example: shielded area (waiting zone) 1. BRICK UNLOADING and CS DETACHING 3. CS GLUING AND BASKET INSERTION Identify a brick to unload: read the bar code of a brick in the loading basket in the row 1 to 5 starting from 1st position Glue a new CS on a free brick in this zone according to the rules 2. CONSULT THE CS RESULTS FOR DECISION Read the CS and brick bar code Identify a brick to reinsert: read the bar code of a brick waiting for scanning. Move the brick to the CS gluing zone Take the brick In the available basket: insert the brick in row 6 to 9 starting from the first free slot. Identify a brick to analyze: read the bar code of a brick waiting for scanning. Put the brick in a stock to be sent to cosmics. Detach the CS validate Read the CS bar code Information source: code bar readers (mandatory) new CS CS to analyse Transport belt cart displacement controlled by the brick operator Development : these CS are transported by the brick operator or a physicist for development Towards cosmic bench before development.

7. Operator user interface

8. The core of the system is called « Brick Manipulation Manager »or BMM. Its tasks are: • communicate to the supervisor all commands and actions from the outside world • retrieve the data which will be used to update the database information. • do the communication with the external systems (OGC, BAM, cosmic bench , CS analysis…)

9. <<subsystem>> BAM <<subsystem>> (OGC)OPERA Global Control <<subsystem>> OPERA On Line System <<subsystem>> OPERA Scanning System <<subsystem>> Brick Manipulation Manager(BMM) Manipulator Interface Scanning Interface Manager Interface BAM Interface <<subsystem>> Supervisor/ Manipulator Links between the various computer systems involved in the brick manipulation <<uses>> <<uses>> <<uses>> <<uses>>

10. Main actors of the BMM system: Function inheritance Opera General User ? Brick Operator Loading/Unloading Operator Opera Global Control On-line Common Operator Physicist

11. Development phases • Design of the brick management system (analysis) • Use cases and user need studies • Constraint studies (data availability, coherence, OS, inputs, outputs) • Sketch the procedure schemes(as shown) • Communication with the supservisor system • Define the commands to exchange between supervisor and BMM • Study and create the interface • Define communication protocol and programming language (interfaces and BMM) • Study and development of the users interface (as shown) • Create the database structure with ORACLE • Develop tools for DB exploitation • API (« Application Programming Interface ») • Information display • Monitoring (ex: aver. time delay between extraction and CS decision)

12. Status: • The manipulator database project has started beginning of 2003. • The team is composed of 2 software engineers (not full time) from LAPP and myself. • 1 student from a Technical Institute (production management department) is working with us and proceeds in understanding the procedures and the system analysis (should finish end of june). • For such a system: • analysis following the Unified System Development Process (USDP) method using the Unified Modeling Language (UML): • Advantages: • Priority is given to the definition of the different actors of the system (with hierarchy, functions…) • then to the definition of the use cases • objects and object classes appear naturally

13. detector +1 Work plan +4 Half super module +1 +31 operations Brick manager wall +1 +64 components Bar code reader Position manager row +1 CS +26 +0,1 +0,1 +0,n +0,1 cell brick basket Example: Some object classes which will appear in the database With their composition and association

14. To access the brick information stored in Database Design of Graphical User Interfaces:

15. Conclusions • Work has started! • The BMS database includes more than just the manipulator informations • It is crucial to understand now how the bricks will be treated during their lives • Procedures should be clearly defined asap • BMM concept seems adapted for the brick and CS manipulation management • BMM need interfaces with external systems (to be discussed tomorrow) as well as the OPERA standards (language …) for those kinds of developments