- Email: [email protected]
FireSignal application Node for subsystem control
Fusion Engineering and Design 85 (2010) 496–499
Contents lists available at ScienceDirect
Fusion Engineering and Design journal homepage: www.elsevier.com/locate/fusengdes
FireSignal application Node for subsystem control A.S. Duarte a,∗ , B. Santos a , T. Pereira a , B.B. Carvalho a , H. Fernandes a , A. Neto a , F. Janky b , P. Cahyna b , J. Písaˇcka b , M. Hron b a b
Instituto de Plasmas e Fusão Nuclear - Instituto Superior Técnico, Avenida Rovisco Pais 1, 1049-001 Lisbon, Portugal Institute of Plasma Physics AS CR, Association EURATOM/IPP.CR, Za Slovankou 3, 182 00 Prague, Czech Republic
a r t i c l e
i n f o
Article history: Available online 28 April 2010 Keywords: Subsystems CODAC FireSignal Java Remote operation
a b s t r a c t Modern fusion experiments require the presence of several subsystems, responsible for the different parameters involved in the operation of the machine. With the migration from the pre-programmed to the real-time control paradigm, their integration in Control, Data Acquisition, and Communication (CODAC) systems became an important issue, as this implies not only the connection to a main central coordination system, but also communications with related diagnostics and actuators. A subsystem for the control and operation of the vacuum, gas injection and baking was developed and installed in the COMPASS tokamak. These tasks are performed by dsPIC microcontrollers that receive commands from a hub computer and send information regarding the status of the operation. Communications are done in the serial protocol RS-232 through fibre optics. Java software, with an intuitive graphical user interface, for controlling and monitoring of the subsystem was developed and installed in a hub computer. In order to allow operators to perform these tasks remotely besides locally, this was integrated in the FireSignal system. Taking advantage of FireSignal features, it was possible to provide the users with, not only the same functionalities of the local application but also a similar user interface. An independent FireSignal Java Node bridges the central server and the control application. This design makes possible to easily reuse the Node for other subsystems or integrate the vacuum slow control in the other CODAC systems. The complete system, with local and remote control, has been installed successfully on COMPASS and has been in operation since April this year. © 2010 Elsevier B.V. All rights reserved.
1. Introduction
2. Machine subsystems
The development of high bandwidth, low latency and low cost communications has allowed control systems in fusion research laboratories to migrate from a centralized paradigm to a distributed one. This implies several subsystems working autonomously, configuring, controlling in real-time and collecting data from specific tasks during the operation of the machine. All subsystems, no matter how autonomous, must interact with other subsystems inside the global Control, Data Acquisition and Communications (CODAC) system [1]. However, it is not trivial to completely integrate different technologies, protocols and hardware. The CODAC in COMPASS tokamak [2] was designed with these challenges in mind. This paper will present the integration of one of such subsystems.
2.1. Vacuum and glow discharge subsystems
∗ Corresponding author. E-mail address: [email protected] (A.S. Duarte). 0920-3796/$ – see front matter © 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.fusengdes.2010.03.056
Subsystems for controlling vacuum and glow discharge (GDC) operation in COMPASS tokamak were recently installed [3]. The hardware behind them is similar: I/O multiplexers control the related machinery, communicating with embedded microprocessors (dsPIC) through an RS-485 bus. The dsPIC series are 16 bit microcontrollers with digital signal processing capabilities, developed by Microchip. They can be programmed in C language [4]. The vacuum subsystem was designed for continuous operation in order to ensure the protection of the high-vacuum pumps and to maintain the pressure inside the torus. All this can be controlled with no human intervention. The GDC subsystem is not expected to work continuously, thus the automatic control is simpler but requires the presence of a human operator. The microprocessors are controlled from a PC, installed in the control room. All communications are made through dedicated optic fibres, using RS-232 protocol.
A.S. Duarte et al. / Fusion Engineering and Design 85 (2010) 496–499
2.2. Local subsystem control client A user interface for local control, monitoring and operations of subsystems in COMPASS (Vacuum, Gas Injection, Shutters, Puffing and Baking) was developed. It was implemented in Java, making use of the RXTX API [5] for communications with the subsystems. This interface was designed with the purposes of being intuitive and allowing users to fully monitor and control the various components of the subsystems. All connections among the components of a subsystem and important information are clearly visible, as it can be seen on Fig. 1. Status of components is represented by different colours, which follow a common scheme for all subsystems.The interface for the local subsystem control client (LSCC) has eight modules: • Vacuum control and gas injection: Controls the vacuum pumps, valves and gas injection systems. In these modules the user can see a schematic of the vacuum and gas injection subsystems, with state of the components, communication and messages received from subsystems. Users can send commands by clicking in the representation of the desired component. • Shutters: Related to the shutters present in different ports. In this module a plant of the tokamak is visible. It shows the location and state of each shutter as well as a description. • Baking: Controls the heating of the vessel to release gases trapped in its walls before the discharge. Its architecture is similar to vacuum control, gas injection and shutters. • Puffing: Regulates the injection of gas in the vessel, in order to improve the plasma density during the discharge. Here it is possible to configure a waveform and send it to a subsystem. The subsystem also allows retrieving the previous waveform loaded, sending a new waveform, arming the subsystem and aborting. The user can save or load waveforms from the hard drive and visualize them in a chart. • State machine: Shows the state machine off all subsystems and their valid states. • Logging: Subsystem state logging, configuring and search by date or last registers. • Communication: For configuring all parameters of the serial ports and to connect to the subsystems. For the Vacuum Control, Gas Injection and Shutter modules the LSCC automatically tries to read the state of these subsystems every 200 ms. These states are shown in the panel with text and specific colours. The LSCC has two types of logging: it can log every state transition (for example when a valve is closed) and also the state of all components on a regular basis. The resulting log is saved to a PostgreSQL database server [6]. 3. Integration in FireSignal system 3.1. Introduction The COMPASS tokamak uses FireSignal (FS) [7] as its CODAC system. FS was designed as a modular system so that new devices could be easily integrated. Hardware clients (called Nodes) can directly manage hardware or act as a proxy to other software. Nodes act as an abstraction of underlying hardware. They are organized in the following hierarchy: Nodes contain FS Hardware, which can be directly related to physical electronic boards or simply be abstractions; FS Hardware contains FS Parameters, which can send data or be a support for configuration Fields of the FS Hardware. The architecture of FS allows the Nodes to be developed in different programming languages. Templates for Java, Python
497
and C++ are freely available. There is a Graphical User Interface (GUI) client written in Java for configuration and management of FS Nodes.
3.2. Subsystem Node The FS Node for subsystems was developed in Java, in order to better interconnect with the LSCC. The Node was organized in the following way: • There is a FS Hardware for each subsystem module. • Subsystem components (pumps, valves) are represented by FS Parameters. • FS Fields show the state of the component, messages sent by the local application and measurements associated with the component. Communications between the FS Node and the LSCC are made through Java Remote Method Invocation (RMI) [8]. These interconnections are visible in Fig. 2. The Node regularly queries the RMI server of the LSCC concerning any state changes occurring on the components of the susbsystem. This design choice was made because FS Nodes cannot warn the FS central server of changes in their configuration fields. Changes would not be visible immediately so there would be no advantage in making the LSCC able to send messages to the Node without being queried. Commands issued by FS operators are immediately sent to the LSCC, which then reports the new state of the component. If an error occurs in one component, the state of the corresponding hardware will change to error. This gives a visual warning to an operator following the main FS Hardware status panel in the user client of FS.
3.3. GUI interface The user client of FS can automatically generate a configuration panel for the FS Hardware, based on an eXtensible Markup Language (XML) description file. This generates a simple interface whose Fields receive common types such as numbers or strings. Visual clues, like colours used in the local GUI, are of great assistance for users monitoring the state of subsystems, though are not implemented on FS. Taking advantage of its plug-in feature, extra visual panels that show information about the components of the subsystem were developed. These include state, a sign using the same colour scheme as the local GUI and messages sent by the LSCC. Since extra panels are specific for each FS Hardware, this approach has the advantage that as long as a FS Parameter is selected, the states of all other FS Parameters in the same FS Hardware are visible. If only the standard panel was to be used, operators would only be able to monitor one FS Parameter at the time.
3.4. Subsystem generic description As an extension of this work, a proposal for defining a method to describe generic subsystems was made. Such description can help the integration of other subsystems in the FS platform, by allowing the Node to automatically generate the hardware–parameter tree and the panels for the user client GUI. The description would contain the structure of the components in the subsystem, their possible states, commands and state machine. This idea is still under appreciation and a draft based on XML is expected to be ready in the short-term.
498
A.S. Duarte et al. / Fusion Engineering and Design 85 (2010) 496–499
Fig. 1. Example of modules of the interface of the LSCC: on the top is the vacuum control panel and in the bottom is the shutters panel. Visible are also tabs for the other modules.
A.S. Duarte et al. / Fusion Engineering and Design 85 (2010) 496–499
499
A generic descriptor for subsystems will allow faster and easier integration of new subsystems in FireSignal. It will also provide coherent and similar interface, thus reducing the time necessary for machine operators to learn how to use it. Acknowledgements This work has been carried out within the framework of the Contracts of Association between the European Atomic Energy Community and “Instituto Superior Técnico” (IST) and IPP.CR. IST also received financial support from “Fundac¸ão para a Ciência e Tecnologia” in the frame of the Contract of Associated Laboratory. The views and opinions expressed herein do not necessarily reflect those of the European Commission. References
Fig. 2. Schematic showing how the Node connects to different parts in the system.
4. Conclusions The local application for controlling the subsystems for vacuum and GDC was installed successfully on COMPASS tokamak and has been used by its operations team since then. Its visually rich and intuitive interface has proven valuable in introducing users to the subsystems operation. A FireSignal Node for subsystems was developed an integrated on the CODAC. It allows users to monitor and operate the subsystems remotely, with the same basic capabilities of the local control application. A plug-in that extends the GUI of FireSignal provides operators with visual information of the state of the machines.
[1] J.B. Lister, J.W. Farthing, M. Greenwald, I. Yonekawa, The status of the ITER CODAC conceptual design, Fusion Engineering and Design 83 (Issues 2–3) (2008) 164–169. [2] R. Pánek, O. Bilykova, V. Fuchs, M. Hron, P. Chraska, P. Pavlo, et al., Reinstallation of the COMPASS-D tokamak in IPP ASCR, Czechoslovak Journal of Physics 56 (Suppl. B) (2006) B125–B137. [3] T. Pereira, F. Janky, B. Santos, P. Cahyna, M. Hron, J. Sousa, H. Fernandes, Subsystems control on the COMPASS tokamak, in: Proceedings of the 7th IAEA Technical Meeting on Control, Data Acquisition, and Remote Participation for Fusion Research, Aix-en-Provence, 2009. [4] Microchip press release, regarding dsPIC: http://www.microchip.com/stellent/ idcplg?IdcService=SS GET PAGE&nodeId=2018&mcparam=en013529 (accessed February 2010). [5] RXTX Java Library. Online: http://users.frii.com/jarvi/rxtx/index.html (accessed February 2010). [6] PostgreSQL. Online: http://www.postgresql.org/ (accessed February 2010). [7] A. Neto, H. Fernandes, A. Duarte, B.B. Carvalho, J. Sousa, D.F. Valcárcel, et al., FireSignal—Data acquisition and control system software, Fusion Engineering and Design 82 (Issues 5–14) (2007) 1359–1364. [8] Sun Microsystems. Java Remote Method Invocation - Distributed Computing for Java, 2001. Online: http://java.sun.com/javase/technologies/core/basic/rmi/ whitepaper/index.jsp (accessed February 2010).
Contents lists available at ScienceDirect
Fusion Engineering and Design journal homepage: www.elsevier.com/locate/fusengdes
FireSignal application Node for subsystem control A.S. Duarte a,∗ , B. Santos a , T. Pereira a , B.B. Carvalho a , H. Fernandes a , A. Neto a , F. Janky b , P. Cahyna b , J. Písaˇcka b , M. Hron b a b
Instituto de Plasmas e Fusão Nuclear - Instituto Superior Técnico, Avenida Rovisco Pais 1, 1049-001 Lisbon, Portugal Institute of Plasma Physics AS CR, Association EURATOM/IPP.CR, Za Slovankou 3, 182 00 Prague, Czech Republic
a r t i c l e
i n f o
Article history: Available online 28 April 2010 Keywords: Subsystems CODAC FireSignal Java Remote operation
a b s t r a c t Modern fusion experiments require the presence of several subsystems, responsible for the different parameters involved in the operation of the machine. With the migration from the pre-programmed to the real-time control paradigm, their integration in Control, Data Acquisition, and Communication (CODAC) systems became an important issue, as this implies not only the connection to a main central coordination system, but also communications with related diagnostics and actuators. A subsystem for the control and operation of the vacuum, gas injection and baking was developed and installed in the COMPASS tokamak. These tasks are performed by dsPIC microcontrollers that receive commands from a hub computer and send information regarding the status of the operation. Communications are done in the serial protocol RS-232 through fibre optics. Java software, with an intuitive graphical user interface, for controlling and monitoring of the subsystem was developed and installed in a hub computer. In order to allow operators to perform these tasks remotely besides locally, this was integrated in the FireSignal system. Taking advantage of FireSignal features, it was possible to provide the users with, not only the same functionalities of the local application but also a similar user interface. An independent FireSignal Java Node bridges the central server and the control application. This design makes possible to easily reuse the Node for other subsystems or integrate the vacuum slow control in the other CODAC systems. The complete system, with local and remote control, has been installed successfully on COMPASS and has been in operation since April this year. © 2010 Elsevier B.V. All rights reserved.
1. Introduction
2. Machine subsystems
The development of high bandwidth, low latency and low cost communications has allowed control systems in fusion research laboratories to migrate from a centralized paradigm to a distributed one. This implies several subsystems working autonomously, configuring, controlling in real-time and collecting data from specific tasks during the operation of the machine. All subsystems, no matter how autonomous, must interact with other subsystems inside the global Control, Data Acquisition and Communications (CODAC) system [1]. However, it is not trivial to completely integrate different technologies, protocols and hardware. The CODAC in COMPASS tokamak [2] was designed with these challenges in mind. This paper will present the integration of one of such subsystems.
2.1. Vacuum and glow discharge subsystems
∗ Corresponding author. E-mail address: [email protected] (A.S. Duarte). 0920-3796/$ – see front matter © 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.fusengdes.2010.03.056
Subsystems for controlling vacuum and glow discharge (GDC) operation in COMPASS tokamak were recently installed [3]. The hardware behind them is similar: I/O multiplexers control the related machinery, communicating with embedded microprocessors (dsPIC) through an RS-485 bus. The dsPIC series are 16 bit microcontrollers with digital signal processing capabilities, developed by Microchip. They can be programmed in C language [4]. The vacuum subsystem was designed for continuous operation in order to ensure the protection of the high-vacuum pumps and to maintain the pressure inside the torus. All this can be controlled with no human intervention. The GDC subsystem is not expected to work continuously, thus the automatic control is simpler but requires the presence of a human operator. The microprocessors are controlled from a PC, installed in the control room. All communications are made through dedicated optic fibres, using RS-232 protocol.
A.S. Duarte et al. / Fusion Engineering and Design 85 (2010) 496–499
2.2. Local subsystem control client A user interface for local control, monitoring and operations of subsystems in COMPASS (Vacuum, Gas Injection, Shutters, Puffing and Baking) was developed. It was implemented in Java, making use of the RXTX API [5] for communications with the subsystems. This interface was designed with the purposes of being intuitive and allowing users to fully monitor and control the various components of the subsystems. All connections among the components of a subsystem and important information are clearly visible, as it can be seen on Fig. 1. Status of components is represented by different colours, which follow a common scheme for all subsystems.The interface for the local subsystem control client (LSCC) has eight modules: • Vacuum control and gas injection: Controls the vacuum pumps, valves and gas injection systems. In these modules the user can see a schematic of the vacuum and gas injection subsystems, with state of the components, communication and messages received from subsystems. Users can send commands by clicking in the representation of the desired component. • Shutters: Related to the shutters present in different ports. In this module a plant of the tokamak is visible. It shows the location and state of each shutter as well as a description. • Baking: Controls the heating of the vessel to release gases trapped in its walls before the discharge. Its architecture is similar to vacuum control, gas injection and shutters. • Puffing: Regulates the injection of gas in the vessel, in order to improve the plasma density during the discharge. Here it is possible to configure a waveform and send it to a subsystem. The subsystem also allows retrieving the previous waveform loaded, sending a new waveform, arming the subsystem and aborting. The user can save or load waveforms from the hard drive and visualize them in a chart. • State machine: Shows the state machine off all subsystems and their valid states. • Logging: Subsystem state logging, configuring and search by date or last registers. • Communication: For configuring all parameters of the serial ports and to connect to the subsystems. For the Vacuum Control, Gas Injection and Shutter modules the LSCC automatically tries to read the state of these subsystems every 200 ms. These states are shown in the panel with text and specific colours. The LSCC has two types of logging: it can log every state transition (for example when a valve is closed) and also the state of all components on a regular basis. The resulting log is saved to a PostgreSQL database server [6]. 3. Integration in FireSignal system 3.1. Introduction The COMPASS tokamak uses FireSignal (FS) [7] as its CODAC system. FS was designed as a modular system so that new devices could be easily integrated. Hardware clients (called Nodes) can directly manage hardware or act as a proxy to other software. Nodes act as an abstraction of underlying hardware. They are organized in the following hierarchy: Nodes contain FS Hardware, which can be directly related to physical electronic boards or simply be abstractions; FS Hardware contains FS Parameters, which can send data or be a support for configuration Fields of the FS Hardware. The architecture of FS allows the Nodes to be developed in different programming languages. Templates for Java, Python
497
and C++ are freely available. There is a Graphical User Interface (GUI) client written in Java for configuration and management of FS Nodes.
3.2. Subsystem Node The FS Node for subsystems was developed in Java, in order to better interconnect with the LSCC. The Node was organized in the following way: • There is a FS Hardware for each subsystem module. • Subsystem components (pumps, valves) are represented by FS Parameters. • FS Fields show the state of the component, messages sent by the local application and measurements associated with the component. Communications between the FS Node and the LSCC are made through Java Remote Method Invocation (RMI) [8]. These interconnections are visible in Fig. 2. The Node regularly queries the RMI server of the LSCC concerning any state changes occurring on the components of the susbsystem. This design choice was made because FS Nodes cannot warn the FS central server of changes in their configuration fields. Changes would not be visible immediately so there would be no advantage in making the LSCC able to send messages to the Node without being queried. Commands issued by FS operators are immediately sent to the LSCC, which then reports the new state of the component. If an error occurs in one component, the state of the corresponding hardware will change to error. This gives a visual warning to an operator following the main FS Hardware status panel in the user client of FS.
3.3. GUI interface The user client of FS can automatically generate a configuration panel for the FS Hardware, based on an eXtensible Markup Language (XML) description file. This generates a simple interface whose Fields receive common types such as numbers or strings. Visual clues, like colours used in the local GUI, are of great assistance for users monitoring the state of subsystems, though are not implemented on FS. Taking advantage of its plug-in feature, extra visual panels that show information about the components of the subsystem were developed. These include state, a sign using the same colour scheme as the local GUI and messages sent by the LSCC. Since extra panels are specific for each FS Hardware, this approach has the advantage that as long as a FS Parameter is selected, the states of all other FS Parameters in the same FS Hardware are visible. If only the standard panel was to be used, operators would only be able to monitor one FS Parameter at the time.
3.4. Subsystem generic description As an extension of this work, a proposal for defining a method to describe generic subsystems was made. Such description can help the integration of other subsystems in the FS platform, by allowing the Node to automatically generate the hardware–parameter tree and the panels for the user client GUI. The description would contain the structure of the components in the subsystem, their possible states, commands and state machine. This idea is still under appreciation and a draft based on XML is expected to be ready in the short-term.
498
A.S. Duarte et al. / Fusion Engineering and Design 85 (2010) 496–499
Fig. 1. Example of modules of the interface of the LSCC: on the top is the vacuum control panel and in the bottom is the shutters panel. Visible are also tabs for the other modules.
A.S. Duarte et al. / Fusion Engineering and Design 85 (2010) 496–499
499
A generic descriptor for subsystems will allow faster and easier integration of new subsystems in FireSignal. It will also provide coherent and similar interface, thus reducing the time necessary for machine operators to learn how to use it. Acknowledgements This work has been carried out within the framework of the Contracts of Association between the European Atomic Energy Community and “Instituto Superior Técnico” (IST) and IPP.CR. IST also received financial support from “Fundac¸ão para a Ciência e Tecnologia” in the frame of the Contract of Associated Laboratory. The views and opinions expressed herein do not necessarily reflect those of the European Commission. References
Fig. 2. Schematic showing how the Node connects to different parts in the system.
4. Conclusions The local application for controlling the subsystems for vacuum and GDC was installed successfully on COMPASS tokamak and has been used by its operations team since then. Its visually rich and intuitive interface has proven valuable in introducing users to the subsystems operation. A FireSignal Node for subsystems was developed an integrated on the CODAC. It allows users to monitor and operate the subsystems remotely, with the same basic capabilities of the local control application. A plug-in that extends the GUI of FireSignal provides operators with visual information of the state of the machines.
[1] J.B. Lister, J.W. Farthing, M. Greenwald, I. Yonekawa, The status of the ITER CODAC conceptual design, Fusion Engineering and Design 83 (Issues 2–3) (2008) 164–169. [2] R. Pánek, O. Bilykova, V. Fuchs, M. Hron, P. Chraska, P. Pavlo, et al., Reinstallation of the COMPASS-D tokamak in IPP ASCR, Czechoslovak Journal of Physics 56 (Suppl. B) (2006) B125–B137. [3] T. Pereira, F. Janky, B. Santos, P. Cahyna, M. Hron, J. Sousa, H. Fernandes, Subsystems control on the COMPASS tokamak, in: Proceedings of the 7th IAEA Technical Meeting on Control, Data Acquisition, and Remote Participation for Fusion Research, Aix-en-Provence, 2009. [4] Microchip press release, regarding dsPIC: http://www.microchip.com/stellent/ idcplg?IdcService=SS GET PAGE&nodeId=2018&mcparam=en013529 (accessed February 2010). [5] RXTX Java Library. Online: http://users.frii.com/jarvi/rxtx/index.html (accessed February 2010). [6] PostgreSQL. Online: http://www.postgresql.org/ (accessed February 2010). [7] A. Neto, H. Fernandes, A. Duarte, B.B. Carvalho, J. Sousa, D.F. Valcárcel, et al., FireSignal—Data acquisition and control system software, Fusion Engineering and Design 82 (Issues 5–14) (2007) 1359–1364. [8] Sun Microsystems. Java Remote Method Invocation - Distributed Computing for Java, 2001. Online: http://java.sun.com/javase/technologies/core/basic/rmi/ whitepaper/index.jsp (accessed February 2010).