1 / 23

Setting and Cycle Management on the ROCS

Setting and Cycle Management on the ROCS . , and beyond?. The rocs system. What makes up a rocs/mugef system: VME crate with:. SAC PPC (currently on lynxos 2.5.1) themis battery backed up memory board TG8 1-8 ramp cards (up to 64 channels)

dareh
Download Presentation

Setting and Cycle Management on the ROCS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Setting and Cycle Managementon the ROCS , and beyond?

  2. The rocs system What makes up a rocs/mugef system: VME crate with: • SAC • PPC (currently on lynxos 2.5.1) • themis battery backed up memory board • TG8 • 1-8 ramp cards (up to 64 channels) • 1-4 adc cards (up to 64*2 channels (ref, dcct) • statophone controler (to control hw status)

  3. mh mh mh mh action action action action action thread thread thread thread Rocs architecture SPS2001 clients SL_Equip client SPS2001 server Rocssystem mugef server timing rocsfe acquire Startup floader sequence statoSurvey

  4. new statoSurvey implementation Sequence task SPS2001 server statoSurveyance Anonymous data signal: Signals report number updates to “whom it may concern” Client- Thread Survey-Thread PSTAT cache Shared memory(read only for others) Statophon HW

  5. Improvement of FLoader • Based on the same principle components as the statoSurvey process: • Client thread to accept and execute commands (reply is optional) • A high priority thread to respond to timing interrupts • Structured shared memory segments (read only access to outside) with status information • Anonymous signal mechanism to inform anyone that something has changed. • More complications: • Manage memory on HW boards • Manage memory of persistent memory boards • Reply to external events • Accept rt-corrections (one more thread)

  6. Improvement of FLoader Timing task(existing) Sequence task SPS2001 server floader Anonymous data signal: Signals report number updates to “whom it may concern” Client-Thread StartFunc-Thread Setting and transaction cache Shared memory(read only for others) Ramp Cards

  7. Capabilities of the Current System • Fixed cycle space of 12-16 functions (slots) per channel. • Functions are selected with slot information extracted from timing events (instant telegram). Not possible to detect if wrong settings are loaded in a given slot.(Note: the same holds for current PS style telegrams). • Clumsy function start procedure. 100 msec advance warning (only required in case functions were updated) • Incorrect HW commit procedure: Uncommitted functions will commit after a HW reboot –was done by design! • HW load errors (although improbable) are detected after commit time: I.e. no escape possible!

  8. Objectives for new system • Flexible system to manage arbitrary number of settings and cycles.Cycle management only in case of a multi cycling machine. • More than one setting object per device possible (and required) • Beam related settings (cycle aware) • Equipment related settings (not cycle aware) • Build in commit handling (optionally using timing events). • No precompiled memory assignment for the settings. • Setting and cycle management independent of type of equipment i.e. c++ code that can be reused in different environments. (PO, BT, RF, timing; SPS, PS,…).

  9. Resident SettingHolder Catalog 0..256 Parameter SettingHolder 0..256 0..256 SettingValue Setting Space Organization • SettingValues for a given parameter are association objects of the parameter with SettingHolder objects.(note: SettingHolder  CycleInstance in the case of SPS magnetic equipment). • New system: During startup a system can be configured for up to 256 SettingHolders (slots) and up to 256 parameters. Important, one may choose less than 256.

  10. SettingValue Identification SettingValues in the SettingHolder space are identified by • During load and retrieve operations:Using the SettingHolder identification of the parameter management data base. • SPS2001: CycleInstanceId(i.e. SequenceTypeKey.CycleTypeKey.CycleSlotNr) • PS: User  No knowledge is required by the setting management of the slot number. • During Execution: • Full SettingHolder identification (I.e. CycleInstanceId) in the telegram:  SPS2001: A true validation of the loaded setting for a given slot. • Resident Cycle Id in the event frame: (format will be explained later)  Resident CycleId in the events make sure that the right slot number is selected (Insensitive to current/next cycle telegram ambiguity). Translation into the internal slot number (0-255) is the responsibility of the resident SettingHolder Catalog

  11. Cycle Resident Cycle Space usage Resident SettingHolder Space usage • SettingValues can only be loaded in equipment for Cycles that have been made resident through a configuration action. • Resident Cycle Space can be reconfigured dynamically (SPS2001) or be preconfigured (PS actual). The action to “Make a Cycle Resident” specifies • FullCycleId (SPS: 3 shorts; PS: userId) • ResidentCycleId: Dynamically assigned number that can be used to uniquely identify a cycle in the resident set. Proposal: two bytes • Cycle Type Id (from data base, specific for SPS-RF?) • VirtualSlot unique number from 0..255 (locally mapped on the equipment to a physical slot)

  12. Transaction DeviceServer 0..* 1 0..* DeviceGroup Parameter Catalog 1..* 0..* 1 0..* Device 1 0..* 1 1..* 1 Parameter Descriptor Resident SettingHolder Catalog 1 0..* 0..256 Parameter SettingHolder 0..256 0..256 0..* SettingValue SettingValueUpdate 1 0..1 Class Diagram

  13. Transaction DeviceServer 0..* 1 0..* DeviceGroup Parameter Catalog 1..* 0..* 1 0..* Device 1 0..* 1 1..* 1 Parameter Descriptor Resident SettingHolder Catalog 1 0..* 0..256 Parameter SettingHolder 0..256 0..256 0..* SettingValue SettingValueUpdate 1 0..1 A property of the “group” pseudo device for the purpose of introspection Class Diagram A pseudo device with transaction maintenance properties A pseudo device with cycle catalog maintenance properties A regular device property

  14. Example of a Resident cycle spaceSPS flavor Full-CycleID(Corresponding to Setting Management Database keys) Resident-CycleID(Dynamically assigned) Full-CycleID text(optional human readable format)

  15. Use cases • Make a cycle resident (only in case of dynamically managed cycle space) • Remove a resident cycle • Load a SettingValue • Execute a resident cycle • Update a SettingValue • Retrieve a SettingValue Notes: • only the essential aspects of these use cases will be discussed. • To better understand the context of the use cases, the behavior of the external actors (ResidentSetManager, TrimManager, CBCM) and the interaction between external actors will be outlines as well.This description is given as a whole, i.e. no attempt is made to identify and attribute specific responsibilities to appropriate classes and objects that may exist within the external actor realization. • Equipment share a dedicated pseudo devices for dynamic cycle management.

  16. Make a cycle resident The resident set manager (RSM) is asked to make a given cycle resident. The cycle is identified by the full-CycleId • The RSM obtains a new unique Resident-CycleId.Example: (To be negotiated with Julian) • one byte is derived from the CycleType (from data base, specific for SPS-RF?) • One byte is a uniquely assigned virtual slot number (0..255) locally mapped on the equipment to a physical slot • The RSM informs the Resident SettingHolder Catalogs in all device servers, providing the following information: • FullCycleId • ResidentCycleId • Cycle name and attributes (optional) Examples • 928.78.0 0101 ”S928.FixedTarget_2.1”, 2inj (1.2 sec) 14GeV, 450GeV • 928.43.8 0102 ”S928.MD26_LHC.1”, 1inj 26Gev, 26GeV i.e. typically the static information of the telegram • The Resident SettingHolder Catalogs verifies the validity of the information, checks available resources and creates the SettingHolder and the association with the parameters. Note: • The equipment now knows about the existence of the resident cycle, however, it does not have the settings yet. • As long as all equipment do not have received acceptable values for the settings, the cycle is not executable (Responsibility of the RSM)

  17. Load a SettingValue • The TrimManager (PM) provides all the equipment parameters with the data for the given cycle. The cycle is identified by the FullCycleId  The PM does not have to know the ResidentCycleId • Explained in more detail in the use case Update a Setting Value Example: parameter:MAL1001.GefFunctioncycle:928.78.0data:0,14000,1200,14000 parameter:MKP.InjSetting cycle:928.78.0data:14,18,52,14,19,55 • When all the settings for a SettingHolder are received and accepted, the SettingHolder reports to the RSM that the SettingHolder is executable • When the RSM has received confirmation of all the SettingHolders, the RSM can inform the central beam and cycle manager (CBCM) that this cycle is now executable.

  18. Execute a resident cycle • The CBCM sends the telegram for this cycle containing: • FullCycleId • ResidentCycleId • The equipment derives its internal the slot from the ResidentCycleId and verifies that the slot corresponds to the FullCycleId.In case of error, it may send an alarm, or raise the hardware beam interlock signal. • The CMCB sends an event to trigger an action. The event frame contains the ResidentCycleId. • The equipment derives its internal slot from the ResidentCycleId and executes the settings associated with this slot.

  19. Update a SettingValue • The TrimManager (PM) allocates a TransactionNumber. • The TrimManager sends all data update request to the equipment parameters adding the FullCycleIdentification and the TransactionNumber • The parameter makes sure that • the cycle specified by the FullCycleIdentification is resident • the SettingValue is not already locked with a TransactionNumber that is different from the specified TransactionNumber. • the specified data is within range (min, max, di/dt) • there are enough resources to store the new settings • If the data is acceptable • the SettingValue locked status is set with the TransactionNumber • the new data is stored on the pending transaction store and preloaded in the HwStore • the requestor (TrimManager) is informed • The Trim Manager arm the transaction with an exclusive transaction event assigned from a global pool. Note: optionally the result can be re tested. • The Trim Manager commits the transaction by sending the event. • the new data is made active and locally persistent, the parameter locked status is cleared. Note the TrimManager can abort a transaction. In that case the parameters involved in the transaction will be unlocked.

  20. Remove a resident cycle • The resident set manager (RSM) is asked to unload a given resident cycle.The cycle is identified by the Full CycleInstanceId • The RSM informs the CBCM that the cycle is now execution inhibited, the RSM waits for confirmation of the CBCM. • The RSM informs the Resident SettingHolder Catalogs in all device servers, providing the following information: • FullCycleInstanceId • The SettingHolders is located which releases all the resources associated with it (I.e. settingValues) • The RSM releases the ResidentCycleId associated with the FullCycleInstanceId

  21. Implementation • Implementation in C++ • Class to manage shareable memory managed data stores • position independent memory management tool • Class to manage setting and setting transaction: • A shareable transaction store • A shareable persistent setting store • Multiple shareable hw resident setting stores • (Allows binding of multiple events to the same setting, special rocs/mugef feature for coast/economy) • These are generic classes which are then specialized into Rocs specific classes.

  22. Implementation Classes

  23. MugefSettingManager (from mugef) <<virtual>> commitSetting() <<virtual>> compressSettings() <<virtual>> createPersistentStore() SettingManager <<virtual>> doEvent() <<virtual>> makeBindingData() (from SettingManager) semaphore : int storeSize : unsigned int theCycleKeys : int* theDeviceKeys : int* abortTransaction() Transaction ShortShareableStore commitTransaction() (from SettingManager) ... ) (from SettingManager) initSettingManager() +theCycleManager 0..* 0..* linkHWdataStore() addEntry() <<virtual>> retrieveData() linkPersistentStore() +theTransactions getFirstEntry() <<virtual>> storeData() CycleManager unloadCycle() Init() <<virtual>> copyData() (from mugef) updateSetting() unlinkEntries() <<virtual>> retrieveItem() <<abstract>> makeBindingData() <<virtual>> storeItem() addCycle() <<virtual>> commitSetting() 0..1 0..1 1 1 +theTransaction getCycle() <<virtual>> compressSettings() +updateOwner removeCycle() <<virtual>> createHwStore() <<virtual>> createPersistentStore() <<virtual>> getHwStore() <<virtual>> updateDirectoryEntry() ShareableStore (from SettingManager) +ourDataStore packStore() truncateObject() +theTransactionStore <<virtual>> copyData() +ourPersistentStore <<virtual>> markFree() +thePersistentStore <<virtual>> retrieveItem() <<virtual>> storeItem() <<virtual>> getAddressOf() <<virtual>> getKeyOf() +theHWdataStore <<virtual>> retrieveData() <<virtual>> storeData() 0..* 0..* +entries 0..* 0..* 0..* 0..* <<struct>> Entry 0..* 0..* MugefRampChannel MugefCycle (from Transaction) SettingDescriptor (from mugef) (from mugef) cycleIndex : char (from SettingManager) clampStatus : int deviceIndex : char activeTime : int startRegister : int getEventBindings() persistentStorageRequirements : int origin : int theBindingTableKey : int 1 1 revision : int theHwSettingKey : int MugefSetting theSettingKey : int (from mugef) getNextEntry() Cycle (from SettingManager) 1 1 +theHwSetting cycleId[6] : int +thePersistentSetting 1 1 cycleAnnouncer : int SettingHeader friendlyCycleInfo[80] : char Setting (from SettingManager) cycleLoadTime : int (from SettingManager) ... ) cycleIndex : char bindingCount : int revision : int deviceIndex : char Parameter checksum : int points : short getEventBinding() points : int revision : int dataSize : int 0..* 0..* checksum : int 0..* 0..* data : void* getDataAddress() Implementation Classes

More Related