P. Chochula ALICE Week Colmar, June 21, 2004 Status of FED developments

P. Chochula ALICE Week Colmar, June 21, 2004 Outline This is a summary talk, based on presentations given at previous DCS Workshops and MAY TB As a reminder, FED architecture will be presented We will give an overview of commands and services recognized by the FED server The aim of this talk is to collect your comments –Performance tests of FED are scheduled for this summer –Generic FED API is due be released in September –FED API will be frozen in December

P. Chochula ALICE Week Colmar, June 21, 2004 Present Status FERO access model has been discussed several times –No negative feedback so far –Very useful feedback from SPD,TRD and TPC –Integration with ECS is already ongoing –Unfortunately some groups are still not familiar with the concept –We encourage detector representatives to communicate the status to software developers within your groups – FED architecture was presented to the ALICE TB (May 24, 2004) DCS focuses now on standardizing of the FED commands and services

P. Chochula ALICE Week Colmar, June 21, 2004 Reminder - FERO Access Architectures in ALICE FERO DDL ControlMonitoring Class A Class C Class D Control Monitoring FERO Non-DDL Class B ControlMonitoring FERO DDL Non-DDL

P. Chochula ALICE Week Colmar, June 21, 2004 Reminder - FED Architecture Class B,C,D Control Class A+B Control ECS DAQ/RCDCS Control CPU FERO Hardware Layer FED Server FED Client Profibus, JTAG, etc. Control CPU DDL SW FED DDL Monitoring of all classes

P. Chochula ALICE Week Colmar, June 21, 2004 Reminder - Architecture of the FED Server (PVSS) DIM Client CA1CAiMA1MAi Hardware HW access Database DIM server Services DIM Interface layer allows for communication with higher levels of software Hardware access layer contains device drivers FED Server Client Software Commands & Data Application layer contains detector control and monitoring code (agents)

P. Chochula ALICE Week Colmar, June 21, 2004 Implementing the FED Server Implementation of the FED Server remains detector’s responsibility All low-level logic (e.g. collision protection, acquisition of data etc.) is implemented in the Application layer Operational logic (complex actions such as calibration or DAQ-DCS-TRG synchronization) is implemented in upper layers, using the ECS FED server should be implemented in C++ (some architectures allow also for direct implementation in PVSS)

P. Chochula ALICE Week Colmar, June 21, 2004 Standard FED Operation OFF Configured Running Configuring Configure Re - Configure RunStop Switch-Off Error Recover

P. Chochula ALICE Week Colmar, June 21, 2004 Detector-Specific FED Operation Calibrating Configured Testing SEU Verifying JTAG Verify JTAG Calibrate Off Configure Verifying Readout Verify Readout Test SEU Some FEDs move to Configured state Some FEDs do not implement this feature at all Example: SPD

P. Chochula ALICE Week Colmar, June 21, 2004 FED Data flow FED DCS Commands Services

P. Chochula ALICE Week Colmar, June 21, 2004 FED Server API Standard command structure: –Type of command –Target –Payload Target is either the sub-detector or its part –Need for detector naming scheme Payload consists of data to be written to the FED server or a database tag (data is retrieved from DB by FED Server)

P. Chochula ALICE Week Colmar, June 21, 2004 FED Server Commands Two groups of standard commands are implemented by all FED servers –FED OPERATION commands –FED OPERATION commands allow for integration of FED with upper layers of software –FED MONITORING commands –FED MONITORING commands allow for integration with DCS (setting of monitoring and logging parameters, external triggering of FED data acquisition and debugging) Detector-specific FED commands facilitate the implementation of detector specific features (such as agent control, internal checks etc.)

P. Chochula ALICE Week Colmar, June 21, 2004 Standard (Mandatory) Commands Recognized by FED Servers FED OPERATION commands: –Configure and Re-Configure –Run –Stop –Switch-Off –Ignore FED MONITORING commands: –Set_Monitoring_Parameters (deadbands, rates …) –Start/Stop_Monitoring –Set_Messenger_Parameters (logging mode, …) –Read_Value

P. Chochula ALICE Week Colmar, June 21, 2004 Detector Specific Commands (SPD example) Verify_JTAG – to test the integrity of the bus Verify_Readout_Chain – to check the bus configuration Test_SEU – verify settings of internal registers Calibrate – perform DAC and Threshold scans Start/Stop Agents – for debugging purposes

P. Chochula ALICE Week Colmar, June 21, 2004 Services Published by the FED Server FED OPERATION service – contains data describing the status of the FED MESSENGER Service – published messages (errors, warning, debugging information) Detector related DCS DATA (temperatures, voltages, etc.)

P. Chochula ALICE Week Colmar, June 21, 2004 Standard (Mandatory) Services Provided by FED Servers FED Operation Service: FED_Status provides structured information of internal status. Published states are: –OFF –Configured (Configuring) –Running –Ignoring (published via separate channel) –Error Using the structured information provided by FED, the DCS computes the overall state for the sub-detector

P. Chochula ALICE Week Colmar, June 21, 2004 The Messenger Service Publishes information on FED server operation Each action results in a message – only requested types of messages will be published Main subscriber to Messenger data is the PVSS client Information provided by the Messenger service is logged by DCS and integrated with standard Alarm and Error handling

P. Chochula ALICE Week Colmar, June 21, 2004 DCS Data Published by FED Structure and contents of the service differs from detector to detector Published data should be grouped in a pragmatic way: –Reasonable size of data published by one service channel –Published data should be preferably organized in the same way as readout – this will simplify correlation of physics with DCS data (e.g. all temperatures from a sector serviced by the same DDL)

P. Chochula ALICE Week Colmar, June 21, 2004 Temperatures from this Sector are published as a single service channel containing 12 values Example of DCS data organization (SPD) This SPD Sector is readout by a single DDL Reminder: Numbering Convention has been approved and must be followed

P. Chochula ALICE Week Colmar, June 21, 2004 Configuring the FED Two types of configuration data: –DCS related FED Server configuration (alarm limits, monitoring rates and deadbands) –FERO configuration data (thresholds, DAC settings, etc.) FED Server configuration is downloaded from PVSS at system startup and can be modified during the operation (concept of recipes) FERO configuration data is loaded directly from the FED server in order to reduce the amount of data passed through PVSS. The configuration request originates in ECS/DCS.

P. Chochula ALICE Week Colmar, June 21, 2004 FED Server Monitoring All monitored data is published as DIM service –Standard data is published by each FED server server state information messenger service –Detector specific parameters are published by individual FED servers DCS Data acquisition is auto-triggered by FED server at predefined intervals (set by PVSS) Implemented commands allow for acquisition of DCS data on external request DCS data provided by FED is treated in PVSS as any other device data

P. Chochula ALICE Week Colmar, June 21, 2004 Device Monitoring Principle in DCS Publishing deadband Published value Acquired values Sampling interval Value recorded In DCS PVSS Alarm Limit

P. Chochula ALICE Week Colmar, June 21, 2004 Integration of FED with ALICE online systems DCS treats the FED as its sub-system FED is modeled as FSM using the FSM tools based on SMI++ Integration into ALICE online systems is done via ECS DCSDAQ/ RC TPCTPC SPDSPD TRGHLT ECS … TPCTPC SPDSPD … TPCTPC SPDSPD … FERO LVLV HVHV Gas LVLV HVHV FERO

P. Chochula ALICE Week Colmar, June 21, 2004 Present developments SPD prototype built at CERN: –SPD HW emulator –SPD FED Server –PVSS FED Client –Launched integration of FED server with FSM tools; first prototype exists (credits to Mike Swanger) SPD (PVSS) DIM Client CA1CAiMA1MAi SPD Router VISA DB DIM server Services Commands & Data

P. Chochula ALICE Week Colmar, June 21, 2004 TPC/TRD/PHOS developments Custom layer implemented and tested (credits to S. Bablock and Ch. Kofler, U. Frankenfeld, M. Stockemier) Software is implemented with real hardware (DCS board) FSM logic being implemented Agreed on prototype tests (performance, stability) Excellent collaboration between TPC, TRD and DCS teams.

P. Chochula ALICE Week Colmar, June 21, 2004 Comparing TPC/TRD architecture with the generic model DIM Server FEE Client InterCom Layer DB PVSS (DIM - Client) FEE Server Original Picture provided by WORMS group FEE Server CA1CAiMA1MAi HW access DIM server (PVSS) DIM Client FEE servers are equivalent of Agents

P. Chochula ALICE Week Colmar, June 21, 2004 Next Steps Written version of this talk will be circulated to detector groups in June/July –Detailed description of the FED concept –Implementation details of the FED server: Structure of commands and services Specifications of the Messenger –Simplified version of the SPD prototype will be provided as a generic example of working FED server and PVSS client We expect feedback from detectors, as the final FED specifications should be ready for approval in September

P. Chochula ALICE Week Colmar, June 21, 2004 What is still needed Feedback Description of detector structure –Naming and numbering scheme of detector components Description of detector operation –Calibration procedures, detector specific procedures, sequence of actions etc. Realistic estimate of published data It is essential to dedicate a person responsible for software developments and to start prototyping. FED servers must be fully debugged before we start integration with ALICE

P. Chochula ALICE Week Colmar, June 21, 2004 Test in summer 2004 We plan to launch a big test involving a big number of dummy FED servers –The aim of the exercise is to test the performance (e.g. ability of PVSS to digest the large number of parameters provided by FEDs) – this is a crucial test which has to be performed We need and estimate of data to be read from your detectors and of the update frequencies –Please provide these number by the end of July –Even preliminary numbers are much better than none By the end of July we need: –List of additional commands (if any) to be recognized by the FED –List of parameters to be downloaded and monitored

P. Chochula ALICE Week Colmar, June 21, 2004 Warning Implementation of FED Server is a very delicate task –Mixing of monitoring and control data could lead to serious problems –Performance has to be carefully studied Working FED server is just the first step, operational details are even more complex –Need for synchronization between online systems –Problems caused in one sub-system could “silently” propagate to different sub-systems without being immediately spotted (recovery procedures must be able to predict this and act)

P. Chochula ALICE Week Colmar, June 21, 2004 Conclusions After March DCS workshop and TB presentation we consider the FED as an approved approach Development now focused on API definition Our next milestone is September –Release of the structure of generic commands and services