Charpentier, P

Franek, B J

Gaspar, C

CERN Document Server

AN ARCHITECTURE AND A FRAMEWORK FOR THE DESIGN ANDIMPLEMENTATION OF LARGE CONTROL SYSTEMSC. Gaspar, CERN, Geneva, SwitzerlandB. Franek, Rutherford Appleton Laboratory, Chilton, Didcot, Great BritainPh. Charpentier, CERN, Geneva, SwitzerlandAbstractThe Online Control System of a high energy physicsexperiment deals with all aspects of the detector’soperations at the experimental site. Grouped in domains:data acquisition, detector survey (temperature, pressure,high and low voltages, fluids supply, etc.) and control,infrastructure (cooling, ventilation, electric power),interaction with the outside world (accelerator system,data storage provider, offline analysis, etc.). In many ofthese respects, sub-detectors have their own independentsystem which are then integrated in the framework of theexperiment, as are also the various domains.The control system should allow the operation of thefull experiment by a limited team of operators in a safeand efficient manner.In order to increase the operating efficiency and thereliability and maintainability of the system we propose aglobal approach in the design of the complete experimentcontrol.1  INTRODUCTIONOur proposal is to use wherever possible a commonapproach in the design and implementation of the variousdomains of the Control System.In order to make this integrated approach possible wewill propose:• A Generic ArchitectureThat can handle all aspects of the monitoring andcontrol of a complete Online System• A FrameworkA collection of tools and mechanisms that allowthe implementation of the architecture. Thisframework should be used by the developers of theindividual subsystems in order to build a coherentsystem.2  THE ARCHITECTUREIn order to design and implement such a complexsystem several levels of abstraction are necessary.Therefore, a hierarchical architecture, with as many levelsas necessary to represent the full experiment, has beenadopted.This hierarchical structure will be composed of buildingblocks organized in a tree-like structure. At the leaves ofthe tree are the blocks which handle real devices andwhere users can insert their own code, other blockscontain the description, model, of the system and of itsdynamic behavior. The behavior description modulesshould be organized in as many abstraction levels asnecessary to describe the full system. Figure 1 shows apossible representation of such an environment.Figure 1: Generic Architecture.3  THE FRAMEWORKIn order to allow for the implementation of the buildingblocks composing the proposed architecture a genericframework should be provided to the users. ThisFramework should provide the following functionality:• Device handling• Static modeling• Connections for various HW devices• Configuration Data Base• Alarm handling and reporting• Data archiving and trending• User interface building tools• Abstract behavior modelingAll items apart from the last one, which is of vitalimportance for the implementation of the higher levels ofthe architecture, are normally made available bycommercial SCADA [1] (Supervisory Control And DataAcquisition) systems. Nothing seems to be availablecommercially for behavior modeling so we will proposeSMI++.International Conference on Accelerator and Large Experimental Physics Control Systems499International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italy4  THE SMI++ TOOLKITSMI++ is based on the original State Manager conceptwhich was developed by the DELPHI experiment incollaboration with the DD/OC group of CERN. SMI(State Management Interface), the first implementation ofthis concept [2], was used in DELPHI since 1990. Due tolack of flexibility in many areas SMI was completely re-designed using Object-Oriented technology and SMI++implements significant extensions to the SMI concept anda more powerful set of tools.SMI++ is an Object Oriented Toolkit for Designing andImplementing Distributed Control Systems. The SMI++methodology combines two concepts: Objects and FiniteState Machines (FSM).Using SMI the experiment can be decomposed anddescribed in terms of objects behaving as finite statemachines.SMI objects can represent concrete entities, forexample an hardware device or abstract entities like alogical sub-system. The objects representing concreteentities interact with the hardware they model and controlthrough driver processes or proxies.The objects are typically organized in hierarchicalstructures called domains. The interaction between objectscan best be seen in the example of Figure 2.Figure 2: SMI++ Run-Time EnvironmentThe object model of the experiment is described usingState Manager Language (SML). This language allowsdetailed specification of the objects such as their states,actions and associated conditions. The maincharacteristics of this language are:• Finite State LogicThe main attribute of an object is its state. Commandssent to an object trigger actions that can bring about achange in its state.• SequencingAn action on an abstract object is specified by asequence of instructions, mainly consisting oncommands sent to other objects and logical tests onstates of other objects. Actions on concrete objectsare sent off as messages to the Proxies.• ParallelismSeveral actions may proceed in parallel. Only a testby an object on the state of another one can suspendsthe first object if the second one is still in transition.• AsynchronousObjects can specify logical conditions based on statesof other objects. These when satisfied will trigger anaction on the local object. This provides themechanism for an object to respond to unsolicitedstate changes of its environment.!- Example of SML codeobject : RUN_CONTROL  state : READY    action : START_RUN      do START READOUT_CONTROLER      if READOUT_CONTROLER in_state RUNNING         terminate_action/state=RUN_IN_PROGRESS      ...  state : RUN_IN_PROGRESS    when READOUT_CONTROLER in_state ERROR      do ABORT_RUN    action : ABORT_RUN      ...The SMI mechanism allows an easy reconfiguration ofthe system: changes in the hardware can be easilyintegrated by modifying or replacing proxies and logicalmodifications by changing the SML code.The decoupling between the actual actions on thehardware (done by the Proxies) and the control logic(residing in the SMI objects) makes the evolution of asystem from its first test phase up to final complexity avery smooth process.4.1 Distributed EnvironmentsSMI++ run-time components (SMI++ Domains,Proxies and User Interfaces) are automatically generatedfrom the SML description and they can run distributedover several different machines.Distribution is embedded in the SMI++ system, all co-operation between the different components of an SMI++environment is transparently handled by an underlyingcommunication system - the DIM [3] package.DIM and SMI++ are available in mixed environmentscomprising the Operating Systems: VMS (VAX andALPHA), UNIX flavours (HP-UX, IBM-AIX, SUN-OS,SUN-Solaris, DEC-OSF, Linux), Windows NT, OS9,LynxOs and VxWorks.5005  SMI++ IN DELPHIIn DELPHI the full online system is controlled throughthis mechanism, the various areas of DELPHI have beenmapped into SMI++ domains: sub-detector domains, dataacquisition (DAS) domain, slow controls (SC) domain,trigger domain, LEP machine domain, etc. The fullsystem comprises about 1000 SMI  objects in 50 differentdomains distributed over 40 machines.A high level of automation of the experiment’s controlsystem is very important in order to avoid human mistakesand to speed up standard procedures.Using the SMI mechanism the creation of a top leveldomain - BIG BROTHER - containing the logic allowingthe interconnection of the underlying domains (LEP,DAS, SC, etc.) was a relatively easy task [4].Under normal running conditions BIG BROTHERpilots the system with minimal operator intervention asshown in Figure 3. In other test and set-up periods theoperator becomes the top-level object and using the user-interfaces he can send commands to any SMI domain.Figure 3: Delphi’s Experiment Control6  SMI++ IN BABARIn BaBar the HW devices where mapped to software“Components” and controlled using EPICS. SMI++ wasthen used to model the behavior of the components and tointegrate them into “Partitions”.Figure 4: BaBar ControlBaBar’s partitioning scheme is totally dynamic. Userscan create partitions and allocate the set of componentsthey which to manipulate as shown in Figure 4. Duringphysics data taking one partition takes over and controlsall the underlying components. The BaBar Control systemis composed of hundreds of SMI++ domains.7  SMI++ / SCADA INTEGRATIONSince the SMI++ toolkit is a collection of toolsdeveloped in C++ it can easily be integrated into a moregeneric framework based on a SCADA system. This canbring several advantages:• Provide Behavior Modeling to the Framework• Use SCADA’s database to store the FSMdescription and configuration, i.e. the samedatabase will contain device description andbehavior• Use SCADA archiving tools to store state changes• Use SCADA User Interface building capabilities:• To build an integrated graphic FSM editor tobe used by the developer• To build the user interface that will interactwith the FSM at run-time.• Extend SCADA’s functionality to control non-supported platforms since SMI++ runs on a largerrange of platforms.8  CONCLUSIONSIn order to build an integrated system capable ofcontroling all aspects of a physics experiment we haveenvisaged a generic architecture based on building blocks.These blocks are organized in a hierarchical structure withseveral abstraction levels.The development of the building blocks should becarried out with the help of a framework. This frameworkshould allow the users to design and implement their sub-system by providing them tools and guidelines. Such aframework could be built around a commercial SCADAsystem by integrating missing parts one important onebeing a tool for abstract behavior modeling. SMI++ caneasily be integrated and provide the SCADA with themissing functionality.REFERENCES[1] A. Daneels, ”What is SCADA?”, these Proceedings.[2] J. Barlow et al.,”Run Control in MODEL: The StateManager”, in IEEE trans. nucl. sci. 36, 1989,pp.1549-1553.[3] C. Gaspar and M. Donszelmann, “DIM - ADistributed information management system for theDELPHI experiment at CERN”, Proceedings of RT93, Vancouver, Canada.[4] B. Franek et al.,”Big Brother - A Fully AutomatedControl System for the DELPHI Experiment”,Proceedings of CHEP 94, San Francisco, USA.501

An Architecture and a Framework for the Design and Implementation of Large Control System

Abstract

Similar works

Full text

Available Versions

CERN Document Server