FSM – ConfDB Integration FW WG Meeting 17 th March, 2006 Fernando Varela Rodriguez, IT-CO (with...

FSM – ConfDB IntegrationFSM – ConfDB Integration

FW WG Meeting

17th March, 2006

Fernando Varela Rodriguez,

IT-CO

(with the input from: Clara, Alex, Sascha, Piotr and Francisca)

Outline

Aim

Prototype

Open question

Discussion

17 March, 2006 FW WG Meeting 2

AimAim

Synchronize the contents of the Configuration DB and

the PVSS internal caches to ensure the availability of

all configuration data for a given running mode

Configuration DB: holds all configuration parameters

FSM: Recipes are applied when a new command is sent

Two tools:

However:

ConfDB: recipes may contain a large number of devices

FSM: distributed and local intelligence


Interface Implementation as DUInterface Implementation as DU

Vertex

HV LV Cooling

1 2 3 4 1 2 3 4 1 2 3 4

CU LU DU DU FSM-ConfDB

ConfDB


Some assumptionsSome assumptions

There is one FSMConfDB DU per either LU or CU The run mode is passed as a command argument

to these DU from the parent CU The FSMConfDB handles the configuration of all

other DU in the control domain Upon the reception of a predefined command (e.g.

LOAD, CONFIGURE), the FSMConfDB DU loads all configurations for a given run mode and for all DU in its control domain from the ConfDB

Recipes are associated to FSM transition

Naming convention required for recipes!!!

DEMODEMO


Initialization of the FSM treeInitialization of the FSM tree

Vertex

HV LV Cooling

1 2 3 4 1 2 3 4 1 2 3 4

ConfDB

X X

All FSMConfDB DU must be initialized by calling: int fwFSMConfDB_initialize(string sDomain, string sConfigurator);

Disables the FSMConfDB DU if its parent is not a CU and returns

Builds an internal list of DU in the SMI++ domain to be configured

Initializes the connection to the ConfDB

If success, sets the state of the DU to NOT_READY, otherwise ERROR


New configuration requestNew configuration request

Two scenarios:

On-the-fly configuration, e.g. thru CONFIGURE command where this command is also defined for other DU in the tree- Pro: It would not require to define an additional command and a state throughout the FSM hierarchy

- Con: Configuration would imply the addition step of loading the recipes

Preloading of recipes, e.g. LOAD command only defined for CU/LU and FSMConfDB DU - Con: Requires the LOAD command and the LOADED state to be implemented by the CUs

- Pros: Could load the recipes at any moment, e.g. one could event prepare for COSMICS when a PHYSICS run is about to finish


Request for new configuration (2)Request for new configuration (2)

FSMConfDB DU gets the run mode:fwDU_getCommandParameter(domain, device, "sMode", mode);

For On-the-fly configuration: The other DU in the domain wait for the FSMConfDB to finish uploading the recipes for the run mode:

bool fwFSMConfDB_waitForStateChange(string sDomain, string sConfigurator, time timeout);

FSMConfDB retrieves all recipes for the given mode from the ConfDB

int fwFSMConfDB_cacheAllRecipesForMode(string sDomain, string sConfigurator, string sMode = "");

FSMConfDB organizes the PVSS internal caches

DOMAIN_NAME/RUN_MODE/FSM_CMD, e.g. EBC/PHYSICS/CONFIGURE


Applying recipesApplying recipes

If DUs apply recipe: FwAioVertexCooling_doCommand(string domain, string device, string

command){ fwFSMConfDB_ApplyRecipeFromCache(domain, device, command); }

BUT…

Could become very inefficient since the Configuration DB tool is optimized to apply a recipe to a bunch of devices at the same time


Applying recipesApplying recipes

Who applies the recipes?

The FSMConfDB DUs?

Better performance but…

Does it provide all functionality required?

Each device unit? Total flexibility but how to organize the caches?

One cache per device? => Too many dps being created/deleted

Single cache per domain and recipe? => ConfDB tool could become slow

Several caches per domain => Recipe Dictionary


Applying recipes (3)Applying recipes (3)

Recipe Dictionary

PHYSCIS/

CONFIGURE

PHYSICS/

GOTO_STG_1

PHYSICS/

GOTO_STG_2

PHYSICS/

GOTO_READY

COSMICS/

CONFIGURE

COSMICS/

GOTO_READY

device1 1 1 1

… 1 1 1 1

device1000 1 1 1 1

Device1001 2 1 1 2 1 2

2 1 1 2 1 2

device2000 2 2 1 2 1 3

… 2 2 3 2 3

deviceN m n 2 3 2 4

It would be set up by the FSMConfDB DU

The other DU would access it to find out the cache to be used


Open questionsOpen questions

Is it fine to impose naming convention on recipes?

How to store to the ConfDB the FSM hierarchy

One cache per recipe and control domain or a set of caches? What should the granularity be?

ConfDB intended to be used by means of tag names. How to handle different version? Version name in recipe name?

Who applies the recipe? Generic and fast vs. local and slow?

Applying a recipe must have a timeout?


DiscussionDiscussion

FSM – ConfDB Integration FW WG Meeting 17 th March, 2006 Fernando Varela Rodriguez, IT-CO (with...

Documents

Transcript of FSM – ConfDB Integration FW WG Meeting 17 th March, 2006 Fernando Varela Rodriguez, IT-CO (with...