Software Design Specification for LLRF Applications at FLASH Version 1.0 Prepared by Zheqiao Geng MSK, DESY Nov. 16, 2009 Copyright 2009 by Zheqiao Geng. Any change of this document should be agreed by the development team.
Software Design Specification for LLRF Applications at FLASH Page ii Table of Contents 1. Introduction...1 1.1 Purpose... 1 1.2 Document Conventions... 1 1.3 Intended Audience and Reading Suggestions... 1 1.4 References... 1 2. Design Strategies...1 2.1 Design Guidelines... 1 2.2 Error Detection and Handling... 2 2.3 Memory Management Policies... 3 2.4 Data Management Policies... 3 2.5 System Structure Overview... 3 3. Functional Architecture...4 3.1 Procedures... 4 3.2 Support Modules... 5 3.3 LLRF Algorithm Library... 6 4. Software Architecture...18 4.1 DOOCS Server Architecture... 18 4.2 Procedure Allocations... 19 5. Policies and Tactics...21 5.1 Coding Guidelines... 21 5.2 Naming Conventions... 21 5.3 Testing Plans... 22 6. Glossary...22 7. To Be Determined List...23
Software Design Specification for LLRF Applications at FLASH Page iii Revision History Version Name Reason For Changes Date 1.0 Zheqiao Geng Initial Revision Nov. 16, 2009 Approved By Name Signature Department Date
Software Design Specification for LLRF Applications at FLASH Page 1 1. Introduction 1.1 Purpose This document is to present the software design specification for the LLRF Applications at FLASH. The architecture of the DOOCS servers and allocation of the procedures, which realize the use cases, will be described. Please note this is only the draft consideration, the server architecture and procedure allocations may be changed by the designer during detailed design and implementation. The LLRF Algorithm Library that carry out most of the signal processing tasks for the procedures are described as subroutines with the definition of input/output data and parameters. And the other supporting modules to the procedures, such as the VME data access interface and the motor control module are briefly described as a group of classes. This document offers a global view of the system design, which might be changed during implementation, but any change should be agreed by the design team. 1.2 Document Conventions To be worked out later. 1.3 Intended Audience and Reading Suggestions LLRF Experts Involved in Operation Algorithm Developers Software Developers Software Testers 1.4 References 1). For FLASH upgrade information, http://flash-intern.desy.de/e5 2). Software Requirements Specification for LLRF Applications at FLASH, v1.0 2. Design Strategies 2.1 Design Guidelines Maximum reusability: the LLRF applications specified in this document will contain most of the domain knowledge of the LLRF system, which can also be used in the LLRF system for the European XFEL, so, when designing the system, the common parts and the FLASH specified parts should be separated for maximizing the reusability.
Software Design Specification for LLRF Applications at FLASH Page 2 Optimization for computation power and memory consumption: the LLRF applications at FLASH will be later extended to the low level processors like DSP for pulse-to-pulse calculation, so the code especially for the LLRF Algorithm Library should be optimized for minimizing the required computation power and memory consumption. Loose coupling: the coupling between different DOOCS servers should be as low as possible, so that they can be easily maintained and upgraded in the future. DAQ system can be used to decouple the different servers. Different DOOCS servers shouldn t have synchronized invocation between them, but only the broadcasting data transfer for information exchange. See figure below. 2.2 Error Detection and Handling Figure 1: Loose coupling between DOOCS servers (TINE: publisher and subscriber ) The errors of the software itself such as memory overflow and division by zero should be detected and reported, and the sources of the errors should be located. The errors happen at the low-level part of the system like the LLRF Algorithm Library should be handled immediately, and if they can not be handled locally, they should be transferred to the higher level. Finally, if the errors can not be handled by the software automatically, they will be reported to the operators. The concept is shown below. Figure 2: Concept for software error handling (Extend to DOOCS method?)
Software Design Specification for LLRF Applications at FLASH Page 3 2.3 Memory Management Policies The buffers used in the procedures should be defined centrally outside the procedures, and only the buffer addresses (pointers) should be transferred to the procedures and subroutines in the LLRF Algorithm Library. We should avoid defining big buffers inside the procedures and subroutines. Reuse the buffers as much as possible, such as storing the results in the same buffers of the initial input data if the input data will not be used again. 2.4 Data Management Policies Firmware for the SIMCON DSP should be stored centrally with uniform naming and versioning conventions. Parameters like the vector sum calibration coefficients, cavity quench limitations should be stored centrally. (Firmware database will be ready soon, parameters storage can be done config files of doocs. First we can use files) 2.5 System Structure Overview Figure 3: Overview of the system architecture The LLRF Applications are mainly used for signal processing, which take mainly the RF signal measurement as input, employee various algorithms concern to the superconducting cavity theory, digital signal processing and control theory, and realize the use cases specified at the Software Requirements Specification. The algorithms used in the LLRF Applications contain the domain knowledge of LLRF system, which is common for similar systems, so, it is meaningful to design an algorithm library to separate
Software Design Specification for LLRF Applications at FLASH Page 4 the LLRF domain knowledge and the machine specific software components for future reuse. And because the algorithms will be also used in DSP program for Low Level Applications, it is preferred to be implemented in C language and optimized for computation power and memory consumption. Basic exception detection and handling will be also implemented for the algorithm library. Based on the algorithm library, the LLRF use cases can be implemented as procedures by following the sequences specified in the Software Requirements Specification, please note all alternative flows and exceptions should be taken into account. The procedures are special for FLASH, so the reusability will not be critical. For automatic operation, a scheduler formed by a sequencer or state machine can be used to organize the procedures. And finally, the buffers (RAM) and constants (ROM) used by the applications will be managed by the DOOCS server, the interfaces to the user and other applications will be provided, and the scheduler will be embedded into the DOOCS framework. A DOOCS server is an independent application for the operating system. 3. Functional Architecture 3.1 Procedures The LLRF procedures are mainly used for organizing the algorithms and other activities such as data read and write to realize the use cases. Each use case can be realized as a procedure. The use cases are described in the Software Requirements Specification for LLRF Applications at FLASH. For convenience, rewrite the use cases below, with an additional ID for procedures. PROC01 (LLRF_UC01): Configure the LLRF firmware PROC02 (LLRF_UC02): Set the vector sum voltage and phase for each RF station PROC03 (LLRF_UC03): Set the fill and flattop duration of the RF pulse, and set the basic feed forward parameters PROC04 (LLRF_UC04): Calibrate the vector sum PROC05 (LLRF_UC05): Close the RF feedback loop PROC06 (LLRF_UC06): Optimize the LO generation tables PROC07 (LLRF_UC07): Correct the DAC offset of the field controller PROC08 (LLRF_UC08): Tune the cavity resonance frequency PROC09 (LLRF_UC09): Adjust the cavity incident phase automatically PROC10 (LLRF_UC10): Adjust the cavity loaded Q automatically PROC11 (LLRF_UC11): Sweep the feedback gain for correlation study PROC12 (LLRF_UC12): Optimize the feed forward tables PROC13 (LLRF_UC13): Measure the system status PROC14 (LLRF_UC14): Start up and calibrate the RF gun PROC15 (LLRF_UC15): Recover the beam parameters after interlock trip PROC16 (LLRF_UC16): Save/restore machine settings PROC17 (LLRF_UC17): Check/set the timing of klystron, LLRF and other components PROC18 (LLRF_UC18): Support the beam based feedback
Software Design Specification for LLRF Applications at FLASH Page 5 The procedures will call the subroutines in the LLRF Algorithm Library and the services provided by the Support Modules, which is shown in the figure below. Typically, one procedure can be arranged in one C++ class. pkg Procedures [Procedures] Procedures LLRF Algorithm Library Support Modules Figure 4: LLRF procedures depend on the LLRF Algorithm Library and Support Modules 3.2 Support Modules (we may use existing APIs) First let s look at some necessary modules that support the procedures but not for signal processing, which means, they are not suitable to be included in the algorithm library. Please note that these classes are also highly reusable for other similar projects. class Support Modul... Firmw are_configuration - baseaddressfpga: long + firmwareconfigure() : void DOOCS_Access +accessmotortunercontrolvia + doocsread() : void + doocswrite() : void Cav ity_motor_tuner_control +configurefpgavia VME_Interface + vmeread() : void + vmewrite() : void + vmeinterrupt() : void +readandwritefpgaregistersandbuffersvia Controller_Interface + registerread() : void + registerwrite() : void + bufferread() : void + bufferwrite() : void +readandwritecontrollerparametersvia + motormove() : void + motor() : void +accessdatabasevia Database_Interface + databaseread() : void + databasewrite() : void +accessdatabasevia Parameters_Save_Restore + parameterssave() : void + parametersrestore() : void Logging + logbookwrite() : void + databaseloggingwrite() : void + databaseloggingread() : void Data_Conditioning - datatopthreshold: float - databottomthreshold: float - unittranslationratio: float + checkdatalimitations() : void + translatedataunits() : void Figure 5: Class diagram of the Support Modules for the procedures Firmware Configuration: The class to configure the FPGA on the SIMCON DSP boards
Software Design Specification for LLRF Applications at FLASH Page 6 with specified firmware, which will use the service provided by the VME Interface VME Interface: The class to handle the read, write and interrupt through the VME bus Controller Interface: The class to read and write the registers and buffers in the RF field controller, which will use the service provided by the VME Interface Parameters Save Restore: The class to save and restore the system parameters (including the field controller parameters), which will use the service provided by the Controller Interface and Database Interface. Assume the database will be used to store the saved parameters. Database Interface: The class to read and write the database Logging: The class to automatically input information to the FLASH logbook, read and write the database to record the important activities done by the LLRF applications Cavity Motor Tuner Control: The class to control the cavity motor tuner for slow cavity resonance control, which will use the service provided by the DOOCS Access, because the motor is controlled by writing in the proper properties of the motor control servers DOOCS Access: The class to read and write other DOOCS properties Data Conditioning: The class to validate the user input, such as checking if the data exceeds the limitations or not; and translate the data between physical units and digital units Note: This is only a draft consideration of the class structure, during detailed design stage, the required classes, the attributes and operations of each class can be checked and rearranged. 3.3 LLRF Algorithm Library The components in the LLRF Algorithm Library used in the procedures are listed below -- Operation support LLRF_APP01: Table generation for field controller -- Beam based calibration LLRF_APP02: Beam transient measurement LLRF_APP03: Vector sum calibration -- Grey box system identification LLRF_APP04: Klystron signal calibration as cavity driving LLRF_APP05: Loop phase and loop gain measurement LLRF_APP06: Beam identification LLRF_APP07: Loaded Q and detuning measurement -- Applications of the grey box model LLRF_APP08: Cavity on-line simulator LLRF_APP09: Forward and reflected power calibration LLRF_APP10: Beam loading compensation -- Adaptive feed forward LLRF_APP11: Black box model identification (only for matlab) LLRF_APP12: Iterative learning control -- Imbalance correction of the vector modulator LLRF_APP13: DAC offset calibration LLRF_APP14: LO generation tables optimization -- RF phase and amplitude measurement
Software Design Specification for LLRF Applications at FLASH Page 7 LLRF_APP15: RF signal stability measurement LLRF_APP16: Timing consistency checking -- Beam based feedback LLRF_APP17: Beam based feedback support -- RF gun control LLRF_APP18: RF gun start up LLRF_APP19: RF gun calibration The software components in the LLRF Algorithm Library can be described by a block with input data, output data and parameters, which is shown in Figure. Figure 6: Interfaces of the LLRF Algorithm Library component The input data and output data will be refreshed for each execution of the components, while the parameters should be relatively stable for a certain working condition. The specification of the input/output data and parameters for each component is described below. 3.3.1 LLRF_APP01: Table generation for field controller Algorithm ID LLRF_APP01 Name Table generation for field controller Priority Basic Functions Generate the set point table, feed forward table and gain table for the field controller Work for each RF station Set point amplitude digit Float Set point phase degree Float RF pulse timing {delay, fill, flattop, beam_on, μs Long beam_off} Ratio of the feed forward table between fill and / Float flattop stage Feed back gain / Float Set point table {I, Q} [PULSE_LENGTH] digit Long Feed forward table {I, Q} [PULSE_LENGTH] digit Long Gain table {I, Q} [PULSE_LENGTH] digit Long Parameters Item Unit Type Loaded Q of cavity / Float Gain scheduling parameters {TBD } / TBD Phase modulation parameters during fill stage (for / TBD
Software Design Specification for LLRF Applications at FLASH Page 8 Used By Other Requirements resonance filling) {TBD } Function selection / enum { Set_Point; Feed_Forward; Gain; All} LLRF_UC02, LLRF_UC03 Smooth the set point table, feed forward table and gain table, avoiding sudden change When the set point table is changed, the feed forward table should be changed automatically The feed forward table should be able to be generated separately The gain table should be able to be generated separately 3.3.2 LLRF_APP02: Beam transient measurement Algorithm ID LLRF_APP02 Name Beam transient measurement Priority Basic Functions Measure the beam transient of moderate beam current, like 3nC for 30 bunches Work for each cavity Cavity probe signal {I, Q} [PULSE_LENGTH] digit Long RF pulse timing {delay, fill, flattop, beam_on, μs Long beam_off} Beam current ma Float Loaded Q of cavity / Float Beam phase absolute value degree Float Beam phase respect to RF degree Float Beam transient amplitude relative to RF amplitude / Float Absolute beam induced voltage MV Float Absolute cavity voltage in physical unit MV Float [PULSE_LENGTH] Calibration coefficient between cavity voltage MV / Float value in physical unit and digital unit digit Parameters Item Unit Type Data range of the RF pulse for calculation μs Long {start_before_beam, end_before_beam, start_after_beam, end_after_beam} Average number / Integer r/q of cavity Ω Float
Software Design Specification for LLRF Applications at FLASH Page 9 Used By LLRF_UC04 3.3.3 LLRF_APP03: Vector sum calibration Algorithm ID LLRF_APP03 Name Vector sum calibration Priority Basic Functions Decide the rotation matrix for each cavity for vector sum measurement based on the beam transient Work for each RF station Beam phase absolute value [CAVITY_NUM] degree Float Beam transient amplitude relative to RF amplitude / Float [CAVITY_NUM] Vector sum calibration coefficients {rotation_gain, {/, Float rotation_angle} [CAVITY_NUM] degree} Parameters Used By LLRF_UC04 3.3.4 LLRF_APP04: Klystron signal calibration as cavity driving Algorithm ID LLRF_APP04 Name Klystron signal calibration as cavity driving Priority Basic Functions Rotate and scale the klystron signal to act as the cavity driving signal for cavity parameters calculation, such as the loaded Q and detuning during RF pulse Work for each cavity Cavity probe signal {I, Q} [PULSE_LENGTH] digit Long Klystron signal {I, Q} [PULSE_LENGTH] digit Long RF pulse timing {delay, fill, flattop, beam_on, μs Long beam_off} Cavity driving signal {I, Q} [PULSE_LENGTH] digit Long Klystron calibration coefficient {I, Q} / Float Parameters Item Unit Type Data range of the RF pulse for calculation {start, μs Long stop}
Software Design Specification for LLRF Applications at FLASH Page 10 Used By LLRF_UC05, LLRF_UC08, LLRF_UC13 3.3.5 LLRF_APP05: Loop phase and loop gain measurement Algorithm ID LLRF_APP05 Name Loop phase and loop gain measurement Priority Basic Functions Measure the loop phase and loop gain of the LLRF control loop Work for each RF station DAC output signal {I, Q} [PULSE_LENGTH] digit Long Cavity driving signal {I, Q} [PULSE_LENGTH] digit Long RF pulse timing {delay, fill, flattop, beam_on, μs Long beam_off} Loop phase degree Float Loop gain / Float Parameters Item Unit Type Data range of the RF pulse for calculation {start, μs Long stop} Used By LLRF_UC05, LLRF_UC13 3.3.6 LLRF_APP06: Beam identification Algorithm ID LLRF_APP06 Name Beam identification Priority Advanced Functions Estimate the beam driving term phase and amplitude based on RF measurement Work for each cavity Cavity probe signal {I, Q} [PULSE_LENGTH] digit Long Cavity driving signal {I, Q} [PULSE_LENGTH] digit Long Toroid signal [PULSE_LENGTH] digit Long RF pulse timing {delay, fill, flattop, beam_on, μs Long beam_off} Beam phase absolute value degree Float Beam driving term amplitude digit Long Toroid calibration coefficient {I, Q} / Float Parameters Item Unit Type Data range of the RF pulse for calculation μs Long
Software Design Specification for LLRF Applications at FLASH Page 11 Used By {start_during_beam, stop_during_beam, start_after_beam, stop_after_beam} LLRF_UC08, LLRF_UC10, LLRF_UC12 3.3.7 LLRF_APP07: Loaded Q and detuning measurement Algorithm ID LLRF_APP07 Name Loaded Q and detuning measurement Priority Basic Functions Measure the loaded Q and detuning of the cavity both from the RF decay and during the RF pulse Work for each cavity Cavity probe signal {I, Q} [PULSE_LENGTH] digit Long Cavity driving signal {I, Q} [PULSE_LENGTH] digit Long Toroid signal [PULSE_LENGTH] digit Long Toroid calibration coefficient {I, Q} / Float RF pulse timing {delay, fill, flattop, beam_on, μs Long beam_off} Loaded Q measured at RF decay / Float Detuning measured at RF decay Hz Float Loaded Q measured during RF pulse / Float [PULSE_LENGTH] Detuning measured during RF pulse Hz Float [PULSE_LENGTH] Parameters Item Unit Type Fitting range during RF decay {start, stop} μs Long FIR filter coefficients for derivative calculation / Float [FIR_ORDER] Used By LLRF_UC05, LLRF_UC08, LLRF_UC10, LLRF_UC13 3.3.8 LLRF_APP08: Cavity on-line simulator Algorithm ID LLRF_APP08 Name Cavity on-line simulator Priority Advanced Functions Simulate the cavity response with cavity model and driving signal Mainly work for each RF station
Software Design Specification for LLRF Applications at FLASH Page 12 Loaded Q measured at RF decay / Float Loaded Q measured during RF pulse / Float [PULSE_LENGTH] Detuning measured during RF pulse Hz Float [PULSE_LENGTH] Cavity driving signal {I, Q} [PULSE_LENGTH] digit Long Simulated cavity output {I, Q} digit Long [PULSE_LENGTH] Parameters Used By LLRF_UC12 3.3.9 LLRF_APP09: Forward and reflected power calibration Algorithm ID LLRF_APP09 Name Forward and reflected power calibration Priority Advanced Functions Calibrate the forward and reflected power for each cavity based on the cavity gradient calibration Work for each cavity Cavity probe signal {I, Q} [PULSE_LENGTH] digit Long Cavity driving signal {I, Q} [PULSE_LENGTH] digit Long Calibration coefficient between cavity voltage value MV / Float in physical unit and digital unit digit Cavity forward power [PULSE_LENGTH] kw Float Cavity reflected power [PULSE_LENGTH] kw Float Calibration coefficient between klystron signal and forward power kw / digit 2 Float Parameters Used By Calibration coefficient between reflected signal and reflected power LLRF_UC13 3.3.10 LLRF_APP10: Beam loading compensation Algorithm ID LLRF_APP10 Name Beam loading compensation kw / digit 2 Float
Software Design Specification for LLRF Applications at FLASH Page 13 Priority Basic Functions Setup the feed forward tables to compensate the beam loading Work for each RF station Beam current setting ma Float Beam phase setting degree Float Beam timing {beam_on, beam_off} μs Long Loaded Q of effect cavity for vector sum / Float Toroid signal [PULSE_LENGTH] digit Long Toroid calibration coefficient {I, Q} / Float Feed forward table for beam loading digit Long compensation {I, Q} [PULSE_LENGTH] Parameters Item Unit Type r/q of cavity Ω Float Used By LLRF_UC12 3.3.11 LLRF_APP11: Black box model identification (only for matlab) Algorithm ID LLRF_APP11 Name Black box model identification (only for matlab) Priority Basic Functions For black box model identification Work for each RF station Parameters Item Unit Type Used By LLRF_UC12 3.3.12 LLRF_APP12: Iterative learning control Algorithm ID LLRF_APP12 Name Iterative learning control
Software Design Specification for LLRF Applications at FLASH Page 14 Priority Basic Functions Compensate the repetitive errors of the system, such as phase and amplitude errors caused by the Lorenz force detuning or beam loading Work for each RF station Vector sum error {I, Q} [PULSE_LENGTH] digit Long Feed forward correction table {I, Q} digit Long [PULSE_LENGTH] Parameters Item Unit Type Black box model {TBD } / Float Iterative learning control parameters {TBD } / Float Used By LLRF_UC12 3.3.13 LLRF_APP13: DAC offset calibration Algorithm ID LLRF_APP13 Name DAC offset calibration Priority Advanced Functions The automatic calculation of the DAC offset based on the error model of the vector modulator for zero power settings Work for each RF station DAC driving sweep {I, Q} [SWEEP_POINT_NUM] digit Long Pre-amplifier response {I, Q} digit Long [SWEEP_POINT_NUM] DAC offset {I, Q} digit Long Vector modulator phase imbalance degree Float Vector modulator amplitude imbalance / Float Parameters Used By LLRF_UC07 3.3.14 LLRF_APP14: LO generation tables optimization Algorithm ID LLRF_APP14 Name LO generation tables optimization Priority Basic Functions Optimize the DAC tables of the switched LO generation for 250kHz IF scheme in order to remove the imbalance effects of the vector modulator
Software Design Specification for LLRF Applications at FLASH Page 15 Work for each RF station LO generation tables {I, Q} [4] digit Long Calibration RF signal measurement {I, Q} digit Long [PULSE_LENGTH] Optimized LO generation tables {I, Q} [4] digit Long Vector modulator phase imbalance degree Float Vector modulator amplitude imbalance / Float Parameters Used By LLRF_UC06 3.3.15 LLRF_APP15: RF signal stability measurement Algorithm ID LLRF_APP15 Name RF signal stability measurement Priority Basic Functions Measure the RF signal stability, including the intra-pulse and pulse-pulse phase and amplitude RMS jitter Work for each cavity RF pulse signal {I, Q} [PULSE_LENGTH] digit Long RF pulse timing {delay, fill, flattop, beam_on, μs Long beam_off} History buffer of RF amplitude [HIS_BUF_LENGTH] digit Float History buffer of RF phase [HIS_BUF_LENGTH] degree Float RMS intra-pulse amplitude jitter % Float RMS intra-pulse phase jitter degree Float RMS pulse-pulse amplitude jitter % Float RMS pulse-pulse phase jitter degree Float Refreshed history buffer of RF amplitude / Float [HIS_BUF_LENGTH] Refreshed history buffer of RF phase degree Float [HIS_BUF_LENGTH] Parameters Item Unit Type Data range of the RF pulse for calculation {start, stop μs Long } Used By LLRF_UC13
Software Design Specification for LLRF Applications at FLASH Page 16 3.3.16 LLRF_APP16: Timing consistency checking Algorithm ID LLRF_APP16 Name Timing consistency checking Priority Advanced Functions Check if the RF pulse is too early in timing compared with the klystron high voltage Work for each RF station DAC output signal {I, Q} [PULSE_LENGTH] digit Long Klystron signal {I, Q} [PULSE_LENGTH] digit Long Condition flag for timing consistency / enum { OK, Warning, Alarm, Exception} Parameters Item Unit Type Threshold of the phase error for timing consistency degree Float checking Data range of the RF pulse for calculation {start, stop μs Long } Used By LLRF_UC17 3.3.17 LLRF_APP17: Beam based feedback support Algorithm ID LLRF_APP17 Name Beam based feedback support Priority Advanced Functions Algorithms to support the beam based feedback Work for specified RF stations Parameters Used By LLRF_UC18
Software Design Specification for LLRF Applications at FLASH Page 17 3.3.18 LLRF_APP18: RF gun start up Algorithm ID LLRF_APP18 Name RF gun start up Priority Advanced Functions Heat the RF gun to accelerate the start up procedure Work for RF gun Parameters Used By LLRF_UC14 3.3.19 LLRF_APP19: RF gun calibration Algorithm ID LLRF_APP19 Name RF gun calibration Priority Basic Functions Calibrate the RF gun without RF probes, using the forward and reflected signal measurement to calculate the effective cavity voltage Work for RF gun Parameters Used By LLRF_UC14
Software Design Specification for LLRF Applications at FLASH Page 18 4. Software Architecture 4.1 DOOCS Server Architecture Figure 7: The architecture and interaction of the DOOCS servers for FLASH LLRF Each DOOCS server will include the parts of: Procedure: the procedures that should be implemented in the server RAM : define all the buffers used in the procedures, such as the buffers to store the cavity probe signal and klystron signal ROM : define all the necessary constants used in the procedures, such as the FIR filter coefficients used for digital derivative calculation Scheduler: organize the procedures to work together with a sequencer or state machine
Software Design Specification for LLRF Applications at FLASH Page 19 class DOOCS Server Architectu... Scheduler DOOCS_Server +scheduleoperationof 1..* Procedure +use ROM_ +use RAM_ Figure 8: DOOCS server structure 4.2 Procedure Allocations See next page.
Software Design Specification for LLRF Applications at FLASH Page 20 Table 1: Allocation map between the procedures and DOOCS servers PROC01 PROC02 PROC03 PROC04 PROC05 PROC06 PROC07 PROC08 PROC09 PROC10 PROC11 PROC12 PROC13 PROC14 PROC15 PROC16 PROC17 PROC18 Front-end Server Gun Front-end Server ACC1 Front-end Server ACC39 Front-end Server ACC23 Front-end Server ACC45 Front-end Server ACC67 Middle-layer Server Gun Middle-layer Server ACC1_01 (Learning Control) Middle-layer Server ACC1_02 (System Mea.) Middle-layer Server ACC1_03 (Beam Based FB.) Middle-layer Server ACC39_01 (Learning Control) Middle-layer Server ACC39_02 (System Mea.) Middle-layer Server ACC23_01 (Learning Control) Middle-layer Server ACC23_02 (System Mea.) Middle-layer Server ACC45_01 (Learning Control) Middle-layer Server ACC45_02 (System Mea.) Middle-layer Server ACC67_01 (Learning Control) Middle-layer Server ACC67_02 (System Mea.) Middle-layer Server for Global Control Note: The procedures are used to realize the use cases, the column items of PROC01 to PROC18 correspond to the LLRF_UC01 to LLRF_UC18 presented in the Software Requirements Specification for LLRF Applications at FLASH.
Software Design Specification for LLRF Applications at FLASH Page 21 5. Policies and Tactics 5.1 Coding Guidelines Comments Layout of the code Guidelines in LLRFWiki: http://mskpc14.desy.de/wiki/index.php/software/standards 5.2 Naming Conventions 5.2.1 Naming convention for LLRF matlab algorithm library For the components of the LLRF Algorithm Library (LLRF_APP01~19), the function name and m file name should be LLRF_appl_matlab_xxx. For the common functions which are used by more than one components of the LLRF Algorithm Library should be named as LLRF_appl_matlab_common_xxx. Example: For the library component of LLRF_APP07: Loaded Q and detuning measurement, the function name should be LLRF_appl_matlab_mea_loadedQ_detuning, and in this function, the digital derivative calculation is used, which can be named as LLRF_appl_matlab_common_derivative. Note: some abbreviations can be used in the names cal calibration mea measurement opt optimization cor correction id identification gen generation sim simulation chk check 5.2.2 Naming convention for LLRF C algorithm library This should be the same as the LLRF matlab algorithm library, except for removing the word of matlab. 5.2.3 Naming convention for matlab procedure For the procedures (PROC01~18), the names should be LLRF_proc_matlab_xxx.
Software Design Specification for LLRF Applications at FLASH Page 22 For the Support Modules to the procedures, the name should be LLRF_proc_matlab_support_xxx. Example: For the procedures of PROC01: Configure the LLRF firmware, the name should be LLRF_proc_matlab_configure_firmware, and in this function, the VME interface is used, which can be name as LLRF_proc_matlab_support_VME_interface. 5.2.4 Naming convention for procedure classes This should be the same as the matlab procedures, except for removing the word of matlab. 5.2.5 Naming convention for DOOCS servers For front-end servers, the name should be LLRF_server_fe_xxx. For middle-layer servers, the name should be LLRF_server_ml_xxx. For RAM, ROM and scheduler of each server, add the name of _RAM, _ROM and _scheduler after the server name. Example: For the front-end server of ACC1, the names below should be used: LLRF_server_fe_ACC1, LLRF_server_fe_ACC1_RAM, LLRF_server_fe_ACC1_ROM, LLRF_server_fe_ACC1_scheduler. For the middle-layer server for learning control of ACC1, the names below should be used: LLRF_server_ml_ACC1_ilc, LLRF_server_ml_ACC1_ilc_RAM, LLRF_server_ml_ACC1_ilc_ROM, LLRF_server_ml_ACC1_ilc_scheduler. For the middle-layer server for global control, the names below should be used: LLRF_server_ml_global, LLRF_server_ml_global_RAM, LLRF_server_ml_global_ROM, LLRF_server_ml_global_scheduler. 5.3 Testing Plans To be done later! 6. Glossary LLRF Experts: the persons from LLRF group involved in daily operation of FLASH, or perform maintenance of the LLRF system and machine studies
Software Design Specification for LLRF Applications at FLASH Page 23 Client Applications: software running in clients, mainly written in matlab Priority has three level: 1. Basic necessary for FLASH commissioning 2. Advanced essential for FLASH operation 3. Nice to Have can be worked out later, if manpower and resources permit 7. To Be Determined List CVS repository LLRF algorithm matlab library LLRF algorithm C library LLRF matlab procedures LLRF C++ procedures LLRF servers Documents (?)