Ada/SPARK Industrial Automation?

Hello Ada-Lang, I have questions.

My recent discovery of Ada has made me wonder: Does anybody use Ada/SPARK in an industrial automation context?

I am an Automation Engineer (Industrial, not software), and work with PLCs, i.e., I make machines do my bidding by programming very rugged, very proprietary, and overly expensive CPUs in IEC 61131-3 languages.

Now today, sitting between two filling machines which were sloshing their contents of foulness onto the floor and permeating my clothes with the stink thereof until the end of time, I was wondering, what a type safe language could do to this industry, so I didn’t have to debug a fault caused by somebody writing 16, instead of 15 in an array, causing the whole line to power down (yes, it was me).

So, I know that the PLC world is greatly standardized, and there is a reason why they are programmed the way they are. For debugging why a sensor is not working, or why a motor isn’t running, I would chose Ladder Logic any day of the week.

But this is exactly what a PLC should do: Take a condition or a set of conditions, and either make something go, or not. Where these conditions come from is essentially irrelevant.

PLCs are perfectly capable of, but I would at times argue not meant to, take on complex tasks such as order handling, complex machine job instructions (shuttles, cranes, lifts, you name it), pathfinding, data storage/logging, data analyzing, etc.

I suppose my first question is, does anybody write software with Ada or SPARK, and then communicates with PLCs in this sense, or at least use it in an industrial context? (I am guessing yes, but I would love to hear about it)

I am self employed and rent myself out to the highest bidder - and if being able to offer my clients, who will throw a tantrum because of 5 minutes downtime, a guarantee… or at least as close to one as possible, that it’s at least not the software’s fault, I would take it.

So part two of my question is, how could I proceed with using Ada or SPARK in my professional context?

Thank you all in advance.

1 Like

You could maybe write a plc logic generator in Ada. The Ada type system, compiler and/or spark prover could then be leveraged to ensure 15 is output in certain circumstances.

I expect our products to be used on lines but not directly, just for protection, resilience and fault detection.

I don’t know about industrial automation, but I recall this thread which could be interesting to you, if you haven’t already read it: Ada for Automation seeking feedback!

2 Likes

You might try connecting with Björn Lundin (@bjorn-lundin on here). He uses Ada for what he calls automation, specifically warehouse management systems. Sounds higher-level than what you’re doing, though.

Yes
As Jeff stated in a reply, I work for a company in the Warehouse Management System business.
However, we are also in the Warehouse Control System business, which is my home turf since the last 15 years. We use Ada to - well - control automation in warehouses. Doing that we see some important tasks

  • Flow control. To understand when a tote/pallet can be released from a mechanical device to the next. This is by far the most overlooked part - but often the difference between success and failure. And usually complex.
  • Protocol interpretor. In this part we talk to the PLCs - or whatever controls the device. Being in Europe, it is often Siemens, but other brands as well. But all big players implement a proprietary socket protocol. (and old ones talk rs232 or rs 485). And all have their own protocol.
    So - talking to PLCs is something we are good at - almost every new project involves writing a communication module this particular vendors fantastic protocol. Sometimes binary, sometimes text, sometimes 1 socket sometimes 2, sometimes serial sometimes OPC (UA/DA). No standard at all.

And yes, downtimes are bad. We have customers that state one (1) hr downtime cost ca € 2M
(big sites)

The level of the communication varies from being informed when a bit in the PLC changes to something more assignment based. or a combination.
Typical example is bringing a pallet out from a crane storage:

  • Conveyor PLC notifies when outbound transfer unit of a crane is free.
  • WCS orders the crane to pickup a tote/pallet.
  • Crane PLC notifies when the tote/pallet is onboard
  • WCS orders the crane to deposit at the free trf unit
  • Conveyor PLC notifies when the trf unit is occupied
  • Crane PLC notifies when tote/pallet is deposited
  • WCS does some way-finding/routing calculations
  • WCS tells conveyor PLC to move to the next communication point in the layout.
  • Conveyor PLC notifies the turf unit is now free again

Sites size ranges from small to large, I think the biggest one we have has 45-50 cranes
Another one has 6 km of conveyors.

/Björn

4 Likes

Thank you for the great reply Björn, this is more or less exactly what I was looking for.

The sites, prices/costs of downtime, and lengths of conveyors all sound far too familiar to me, so it’s nice to see somebody working with Ada that works in the same industry.

How do you deploy your software? Do you run it on industrial PC’s, a server rack, a regular desktop (if so, how did you convince them?), etc?

I assume you have written your own OPC, PN, PB, EIP, and other communication libraries? I have looked around a bit, and I think the only thing easily available is modbus.

I don’t remember all the details. I worked for a company that developed and commissioned SCADA systems for oil, gas, and water pipelines in the late 1990ies. The SCADA systems run on desktop workstations controlling the PLCs along the pipelines. At that time I could convince my boss to write some modules in Ada, like a watchdog and a network redundancy controller. They worked quite well as far as I remember. I don’t know how long they survived after I left that company, however.

1 Like

That’s actually really cool.

My experience in this industry tells me that most likely it would still be implemented. The factory I am currently at is still using the old Siemens S5 controllers from before the creation of the universe, and they are steadily churning out product.

It’s only very recently I find that the IA industry has started to be interested in the new and shiny. Most of my clients have the ‘If it’s not broken, don’t even consider fixing or changing it’ mentality.

So - the system was designed in 1988. Back then, it was running on DEC/Vax_vms mini computers. They were delivered to us (well, I was still in school then), and we installed software and db. We are database heavy. We log lots of things. Then it was ported to IBM’s AIX, and a couple of years later also Windows NT. We are now around 1995. We still got the machines, and installed all software on it. We then used Oracle DB exclusively. Anybody maintaining an Oracle DB knows they are really picky. So lots of effort went into maintenance scripts.

Still - we delivered pre-configured boxes.
Around 2010 we brought sql-server to the party. Same thing - we thought.
We now realized that customers now had (some) competence to maintain their systems.
And by that time VMs had become big.

So from now on - almost everything is delivered as virtual machines. And we start to say that DB-maintenence is something the customers do just as well. So we focus on the application. In the late 2010:s we drop AIX, and deliver on Linux instead.

And there we are today - delivering Virtual systems running Windows or Linux, using Oracle or MS sql-server.

Some customers say cloud, and the WMS system we have is delivered as cloud.
We have yet to do it, and some sites may be ok - but far from all.

I assume you have written your own OPC, PN, PB, EIP, and other communication libraries? I have looked around a bit, and I think the only thing easily available is modbus.

Yes, OPC-DA built on Gnatcom. Works - but hard to maintain.
OPC-UA - cheated. Made a C# implementation that we talk to via jsonrpc2 (via Ada WS)

Funnily, Modbus is something we never did. Always another protocol.

During the last 20 years it has been questioned if we should stick with Ada or move on to something more ‘modern’. The system is ca 1.2 Mlocs and it is not easy to just rewrite. I’ve strongly defended the Ada-way - and we are still using it.
We do have difficulties recruiting, and that is the greatest concern. Sure, we teach newcomers - but there are too few newcomers to start with.

We have no SPARK - yet. I would like - but not started yet.

/Björn

3 Likes

Forgot to address this.
The server is connected to a version handling system,
and we build on the local machine. We have source and the entire build setup on site.
We have this, due to difficulty to test all before commissioning, so sometimes fixes are needed. It is then committed to subversion, when the programmer is satisfied.
We are migrating to Git this spring.

Using 3964R protocol ?
No fun at all.

I also experience the mentality ‘don’t upgrade or change if it is working’
As late as 2001 I saw win 3.1 in production at one place.
Just before the millennium shift - we migrated one PDP/11 system and verified another. The surviving one was set to the year 1994 I think - because the weekday of a date matched the weekday of the date in 2000.
Very conservative

Thank you again for your very detailed response.

Learning Ada will be a journey; one that I am already enjoying. I hope one day to be able to do something similar - implementing Ada built systems into the world of Industrial Automation.

I hope for your sake that they do not in the end chose the more ‘modern’ solution, as the benefits seem to outweigh the disadvantages. It baffles me, maybe also because of my industry, why everyone wants to jump ship once something new arrives, which basically does the same thing. It scares me to imagine the hours and costs associated with rewriting your codebase.

The same can be said for Common Lisp, a language I absolutely adore - but it is the diametrical opposite of shiny.

You have given me much to think about. I appreciate it.