Adding two flow values that reside on different servers

[MikeEckert]

I am trying to add two flow values and they each reside on different servers. Sounds easy enough to do but I can not 

seem to figure it out.

[BevanWeiss · Accepted solution]

I wouldn't say 'sounds easy enough to do' 😉  I mean... you need to consider that what you've just described is 'The Internet' and it wasn't exactly a trivial invention for that to come about 😛

But... it sounds like what you have are two Geo SCADA Expert SYSTEMS.

NOTE: I really need to emphasis SYSTEM here, and NOT server.  Since whilst perhaps you may indeed only have one server in each system, it is possible to have many more, and that does make things different.

Ok.  So we have that out of the way.  You have two Geo SCADA Systems.  If you don't actually have Geo SCADA (or ClearSCADA) systems... then you're lost.  This is not the forum for you.

But now you definitely have two Geo SCADA Expert systems, and they are 'visible' to each other, i.e. there are possible network connections between them such that ALL servers in the first system can reach ALL servers in the second system.

Natively Geo SCADA Expert supports acting as a number of different types of 'server':

* OPC (DA / HDA)

* ODBC

* EcoStructure Web Service

* DNP3

* Modbus

.... here's a list https://tprojects.schneider-electric.com/telemetry/display/public/CS/Supported+Interface+and+Protoco...

Natively Geo SCADA Expert supports acting as a number of different types of 'client':

* OPC

* ODBC

* EcoStructure Web Service

* DNP3

* Modbus

.... here's a list https://tprojects.schneider-electric.com/telemetry/display/public/CS/Supported+Interface+and+Protoco...

If you've read everything I've written so far... you should have noticed that I linked you to the same URL twice.  That's how doubly useful it will be.

So.  To perform a calculation of the two values, value1 from system1, and value2 from system2, you need to decide on which system the result of the calculation will be most useful.  If you decide that the result needs to be on BOTH systems.. then you have doubled how much work you need to do.

The simple solution is thus... Our result will be on system1.

- Configure an Advanced OPC connection from system1 to system2 (with all the servers required in the OPC server list)

- Configure an Advanced OPC Point to read the value2 required from system2, at the rate required for your calculation (this will now be point2 on system1)

- Configure a calculation point on system1 which reads point1 (which has value1) and point2 (which has value2) and is the result of the calculation between these two values.

- Job done... profit. 

If you don't want to use OPC... and you possibly don't, because it does entail needing an OPC server license.  Then you can essentially do the same with the other protocols.

e.g. setup System2 to be an EWS server, setup System1 to read the value2 via EWS from System2.. perform calculation

or setup System2 to be a DNP3 slave, setup System1 to read value2 via DNP3 from System2... perform calculation

or setup System2 to be a Modbus slave, setup System1 to read value2 via Modbus from System2... perform calculation

or setup System2 to allow ODBC, setup System1 to read value2 via ODBC from System2... perform calculation

or setup System2 to be an IEC 60870-5 slave, setup System1 to read value2 via IEC 60870-5 from System2... perform calculation

There is one last way that I have seen done also... and I really don't recommend it.

It's possible to send an SMS message which has a value.  It's also possible to receive SMS messages into Geo SCADA Expert...

You could have System2 send periodic SMS messages to System1 and then have System1 parse the SMS and write this into a point... perform calculation (sometimes... if the SMS sending/receiving worked)

Those are obviously high level approaches.  The only one I have NOT seen done before is the IEC60870-5... but then I'm in Australia, and we're not good with big numbers, so this protocol isn't popular here, we still struggle with DNP3... I'm sure there's people here that would like a return to the "good old days of DNP1..." 😉

[AdamWoodland]

Just to add, https://community.se.com/t5/Geo-SCADA-Knowledge-Base/Comparison-of-Methods-to-Transfer-Point-Data-Be... might be a useful read too (although does duplicate some of what Bevan has written above).

[BevanWeiss]

Hi @AdamWoodland

1. If I'd of known about that link I absolutely would have provided that instead of my spiel 🙂
2. It does mention in that link however around DNP3

   Available Target for Data	Main server only

   
   Is that true?  I am really sure that I've had DNP3 comms working to a Standby server.  I thought this was (one of) the reasons that the DNP3 driver still runs on the Standby server..

And as I like to take threads off on side-tracks.

Do you know if there has been any discussion internally about OPC-UA support yet (at both ends)?

My understanding is that this would register as 'Great' in many of the fields within the table..

• OPC-UA can support subscription type connections (no need to always poll for new data)
• OPC-UA can support both Raw and Processed historical data retrieval
• OPC-UA can support 'alarms and conditions', which appear to align quite nicely with that of Geo SCADA already... with a slight deviation around 'alarm instances' (i.e. an individual alarm raise/clear 'event') being individually acknowledge-able.  Geo SCADA will log the raises/clears as separate events, but it's still only the one 'alarm instance' (e.g. if an alarm occurred between 01:00-02:00 and then again from 03:00-04:00, and an operator only arrived at desk at 07:00, they would only see/acknowledge a single alarm in Geo SCADA.. whilst OPC-UA provides for details on both alarm instances...).  Obviously the utilisation of this will be very implementation dependent, and acknowledging 1000 spurious alarms for a flickering input signal sounds horrible...
• OPC-UA supports security (both transport, and authentication)
• OPC-UA apparently has good bandwidth utilisation.  Although I haven't heard of its suitability on high latency links (I think for something like low bandwidth microwave DNP3 over UDP would still be the winner)

[Anonymous user]

Drivers (DNP3 and Adv Modbus at the moment) run on the standby for quick changeover since the objects are pre-loaded in the driver from the server, there's no comms.

OPC-UA is on it's way, but will be one end before the other.

[BevanWeiss]

Ohh... so after a server fail-over, if a DNP3 slave reports unsolicited data into the standby server, this will just fail?

There ya go... you learn something everyday... I wish I hadn't learnt this though. I was happy in my naivety.

Yes, OPC-UA client driver makes a lot of sense.  I am a bit surprised it's taking so long actually, given the OPC Foundation actually have example code for both Server and Client which I would have expected to have done the 80% stuff...  which only leaves the other 120% or however that rule works...

[Anonymous user]

Yep, but it wouldn't be ack'd so it should be later reported to the new Main.

[AdamWoodland]

I think Jesse answered your questions, but if you have any other suggestions to that page let me know as I'm happy to update it to make things better/clearer/more helpful.

Once OPC-UA is available, both server and client, then that can/will also be added although how it compares on some of those categories I've no idea... yet. Time will tell.

[Anonymous user]

SCADA Systems