Beltrán, D

Perlas, J A

Rosich, J

CERN Document Server

DESIGN AND IMPLEMENTATION OF A FINITE STATE MACHINEQUEUING TOOL FOR EPICSJ.A. Perlas, D. Beltrán, J. RosichSynchrotron Light Laboratory, LLS-IFAEEdifici Cn, Campus UAB, E-08193 Bellaterra, Barcelona (Spain)AbstractIn the process of making a detailed design for asynchrotron accelerator in Barcelona, we have designedand implemented the control system for a magneticmeasurements system [1], conceived as an evaluation forthe accelerator control system which is planned to use theEPICS toolkit [2].In this article, we introduce a new sequencing tool(called Finite State machine Queuing Tool or FSQT) andwe discuss its design and its advantages using a newimplementation of our test bench applications. FSQT hasborn from the limitations of the equivalent EPICS tool(the Sequencer).1  WHY A NEW SEQUENCING TOOLAlthough we have found the Sequencer [3] to be a veryuseful tool for small applications, the necessity ofdeveloping a new design arises mainly from itslimitations. These are listed below:• It is not possible to determine the new statedynamically (during the execution of the currenttransition).• A new state is required for the introduction of atimeout timer.• Accesses can be made via the Channel Access(CA) facility in either synchronous orasynchronous mode, but this can only be decided atcompilation time.• The “put” to a Process Variable (PV) inasynchronous mode does not provide any functionthat indicates the completion of execution.• There exists an intermediate “engine” (i.e. theSequencer) between the Operating System (OS)and the code. This complicates the debuggingphase.• The C-language code can be “escaped” in anapplication but this makes it much less readable. Inaddition, there are strong limitations in theinclusion of subroutines and system calls.Furthermore, the syntax used for CA accessesinside subroutines is different to that used outsidethem, making very difficult the readability andreusability of the code.• It is not portable.After analysis of all these issues and considering thedesirable features that a minimally powerful sequencingtool has to provide, we arrived at two options: a) upgradethe Sequencer, or; b) create a new tool. Taking intoaccount that there are intrinsic limitations in the currentsequencing tool, which are not possible to overcome(mainly because of the decision to provide its ownlanguage/syntax) our decision has been to create a newtool, which we call FSQT.2  THE FSQT DESIGN CONCEPTS2.1  General BackgroundThe main idea in the new design is to provide acentralized manager that listens to all the stimuli sources(internal and external) of a real-time program and actsaccordingly and chronologically upon them.Very often in a program it is necessary to wait forevents that are generated from several sources. When thearrival of one such event takes place, it is desirable to takeaction to perform a specific task. To standardize theprocess of generation, waiting and management of events,the FSQT tool has a centralized (and prioritized) FIFOqueue where the different generated events in the systemare received, waiting for later treatment. In this way, toeach of the stimuli of our system it will be assigned adifferent “facility” that will allow to univocally identifythe stimulus that generated the event. These facilities willbe inserted (with priority) by the “stimuli generators” inan unique queue, where they will remain stored until theirextraction and subsequent execution of their associatedactions. In this way, all the stimuli are processed in achronological way in the order in which they weregenerated avoiding, in addition, any loss.For an application of medium or high complexity, it isdesirable to implement it using the Finite State MachineFSM approach [4]. In this case these stimuli can invoketransitions between the previously designed states of ourState Diagram.2.2 FSQT design requirementsIn the FSQT conception process, besides solving theSequencer problems, we imposed the followingrequirements:• To use a standard programming language like Cand thus avoid the creation of a special syntax.• The tool has to be well layered, containingindependent support libraries for the differentfunctionality that it has to provide. An applicationInternational Conference on Accelerator and Large Experimental Physics Control Systems564International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italyprogram can use all or part of these supportlibraries.• Portability across different platforms.• The package has to include a graphical tool to editthe State Diagram and generate the source code.• To support nested states (according to Booch [5]).• Reusability for other control systems different toEPICS.3  FSQT IMPLEMENTATION3.1  Tool componentsFollowing the above philosophy and requirements, theFSQT tool has been implemented as three completelyindependent C-libraries. They have been ported to severalOS and their APIs are very well defined. These librariesare:1. Queue action library (fsqt_qa). This centrallymanages the different events generated in thesystem and allows the execution of a routine that isassociated to every possible event.2. FSM library (fsqt_fsm), which supports thehierarchical implementation of State Diagrambased programs.3. Channel Access library (fsqt_ca). This is a simpleinterface with the EPICS CA Client layer used toestablish communication with the ProcessVariables, both synchronously and asynchronously,including transaction-completion functions.Fig. 1 shows the FSQT software layer design and how itis integrated inside the EPICS architecture.Figure 1. FSQT software layers.One of the implementation choices for these librarieshas been the use of the Posix 1003.1b standard whereverpossible to ensure that the code is portable to any otherRTOS. Where this has not been possible, a platform-dependent library has been used. Nevertheless, ourintention is to eventually use the EPICS OSI Layer [6]that is currently being developed.All these library functions include a VxWorks-likeerror code system. These error codes are associated to acharacter string that explains the cause of failure.The FSQT libraries also contain initialization andcleanup functions that, due to their autonomous andmodular design, must be called from the application. It isimportant to note that in spite that a full-featured FSQTapplication should use the three libraries, those areprovided as “building blocks”, in the sense that anyapplication may use only one or two of them, e.g. a non-real-time application in a Unix host machine, for a non-EPICS control system could use only fsqt_fsm to do thesequencing of user input data in an accelerator operationalprocedure.This set of libraries is complemented with a graphicaltool (called GFSQT), implemented in Tcl/Tk that allows,in a comfortable and simple way, the graphical design ofStatecharts, and the generation of the associated C code.An example is shown in Fig. 2.Figure 2. Graphical FSQT example.3.2  CA performanceOne of the important aspects for any re-design is tocheck that the performance of the new software (havingmore functionality) has not been degraded.The performance in the CA access times to the PVs inthe current fsqt_ca version has been evaluated andcompared with the Sequencer. Using the hardware timersin the CPU board, we have measured the mean times forthe remote access (gets) of software PVs, for both thefsqt_ca functions and the Sequencer equivalents, making acomparison. The results are shown in Table 1.Table 1. Comparison of average remote (get) times(msec/PV) between FSQT and Sequencer.Synchronous AsynchronousFSQT 4.58 2.77Sequencer 4.76 2.71This test was carried out in a 68040 CPU boardaccessing to 100 PVs residing in a remote database. WeChannel Access ClientChannel Access ServerRecords, Devices, DriversOperating System (Real Time or Host)Fsqt_caFsqt_fsmFsqt_qaApplicationFSQT565can clearly see that the fsqt_ca library doesn’t introduce asignificant overhead, obtaining similar access times tothose using the Sequencer.4  ADVANTAGES OF THE FSQT DESIGNFSQT has solved most (and potentially all) theproblems of the Sequencer and it further extends itsfunctionality. This is summarized in the followingenhancements list:Major additions:  • Permits hierarchical state diagram designs.• Portability to be executed in any (supported) hostcomputer.• Includes a graphical FSM editor with skeleton-code generation.• Optionally permits several state machines share asingle task.• It is much easier to debug applications (nointermediate “engine” present, and no multi-taskingused).• Provides full C-language support, including ISRs.Minor additions:  • Allows pre and post-actions to be executed.• Supports Channel Access put with callback.• Allows an action not to reset timers.5  CASE STUDY: THE MAGNETICMEASUREMENTS SYSTEMOur “old” Sequencer code for the magneticmeasurements system has been ported to FSQT. A partialState Diagram of the new code can be seen in Fig. 3.Figure 3. Partial view of the application FSM.This experience has been very useful to demonstrate thebig differences over the old version. These are:1. Programming simplicity (through hierarchies andthe use of the graphical editor).2. Faster reaction time to user intervention.3. No loss of events.4. Same CA performance.5. Some applications now run in the Unix host.6. Code more readable and maintainable.7. Better code quality through the use of sub-routines(avoiding duplication, resulting in 25 % less code).8. Allow full use of OS resources.6  CONCLUSIONSWe have performed a software analysis and produced anew design and implementation for a new sequencing tool(FSQT). This overcomes the problems of the currentEPICS Sequencer and adds much more flexibility andpower to future sequencing applications, both for EPICSand non-EPICS.Amongst the most important features, we emphasizethat it supports hierarchical state machine designs, it isportable and runs in the host computer, it includes agraphical FSM editor with C-code generation, it is mucheasier to debug applications, and finally, since noproprietary syntax is used it has the support of the C-language and any other third-party C libraries.The CA accesses performance of FSQT is as good asthat of the Sequencer and it has proved very satisfactoryfor controlling our magnetic measurements system, afterporting the software that was using the EPICS Sequencerto this new approach. Big improvements have beenattained in programming simplicity, faster reaction time touser intervention and no loss of events. Furthermore,using the graphical tool and the portability to the Unixhost, applications for prototyping and testing have beendeveloped in record time producing better code quality.The testing of the FSQT tool is practically completedand we intend it to be the next generation of the EPICSsequencing tool. Although the library support is welldeveloped and tested, the GFSQT application is still underdevelopment and will be essential for the proper supportof hierarchical statechart designs.REFERENCES[1] D. Beltrán, J.A. Perlas et al., “The LLS magnet testfacility...”, EPAC’98, Stockholm, June 1998.[2] L.R. Dalesio et al., “EPICS: past, present and future”,NIM A, 352 (1994) 1-5.[3] A. Kozubal, W. Lupton, Sequencer v1.9.2 (1996).[4] D. Harel, “Statecharts: a Visual Formalism forComplex Systems”, Sci. Comp. Prog. 8 (1987).[5] G. Booch, “Object-Oriented Analysis and Designwith Applications”, Ed. Addison-Wesley, 1994.[6] M. Kraimer, Operating System Independent Layer forEPICS, http://epics.aps.anl.gov/asd/controls/epics.,1,7581723/(9(/58167$7(566

Design and Implementation of a Finite State Machine Queuing Tool for EPICS

Abstract

Similar works

Full text

Available Versions

CERN Document Server