Time Synchronisation of Mark VI System

In a plant where many control systems are used for specific dedicated purposes, it is essential that all their individual times are synchronised. Mark VI System used for Gas Turbine Control has the facility to synchronise its time with other systems via the Network Time Protocol (NTP) system. After connecting all Controllers and HMIs into the same network and establishing communication among them, the next requirement was to get the system time-synchrnised with the Plant GPS enabled Master Clock system. And it was the first time.

So first of all it was necessary to get the scheme clear. It became clear that unlike DCS Processors, Mark VI Controllers do not have direct time signal input facility. Rather one or more of its HMIs can be made Time Masters which will receive time signal input from the main time source (e.g. GPS system) and work as servers for time signal in its own network. Since all the Controllers and other HMIs are on the same network, they will become client to the time server and become time-synchronised with the time server.

To begin with we planned to make a single unit (Unit-1) out of two units ready with time-synchrinisation. So the devices on the Mark VI network were -

• Mark VI Control Panel for Unit-1
• Local HMI for Unit-1 panel (GT1_SVR)
• Remote HMI for both the units (CRM1_SVR)

Next when we made a list of the pre-requisites for implementing the scheme it was somewhat like this -

• Fully established communication among the controllers and the HMIs - which was ready
• Network Time Protocol software installed on the HMIs -which was also ready
• A receiver for time signal called Time Card capable of receiving IRIG-B time signal - it was installed on the CRM1_SVR which was to be configured as the time server. In our case the Time Card was bc635PCI time module installed at a PCI Slot supplied by Symmetricom. This card was identified by the Operating system through its driver. The connection was to be made through a 15-pin 'D' connector.
• 'D' Connector to BNC adapter - it was required because the IRIG-B signal was available from the Master Clock system via co-axial cable, and this was also supplied with the time card.

In addition to these, the HMI with the time card was also having two other software namely Symmetricom Demonstration Driver bc635CPP and TrayTime whose utilities, at the beginning, we were not so sure about.

So everything was ready and only the implementation was left. We started with the internal configuration of the Mark VI system which we divided into 3 steps and did like this -

1. Configuring Mark VI Controller (in the M6B file): "Unicast" selected at the NTP tab on the device (G1) properties and servers UDH names were specified. The primary server was the remote server i.e. UCRM1_SVR and the backup server was the local server i.e. UGT1_SVR.
2. Configuring CRM1_SVR (HMI with the time card): 
• First NTP server was configured from Control Panel by selecting it as a Time "Master (supply time to clients)" and operating mode as "Unicast."
• Next the time card was configured at the Turbine Control Interface from Control Panel. At the Time Hardware tab, appropriate time card was selected (in our case BC635PCI) and in the Satellite Time Source section Timecode was selected as "IRIG-B, Modulated" and Timebase as "UTC".
3. Configuring GT1_SVR (HMI without the time card): For this only NTP was required to configure from Control Panel by selecting it as a Time "Client" and operating mode as "Unicast." In addition the Server was to be provided, for which the PDH name of the Primary Time Master, i.e. CRM1_SVR was provided.

With these the internal configuration was over. Now it was time to connect the IRIG-B cable to the time card via the BNC to 'D' adapter. After the connection the utility of the software bc635cpp became apparent. The bc635cpp program allows the user to access the bc635PCI card and demonstrates the board functionality. And with this we saw that the time card was receiving time signal from the time source.

The next step was to set the HMI system time as per the acquired time which will further be synchronised thoughout the network. Then it was the time for the software TrayTime. This system tray utility queries the bc635PCI and set the system clock on a periodic basis. That was it. It was to be kept running to sync the system time with the acquired time after a certain interval. Then we checked one by one and found that all the controllers and HMIs were showing the same time in synchronisation.

My experience with Optical Fibre Communication

I had never imagined that Optical Fibre Cables (OFC) would play such an important role in the installation of the Mark VI network at the Siddhirganj Project. The problem was noticed at the time of initial installation of HMIs. We had to connect 3 separate HMIs and 2 separate panels which were installed inside 3 separate buildings into the same network. Because of the distance among the buldings normal UTP cable could not be used. So the only solution was using OFC. I was excited but at the same time a little tense as I had never seen OFC connection before and I had no idea how it was to be done. However some googling and consultation with the executing agency made the scheme almost clear to me. As I understood it was going to be somewhat like this -

Network Switch - Ethernet Patch cord - Media Converter - OF Patch cord - LIU - OFC - LIU - OF Patch cord - Media Converter - Ethernet Patch cord - Network Switch

Where Media Converter converts light to electrical signal (in our case ethernet) and vice versa, and LIU is like a Junction Box for fibre interconnection which uses Pigtail connectors.

From further study of the supplied hardware, it was found that the Media Converters would not be required as the Allied Telesyn AT-8624T/2M network switches were having in-built AT-A45/SC OFC connection ports which were nothing but media converters with SC (among so many types of OFC connectors it is the square push-type one) connector. Such a great product! The rest was easy -

Network Switch - OF Patch cord - LIU - OFC - LIU - OF Patch cord - Network Switch

Though the scheme looked pretty easy, the job was not. Optical Fibre cable connection is hell of a job, consisting of so many steps in which Splicing is the toughest and not a child's play. But we were through.

Next was the testing. We were smart enough to jump over the light test. We went for the much easier method. Yes, ping-ing! Since IPs were known, it took only a few minutes to know that our communication was established.

A Little Farther

Sometimes comes a situation when something is not what it is supposed to be. When everything is not in order. Then you have to go a little farther, dig a little deep to bring order from chaos, to get things working. Such a situation I faced when things were not working after installing and powering up an Ethernet switch supplied separately for expanding  a Mark VI network.

It was not communicating with any device on the network. I understood that the switch was not configured unlike other switches and the problem will be solved if I could configure it. But how? Then the manual came handy. There was a web interface but since the switch ip was not known, it was not helpful. Then remains the obvious solution. Use the serial cable supplied with the switch and try.

I became a fool by the instruction written in the manual. It said that after connecting the serial cable on booting the switch a prompt will come on the computer screen, if not press the Enter key several times and it will. I connected the cable. Powered up the switch and waited for 10 minutes. Pressed Enter for about hundred times. But nothing happened! I began to lose hope.

Then the "linux-power-user-during-college-days" in me woke up and told me, "This shouldn't be the way. How can a prompt come by itself after connecting a serial cable? There has to be something, sort of interface." Suddenly I thought why I shouldn't try the hyperterminal facility for this? I invoked a hyperterminal window and created a new connection using the COM port the switch was connected to with port settings as per the manual. Rebooted the switches and voila! The login prompt was there in front of my eyes on the hyperterminal window.

I tried the default login name and password and it clicked! I was in. Then the next part was how to configure the switch? Though the linux-user was awake but still I was not confident enough with the serial cable CLI. I thought of using the Web GUI. For this a little effort was enough. With the help of the manual I assigned an ip to the switch on our Mark VI PDH. Then I tried to use the GUI by typing this ip on the Browser's address bar and the GUI opened with a login screen! I again typed the default strings and I was in!

After crossing the initial threshold I felt that my luck started to favour. Quite luckily I found one configuration file 'default.cfg' saved in the switch memory itself. I opened it and found that all the necessary configurations were there on that file. I thought of using it for switch configuration. But I commented out the line in the file which defined the user and the password (encrypted) so that I could again log in with the CLI in case anything went wrong. I saved the file with a relevant filename and set the switch to use it on bootup. Logged out, closed every program and rebooted the switch.

I ping-ed the switch with my fingers crossed. It started working as it was supposed to. Communication was through with all the controllers, switches and servers. My effort was successful. The new switch was configured.