The Virtual Accelerator Allocator Status

Cesar Torcato de Matos1

The Virtual Accelerator Allocator Status

PR-101208-a-CTM, December 8th , 2010

R. Gutleber

2

Overview

• Concepts• Virtual accelerators

• Architecture• Overview• VAA commands

• Status• Work done• Planed work till next MACS week

Cesar Torcato de MatosPR-101208-a-CTM, December 8th , 2010

3

CONCEPTS


4

Virtual Accelerators (VAcc)

• Consists of a list of machines• addressed with a unique identifier (e.g. CS-02-001-ACC)• VAcc may be only in one mode at a time

• All Machines (Working Sets) have to be in that same mode• Overlapping VAccs cannot be used at the same time.• Non-overlapping VAccs can be used at the same time

• And may be in different modes


5

Virtual Accelerator Allocator (VAA)

• Scheduler that allocates VAccs for exclusive usage• Scheduling based on availability, request time and priority• Receives requests from clients (BDCS or ProShell)• Responsible for configuring all components of the VAcc• Forwards commands (StartCycle, NextCycle, ...) from clients to the MTS

• VAA will not automatically change the mode (clinical, QA, physics, service) of any resource

• Avoid unintendend mode changes• An operator procedure will be required to move a device in a certain state and mode


6

ARCHITECTURE


7

General Architecture

• VAA• Forwards requests to the MTS (NextCycle, StartCycle etc..)• Single entry point for allocation in the system (safety!)• Serializes requests to MTS and PVSS (avoiding race conditions)

DeviceDevice

BDCSBDCS

VAA

SCADA Tool

MTSBDCS

R

R

ProShellProcedureFramework

R

RDevice


8

VAA Request State Machine

Each allocation request is handled by a single VAA request state machine.• Pending – request is waiting for resources• Allocated – all resources are claimed• Active – all resources are configured and irradition may start• Failed – when one resource moved to failed• Deallocated– request is finished


9

AllocationThe VAA performs the following actions when receiving allocation request:1. Check that none of the resources is in failed state2. Check that all resources are in the requested mode (clinical, QA, physics, service)

• Reject request if mode does not match3. Check availability of all resources

• Keep request pending if resources are in use by another request to avoid starvation.

4. Check devices in checklist 5. Allocate all resources6. Configure MTS execution slot (runfile, list of cycle-dependent devices)7. Configure all resources to listen for MTS events in selected execution slot8. Send ActivateRun command to MTS

• To trigger loading of cycle-dependent values (waveforms) – May take time!9. Sends „Prepare“ command to all devices except beam transfer elements that

connect to WSs outside of the VAcc (will unground and magnetize magnets etc..) Note: Beam Transfer Elements are still disabled!


10

Activation

The VAA will perform the following actions on activation requests:1. Check state (red,orange,green) of the Patrol Control System (PCS)2. Sends „Activate“ command to all devices except beam transfer elements

that connect to WSs outside of the Vacc. a. Move out beam stoppersb. Unground and magnetize all switching dipoles

Note: Subsequently the BDCS may request cycles for this VAcc


11

Deactivation

The VAA will perform the following actions on deactivation requests:1. Send „Deactivate“ command to all components in the VAcc

a. Move in beam stoppersb. Ground and degauss all switching dipoles

2. Configure components to not listen to MTS events anymore

Note: Subsequently the BDCS may not request cycles for this VAcc anymore (Irradiation is paused)



Deallocation

The VAA will perform the following actions on deallocation requests:1. Free MTS execution slot2. Send „Finalize“ command to all devices

(degauss and ground magnets etc...)3. Deallocate all components4. Trigger rescheduling for pending requests


13

Status And Outlook



VAA Skeleton Implementation• Reacts to the basic commands over network

(allocate, activate, get_status etc...) • PVSS test project with 5 VAccs , 13 WS , 2000 devices and 11

beam transfer elements



Interface to PVSS• Gets all data of available WS and

VAccs from PVSS • Allocates and checks all conflicts

down to the device level• VAA datapoint in PVSS defined• Reacts to commands following

“generic device interface”• Displays status of all requests and

VAccs in PVSS• Will be integrated with WS and

VAcc PVSS scripts and state machine in the incoming weeks



Current Status

• Requirements and design in Enterprise Architect • Requirements gathering and architecture design

(a lot of details added)• Ways of automatically identifying beam stoppers, beam transfer

elements in PVSS defined• Conflict checks with VAccs and WS refined• Interface with PVSS defined

• Can allocate WSs and VAccs performing conflict checking (some new requirements added that are being incorporated)

• Can receive commands and post information into PVSS (execution status, VAcc status, request table)



Planed Work till next MACS week

• PVSS “distributed project” enable VAA (dpGets and dpSets)• Generic device interface into VAA (partially done: performs

commands from PVSS)• Transition of requests from “Activated” to “Allocated” (pause

irradiation)• Interface with VAccs and WSs using PVSS scripts (currently

looping over devices)• STM communication (currently using DIM to simulate it)• Extra conflict checking (check-list datapoint-element)



Status

• Ahead Schedule• None

• In Time• Architecture Design• PVSS interface• Skeleton: Basic commands and basic conflict checking

• Behind schedule• Updating requirements document• More advanced conflict checking• Activate and prepare command implementation

(currently only log entries)


The Virtual Accelerator Allocator Status

Documents

Transcript of The Virtual Accelerator Allocator Status