Setting and Cycle Management on the ROCS

Setting and Cycle Managementon the ROCS,

and beyond?

The rocs systemWhat 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)

Rocs architecture

mhmhmhmh

SL_Equip client

mugef server

rocsfe

sequence

threadthreadthreadthread

timing

acquire

floader

Startup

SPS2001 server

actionactionactionactionaction

SPS2001 clients

statoSurvey

Rocssystem

new statoSurvey implementation

statoSurveyance

Survey-Thread

Client- Thread

Statophon HW

PSTAT cacheShared memory(read only for others)

Sequence task SPS2001 server

Anonymous data signal:Signals report number updates to “whom it may concern”

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)

Improvement of FLoader

floader

StartFunc-Thread

Client-Thread

Ramp Cards

Setting and transaction cacheShared memory(read only for others)

Sequence task SPS2001 server

Anonymous data signal:Signals report number updates to “whom it may concern”

Timing task(existing)

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!

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

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.

Parameter

SettingValue

SettingHolder

ResidentSettingHolder

Catalog

0..256 0..256

0..256

SettingValue IdentificationSettingValues 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

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)

Cycle Resident Cycle Space usage

Class Diagram

Parameter

SettingValue

SettingHolder


Catalog

0..256 0..256

0..2560..*

Device

DeviceGroup

1

1

0..*

ParameterDescriptor

1

1

DeviceServer

1..*

0..*

ParameterCatalog

1

0..*1..*

0..*

0..1

SettingValueUpdate

Transaction

1

1

0..*

0..*

Class Diagram

Parameter

SettingValue

SettingHolder


Catalog

0..256 0..256

0..2560..*

Device

DeviceGroup

1

1

0..*

ParameterDescriptor

1

1

DeviceServer

1..*

0..*

ParameterCatalog

1

0..*1..*

0..*

0..1

SettingValueUpdate

Transaction

1

1

0..*

0..*

A regular device

property

A pseudo device with cycle catalogcycle catalog

maintenance properties

A pseudo device with transactiontransaction

maintenance properties

A propertyof the “groupgroup” pseudo device for the purpose of introspection

Example of a Resident cycle spaceSPS flavor

928 78 0 01 01 S928.FixedTarget_2.1

928 43 8 03 02 S928.MD26_LHC.1

9281 78 0 01 0A S928dev.FixedTarget_2.1

9281 43 8 03 0B S928dev.MD26_LHC.1

421 23 0 01 05 SCNGS.CNGS.1

421 23 6 01 06 SCNGS.CNGS.2

421 43 12 03 07 SCNGS.MD26_LHC.1

34122 1431 0 05 08 LHC_FT.LHC.1

34122 78 15 01 09 LHC_FT.FixedTarget_2.1

Full-CycleID(Corresponding to Setting Management Database keys)

Resident-CycleID(Dynamically assigned)

Full-CycleID text(optional human readable format)

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.

Make a cycle residentThe 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, 26GeVi.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)

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.GefFunction cycle: 928.78.0 data: 0,14000,1200,14000parameter: MKP.InjSetting cycle: 928.78.0 data: 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.

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.

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.

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

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.

Implementation Classes

MugefSetting(f rom mugef )

ShortShareableStore

<<virtual>> retrieveData()<<virtual>> storeData()<<virtual>> copyData()<<virtual>> retrieveItem()<<virtual>> storeItem()

(f rom SettingManager)

SettingManager

semaphore : intstoreSize : unsigned inttheCycleKeys : int*theDeviceKeys : int*

abortTransaction()commitTransaction()initSettingManager()linkHWdataStore()linkPersistentStore()unloadCycle()updateSetting()<<abstract>> makeBindingData()<<virtual>> commitSetting()<<virtual>> compressSettings()<<virtual>> createHwStore()<<virtual>> createPersistentStore()<<virtual>> getHwStore()<<virtual>> updateDirectoryEntry()


ShareableStore

packStore()truncateObject()<<virtual>> copyData()<<virtual>> markFree()<<virtual>> retrieveItem()<<virtual>> storeItem()<<virtual>> getAddressOf()<<virtual>> getKeyOf()<<virtual>> retrieveData()<<virtual>> storeData()


+theTransactionStore

+thePersistentStore

+theHWdataStore

Transaction

addEntry()getFirstEntry()Init()unlinkEntries()

(f rom SettingManager)...)

0..*

+theTransactions

0..*

SettingDescriptor

activeTime : intorigin : intrevision : int


0..*

0..10..1

+updateOwner

MugefCycle

getEventBindings()

(f rom mugef )

0..*

Cycle

cycleId[6] : intcycleAnnouncer : intfriendlyCycleInfo[80] : charcycleLoadTime : intbindingCount : int

getEventBinding()


Parameter

0..* 0..*0..* 0..*

CycleManager

addCycle()getCycle()removeCycle()

(f rom mugef )

+ourDataStore

+ourPersistentStore

0..*

MugefSettingManager(f rom mugef )

<<virtual>> commitSetting()<<virtual>> compressSettings()<<virtual>> createPersistentStore()<<virtual>> doEvent()<<virtual>> makeBindingData()

+theCycleManager

MugefRampChannel

clampStatus : intstartRegister : int

(f rom mugef )

0..*0..*0..*

SettingHeader

cycleIndex : chardeviceIndex : charpoints : shortrevision : intchecksum : int

getDataAddress()


11+theHwSetting 11 +thePersistentSetting

Entry

cycleIndex : chardeviceIndex : charpersistentStorageRequirements : inttheBindingTableKey : inttheHwSettingKey : inttheSettingKey : int

getNextEntry()

(f rom Transaction)

<<struct>>

0..*

1

+entries0..*

1 +theTransaction

11

Setting

revision : intchecksum : intpoints : intdataSize : intdata : void*

(f rom SettingManager)...)

Implementation Classes

MugefSetting(from mugef)

MugefCycle

getEventBindings()

(from mugef)

0..*

CycleManager

addCycle()getCycle()removeCycle()

(from mugef)

MugefSettingManager(from mugef)

<<virtual>> commitSetting()<<virtual>> compressSettings()<<virtual>> createPersistentStore()<<virtual>> doEvent()<<virtual>> makeBindingData()

+theCycleManager

MugefRampChannel

clampStatus : intstartRegister : int

(from mugef)

0..*0..*

+ourDataStore

+ourPersistentStore

0..*0..*

ShortShareableStore

<<virtual>> retrieveData()<<virtual>> storeData()<<virtual>> copyData()<<virtual>> retrieveItem()<<virtual>> storeItem()

(from SettingManager)

SettingManager

semaphore : intstoreSize : unsigned inttheCycleKeys : int*theDeviceKeys : int*

abortTransaction()commitTransaction()initSettingManager()linkHWdataStore()linkPersistentStore()unloadCycle()updateSetting()<<abstract>> makeBindingData()<<virtual>> commitSetting()<<virtual>> compressSettings()<<virtual>> createHwStore()<<virtual>> createPersistentStore()<<virtual>> getHwStore()<<virtual>> updateDirectoryEntry()


ShareableStore

packStore()truncateObject()<<virtual>> copyData()<<virtual>> markFree()<<virtual>> retrieveItem()<<virtual>> storeItem()<<virtual>> getAddressOf()<<virtual>> getKeyOf()<<virtual>> retrieveData()<<virtual>> storeData()


+theTransactionStore

+thePersistentStore

+theHWdataStore

SettingDescriptor

activeTime : intorigin : intrevision : int


0..*0..*

Cycle

cycleId[6] : intcycleAnnouncer : intfriendlyCycleInfo[80] : charcycleLoadTime : intbindingCount : int

getEventBinding()


Parameter

0..*0..* 0..*

SettingHeader

cycleIndex : chardeviceIndex : charpoints : shortrevision : intchecksum : int

getDataAddress()


11+theHwSetting 11 +thePersistentSetting

Entry

cycleIndex : chardeviceIndex : charpersistentStorageRequirements : inttheBindingTableKey : inttheHwSettingKey : inttheSettingKey : int

getNextEntry()

(from Transaction)

<<struct>>

0..* +entries0..*

Transaction

addEntry()getFirstEntry()Init()unlinkEntries()

(from SettingManager)... )

+theTransactions

0..*0..*

+updateOwner

0..10..1 11 +theTransaction

11

Setting

revision : intchecksum : intpoints : intdataSize : intdata : void*

(from SettingManager)... )

Documents

Setting and Cycle Management on the ROCS