Re: Ada for Automation

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

On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:

> Le jeudi 6 novembre 2014 14:31:15 UTC+1, Dmitry A. Kazakov a écrit :
>> On Thu, 6 Nov 2014 03:14:43 -0800 (PST), slos wrote:
>> 
>> Regarding communication boards, they are not very useful.
> Of course, since I am the support guy in France for the Hilscher company,
> I cannot let you say such a thing without reaction.
> 
> Hilscher is on this market since 1986, let's say since the birth of field
> buses, and has been very successful doing that.
> 
> Hilscher products are used by major players in the automation field and
> their products are found everywhere from encoders to drives, PLCs to HMIs.

I know Hilscher. It is not specific to their product. In my view such
boards is a wrong solution, designed mainly for vendor lock reasons not for
technical reasons.

Don't you find it strange that you'd need a special hardware to communicate
devices designed to be Ethernet-compatible? Why don't you need a board to
communicate ModBus? Telnet? HTTP?

>> The protocol requires a very complicated initialization to talk even
>> with relatively simple slaves. You might be able to connect a simple
>> analogue I/O terminal, but nothing beyond that. Even TwinCAT, which is
>> vendor's tool does not support everything. Our EtherCAT master does, almost
>> (:-)).
>> 
> Yes, that's true. Industrial protocols tend to be more and more complex
> because the world is getting more and more complex.

Not really. All of them except very few are quite poorly designed. There is
nothing in the world that can justify the enormous complexity of EtherCAT.
It is simply wrong design all way up from the lowest transport level, which
itself is nice and elegant. It looks like EtherCAT was designed by
different people. The rest of EtherCAT layers is garbage with anything done
wrong, what could be done wrong. It complicates everything, slaves,
masters. It does not support auto-configuration as proclaimed. It has a
huge and absolutely unnecessary initialization delay. Distributed clock is
broken. There is no diagnostics whatsoever and so on.

>> So, my advice would be to implement these stacks natively.
> That is surprising after reading what you have said just above.

There is no other way putting it into a small board, e.g. an ARM-based
board. And, IMO, you will not attract much community support if special,
expensive, proprietary hardware will be required. People expect it working
on a $100 board with no extra costs.

We can safely project that next generations of sensors and actuators will
be much smaller than Beckhoff terminals and fully Ethernet-capable which
will bring death to GPIO. In this context pure Ada solutions have bright
future, IMO.

>> Yes, it is a huge amount of work and you will need community support.
> Or an Hilscher board.

... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I don't
believe you could gather much interest in that. Hobbyists won't go into a
vendor lock. Professionals will stick to paid services and complete
solutions.

> There was once an open source stack but it is not available because one
> need buying a licence from ETG.

These stacks are unusable as they implement less than 5% of what is
actually needed to handle complex EtherCAT slaves like oversampling
analogue inputs or incremental encoders.

The purpose of such stacks is to use them as a starting point for a
customized single-purpose system.

That is not the case for a "universal" automation system. You need to go
all way up to the application level leaving it configurable for each
combination of slaves, for each operation mode etc. You must support
interaction between hardware of different origin, e.g. signaling EtherCAT
frames by CAN telegrams etc. It is a different world.

>> This is not one-man job.
> More than two hundred people are working at Hilscher, creating the
> communication solutions that "Ada for Automation" users would need.
> Right now, you can start on a PC with any format and down to the embedded
> market using modules with same API.

Same here. Less people, though.

>>> Thanks to GtkAda it can be built with a GUI.
>>> It can be built without of course.
>> 
>> Do you mix data acquisition and distribution middleware with the GUI?
> No, this is not mixed.
> Tasks are employed dealing with acquisition, processing, and GUI but they
> are interfaced using protected types.

Monolithic design. It is all OK for an embedded system, but barely
acceptable for a medium-scale automation subsystem running on a PC with
components being independent processes. Protected objects cannot cross
process borders. You don't want to have it in single process for many
reasons.

>> That
>> is not a good idea, generally. It is better to keep them separate. Which is
>> a serious architectural problem how to communicate between the middleware
>> dealing with the hardware, providing publisher-subscriber services and
>> various clients. GUI is only one of them. Inter-process communication, DLLs
>> are all system-dependent. No solution is scalable and portable, meets
>> real-time requirements. It is a very difficult problem to resolve.
>>  
>>> It works rather nicely but it would be fantastic if some experienced
>>> person would review the code and give me some feedback on the design, the
>>> bindings, the code quality... I'm a lonely Ada programmer, and I miss
>>> feedback.
>>> 
>>> Of course, I am interested in any collaboration around this matter.
>>> So, do not hesitate to get in touch when you have some real case.
>> 
>> We do the same stuff, but it is a commercial product. So I cannot do that
>> on ethical and contractual grounds, sorry.
> There are plenty of commercial solutions already available like WinAC,
> CoDeSys, PROCONOS, ISaGRAF... to create automation solutions, none in Ada.

Ours (its embeddable variant) is all in Ada. (:-))

> I think there is some room left between automation and industrial
> computing where the languages used in automation (IEC 61131-3) make it
> hard to create evolved applications and where the C/C++ languages are not
> easy to master for automation engineers. And we know what happens when
> one does not master the tool he uses.
> 
> Ada seems to fit perfectly here to me.

Yes, but not perfect. Issues of distribution and modularity are addressed
in a way that is not very suitable for automation systems. Not that there
exists any language that does it better, but still.

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