Like hardware, software is also distributed over three layers namely User Interface Layer, Supervisory Layer and Equipment Control Layer.

Layer 1 software, which is also termed as Graphical User Interface (GUI), handles user interaction and provides a means of communication between user and accelerator machine. It mainly deals with user requirements and should respond each of the user actions. Such application software on a host can run with non real time operating system. The response to user interaction should be with in the human acceptable limits (500 milliseconds to 1 second). Similarly database updating may be at the rates of 1 second to few minutes and more according to requirements. Application software at layer 1 has to communicate with supervisory (SC) layer for data acquisition and control initiation.

The software at this layer is for the data acquisition and control. The requirements at this layer are fast, multi tasking performance, good network communication facilities and a convenient environment for software development and debugging. Supervisory level software has to manage two network interfaces, Ethernet for upper layer and Profibus for lower layers.

Software requirements at this level are mainly governed by machine side. The main task at this level is to get data from EC at regular time interval or on demand, and provide a response to any communication received from the layer 1 like transmitting a block of data or initiating the action to change the status or set the values of parameters of the subsystem it is designated to. Real-time operating system OS-9 is used at this level. Availability of powerful development tools such as editor, source level debugger and compilers help to develop the required applications conveniently.

OS-9 supports TCP/IP protocol on Ethernet with native programming environment and optionally cross-development facilities under UNIX, WinNT over network. Code is written in C language and after compilation downloaded on VME crate over network using FASTTRACK tool, supported by Microware.

EC software is almost dedicated to a particular task and confines to a group of instruments. Its basic function is to access equipment parameters and report its status to supervisor when demanded. It also controls the equipment according to user requirements and commands. Additionally, it has to execute diagnostic tasks related to hardware interfaces like ADC, DAC calibration with respect to reference source provided on board and report and correct accordingly. A dedicated software in coordination with upper layer, provides total accessibility of equipment at remote control location. Software at this layer can also respond to any abnormal behaviour of equipment at this level, like abnormal heating, failure of cooling channel, etc. These functions more or less depend on design of the equipment and the control and monitoring action provided. For control action, data has to flow from user to EC and then to machine and for monitoring data has to flow from EC to user layer. The response time of the system is important for user point of view. The total response time for any command is from user to equipment and then back to user, for feed back. This is expected to be in the range of few hundred milliseconds to 1 second.

The software for layer is written in C code and downloaded to EC after compilation. It consists of various modules like I/O modules (drivers and descriptors), Command/Response (C/R) modules, alarm modules, special modules like magnet cycling module & ramp generation module etc.
I/O modules contain descriptor for each I/O point specifying characteristics like conversion parameters and offsets.
C/R modules handle the data exchange between EC and SC. It parses the message received from SC and convert the same in the proper format for EIU to take appropriate action.
Alarm modules test the status of equipments and report abnormal conditions for taking proper action. Then may then inform the SC of the action taken.
Ramp generation modules calculate the required parameters for the ramp and the ramping process is initiated and controlled with synchronizing pulses.

The Control System for Magnet Power supplies (P/Ss) of Indus-2 is one of the systems that is used to set up the dynamics of the beam in the accelerator. The control system facilitates setting up the different magnet P/Ss for beam injection, ramping and storage at the higher energy levels. The beam dynamics pose different requirements for all these phases. The flexibility to operate P/Ss in different modes and catering the stringent accuracy and stability requirements are the features of the system. The best of the accuracies of the references is 50 ppm maintained at the supplies inputs. This is assured by the hardware. The system provides a very flexible, fully programmable and synchronous energy ramping and the magnet cycling procedure. The system also provides the diagnostics information to the operator level. The ramping system also facilitates the ramping of RF voltage synchronously, a typical requirement from an accelerator. The present control system is the third version after various reviews. It is being operated daily without hurdles though the system is not absolutely trouble free.

Vacuum system in Indus-2 is widely scattered and uses differing kind of devices viz., pumps, gauges, isolation valves, Residual Gas Analyzers (RGA), temperature monitors etc. The Control System for Vacuum (VCS) monitors and controls all such devices. The specialty of this control system lies in its interface to the diversified type of devices. Provision to incorporate more devices in future is made. The partial pressure of the gas components in the vacuum chamber of Indus-2 is available from 16 RGAs. New software with substantial capabilities was developed to integrate the RGA system to VCS. The Thermocouple Interface Unit (TCIU) monitors temperature of vacuum chambers of Indus-2. Software was developed for this system in LabView. The software reads 20 no�s of TCIU units on multi-drop RS 485 link. The temperature information is also provided to Machine Safety Interlock System (MSIS) as temperature interlocks. The System has alarm generation, data logging to central database and various diagnostics features. Later both RGAs and TCIUs are also integrated with VCS.

The RF control is fully implemented for all four cavities. A parallel operator console is also provided in the far off RF system hall. This was required temporarily for but its usefulness made it a permanent feature and it is now regularly used. All RF systems are under a full fledged local RF supervisory control system which is a superset of the remote control system for RF. The RF control system is interfaced to this local RF control station. This allows the filtering of some of the control actions which are critical to the RF systems. Monitoring of the parameters is available on both the systems. Virtually the two control systems work on a single system.

This system controls all beam diagnostic devices placed in TL3 and Indus-2 ring. Recently control of sighting beam line was added to this sub system.

The control system for Radiation Safety & Surveillance System (RSS) monitors the radiation levels all around Indus-2 accelerator complex. It handles about 52 radiation monitors and various safety devices. The control system issues warnings and alarms when radiation levels reach some prefixed critical values. It also display and plot the radiation dose rate of all the radiation monitors. Status of protection and warning devices viz., Search and Scram switches, Door Interlocks and Flashing Lamps is displayed in the control room. It also facilitates data logging of all the parameters for future reference and analyses. There are about 225 Digital Input and about 52 Analog Input signals interfaced to RSS Control system.

The first system to be commissioned was the control system for Indus-2 LCW plant. LabView ver 6.0 was relied upon to build the system software. The system monitors about 700 parameters and provides features like re-configurability in control actions and requirement of dealing with slower devices viz. electrical valves which take about 20 seconds to operate. In addition, the sequential operation of such devices slowed down the over all performance of the system. The Concept of event driven architecture was brought in to rescue from the problem. The advantage of this architecture was further realized when the number of parameters increased to 1500. The control system fulfilled the requirement of a standalone plant control system and later integrated in the main control system of Indus-2.

Of the late introduced the Alarm Handling System (AHS) alerts the operator of any abnormality in the machine parameters, e.g., supply trips, faulty status, interlocks etc. The audio alerts immediately draw the attention of the operator. The alarming parameter can be seen and acknowledged on the system display. The happenings are categorized as alarms and events. The alarms and events are logged with detailed information about their origin. The Alarm history can be displayed on web. Measures have been taken to avoid occurrence of spurious alarms. The AHS uses central database for alarm generation thus it is possible to include any number of parameter in the alarm list.

Screenshot of Alam Handling System Software.

The centralized Machine Safety Interlock System (MSIS) is implemented for protection of critical machine components like magnets, photon chambers, DCCT, sector valves etc. Over temperature and flow switches mounted on the components provide temperature status. The MSIS gives a trip signal to various devices when any of the High Radiation status, over temperature or TCIU status is found bad. Later BLFE interlock and emergency beam dump request from beam line users etc, will be incorporated in the MSIS. The typical use of control interlock contacts and the architecture guarantees failsafe operation of accelerator w.r.t. power/power supply failure, processor and communication failure. Interlock system always polls all the input status and sends all information to supervisory control crate. RS485 is used for communication between L2 and L3. Control actions are taken at layer L2.

Indus-2 Beam Line Front Ends (BLFE) control system was developed to protect the machine vacuum from beam line failures and vice versa. This allows a well co-ordinated and safe usage of machine by its users. This system involved design complexity, as it had to control vacuum gate valves, safety shutters in presence of a local control system at front end. The software automatically closes the gate valves when the vacuum degrades on the either side of the front end. Beam injection request and giving permissions for valves and safety shutters is password protected so that only authorized operator may operate. The control system also provides facility of logging beam usage and experiment related information for administrating Indus-2 utilization.

A global slow orbit feedback system has been designed using Matlab and PVSS.