Re: Ada / Automation fellows

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 28 Mar 2015 15:36:07 -0700 (PDT), slos wrote:

> Le samedi 28 mars 2015 10:05:48 UTC+1, Dmitry A. Kazakov a écrit :

>> Interesting. We design SCADA more or less anew each time. Customer's
>> requirements vary too greatly. Quite often a corporate look and feel is
>> mandated etc.
> In another life I have used several SCADA from the market like PcVue, WinCC or Intouch.
> They would do the job often, never needed to redevelop one but your
> customers may have strange requirements.

Nothing strange. Customers are always focused on what is visible, the GUI
(and take everything else for granted). They are never satisfied with the
behavior of standard widgets. It is always, OK, but when cursor hovers,
that should do this, page-scroll must do that etc.

>>> It's HTML, SVG, JavaScript... and I was impressed by the achievement.
>> 
>> I am not a fan of Web-based automation systems. It does not feel good. It
>> does not properly separate control and UI, which is a big step back to me.
> Well, I don"t see why you could not separate control and UI with web technologies.

Because if you honestly do it in Web, your real-time controller must run a
HTTP server. This kind of architecture is not scalable at least.

Normally there are more nodes than a controller and the UI host. There are
more than one UI host, with different roles.

You have to distribute data between the nodes. Since you cannot do it with
HTTP, you will have some DDL, e.g. OPC UA, if you are out of luck. This
needs to be installed on the UI host in order to get at the data. So it is
no more "anything anywhere". If you can install DDL on the UI host, you can
also install a decent GUI library.

>> Freshly introduced WebSockets is just acknowledge of superiority of the
>> communication architectures we have been using for decades before HTTP ever
>> existed. Now I'm wondering how it would be for somebody to implement
>> something as nasty as OPC UA stack on top of WebSockets in JavaScript at
>> the client side... (:-))

> Some people prefer web based UI and some native applications.

There are no technical merits to have Web-based UI. It only complicates
design and, immensely, maintenance. I think that people advocating it have
throw-away UI in mind. This is not the case for most commercial automation
systems.

>> Maybe Gnoga can change that, some day. I don't know.
>> 
>>> And so I was looking for some free alternative and found MBLogic which
>>> uses same web technologies and Python for the logic and web server :
>>> http://mblogic.sourceforge.net/index.html
>> 
>> From my experience the visual design of the UI is such a minor thing for an
>> automation system developing, that it does not really matter what kind of
>> GUI library you would use. We did it in almost all frameworks LabWindows,
>> DiaDem, Win32 GDI, C#, Web and so on. All GUI frameworks are designed alike
>> (and wrong from the automation and real-time control POV). So the problems,
>> solutions, workarounds are basically same. But it is probably less than 1%
>> of what should be done for a medium-sized automation system anyway.
> In normal automation applications, UI is done with those previously
> mentioned SCADA systems by people who do not have / need computer
> programming knowledge.

But they cannot do this! It is far more complex than throwing together some
widgets connecting them to some data. It is absolutely unrealistic for a
customer to do, even for one with programming background.

It is true that customers ask for UI being programmable, but NONE of them
change the UI in the end. And it is not only programming knowledge
required. The end customer is an operator. He does not know how the system
functions. Nor programmers know it in details. Designing and setting up an
automation system requires expert knowledge of the process under control
and of the measurement subsystems. This is the third party involved in the
process.

If you have a dynamometer with 10K Euro per hour running costs, you would
not try to change anything.

> With those tools, they draw and animate symbols quite easily without a
> single line of code.

There is an immensely complex control logic behind some of these symbols.
They have meaning, this meaning is 99% of what an automation system does.
Animated UI is less than 1%.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de