- Email: [email protected]
The KSTAR integrated control system based on EPICS
Fusion Engineering and Design 81 (2006) 1829–1833
The KSTAR integrated control system based on EPICS K.H. Kim ∗ , C.J. Ju, M.K. Kim, M.K. Park, J.W. Choi, M.C. Kyum, M. Kwon, the KSTAR Control Team National Fusion Research Center, 52 Eoeun-dong, Yuseong-gu, Daejeon 305-806, Republic of Korea Available online 23 May 2006
Abstract The Korea Superconducting Tokamak Advanced Research (KSTAR) control system will be developed with several subsystems, which consist of the central control system (e.g. plasma control, machine control, diagnostic control, time synchronization, and interlock systems) and local control systems for various subsystems. We are planning to connect the entire system with several networks, viz. a reflective-memory-based real-time network, an optical timing network, a gigabit Ethernet network for generic machine control, and a storage network. Then it will evolve into a network-based, distributed real-time control system. Thus, we have to consider the standard communication protocols among the subsystems and how to handle the various kinds of hardware in a homogeneous way. To satisfy these requirements, EPICS has been chosen for the KSTAR control. The EPICS framework provides network-based real-time distributed control, operating system independent programming tools, operator interface tools, archiving tools, and interface tools with other commercial and non-commercial software. The most important advantage of the use of the EPICS framework is in providing homogeneity of the system for the control system developer. The developer does not have to be concerned about the specifics of the local system, but can concentrate on the implementation of the control logic with EPICS tools. We will present the details of the integration issues and also will give a brief summary of the entire KSTAR control system from an integration point of view. © 2006 Elsevier B.V. All rights reserved. Keywords: Tokamak control; Plasma control system; Real-time network; Distributed control system; EPICS; KSTAR
1. Introduction The integrated control system for KSTAR [1] should be categorized as a network-based distributed control system, since the entire control system for KSTAR will be composed of several subsystems classified by their functions in the entire system. The subsystems will be ∗ Corresponding author. Tel.: +82 42 870 1616; fax: +82 42 870 1609. E-mail address: [email protected] (K.H. Kim).
0920-3796/$ – see front matter © 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.fusengdes.2006.04.026
connected through networks and will make highly systemized interaction with one another. The integrated control system will be realized by the connections and by the interactions among subsystems as mentioned above. To develop an extensible and reliable control system, the use of verified development tools and middleware is required. These can provide us with a framework for making a distributed control system and can provide software facilities such as a standard communication protocol, processing databases, bundled hardware drivers, etc. We have chosen EPICS [2] as the stan-
1830
K.H. Kim et al. / Fusion Engineering and Design 81 (2006) 1829–1833
dard development tool and middleware for the KSTAR control system. It has the channel access (CA) communication protocol to make TCP/IP connections between EPICS systems and to transfer processing variables (PVs) through the protocol. The EPICS also provides us with a processing database, which is a set of PVs, and we can implement control algorithms through configurations of the processing database. Some of Graphical User Interface (GUI) Tools can be used for the configurations of databases and they can be used as a kind of graphical programming language. EPICS has the State Notation Language (SNL), which is very similar to the C language and can easily make a Finite State Machine (FSM) model. There are many tools that can be used to make Operator Interface (OPI) and to make an archiving system. The CA gateway can be used for access control and for configuration of the network topology. We have studied how the EPICS system can be used for the KSTAR control system and which features in EPICS can be used for specific requirements in the KSTAR control system.
2. Structure of the KSTAR control system The KSTAR integrated control system (Fig. 1) is composed of the central control system (CCS), which
provides us with the capability of performing supervisory control for the entire system and many local systems. The central control system contains the plasma control system (PCS), machine control system (MCS), diagnostic control system (DCS), time synchronization system (TSS), and interlock system (ILS). These systems are connected by several network systems: the machine control network-based on Ethernet, the timing network-based on optical fibers with KSTAR’s own timing network protocol, the reflective-memory-based real-time network (RTNet), and an interlock networkbased on optical ControlNetTM [3]. 2.1. Supervising the entire system The system provides OPIs for man–machine interface (MMI) and for performing the continuous monitoring and control for entire systems. EPICS OPI tools can be used to develop machine operation MMIs. The OPI tools provide many advantages to develop MMI for plant operation, such as alarm handling, visualization for system and operation status, etc., but they are inadequate to display scientific data. Hence, we are going to use MDSplus tools such as JScope to display plasma physics oriented parameters. The system also provides the supervisory functions for machine control and plasma control. The supervisory functions pro-
Fig. 1. Structure of KSTAR control system.
K.H. Kim et al. / Fusion Engineering and Design 81 (2006) 1829–1833
vide the information exchange between entire underlying systems and operating procedure for autonomous plant operation. The CA protocol will be the standard protocol for the information exchange and the SNL will be the solution to implement operation procedures for the autonomous sequential operation. The core of the supervisory control is the SNL code and it is located in one of the Input/Output Controllers (IOC) in the CCS.
1831
nostic system). But we do not use these features in MDSplus; only archiving features will be used. EPICS will control the diagnostic digitizers directly to simplify the structure of the system. We have a plan to develop MDSip supports on EPICS, which perform data transfer from data acquisition devices to the MDS server through Ethernet to archive diagnostic data and work as EPICS driver supports. 2.4. Networking and interface
2.2. Plasma discharge control Three [K.H. Kim1] systems are involved in plasma discharge control. The DCS provides the diagnostic information about plasma for the PCS. The PCS performs real-time plasma control algorithms and provides the results of the control algorithms to MCS. The MCS activates actuators such as magnet currents, heating systems, and puffing systems. These require, dedicated, and very low latency communications. We are going to use RTNet for communication in the discharge control. 2.3. Data acquisition There are two kinds of archiving systems required. One is an archiver for machine operation. It would be used for low data/events rate and large number of channels. Above all, it would require a continuous archiving feature because it will be used for plant operation and monitoring such as the helium cryo system, the vacuum, and the superconducting magnets which are operated 24 h a day. Actually, the CA archiver seems to be the best solution for this archiving system. The CA archiver provides basic archiver engine, retrieving tools and also APIs. The other archiver is for diagnostic and experimental data. It would be used for large amounts of data and a smaller number of channels as compared to the machine operation. The most important difference from the CA archiver is the shot based archiving required for diagnostics systems and the plasma control system. We are considering MDSplus [4] for this archiver, since MDSplus has been used in the fusion community and it also supports many legacy codes. Actually, the MDSplus has an archiving feature as well as other features (for example, a dispatcher which can be used for controlling and arming digitizers in a diag-
The machine control network is based on Ethernet. It delivers CA protocols which are standard protocols in the KSTAR control system to transfer machine control data. The OPIs and machine control data archiver also use the CA protocol. The CA gateway will be involved in the machine control network. The CA gateway is working as a proxy server, so it reduces the number of CA connections for individual IOCs. The CA gateway also provides an access control feature. We are planning to use the host base access control to give security for the control system. The CA gateway also provides the virtual connection among CA servers and clients. Usually, many of the CA connections would be established among IOCs and OPIs. The CA gateway makes virtual circuits internally to reduce the number of CA connections on the server (IOC) side. This is a very useful trick to save CPU power so that it will be used for higher priority tasks instead of the communication task in a real-time system. The diagnostic systems are connected to the MDS server though Ethernet, which is separate from the machine control network, to archive experimental data into the MDS server. The optical timing network delivers 100 MHz timing clock and event information. The RTNet is based on an optical ring network and VMIC5565 reflective memory modules. It has very low latency (<0.4 s/node) and high data thruput (>174 MB/s). So, we plan to use this network for the PCS system to deliver plasma diagnostic data and actuator control data. A PLC-based interlock system uses a separate interlock network, the optical ControlNetTM . This network can be accessed by EPICS through EtherIP communication modules, which make conversion between ControlNetTM and UDP based EtherIP. EPICS has driver supports for the EtherIP protocol. So we can
1832
K.H. Kim et al. / Fusion Engineering and Design 81 (2006) 1829–1833
easily combine the interlock system into the integrated control system.
it unsuitable for handling high data rates. The cPCIbus and PXIbus would be acceptable choices. There are some technical issues for developing a control system with EPICS:
3. Technical implementation
• Implement the elementary control algorithm on EPICS database: data conversion, PID control, simple calculations, and control. • Utilize SNL program for more complex control: sequential control, complex control algorithms, and C embedded programming. • Utilize event driven features: EPICS provides useful features for event driven programming in database and in SNL. We can use it to make more efficient codes.
3.1. PXI support for fast monitoring We are considering the PXI system for the magnet and structure monitoring systems. Even though they do not require real-time features, they have to handle fast data rates and a large number of channels with a variety of I/O modules. The PXI system can provide a variety of I/Os as well as various commercial signal conditioning modules such as SCXI. To support PXI hardware in EPICS, we have developed the genericPXI, which supports almost all PXI hardware and is designed for generic machine control and monitoring. The genericPXI accepts multiple device support, so we can also use it for the diagnostic system. We can adopt the MDSip support, which are archiving device supports for MDS, as a device layer of genericPXI. 3.2. cFP support for remote I/O Many KSTAR local control systems, e.g. vacuum and cryostat controllers, need robust and low-cost I/O modules that are not necessarily fast. The requirements specify the use of remote I/O modules. The CompactFieldPoint (cFP) solution satisfies the requirements. The cFP has a small CPU module for the RT-LabView program on PharLab RTOS and also has a variety of I/O modules – ai, ao, di, and do. We have developed a small protocol based on TCP/IP to enable communication between EPICS and cFP.
4. Integration strategy There are some strategies for choosing software and hardware platforms to ease integration with EPICS. For the required read-time features, vxWorks/VMEbus system is a faultless choice. We already chose this platform for the Magnet Power Supply (MPS) and the TSS. This solution would allow us to use various bundled hardware drivers in EPICS. But, the limited VMEbus speed (worst case ∼13 MB/s for single word transfer), makes
There are some restrictions in the use of the SNL program as compared to the EPICS database. Usually, the EPICS database program uses dbAccess routines which are a kind of memory access to communicate among the records (PVs) in the database, but the SNL is using the CA to access PVs. However, the SNL program is running on the same IOC which contains the PVs it wants to access. The dbAccess has less overhead than the CA. Thus, we have to be prudent when we apply the SNL program for real-time tasks. We have developed an automated control with SNL for the KSTAR vacuum system. Usually, the SNL in this system gives a response to external events within 7 ms. This is good enough to use for the vacuum system, however the latency is neither short nor predicable. 5. Summary and future plan After choosing the EPICS as the middleware for KSTAR control, we have developed low level hardware support to adapt it for system requirements and integration strategy. We already made various hardware supports but still need to develop cPCI supports for PCS and MDSip supports for experimental archiving. We also need to obtain a clearer understanding of Tokamak operation to implement the integration control system for KSTAR. Acknowledgements This work was supported by the Korean Ministry of Science and Technology. We also acknowledge
K.H. Kim et al. / Fusion Engineering and Design 81 (2006) 1829–1833
substantive technical discussion with A.C. England, NFRC, KBSI. References [1] G.S. Lee, J. Kim, S.M. Hwang, C.S. Chang, H.Y. Chang, M.H. Cho, The design of KSTAR tokamak, Fusion Eng. Des. 46 (1999) 405–411.
1833
[2] http://www.aps.anl.gov/epics. [3] M. Kwon, I.S. Choi, J.W. Choi, J.S. Hong, M.C. Keum, K.H. Kim, The control system of KSTAR, Fusion Eng. Des. 71 (2004) 17–21. [4] T.W. Fredian, J.A. Stillerman, MDSPlus. Current developments and Future directions, Fusion Eng. Des. 60 (2002) 229– 233.
The KSTAR integrated control system based on EPICS K.H. Kim ∗ , C.J. Ju, M.K. Kim, M.K. Park, J.W. Choi, M.C. Kyum, M. Kwon, the KSTAR Control Team National Fusion Research Center, 52 Eoeun-dong, Yuseong-gu, Daejeon 305-806, Republic of Korea Available online 23 May 2006
Abstract The Korea Superconducting Tokamak Advanced Research (KSTAR) control system will be developed with several subsystems, which consist of the central control system (e.g. plasma control, machine control, diagnostic control, time synchronization, and interlock systems) and local control systems for various subsystems. We are planning to connect the entire system with several networks, viz. a reflective-memory-based real-time network, an optical timing network, a gigabit Ethernet network for generic machine control, and a storage network. Then it will evolve into a network-based, distributed real-time control system. Thus, we have to consider the standard communication protocols among the subsystems and how to handle the various kinds of hardware in a homogeneous way. To satisfy these requirements, EPICS has been chosen for the KSTAR control. The EPICS framework provides network-based real-time distributed control, operating system independent programming tools, operator interface tools, archiving tools, and interface tools with other commercial and non-commercial software. The most important advantage of the use of the EPICS framework is in providing homogeneity of the system for the control system developer. The developer does not have to be concerned about the specifics of the local system, but can concentrate on the implementation of the control logic with EPICS tools. We will present the details of the integration issues and also will give a brief summary of the entire KSTAR control system from an integration point of view. © 2006 Elsevier B.V. All rights reserved. Keywords: Tokamak control; Plasma control system; Real-time network; Distributed control system; EPICS; KSTAR
1. Introduction The integrated control system for KSTAR [1] should be categorized as a network-based distributed control system, since the entire control system for KSTAR will be composed of several subsystems classified by their functions in the entire system. The subsystems will be ∗ Corresponding author. Tel.: +82 42 870 1616; fax: +82 42 870 1609. E-mail address: [email protected] (K.H. Kim).
0920-3796/$ – see front matter © 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.fusengdes.2006.04.026
connected through networks and will make highly systemized interaction with one another. The integrated control system will be realized by the connections and by the interactions among subsystems as mentioned above. To develop an extensible and reliable control system, the use of verified development tools and middleware is required. These can provide us with a framework for making a distributed control system and can provide software facilities such as a standard communication protocol, processing databases, bundled hardware drivers, etc. We have chosen EPICS [2] as the stan-
1830
K.H. Kim et al. / Fusion Engineering and Design 81 (2006) 1829–1833
dard development tool and middleware for the KSTAR control system. It has the channel access (CA) communication protocol to make TCP/IP connections between EPICS systems and to transfer processing variables (PVs) through the protocol. The EPICS also provides us with a processing database, which is a set of PVs, and we can implement control algorithms through configurations of the processing database. Some of Graphical User Interface (GUI) Tools can be used for the configurations of databases and they can be used as a kind of graphical programming language. EPICS has the State Notation Language (SNL), which is very similar to the C language and can easily make a Finite State Machine (FSM) model. There are many tools that can be used to make Operator Interface (OPI) and to make an archiving system. The CA gateway can be used for access control and for configuration of the network topology. We have studied how the EPICS system can be used for the KSTAR control system and which features in EPICS can be used for specific requirements in the KSTAR control system.
2. Structure of the KSTAR control system The KSTAR integrated control system (Fig. 1) is composed of the central control system (CCS), which
provides us with the capability of performing supervisory control for the entire system and many local systems. The central control system contains the plasma control system (PCS), machine control system (MCS), diagnostic control system (DCS), time synchronization system (TSS), and interlock system (ILS). These systems are connected by several network systems: the machine control network-based on Ethernet, the timing network-based on optical fibers with KSTAR’s own timing network protocol, the reflective-memory-based real-time network (RTNet), and an interlock networkbased on optical ControlNetTM [3]. 2.1. Supervising the entire system The system provides OPIs for man–machine interface (MMI) and for performing the continuous monitoring and control for entire systems. EPICS OPI tools can be used to develop machine operation MMIs. The OPI tools provide many advantages to develop MMI for plant operation, such as alarm handling, visualization for system and operation status, etc., but they are inadequate to display scientific data. Hence, we are going to use MDSplus tools such as JScope to display plasma physics oriented parameters. The system also provides the supervisory functions for machine control and plasma control. The supervisory functions pro-
Fig. 1. Structure of KSTAR control system.
K.H. Kim et al. / Fusion Engineering and Design 81 (2006) 1829–1833
vide the information exchange between entire underlying systems and operating procedure for autonomous plant operation. The CA protocol will be the standard protocol for the information exchange and the SNL will be the solution to implement operation procedures for the autonomous sequential operation. The core of the supervisory control is the SNL code and it is located in one of the Input/Output Controllers (IOC) in the CCS.
1831
nostic system). But we do not use these features in MDSplus; only archiving features will be used. EPICS will control the diagnostic digitizers directly to simplify the structure of the system. We have a plan to develop MDSip supports on EPICS, which perform data transfer from data acquisition devices to the MDS server through Ethernet to archive diagnostic data and work as EPICS driver supports. 2.4. Networking and interface
2.2. Plasma discharge control Three [K.H. Kim1] systems are involved in plasma discharge control. The DCS provides the diagnostic information about plasma for the PCS. The PCS performs real-time plasma control algorithms and provides the results of the control algorithms to MCS. The MCS activates actuators such as magnet currents, heating systems, and puffing systems. These require, dedicated, and very low latency communications. We are going to use RTNet for communication in the discharge control. 2.3. Data acquisition There are two kinds of archiving systems required. One is an archiver for machine operation. It would be used for low data/events rate and large number of channels. Above all, it would require a continuous archiving feature because it will be used for plant operation and monitoring such as the helium cryo system, the vacuum, and the superconducting magnets which are operated 24 h a day. Actually, the CA archiver seems to be the best solution for this archiving system. The CA archiver provides basic archiver engine, retrieving tools and also APIs. The other archiver is for diagnostic and experimental data. It would be used for large amounts of data and a smaller number of channels as compared to the machine operation. The most important difference from the CA archiver is the shot based archiving required for diagnostics systems and the plasma control system. We are considering MDSplus [4] for this archiver, since MDSplus has been used in the fusion community and it also supports many legacy codes. Actually, the MDSplus has an archiving feature as well as other features (for example, a dispatcher which can be used for controlling and arming digitizers in a diag-
The machine control network is based on Ethernet. It delivers CA protocols which are standard protocols in the KSTAR control system to transfer machine control data. The OPIs and machine control data archiver also use the CA protocol. The CA gateway will be involved in the machine control network. The CA gateway is working as a proxy server, so it reduces the number of CA connections for individual IOCs. The CA gateway also provides an access control feature. We are planning to use the host base access control to give security for the control system. The CA gateway also provides the virtual connection among CA servers and clients. Usually, many of the CA connections would be established among IOCs and OPIs. The CA gateway makes virtual circuits internally to reduce the number of CA connections on the server (IOC) side. This is a very useful trick to save CPU power so that it will be used for higher priority tasks instead of the communication task in a real-time system. The diagnostic systems are connected to the MDS server though Ethernet, which is separate from the machine control network, to archive experimental data into the MDS server. The optical timing network delivers 100 MHz timing clock and event information. The RTNet is based on an optical ring network and VMIC5565 reflective memory modules. It has very low latency (<0.4 s/node) and high data thruput (>174 MB/s). So, we plan to use this network for the PCS system to deliver plasma diagnostic data and actuator control data. A PLC-based interlock system uses a separate interlock network, the optical ControlNetTM . This network can be accessed by EPICS through EtherIP communication modules, which make conversion between ControlNetTM and UDP based EtherIP. EPICS has driver supports for the EtherIP protocol. So we can
1832
K.H. Kim et al. / Fusion Engineering and Design 81 (2006) 1829–1833
easily combine the interlock system into the integrated control system.
it unsuitable for handling high data rates. The cPCIbus and PXIbus would be acceptable choices. There are some technical issues for developing a control system with EPICS:
3. Technical implementation
• Implement the elementary control algorithm on EPICS database: data conversion, PID control, simple calculations, and control. • Utilize SNL program for more complex control: sequential control, complex control algorithms, and C embedded programming. • Utilize event driven features: EPICS provides useful features for event driven programming in database and in SNL. We can use it to make more efficient codes.
3.1. PXI support for fast monitoring We are considering the PXI system for the magnet and structure monitoring systems. Even though they do not require real-time features, they have to handle fast data rates and a large number of channels with a variety of I/O modules. The PXI system can provide a variety of I/Os as well as various commercial signal conditioning modules such as SCXI. To support PXI hardware in EPICS, we have developed the genericPXI, which supports almost all PXI hardware and is designed for generic machine control and monitoring. The genericPXI accepts multiple device support, so we can also use it for the diagnostic system. We can adopt the MDSip support, which are archiving device supports for MDS, as a device layer of genericPXI. 3.2. cFP support for remote I/O Many KSTAR local control systems, e.g. vacuum and cryostat controllers, need robust and low-cost I/O modules that are not necessarily fast. The requirements specify the use of remote I/O modules. The CompactFieldPoint (cFP) solution satisfies the requirements. The cFP has a small CPU module for the RT-LabView program on PharLab RTOS and also has a variety of I/O modules – ai, ao, di, and do. We have developed a small protocol based on TCP/IP to enable communication between EPICS and cFP.
4. Integration strategy There are some strategies for choosing software and hardware platforms to ease integration with EPICS. For the required read-time features, vxWorks/VMEbus system is a faultless choice. We already chose this platform for the Magnet Power Supply (MPS) and the TSS. This solution would allow us to use various bundled hardware drivers in EPICS. But, the limited VMEbus speed (worst case ∼13 MB/s for single word transfer), makes
There are some restrictions in the use of the SNL program as compared to the EPICS database. Usually, the EPICS database program uses dbAccess routines which are a kind of memory access to communicate among the records (PVs) in the database, but the SNL is using the CA to access PVs. However, the SNL program is running on the same IOC which contains the PVs it wants to access. The dbAccess has less overhead than the CA. Thus, we have to be prudent when we apply the SNL program for real-time tasks. We have developed an automated control with SNL for the KSTAR vacuum system. Usually, the SNL in this system gives a response to external events within 7 ms. This is good enough to use for the vacuum system, however the latency is neither short nor predicable. 5. Summary and future plan After choosing the EPICS as the middleware for KSTAR control, we have developed low level hardware support to adapt it for system requirements and integration strategy. We already made various hardware supports but still need to develop cPCI supports for PCS and MDSip supports for experimental archiving. We also need to obtain a clearer understanding of Tokamak operation to implement the integration control system for KSTAR. Acknowledgements This work was supported by the Korean Ministry of Science and Technology. We also acknowledge
K.H. Kim et al. / Fusion Engineering and Design 81 (2006) 1829–1833
substantive technical discussion with A.C. England, NFRC, KBSI. References [1] G.S. Lee, J. Kim, S.M. Hwang, C.S. Chang, H.Y. Chang, M.H. Cho, The design of KSTAR tokamak, Fusion Eng. Des. 46 (1999) 405–411.
1833
[2] http://www.aps.anl.gov/epics. [3] M. Kwon, I.S. Choi, J.W. Choi, J.S. Hong, M.C. Keum, K.H. Kim, The control system of KSTAR, Fusion Eng. Des. 71 (2004) 17–21. [4] T.W. Fredian, J.A. Stillerman, MDSPlus. Current developments and Future directions, Fusion Eng. Des. 60 (2002) 229– 233.