Re: [Qscada-developers] R: Exciting news

[Jovan K. <cho...@gm...>]

Hi,

On 11/16/06, wireless <wir...@ta...> wrote:
> Jovan,
>
> WE agree again!  (this is quite scary for me)....

Ok, from now on what ever you say I'll take the opposite side :)



> But, my question is what do you do when the "big boys"
> Do not develop compatibility with Qscada? Reverse engineering
> their proprietary portocols, even with a limited measure of success,
> will motivate them. I'm sorry, but I do not see Rockwell, Siemens,
> etc etc jumping on the Qscada bandwagon, as most have purchased
> part or all of companies that have their own SCADA products.
> Reverse engineering protocols provides that nudge some may need.
> If not, potential users of Qscada, will have an alternative.

Good point. I'll check (already found) some existing FLOSS projects of
Scada systems
for PLC drivers (tested and ready to use). I'll also dig
http://forums.mrplc.com for
docs and reverse engineered protocols (they had loads of that stuff).

We should always have in mind that some companies want "out of the box"
solutions and always buy everything from one vendor.
Sad, but true :(


> If the (legacy) Scada server to PLC communiations involve many
> proprietary protocols, migration away from that (vendor's)Scada server
> platform can be a lot of work, and preclude many from the effort. That
> is why we'll need to suppport these legacy (proprietary) protocols
> in QScada. If not this approach, then  tell me what is our plan to
> attract (migrate) folks from their legacy scada setup to QScada?

No, you're wrong (read this yes you're right :) We have to support
as much protocols as we can. There are some people somewhere in
the world that have already done reverse engineering and rewritten the
protocols so we just have to ask them for help.


> If we do not have compatibility with the "big boys" on their proprietary
> (plc) protocols, migration from other commercial SCADA offerings to
> Qscada, may take a long time. Most protocols are "clear text" and
> therefore straightforward to reverse engineer.... We do it all the time,
> but, as you have elluded, maintaining such code, is time consuming....

As I said before. We can reverse engineer ourselfs or to wait somebody else
to do it and all we should do would be writing the protocol by
his/hers docmentation,
or even easier, change the code that they have written to comform our needs.

GREETZ, Jovan