Status of FED developments

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

2. 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

3. 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

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

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

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

7. 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

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

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

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

11. 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

12. FED Server Commands • Two groups of standard commands are implemented by all FED servers • FED OPERATION commands allow for integration of FED with upper layers of software • 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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

20. 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

21. 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

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

23. 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 ECS DCS DAQ/RC TRG HLT SPD TPC … SPD SPD TPC … TPC … LV LV HV HV FERO FERO Gas P. Chochula ALICE Week Colmar, June 21, 2004

24. 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 Commands & Data Services DIM server DB CA1 CAi MA1 MAi VISA SPD Router P. Chochula ALICE Week Colmar, June 21, 2004

25. 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

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

27. 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

28. 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

29. 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

30. 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

31. 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 P. Chochula ALICE Week Colmar, June 21, 2004