Abe, I

Kishiro, J

Kosuge, T

Kurokawa, S

Mutoh, M

Nigorikawa, K

CERN Document Server

GUI AND I/O INTERFACE FOR COACK-IIK. Nigorikawa, I. Abe, J. Kishiro, S. Kurokawa, T. KosugeHigh Energy Accelerator Research Organization(KEK), 1-1 Oho, Tsukuba, Ibaraki 305-0801, JapanM. MutohLNS Tohoku Univ. Taihaku, Sendai, Miyagi, JapanAbstractCOACK-II[1,5] (Component-ware Oriented AcceleratorControl Kernel) is a project currently under developmentat KEK1. It is a generalized control kernel in anaccelerator domain based on COACK phase-I, which wasdeveloped by the KEK PF Linac group. The conceptualsystem configuration of COACK-II and various testresults are described in this paper.1 INTRODUCTIONThe control software for accelerators or large-scaleexperimental equipment was occasionally developedindependently and sometimes dedicated to specificequipment. Based on an object-oriented analysis ofcontrol system fundamentals, it was concluded that inspite of the difference in size or architecture of the controlsoftware, there exists a common flow of commands ordata. The control commands to the accelerator magnet, forinstance, come from the control client to the I/O interfacemodule through a command exchanger, in whichcommand security, examination and assignment of the I/Omodule address and logging into the database etc. areperformed. The magnet current or voltage data is returnedto the client GUI, and also recorded into the database. Inthis example, except for the realization method, thefundamentals are security examination, addressing, andlogging and recording of the command and data. In theobject-oriented model, these are private procedures andthe contents of the command and data are publicproperties. The magnet control is easily classified as a“Magnet object”.2 COACK-IIThe COACK-II project is a new accelerator controlkernel development based on Object Oriented Modelingand an extension of that to the COM (ComponentOriented Model). In COACK-II, the fundamentals of theaccelerator control software are constructed usingComponent ware, and entire control programs areassembled in the Component Oriented architecture. Thecontrol components are implemented not only in thekernel itself, but also in the communication between the                                                          1 This project supported by JST.client GUI and the kernel, and between the kernel and theI/O device. In the control network the many distributedI/O devices are easily implemented in a single kernel byemploying DCOM[2] (Distributed Component ObjectModel).3 GUI AND I/O IN THE COACK-IIThe control software usually implements a character-based code according to specially developed I/O accesscommands. The software developers need to know at leastthe command provided by the system designer or thehardware developers. By contrast, COACK-II is designedto assemble all of the control commands based on anobject-oriented method. For instance the objects areclassified as “Magnet” and “Vacuum” etc., each of whichcontains the data and set-up procedures for the concerneddevices. The objects are also implemented inCOM/DCOM as a communication procedure. TheCOACK-II kernel is mainly implemented by employingthe component-oriented method. This allows the mainflow of data and commands to the accelerator objectthrough the kernel to be implemented via a COM/DCOMchannel. The fundamental components in the kernelcommunicate with each other through this channel.Transmission of the control command is an equivalentaction to change the property of the concerned object. TheCOM/DCOM architecture provides automaticFigure 1: COACK-IICOACK-IIGUIDCOM DCOMSocketI/OActive XDCOM DCOMDBWEB serverComponent(COM/DCOM)International Conference on Accelerator and Large Experimental Physics Control Systems538International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italycommunication between the kernel components and theuser GUI presentation frames. The component-warearchitecture makes it possible to build up a complicatedcontrol GUI by dragging and dropping the componentsthat are already implemented in the system.As a result of the many types of I/O devices in anaccelerator control system, the software developer mustimplement many device handlers. To avoid this frustration,COACK-II components are designed to include thecommunication channel to the currently available SCADAsoftware.4 GUI AND I/O CONNECTION TOCOACK-II4.1 Connection ProtocolThe connection between the user GUI and COACK-IIis implemented using COM/DCOM. COACK-II alsoincorporates a TCP/IP Socket, thus allowing theimplementation of multiple platforms.The string-command goes through the network from theuser GUI and COAKC-II, in which a class, object andproperty name are formatted specifying the components inthe control network. COACK-II incorporates a Message-exchanger to decode this command and inheritance for thecomponent, which corresponds to this command. TheMessage-exchanger examines the registered component inthe system, and transmits the command to the instance, orrelays a message to the user GUI if the component is notavailable. Because these communications areencapsulated by DCOM, the user or developers need notknow the command. Figure 2 depicts the command flowin COACK-II.4.2 Implementation of the ACOPFor the GUI layer, we examined the ACOP[3](Accelerator Component Oriented Programming) systemdeveloped at DESY/CERN. ACOP demonstratesexcellent performance on our COACK-II project. ACOPalso has the advantage of being able to be downloadedfrom the Internet. ACOP is the pioneer of component-ware for accelerator control systems.4.3 Implementation of SCADASCADA (Supervisory Control and Data Acquisition)software is strongly supported in COACK-II, because thissoftware is commercially available to every controldeveloper. SCADA not only supports direct access to theI/O devices, but is also a means of GUI. SCADA is usedin COACK-II as local intelligence in the I/O layer, whichprovides the possibility to develop local controlindependently of the whole system. SCADA local controlis implemented as a local component using ActiveX. Thisconfiguration explicitly smears out the varieties of I/Odevices and accelerator objects in COACK-II.4.4 DCOM performanceUsing DCOM as the protocol for networkcommunication enables the components to be distributedin the network. DCOM is not a simple communicationprotocol, but it can be superior to the network, whichcontains various security checks of the distributedcomponents, and so on. We have measured thecommunication speed on the network compared to asimple TCP/IP Socket using WindowsNT (Pentium III450MHz, 100Base-T). A formatted command, asdescribed above, was transmitted 10,000 times to theserver computer through Fast Ethernet, and the transfertime was measured. The results are given in table 1.Using DCOM, a single command can be transmitted in3.6ms, approximately seven times longer than the samecommand transmitted via a TCP/IP Socket. Thecommunication speed is fast enough to transfer thecommand to COACK-II. DCOM is itself a network-oriented communication, which includes some types ofchecks that DCOM is reliable enough to be used in theCOACK-II project.4.5 Communication testThe program shown in figure 3 was created for acommunication test between the GUI, the I/O andCOACK-II. This program also tested the DataBase. TheGUI was written in Visual Basic and implemented usingACOP. Figure 4 shows the GUI. This software and theDCOM-Server communicate using DCOM; the I/O andDataBase communicate through the DCOM-Server.LabVIEW was introduced for the I/O layer to controlmany devices. LabVIEW and COACK-II alsoFigure2: Message-exchangerTable1: Connection speedProtocol Speed (mSec)TCP/IP Socket 0.49DCOM 3.58DCOMTo I/O To/From DataBaseCOMCOM COMCOMCOMMe ss age-e xch an ge r539communicate using DCOM. Figure 5 is an example of I/Ocontrol using DCOM.Through the use of ActiveX, DCOM communicationcan be implemented into LabVIEW.The DCOM-Server in this test program is a small-scaleCOACK-II.The test result showed a fast response and high level ofreliability of device control over the network. 5  THE NEXT PLANThrough the use of standardized OPC[4] (OLE forProcess Control), COM and ActiveX technology, I/O canbe connected.Therefore, it can be said that the conditions underwhich various I/Os connect to COACK-II will be widened.6  SUMMARYA new from of connection between the GUI and I/Ohas been proposed. The actual connection betweenCOACK-II and I/O was demonstrated, and the statisticalresults presented. Remote control using the network waseasily realized and satisfactorily performed.Because COACK-II was created from component-ware,it is easy to add new functions dynamically. Furthermore,multiple connections of SCADA software and expansionby OPC can be expected.REFERENCES[1] I.Abe, et al., “COACK-II Project on AcceleratorControl Kernel Development”, this conference.[2] Guy Eddon, et al., “Inside DCOM”, Microsoft Press[3] P.Duval, “Using ACOP in HERA ControlApplications”, PCaPAC’99, Tsukuba (1999)[4] http://www.opcfoundation.org/[5] http://ninja.kek.jp/COACK2/Figer3: Test programFigure4: Window of GUIFigure5: Panel of I/ODCOM-Server MS-S QLLabVIEW (I/O)GUISmall scale COACK-IIDCOMDCOM540

GUI and I/O Interface for COACK-II

Abstract

Similar works

Full text

Available Versions

CERN Document Server