The BISCoTO Project

1. The BISCoTO Project Beam Instrumentation Software Common Template and Organization SL-BI-SoftWare Section: Ana Guerrero - Henriette Hiller - Stuart Baird - John Fullerton - Jean-Jacques Gras - Stephen Jackson - Lars Jensen The BISCoTO Project Presented to PCRSWM on 9/11/2000

2. Purpose • Encourage collaboration inside the Software Section in order to balance the usual split imposed by the different BI software projects. • Share the same technical knowledge and language within the Section. • Improve our software development methods in terms of efficiency, reliability and maintenance. • Ease transition to new SL/CO standards (Middleware, CPUs, RTOS...). The BISCoTO Project Presented to PCRSWM on 9/11/2000

3. Scope • The migration of the remaining Themis/OS9/SL-CO-RPC platforms to PPC/LynxOS/?SPS2001?. (Front End Server and Expert/Operational GUIs). We can only fit this extra activity in the 2 next shutdowns. • Future BI software support, development and maintenance. • SPS 2001 Compliant Software. • STOPMI Compliant Software. The BISCoTO Project Presented to PCRSWM on 9/11/2000

4. Objectives • Develop a basic and condensed set of common tools, interfaces and libraries. (These developments will be based on C/Posix.4 for the front end and pure Java for the GUIs in order to be as platform independent as possible.) • Based on these interfaces and our experience, develop a BI Front End System Skeleton SPS2001 compliant. • Based on these interfaces and our experience, develop a BI GUI skeleton for this server for our Expert Interfaces. • Use this new infrastructure to migrate the instruments still under Themis/OS9/RPC platforms during 2000/2001 and 2001/2002 shutdowns (Servo Spill, Fast Spill, Fast Pos, Colmon, BTVP, SPS Matching, Scrapers...) The BISCoTO Project Presented to PCRSWM on 9/11/2000

5. How does an average BI Front End System Work and Look Like [1/2]? • It is a VME crate(let forget the rest for the moment) with: • One SAC, One CPU. • One (or more) Synchronization Card (TG3/8, BSTR, …) • BI Acquisition and Control Cards specific to the instrument. • Many different instruments can share the same crate (obviously to spare money). • Many Items of the same instrument can share the same crate (up to 4 for the BTVP’s or 64 for the collimators). The BISCoTO Project Presented to PCRSWM on 9/11/2000

6. Misc Misc Acq N Acq 1 Creator 2 Creator 1 SLEquip Srv Comm Srv SLEquip/RPC/TCP Timing ... Tg8 HW HW HW HW How does an average BI Front End System Work and Look Like [2/2]? The BISCoTO Project Presented to PCRSWM on 9/11/2000

7. Where could we Merge? • On Common Functionality: • The Creator. • The Process Synchronization (for 90% of the cases where µs response time are not needed). • The Process Progress Logging… • On Common Inter Process Communication: • Use Message Queues for Commands and Synchro. • Use Shared Memories for Data. • On Common Communication Interface with the Outside World (we have to deal today with TCP/[RPC]/SLEquip/SPS2001/CESAR). • On Common Rules, Interfaces and Standards whenever possible (Error Handling, MSQ, SHM, Logging, Synchro…) The BISCoTO Project Presented to PCRSWM on 9/11/2000

8. Common Rules, Interfaces and Standards • Relies on the C BISCoTO.a [.h] library (LynxOS only) and a set of rules on how to use it. • Based on POSIX.4 standard for portable real-time programming and a set of necessary goodies provided by SL/CO (ms timer, MTG access, direct VME access, eventually standard DMA…) • The goal there is to allow painless platform evolution by clearly specifying our needs. ‘We understand SL/CO can not keep the same platform for ever but if you provide a gcc/Posix.4 compliant RTOS with these goodies we’ll have a chance to have a painless migration. The BISCoTO Project Presented to PCRSWM on 9/11/2000

9. Common Rules, Interfaces and Standards • These Library functions have been tailored to our Front End Software Needs. • By ‘Tailored’, we mean: When an option, a flag is notnecessary, we Hide it (set to the adequate default value) deep in the library. • All future BI Front End Software will be based on this library. The BISCoTO Project Presented to PCRSWM on 9/11/2000

10. The BISCoTO Library Deals with: • Error Handling [bisw_Err_xxx()]. • Time Stamping [bisw_TStamp_xxx()] with a micro sec. resolution. • Time Out [bisw_TOut_xxx()] with a milli second resolution. • Timers [bisw_TimMs_xxx()] with a milli second resolution. • Process/Thread Priorities [bisw_Prior_xxx()]. • Message Queues [bisw_MsQ_xxx()]. • Shared Memories [bisw_ShM_xxx()]. • Process Activity Logging [bisw_Log_xxx()]. • Common Communication Interface [bisw_Comm_xxx()]. • Process Synchronisation [bisw_Sync_xxx()] (with MTG, BST, external request...) The BISCoTO Project Presented to PCRSWM on 9/11/2000

11. Simple example: Priority Handling PRIORITY This set of functions handles priority. We defined 5 different levels of priorities with the following properties and usages in our context: The God Priority: It correspond to Normal Priority plus 2 and a FIFO type of scheduling which mean that once the process takes the hand, it won’t leave it till a process with higher priority wakes up. This priority should be used with a lot of care and is reserved in our context to critical and short code of the Acquisition processes. The High Priority: It correspond to Normal Priority plus 1 and a FIFO type of scheduling which mean that once the process takes the hand, it won’t leave it till a process with higher priority wakes up. This priority should be used with a lot of care and is reserved in our context to the Timing and Dispatcher processes. Normal Priority: It correspond to a Round Robin type of scheduling which mean that once the process takes the hand, it will give it up to a process with higher priority or to a process with the same priority after a system define delay (20 ms. usually). This priority is the standard one and it will be used in our context in the Communication and Acquisition processes. Low Priority: It correspond to Normal Priority minus 1 and a Round Robin type of scheduling which mean that once the process takes the hand, it will give it up to a process with higher priority or to a process with the same priority after a system define delay (20 ms. usually). This priority is will be used in our context in the Creator and Logging processes. Agony Priority: It correspond to Normal Priority minus 2 and a Round Robin type of scheduling which mean that once the process takes the hand, it will give it up to a process with higher priority or to a process with the same priority after a system define delay (20 ms. usually). This priority is pretty weak. The BISCoTO Project Presented to PCRSWM on 9/11/2000

12. Function call Example bisw_Prior_High Synopsis #include <BISCoTO.h> int bisw_Prior_High (void); Conditionality None. Description Bisw_Prior_High is used to set the priority of the calling process to High level. Return values BISW_OK if successful. Returns BISW_PB if not. The external variables int Bisw_ErrNo, char *Bisw_ErrMsg will respectively contain the computer and human description of the problem. Errors Any other defined by the System (equivalent to errno and ERRMSG(errno)). The BISCoTO Project Presented to PCRSWM on 9/11/2000

13. Common Functionality: The Creator • The Creator process has been written once for all. Based on a config file, it will: • Sequentially launch processes. • Wait the OK from the previous process before to launch the next one. • Survey them (and Log) when requested in Config. • Relaunch them (and Log) when requested in Config. The BISCoTO Project Presented to PCRSWM on 9/11/2000

14. Common Functionality: The Logging • The Logging process has been written once for all. It will be used by the other processes via MsQ to Log on files their progress or problems. The advantages are: • Write to a MsQ is quicker than to a file through NFS. • The Real Process is not bothered if NFS is stuck. • The Logging run on a low Priority and does not bother the other processes. • It is dynamically and remotely possible to control the ‘Debug Level’ of a process [BISW_LOG_FATAL, BISW_LOG_ NONFATAL, BISW_LOG_ WARNING, BISW_LOG_ STATUS]. • It is dynamically and remotely possible to ‘merge’ many process logging into the same file keeping the sequentiality of the messages. The BISCoTO Project Presented to PCRSWM on 9/11/2000

15. Common Functionality: The Logging bisw_Log_MkEntry Synopsis #include <BISCoTO.h> int bisw_Log_MkEntry(char *logName, int debugLevel, char *logEntry, ... ); Conditionality None. Description Bisw_Log_MkEntry is used to make entries to a log. It works like the printf() family of C calls. A log entry string may contain any of the formatting commands understood by printf and the bisw_Log_MkEntry() function can accept an arbitrary number of arguments. Return values BISW_OK if successful. BISW_PB if not. The external variables int Bisw_ErrNo, char *Bisw_ErrMsg will respectively contain the computer and human description of the problem. Errors Any other defined by the System (equivalent to errno and ERRMSG(errno)). The BISCoTO Project Presented to PCRSWM on 9/11/2000

16. Common Functionality: The Process Synchronization • The Timing process for the TG8 has been written once for all. • It will be used to handle one TG8 card for all the crate. • No other process will access the TG8. • It deal with interrupts and front panel hardware pulses. • The Timing Dispatcher has been written once for all. • It will handle one instrument (ie all its items). • It will receive subscriptions from the acquisition processes of this instruments and transmit them to the right timing process (TG8_1, TG8_2, BST…). • It will transmit these events to the acquisition process when they occur. The BISCoTO Project Presented to PCRSWM on 9/11/2000

17. Common Functionality: The Process Synchronization • The Interests are the following for the developer to synchronize an Acquisition process: • He will use the function bisw_Sync_AddSoftEvt to subscribe to an event. He can specify the source (TG8_1/2, BST, User pressing Acquire Button…) and the event. That’s it. • He will use the function bisw_Sync_WaitGenEvt to wait for any subscribed event. He will get the source, the event and the time stamp (µs resolution) of when this event really occurred. • He does not have to bother about where it comes from or about potential clashes with other processes. The BISCoTO Project Presented to PCRSWM on 9/11/2000

18. Misc Acq 1 Creator 2 Creator 1 Acq N Acq 1 Main Creator Service Task Timing Dispatcher Comm Srv Comm Srv LoggingDebug Timing ... Tg8... HW HW HW HW How does the New BI Front End System Look Like [Design based on our Experience] Generic Code Written Once for All Command and Synchro Exchanges Via Message Queues. Data Exchanges Via Shared Memories. Instrument Specific Code The BISCoTO Project Presented to PCRSWM on 9/11/2000

19. Common Functionality: the Configuration Handling Next Time if You’re Interested The BISCoTO Project Presented to PCRSWM on 9/11/2000

20. Common Functionality: the Communication Interface Next Time if You’re Interested The BISCoTO Project Presented to PCRSWM on 9/11/2000

21. How will a BI Expert GUI Work and Look Like[Design based on our Experience] Next Time if You’re Interested. The BISCoTO Project Presented to PCRSWM on 9/11/2000

22. Current State of the Project • Library, Creator, Logging, Synchronization Done. • The Configuration Application is Done. • Communication Interfaces defined and TCP version ready. SLEquip Version in Progress. SPS2001 version under discussion. CESAR version waiting for a decision of the project. • We still have to define the naming conventions for the ShM, MsQ and process names to finalize our Front End System Skeleton. • We still have to see if we can go further in the Acquisition Process Standardization. • The Expert GUI is in Progress and ready to incorporate STOPMI directives and graphic tools. The BISCoTO Project Presented to PCRSWM on 9/11/2000

23. Is there an Interest in some of these developments Outside BI? • Difficult to Say Today! • All this work has been done to allow us to port 8 different operational instruments from Themis/OS9/RPC to PPC/LynxOS/?SPS2001? during the next 2 shutdowns and make the others SPS2001 compliantwhen necessary (Front End Software and Expert/Operational GUI’s). • This work has to be done in addition to our ‘normal’ new development activities for the SPS, SLI, LHC, EA and CNGS projects. • So the BISCoTO project has been strongly focussed on this specific constraints and tailored to our Front End needs and it may be almostperfect for other purpose BUT. The BISCoTO Project Presented to PCRSWM on 9/11/2000

24. Is there an Interest in some of these developments Outside BI? • People who tried/try to make generic software for different users know how difficult and time consuming this task is. And this task is well beyond BI mandate and manpower. • If SL/CO is interested to make SL standards from some of these tools. We’ll provide the corresponding code and information when a stable version of the system will be available (Q1 2001). • If people in charge then modify them and diverge to much from the original version, BI may have to stick to its version for the given reasons. The BISCoTO Project Presented to PCRSWM on 9/11/2000