Buceti, G

Centioli, C

Iannone, F

Panella, M

Torelli, C

Vitale, V

CERN Document Server

TWO CASE STUDIES OF INDUSTRIAL SYSTEMS IN FTUM.Panella, G.Buceti, C.Centioli, F.Iannone, C.Torelli, V, Vitale, ENEA, Frascati, ItalyAbstractFTU (Frascati Tokamak Upgrade) started operations in1989. The experimental session on FTU is a pulsedactivity where a shot every 30 minutes should be done.So the control system is asked to manage for all thesubplants a startup phase, hardware-controlled plasmashot, and a shutdown phase. The development of thecontrol system has undergone two phases: in the first onea commercial company has been involved into thedevelopment of an ad hoc control system, in the secondphase a commercial package from Digital has beencustomized to be used on FTU machine. Both solutionshave shown limitations. A full account of the twoexperiences will be given and further modifications willbe described.1 INTRODUCTIONWhen the Frascati Tokamak Upgrade  (FTU) projectstarted about fifteen years ago [1], reliability plus easydevelopment and integration seemed far from what anycommercial software product offered, and building oursystem from scratch would have entailed a relatively largeteam of in-house computer analysts.Since we were very few people (about fiveprofessionals), we had to involve a software house in thedevelopment of our system.Just to give an idea of the complexity of the FTUplant, we may recall that the control system has tomonitor more than 6000 data points, acquire more than2000 channels to produce about 15 MB of data per shotand has to run about 130 different types of mimics tomonitor the plant status.The basic requirements for the control system were:- a computer-based plant control based on concepts ofprocess control;- give real-time information about plant status andvariable values by means of mimics;- automation of the main experimental phases (fig. 1) andplant management procedures;-  use of a real-time database;- handle asynchronous events;- handle alarms;- archive, access, and process the acquired experimentaldata;- man-machine interface based on graphic monitors toimprove plant visibility and facilitate enhancement andmaintenance;- development of an ad hoc control system through acommercial company.newconfigurationstart experimentsend ofexperimentsstart runslowphasefastphaseslowphaseFig. 1 - Typical Tokamak experiment State Diagram2 THE FORMER FTU CONTROLSYSTEM2.1 System ArchitectureThe system architecture (fig.2) was completely softwarebased, in comparison with the previous way of conceivinga control system, i.e. hardware based [2]:- logic-functional division of the system into plants(electrical power supplies, machine plants,radiofrequency, data acquisition, supervisor) and sub-plants (vacuum system, cryogenic, RF modules, etc.);- dedicated software with a real-time database and atailored man-machine interface;- a computer for each plant connected via Ethernet;- plant interface based on several PLC's and PLCsupervisors, to transfer only data changes to thedatabase for the slow monitoring phase;- the fast monitoring phase was run by means anhardware timing system, via CAMAC modules;- integration of the existing data acquisition system intothe control system;- several command procedures to be executed in a pre-defined order. This was achieved with a languageinterpreter and some other utilities provided by thesupplier.International Conference on Accelerator and Large Experimental Physics Control Systems391International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, ItalyComputerPLC's SupervisorGSComputerPLC's SupervisorGSComputerPLC's SupervisorGSComputerPLC's SupervisorGSCAMAC DriverDataAcquisitionSystemRadiofrequencyControlPower SuppliesControlExperimentControlTorus SubplantsControlGS = Graphic StationFig. 1 - FTU control system: block diagram2.2 LimitationsAfter several years of FTU operation, we realized that:- since the local project team and the company developersteam hadn’t kept in touch from the very beginning, thecontrol system came in a single delivery (i.e. withoutintermediate tests or releases); this led to architecturalmistakes one couldn’t get rid of;- the company couldn’t supply a software maintenanceservice for a long time, especially on the inner parts ofthe system. Moreover, even the attempt to maintain thecode on our own, getting the program sources from thecompany had proven useless, because of the lack ofknowledge transfer from the company to ourprofessionals.We found other limitations on the first release of theFTU control system:- a large amount of code was developed and a long periodof debug was requested to reach a stable configuration.- due to the lack of operational knowledge of themachine, great emphasis – and thus big effort – wasplaced on the development of capabilities which werelittle use in everyday operations;- the operational experience suggested manymodifications and every change was a painful task,because the inner knowledge of the system was out ofour group.- a true availability of the system was never reached.3 THE CURRENT CONTROL SYSTEM3.1 RequirementsBecause of a long "shutdown" of FTU, planned toimprove the machine characteristics, we analyzed thesystem limitations and we decided to rebuild a new controlsystem, meeting the following additional requirements:- advanced and powerful man-machine interface, availableon the market;- easy servicing and updating of the software system;- possibility to include important commercial softwareapplications, such as database, historical recording ofplant measurements, etc;- possibility to integrate user applications, such as theexisting data acquisition system.- take advantage of the updated hardware available.3.2 Choosing the software environmentBefore replacing the previous software, we lookedaround for a commercial product. The DigitalBasestarOpen package seemed to meet our requirements,because it's a distributed platform born for applicationsintegration: implementations of BasestarOpen made fordifferent operating systems (such as Digital UNIX,HPUX, VAX-VMS and WindowsNT) may be used tobuild complex systems on an heterogeneous network.3.3 Hardware ArchitectureThe data flow between the PLC's and the databasesystem is filtered now by a VME cpu under an OS9operating system that transfers only the variations in datato the database by means of a TCP-IP protocol.The VME CPU also controls all the commands that aresent to the plant (whether they are sent by mimics orapplications).Graphic representation of the plant is achieved bymeans of a network of X-terminals in the control rooms,rather than several dedicated stations point-to-pointconnected to each computer.3.4 Software EnvironmentThe current system is centered on the BasestarOpendatabase, which is the Digital Equipment Corp. (DEC)package [3] designed to facilitate the integration ofautomation applications with plant-floor control devices.BasestarOpen contains a predefined set of objects:-data-point objects to represent machine and plant status;-event objects to represent significant events, e.g., hightemperature alarm;-trigger objects to generate automatic notification of datachanges;392-enbox objects to allow users and applications to receivenotification of events;-activity objects to represent user-written applications.3.5 Software ArchitectureOur control system consists of a set of processescentered on the BasestarOpen database and distributed overthree Unix machines and a VAX (OpenVMS) that allowremote supervision of the plants and the experiments.Each mimic is based on the SL-GMS graphic tool andoperates through a dedicated process (named BaseStarGraphic Enabler) that obtains information from theBasestarOpen database and allows the technical team todevelop any mimic easily.Plant status can be obtained from a real-time database,updated by communication processes and, whenevernecessary, the operator can transmit commands via themimics to the plant structures and/or hardware devices,such as the Camac modules.In addition to sending simple commands from a mimic,the operator can send a prefixed sequence of commandsthat have their own control logic for carrying out specificactivities (experiments, machine cooling, etc.)We developed in-house all system processes utilizingBasestarOpen database tools, particularly the eventmechanism that is based on objects such as event, enbox,and trigger, also for the database access and inter-processcommunication,4 LIMITATIONSCompared with the previous experience, the adoption ofthe Digital BasestarOpen package was an undoubtedimprovement of control system.Nevertheless, several serious limitations arose from thisexperience:- the supplied documentation has not been sufficient  toinvestigate all the aspects of the package, as, forexample, the system messages interpretation;- because of the pulsed nature of our experiment, weconfigured many processes to startup and shutdown foreach experiment (on average twenty per day). Wediscovered too late this is not the proper use of thepackage and some extra bugs arose;- due to the relationship with a commercial company, wewere free to change some application parameters, butwe had to wait for a new package release to fit thesystem on further plant needs;- as for the previous system, we exploited thesuggestions coming from the company experts (i.e.Digital) to customize our application, but the lack ofdeep knowledge of our needs brought often misleadingindications;- other users of the same package are out of the scientificworld, so we didn't have the possibility to share ourexperience with other laboratories.- we experienced situations not shared by other users, sothe company didn't consider our problem so importantto be solved employing new resources ;Some additional problems derived from our strategy:- a strong emphasis was placed on the centralized natureof the system, underestimating the advantage of thearchitecture where separate modules and/or subplantsmay run autonomously;- we had just one year to release the current system, thenwe had no time to redesign the global architecture- the startup phase took advantage of the 'ready-to-use'nature of the package but a lot of time has beenafterwards spent to identify and correct the bugs.5 CONCLUSIONSThe tokamak systems are in practice experimental asregards both their intrinsic complexity and the constantmodifications necessary for physics investigations. Whatis important in our context is that within a singleenvironment, different objectives have to be reachedsimultaneously: plant control in seconds time scale (viathe PLC) together with the study of phenomena inmilliseconds (via the Camac); continuous monitoring ofthe plant together with the control of the "pulsed" phasesof experimentation; the simultaneous transmission ofsingle commands or complex operational procedures bythe same, relatively specialized, operator. Finally, a highlevel of control reliability with flexibility (easyreconfiguration according to experimental requirements) isrequired.Now, the experiments on FTU proceed and the controlsystem is reliable in a way it was asked to run for theexperimental sessions.However, we believe the whole project can be adjustedand optimized. In fact, we wish to improve thearchitecture moving some functions on the plantcomputers and simplifying other parts. This will makethe subplants more autonomous and then more reliable.Our results bear out the opinion that it is worthwhilepurchasing a commercial package and adapting it toprovide a system capable of sophisticated controlrequirements.Nevertheless, while a commercial package reduces in-house software engineering, one cannot expect from thisrobustness and reliability as from a software productdedicated to process control, without extra care in theoptimization.REFERENCES[1] R.Andreani et al., “The Frascati Tokamak Upgrade:Electrical Mechanical and Thermal Features”, FusionTechnology 218,1991.[2] B.Berardi et al., “Development status of FTU controlsystem”, Symposium On Fusion Technology,Avignon, 1986.[3] M.Panella et al., “A commercial real-timemanufacturing platform for the new control systemon FTU”, Fusion Engineering and Design 43,1999.393

Two Case Studies of Industrial Systems in FTU

Abstract

Similar works

Full text

Available Versions

CERN Document Server