PDA

View Full Version : ProcessGateway Control 2 BCU Hot Standby



anbkhn90
1st March 2017, 11:29
Hi all,<br><br>My system is now having 2 BCUs working with mode Hot-Standby. That means in one time just only 1 BCU is Hot mode and the other is Standby Mode. The Hot mode allows controlling but the Standby does not allow this. So, the problem here is when communicating with load dispatch center with a protocol( in this case 60870-5-101 or 104), how can we control from Load Dispatching Center to the right BCU in Hot mode?<br><br>I just see in the configuration in driverIEC60870 we just can map directly to one variable. So, Could you give me any ideas for this case?<br><br>Thanks,

ursulak
1st March 2017, 11:45
i don't understand your system architecture. Are these two BCU redundant? Thus actually a single BCU but available via two&nbsp;TCP/IP addresses? Or you mean that&nbsp;zenon is a BCU with HMI and works as redundant network with process Server and Standby?&nbsp;<br><br>Are you using in iec870 driver two 'Connections' and each with own set of created zenon variables <br>&nbsp;or single connection with primary and secondary IP address and only one set of variables covering only one BCU?

anbkhn90
1st March 2017, 15:44
i don't understand your system architecture. Are these two BCU redundant? Thus actually a single BCU but available via two&nbsp;TCP/IP addresses? Or you mean that&nbsp;zenon is a BCU with HMI and works as redundant network with process Server and Standby?&nbsp;<br><br>Are you using in iec870 driver two 'Connections' and each with own set of created zenon variables <br>&nbsp;or single connection with primary and secondary IP address and only one set of variablesby covering only one BCU?<br>
Hi ursulak,<br><br>Yes, My architecture system is about : one bay is controlled and monitored by 2 BCUs. That is 2 BCU redundant. In this case they work with Hot Standby Mode, which means in one moment just only one BCU is Hot , the other is Standby. Just only Hot BCU can control devices in the bay, the other cannot. So that, i need to find a solution to merge 2 BCU for the command from Load Dispatch Center ( Using 60870-5-101 and 104 Protocols).<br><br>Could you help me for this solution?<br><br>Thanks

ursulak
1st March 2017, 15:55
Sorry,&nbsp;i'm still not smarter. <br><span style="color: rgb(128, 128, 128);"><br>&gt;My architecture system is about : one bay is controlled and monitored by 2 BCUs. That is 2 BCU redundant.<br></span><br>What components&nbsp;you already have? Or this is only&nbsp;about plans/wishes to have?<br>Are these BCUs then some already existing intelligent devices? or you&nbsp;ask how to&nbsp;use zenon&nbsp;- SCADA/HMI - to&nbsp;make&nbsp;a project working like&nbsp;a redundant&nbsp;BCU?&nbsp;<br>&nbsp;

anbkhn90
2nd March 2017, 02:47
Sorry,&nbsp;i'm still not smarter. <br><span style="color: rgb(128, 128, 128);"><br>&gt;My architecture system is about : one bay is controlled and monitored by 2 BCUs. That is 2 BCU redundant.<br></span><br>What components&nbsp;you already have? Or this is only&nbsp;about plans/wishes to have?<br>Are these BCUs then some already existing intelligent devices? or you&nbsp;ask how to&nbsp;use zenon&nbsp;- SCADA/HMI - to&nbsp;make&nbsp;a project working like&nbsp;a redundant&nbsp;BCU?&nbsp;<br>&nbsp;<br>
Hi ursulak,<br><br>In my country, almost projects do have this architecture system : One bay ( Ex: Line Transmission as the image I attached) is controlled and monitoring by 2 BCUs. Of course, beside these 2 BCUs , this bay has more IED ( Just for Relay Protection).&nbsp;<br><br>The problem here is, Load dispatch center wants to monitor and control from remote to the local substation. In my current project, 2 BCUs working with Hot Standby Mode as I explain before. I would like to ask Does Zenon have method to merge signals in 2 BCUs to become as one signal to send to LDC. For example: we have the status of circuit breaker, but 2 BCUs send together. If BCU is Hot then this BCU will send to LDC and receive the command from LDC.<br><br>Thanks,

ursulak
2nd March 2017, 10:55
<p>So i suppose the answer on my question: "Are these BCUs then some already existing intelligent devices" - is YES <img title="Lächeln" class="inlineimg" alt="" src="images/smilies/smile.png" border="0" smilieid="1">.<br>But the key question: "Are you using in iec870 driver two 'Connections' and each with own set of created zenon variables <br>&nbsp;or single connection with primary and secondary IP address and only one set of variables covering only one BCU?"<br>- Is unfortunately not clear yet for me.<br></p><p>When the 2 BCUs are redundant there are two ways to do the zenon project:<br><strong>1. Variant</strong>: the driver in zenon, e.g. iec870, iec850 etc. - the driver communicating to BCUs -&nbsp;is configured to have only 1 connection, but to redundant - 2 - IP addresses: primary and secondary.<br>Pros: zenon project contains only one set of variables, i.e. only one variable representing the position of the switch. The local SCADA and the control centers are controlling the currently hot BCU, no need to merge data etc.<br>Contras: as long the communication runs to primary IP you do not know what happens on secondary.<br><br>Is it important for you to monitor and control the BCU while it is in standby mode?<br></p><p><strong>2. Variant</strong>: the driver is configured to communicate via 2 connections - thus to communicate in parallel with both BCUs all the time.<br>Pros: you always can see also what standby BCU has and control it independently from hot BCU.<br>Contras: you have in zenon project then all data points (variables) double; thus - if a control center acquires data via Process Gateway in your SCADA system - you would have to merge the doubles to single data points. Such merging is possible but demands additional, individual, projecting work and the 3th set of variables. In zenon you may add a zenon Logic project doing this job or implement a VBA/VSTA solution. And each system is deferent thus it is hard to give universal guidelines - they may be then not the best in your particular case.</p><p><br><br>Thus, if i would be you, i would first consider if it is possible to use variant 1. And for variant 2 - take in contact with your COPA-DATA Support or representative; and maybe consider to order a training or workshop. </p>

ursulak
2nd March 2017, 11:17
The 3.th Variant i know from some customer projects would be to use 'IEC 60870 Master' driver in zenon Logic project, not directly in zenon. Then you can merge the variables of 2 connections already in Logic - "below" zenon. Then in zenon you would have only one set of 870-variables + additional information from Logic about connection status of hot and standby BCU.
This solution demands smart project in zenon Logic (PLC programming) - training, training, training.

anbkhn90
3rd March 2017, 07:45
<p>So i suppose the answer on my question: "Are these BCUs then some already existing intelligent devices" - is YES <img title="Lächeln" class="inlineimg" alt="" src="images/smilies/smile.png" border="0" smilieid="1">.<br>But the key question: "Are you using in iec870 driver two 'Connections' and each with own set of created zenon variables <br>&nbsp;or single connection with primary and secondary IP address and only one set of variables covering only one BCU?"<br>- Is unfortunately not clear yet for me.<br></p><p>When the 2 BCUs are redundant there are two ways to do the zenon project:<br><strong>1. Variant</strong>: the driver in zenon, e.g. iec870, iec850 etc. - the driver communicating to BCUs -&nbsp;is configured to have only 1 connection, but to redundant - 2 - IP addresses: primary and secondary.<br>Pros: zenon project contains only one set of variables, i.e. only one variable representing the position of the switch. The local SCADA and the control centers are controlling the currently hot BCU, no need to merge data etc.<br>Contras: as long the communication runs to primary IP you do not know what happens on secondary.<br><br>Is it important for you to monitor and control the BCU while it is in standby mode?<br></p><p><strong>2. Variant</strong>: the driver is configured to communicate via 2 connections - thus to communicate in parallel with both BCUs all the time.<br>Pros: you always can see also what standby BCU has and control it independently from hot BCU.<br>Contras: you have in zenon project then all data points (variables) double; thus - if a control center acquires data via Process Gateway in your SCADA system - you would have to merge the doubles to single data points. Such merging is possible but demands additional, individual, projecting work and the 3th set of variables. In zenon you may add a zenon Logic project doing this job or implement a VBA/VSTA solution. And each system is deferent thus it is hard to give universal guidelines - they may be then not the best in your particular case.</p><p><br><br>Thus, if i would be you, i would first consider if it is possible to use variant 1. And for variant 2 - take in contact with your COPA-DATA Support or representative; and maybe consider to order a training or workshop. </p><br><br>Hi ursulak,<br><br>I think maybe you still misunderstand me. In my case, there are 2 BCUs identical, each BCU has its own IP address and these 2 BcUs work with Hot standby mode. <br><br>That means when i using driver Iec0870&nbsp;i have to create 2 connections to 2 BCU and these 2 BCUs are capable of sending signals or receiving command from LDC independently. But the truth is, just Hot BCU can control devices but Standby BCU cannot, and the hot and the standby still sending the signals to the remote. That means the operator in remote center should know which BCU is hot to control exactly, but actually they don't care about it. They just know to send the command and the devices have to be operated as the direction they want, they don't care which BCU is hot. And the signals come from the local substation to remote center should not be duplicated. The operator just want to know one signal come from this bay and do not care about this signal come from which BCUs. That is why I said I want to merge the same signals of 2 identical BCUs to become as one signal to send to the remote.<br><br>The Variant 1 you said I think it is right when I use 1 BCU with redundant ports.<br>My case maybe is your Variant 2. I am thinking about VBA/VSTA program to merge these signals but it should take long effort to do this.<br><br>Thank you,

ursulak
3rd March 2017, 10:03
&gt;The Variant 1 you said I think it is right when I use 1 BCU with redundant ports.<br><br>Yes, the use in iec870 driver settings the primary and secondary IP - was originally developed to support devices with redundant IP ports. But if these BCUs are really identical - have the identical list of Information Objects (the same COA, IOA, Type IDs) then it may work. And would be&nbsp;the simplest solution.<br><br>&gt;My case maybe is your Variant 2. I am thinking about VBA/VSTA program to merge these signals but it should take long effort to do this.<br><br>In general i would always recommend to first consider the use of zenon Logic, not immediately the programming interface (API). By solutions on API&nbsp;there is a danger that&nbsp;by mistakes in concept or in programing,&nbsp;your additional code&nbsp;may block&nbsp;the zenon Runtime or cause very strange effects&nbsp;which are typically&nbsp;hard to&nbsp;analyze.&nbsp;The programming effort in Logic is similar (and the programming language ST is similar to VBA/Pascal etc.) and the Logic program then cannot disturb the zenon Runtime.&nbsp;<br><br> zenon Logic has additional fieldbus drivers for&nbsp;various protocols, thus it may do more as&nbsp;simple data merging. But to be fair i have to warn you that the code in Logic and data exchange with fieldbus drivers&nbsp;are executed in cycles, not on events,&nbsp;and programming demands a little bit different way of thinking... Training?<br><br><br>

anbkhn90
8th March 2017, 11:03
<br><br>&gt; Yes, the use in iec870 driver settings the primary and secondary IP - was originally developed to support devices with redundant IP ports. But if these BCUs are really identical - have the identical list of Information Objects (the same COA, IOA, Type IDs) then it may work. And would be&nbsp;the simplest solution.<br><br><br>
Hi,<br><br>
Could you explain the quote above for me, please. I actually don't understand about this.<br><br>Thanks,

ursulak
8th March 2017, 16:17
<p>Are these two BCUs&nbsp;really identical:&nbsp;have they the same list of Information Objects (variables), with the same addressing (Type ID, IOA, COA) and both are delivering the same data values with the same timestamps (the same events and measured analog values)?&nbsp;If yes,&nbsp;then from the SCADA point of view this is almost the same like to communicate with only single BCU with two Ethernet cards.<br></p><p>If these BCUs are well synchronized and are delivering identical variable lists and identical values, then you may configure the driver like on my screenshot. Then in zenon you will have only one set of variables - variables like from only one BCU, not double.</p><p><br>The driver will communicate with the first or with second BCU - depending which one is available and/or depending what&nbsp;your project will&nbsp;decide to use. The details of the solution how to force the use of primary or secondary IP depend on how the BCU is informing when it changes from hot to standby or vice versa. </p><p>Questions: <br>- When a BCU decides to become hot and when to become standby?<br>- How the BCU informs SCADA system if it is hot or standby? Does it inform SCADA before or after it changes the mode?<br>- How the BCU in standby mode reacts when SCADA would try to send a command - does the standby BCU simply refuse the command or maybe it crashes or does something not allowed with hardware?</p><br>&nbsp;

anbkhn90
9th March 2017, 05:21
Are these two BCUs really identical: have they the same list of Information Objects (variables), with the same addressing (Type ID, IOA, COA) and both are delivering the same data values with the same timestamps (the same events and measured analog values)? If yes, then from the SCADA point of view this is almost the same like to communicate with only single BCU with two Ethernet cards.

If these BCUs are well synchronized and are delivering identical variable lists and identical values, then you may configure the driver like on my screenshot. Then in zenon you will have only one set of variables - variables like from only one BCU, not double.

The driver will communicate with the first or with second BCU - depending which one is available and/or depending what your project will decide to use. The details of the solution how to force the use of primary or secondary IP depend on how the BCU is informing when it changes from hot to standby or vice versa.
Questions:
- When a BCU decides to become hot and when to become standby?
- How the BCU informs SCADA system if it is hot or standby? Does it inform SCADA before or after it changes the mode?
- How the BCU in standby mode reacts when SCADA would try to send a command - does the standby BCU simply refuse the command or maybe it crashes or does something not allowed with hardware?



> Are these two BCUs really identical: have they the same list of Information Objects (variables), with the same addressing (Type ID, IOA, COA) and both are delivering the same data values with the same timestamps (the same events and measured analog values)? If yes, then from the SCADA point of view this is almost the same like to communicate with only single BCU with two Ethernet cards.

Yes, these 2 BCUs are totally identical in purpose, both are delivering the same data values with the same timestamps,but different in CID because of its IED name, so that the symbolic address of 2 BCUs is different. You can see in the image (CaptureBCU) ​for detail

> If these BCUs are well synchronized and are delivering identical variable lists and identical values, then you may configure the driver like on my screenshot. Then in zenon you will have only one set of variables - variables like from only one BCU, not double.

I just saw that you did with 60870-5-104 protocol but in my project they just use 60870-5-101. Or you mean I should do with 104 first then make somehow a translation from 104 to 101 protocol?

> When a BCU decides to become hot and when to become standby?

These 2 BCUs work for the same bay. You can see the attached images (Capture1 and Capture2) for detail. In summary, in one time, the bay just has only one hot BCU. If a hot BCU is failed, then it will switch into standby, and the other will switch into hot mode.

> How the BCU informs SCADA system if it is hot or standby? Does it inform SCADA before or after it changes the mode?

Actually, I have a variable Hot-standby assigned in a report of each BCU to inform which mode it switch on. You could check in the attached image (Capture 112). So I use this variable to inform which BCU is hot or standby. There is no need to inform the changing mode to Remote Center Control (RCC), RCC just only know to send the command without knowing which BCU is hot.

> How the BCU in standby mode reacts when SCADA would try to send a command - does the standby BCU simply refuse the command or maybe it crashes or does something not allowed with hardware?

When you send a command control to the standby BCU the command will be block by Mode. You could see in the attached image( CaptureControl). In this image I tried to control a device through standby mode BCU.

Thanks,

ursulak
9th March 2017, 10:59
on your screenshot i see that your variables have&nbsp;Symbolic Address like in IEC 61850 protocol -&nbsp;supported by&nbsp;iec850 driver, not iec870.&nbsp;But you have written:<br>&gt;in my project they just use 60870-5-101<br><br>So now i'm confused. Where in your system you have to use IEC 60870-5-101 protocol?&nbsp;Is it <u>only</u> to communicate with the remote center?<br><br>Sorry, but in my previous answers i was assuming that the communication between zenon and&nbsp;BCUs is via iec870 driver, not iec850.&nbsp;<br>If&nbsp; IEC 60870 protocol is only for&nbsp;communication with remote center, then you will not have iec870 driver (Master)&nbsp;in your project; you will use IEC870 Slave in Process Gateway or in&nbsp;Logic; and API (VBA/VSTA) or Logic to smart merge data in monitoring direction and to route the controlling direction to the right BCU.<br>The <strong>variant 1&nbsp;</strong>is not suitable for you as these BCUs are using different Logical Device names - one is BCU<u>1</u>Ctrl, the second BCU<u>2</u>Ctrl. This means that the variables have different addressing and because of this must&nbsp;be on iec850 driver communicated using two independent 'connections'.<br><br>So you can consider only the use of <strong>variant 2</strong> or <strong>variant 3</strong>. The best place and way to merge double data (acquired via&nbsp;IEC 61850 protocol)&nbsp;and give the remote access via IEC 60870 protocol depends on the&nbsp;individual&nbsp;characteristics&nbsp;of your zenon project. <br><br>Most important questions: Are you using in zenon project the module Command Processing to control the BCUs?<br>Does the remote&nbsp;center sends the commands&nbsp;in&nbsp;'Select before&nbsp;Execute' procedure and expects that the Select will be refused in case of interlocking? Or it would be also OK if the 870-slave responds the Select to remote center positive or negative only according local/remote mode; but&nbsp;ignoring the current interlocking in BCU, and then only Execution of an interlocked&nbsp;object&nbsp;will be&nbsp;refused? <br><br>Are these BCUs delivering some variables via <u>Buffered</u> Reports? If yes - how do you handle differences in buffered data in the case when&nbsp;hot and standby BCUs were&nbsp;discontented from SCADA&nbsp;for different periods of time?&nbsp;<br>I'm asking because in&nbsp;the period when only one BCU has connection to the SCADA this BCU is sending events "on change" but the disconnected BCU - is buffering these events. Thus into SCADA (so then - to&nbsp;remote center) you get the same events at totally different points of time: first "on change"&nbsp;is coming from connected BCU,&nbsp;then -&nbsp;eventually much, much later - the same event (same value and same timestamp - from the past) - from&nbsp;second BCU when reconnected.&nbsp;<br><br>As you see this discussion grows and grows, the answers are arising more questions.&nbsp;Actually the Forum is&nbsp;platform for fast question - fast answer.&nbsp;<img title="verwirrt" class="inlineimg" alt="" src="images/smilies/confused.png" border="0" smilieid="10">&nbsp;What about the official contact to your responsible Support, trainings and workshops (like e.g. the 'Energy Connectivity' workshop)?<br>

anbkhn90
17th March 2017, 09:04
<span style="color: rgb(51, 51, 51); background-color: rgb(250, 250, 250);">Hi ursulak,<br><br>With the system configuration with 2 Servers working with Redundant Mode ( Hot-Standby), I have read some topics in this forum about Process Gateway but I am not still clear for this issue.<br><br>The communication between Server and Remote Control Center is IEC60870-5-101.<br>Case1:<br><br>I have a computer plays a client to connect to 2 Servers over Ethernet Switch. Of course, my client computer will just receive data from Hot Server (according to Help about Networking), right?. So that, I can run the Process Gateway from Client Computer to send data to Remote Center without knowing which Server is hot, right?<br><br>Case2:<br><br>I will run Process Gateway both in Hot Server and Standby Server and the output ports (Serial Ports) I will connect them together ( like Multiplexer) to make only one port. In order to do this, I think I will have some method to know when a Server switch into Hot, or Standby. If Server is Hot, I will run Process Gateway Module. If Server is Standby, I will turn off Process Gateway Module.<br><br>What do you think about this? Could you give me some advice for this.<br><br>Thank you so much,</span>

ursulak
23rd March 2017, 14:12
ad Case1<br>In zenon Network to start zenon Process Gateway on a (dedicated) network client is the simplest and most robust solution;&nbsp;and we recommend it to our customers. <br>It is like you have noticed -&nbsp;a network client&nbsp;gets all&nbsp;the process data from current&nbsp;SCADA process server, whatever&nbsp;it 'Server 1' or 'Server 2' is. And the clients in network are switching automatically when the Standby takes over.&nbsp;<br><br>On the client PC you may start zenPG while starting zenon project.&nbsp;The System&nbsp;driver - SYSDRV -&nbsp;contains variable with the current computer name,&nbsp;this variable may be linked to a string reaction matrix calling the zenon function 'start program'.<br><br><br>ad Case2<br>To start two&nbsp;instances of zenon Process Gateway - on two clients in Network, or on 'Server 1' and 'Server 2', makes the&nbsp;engineering of the system more complex, so gives more place for mistakes. And - like you have noticed -&nbsp;it demands&nbsp;additional system components (multiplexer) or&nbsp;that the master in Control Center handles double&nbsp;connections and/or double data. <br>And to start only one of two possible instances of zenPG - once on 'Server 1', then terminate it&nbsp;and start on 'Server 2' - makes things not simpler.&nbsp;<br>Anyway in zenon also such constellations are possible and would&nbsp;be valid.<br><br>In SYSDRV there is variable giving information&nbsp;if current computer is a Network Server, Standby, Client or standalone PC. Thus on Standby you may, e.g. set dynamically the zenPG IEC870 Slave&nbsp;to "silent mode" (T00 with IOA=2, value 2) -&nbsp;to ignore commands coming from Control Center.<br><br>In general all zenon Process Gateways, when started, are running until the Runtime is terminated or the user press 'Exit' button on zenPG dialog. From the Runtime you may start zenPG in AUTOSTART script but you cannot&nbsp;terminate it so easy, it terminates only on RT exit. If on Standby the "silent mode" is not enough - if you have to freeze the monitoring direction too -&nbsp;then you have to terminate zenPG while Runtime is still running.&nbsp;For this you&nbsp;may use a BAT-file&nbsp;with a cmd killing the process. Or you would have to trigger the reload&nbsp;of the&nbsp;XML-file with zenPG configuration&nbsp;via new T00 variable with IOA=8 (new feature will be possible&nbsp;soon) - to&nbsp;a XML with a "dummy" configuration without IOs in monitoring direction.<br><br><br><br><br>&nbsp;&nbsp;<br><br>