the biscoto project

SL-BI-SW The BISCoTO Project Presented to PCRSWM on 9/11/2000 Slide 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


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


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.


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


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


How does an average BI Front End System Work and Look Like [2/2]?

Creator 1

Comm Srv SLEquip/RPC

/TCP

Acq 1 Acq NMisc

Timing

SLEquip Srv

Misc

...

Creator 2


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…)


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.


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 not

necessary, 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 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...)


Simple example: Priority Handling

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


Function call Example

bisw_Prior_High

Synopsis#include <BISCoTO.h>int bisw_Prior_High (void);

ConditionalityNone.

DescriptionBisw_Prior_High is used to set the priority of the calling process to High level.

Return valuesBISW_OK if successful.Returns BISW_PB if not. The external variables int Bisw_ErrNo, char *Bisw_ErrMsg will respectivelycontain the computer and human description of the problem.

ErrorsAny other defined by the System (equivalent to errno and ERRMSG(errno)).


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.


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.


Common Functionality: The Logging

bisw_Log_MkEntry

Synopsis#include <BISCoTO.h>int bisw_Log_MkEntry(char *logName, int debugLevel, char *logEntry, ... );

ConditionalityNone.

DescriptionBisw_Log_MkEntry is used to make entries to a log. It works like the printf() family of C calls. A log entrystring may contain any of the formatting commands understood by printf and the bisw_Log_MkEntry()function can accept an arbitrary number of arguments.

Return valuesBISW_OK if successful.BISW_PB if not. The external variables int Bisw_ErrNo, char *Bisw_ErrMsg will respectively contain thecomputer and human description of the problem.ErrorsAny other defined by the System (equivalent to errno and ERRMSG(errno)).


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.


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.


How does the New BI Front End System Look Like [Design based on our Experience]

Generic Code Written Once for AllInstrument Specific Code

Creator 1

Timing Dispatcher

Comm Srv

Acq 1 Acq NMisc

Creator 2

Timing

LoggingDebug

Main Creator

Command and Synchro Exchanges Via Message Queues.

Data Exchanges Via Shared Memories.

Acq 1

...

Comm Srv

Service Task


Common Functionality: the Configuration Handling

Next Time if You’re Interested


Common Functionality: the Communication Interface

Next Time if You’re Interested


How will a BI Expert GUI Work and Look Like[Design based on our Experience]

Next Time if You’re Interested.


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.


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 compliant when 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 almost perfect for other purpose BUT.


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

Documents