Disruption in the Automation World, and a practical PLC Code Generator to get started

EdStevens

Member
Join Date
Mar 2017
Location
Boston
Posts
29
Hello everyone. I'm starting a new thread on the recommendation of RheinhardtP.

This is a lengthy post, so bear with me.

It's about disruption, automation communities, ecosystems and how we program our PLC's/PAC's/DCS.
With at the end a practical proposal for change and a request for involvement.

I believe a big change is about to happen to our industry. And with our industry I mean the automation industry: the automation of machines, factories and other assets.

We have for a long time been at the forefront of innovation and practical applications of new technologies. We had 'Big Data', Analytics, Networks, … way before most consumer applications.

But today this is no longer the case. We still program our controllers like we did 20 years ago, the automation vendors still have fairly closed ecosystems and while the community is often ready to help each other out, there is not yet an environment where there is a wide sharing of coding examples, libraries, tools, scripts, …, at least not at a level that is relevant to what is happening in the tech world.

Also the controllers we use are not keeping up with the exponential curves in the tech/enterprise/consumer markets. There are even cases of the hardware being downtuned deliberately…

Other practices in our field are also long overdue, like putting the entire plant network behind a firewall and then claiming that we’ve secured the system.

On the other side of the wall of our industry is a world that is buzzing with innovation. Everything is on an exponential curve, using open technologies, open API’s, open software. Companies who hold on to the status quo for too long are waking up to new players disrupting entire industries and business models. We all know the examples of companies like Blackberry and Blockbuster.

And every new engineering batch that gradutates in our field enters with a bigger tech gap from the world they know than the year before.

You probably get the point until here. Probably you’ll have at least one place where you think “But our industry is different because of X” And you most likely have a good argument there. But it will still not stop from companies coming in and do it in a better way and by that changing our market.

Now many experienced people in our industry already see what’s coming. Not so many are very vocal about it, for different reasons. But some are, and some are even taking considerable actions.

The first example is ExxonMobil where Don Bartusiak and his team have engaged Lockheed Martin to open our the hardware ecosystem in a similar way like Lockheed did in the Aviation industry. Even if they would not succeed at this time, they have put bright spotlights on the problems and lack of innovation.

The second example is Jeff Immelt at GE. Just this month he said “the Industrial Internet will be far greater in size and impact than the Consumer Internet”. GE is building a big platform with the goal to get all industrial assets connected, and their competitors are struggling to get their own solutions online. (There are doubts if it’s a good idea of putting everything in the clould, but that’s another story, and they already have the answer with Edge and Fog computing)

At BP Ahmed Hashmi is pointing out that sofware development is way to slow, and that we have to move to automated development.

And with the visions of Immelt and Hashmi we can see there’s one missing piece of the puzzle that GE is not solving with their analytics platform: the way that we design and program our controllers.

Let’s take one of the most critical examples in our field: the automation of a Pharmaceutical Processes. Let me tell you how that works in case you didn’t have the experience: one or more persons design the analysis (URS => FDS => SDS). Then depending on the size of the project you might have a team of 10-20 persons locked up in a room coding all the controller logic with zero room for innovation or creativity. Everything that is in the documents needs to be in the program and nothing is allowed in the program that’s not in the documents.

Now why do we need a room of programmers for a job that’s so dull and repetitive. Haven’t we all become automation engineers in order to remove all those dull and repetitive jobs?

Also tell me why the pharma industry is still taking the risk of manually coding their production lines for such a critical consumer group, and then even doing most tests by hand, while in the IT world everything goes throug automated module and integration tests.

As both Jim McHugh (NVIDIA) and Marc Cuban recently said: “Software will write Software”.

So there it is: the Holy Grail, the quest for automating our controller code generation. Many have tried, many have failed. And a well-known secret is that quite some have succeeded, at least partially.

There are a couple of reasons why code generation has not yet taken over the workflow for most of us:

- The companies who have developed a working solution often keep it very secret, and often in the hands of only a couple of key people
- Some solutions just move the effort elsewhere often to another engineering environment that requires the same or even more work to define models at a higher level.
- Some solutions only work for one or two brands
- Some solutions are killed because they are a threat to the existing business
- Some solutions only solve parts of the problem, often generating only the basic structure and linking the IO

Now let's turn this around and list the requirements of what is needed to make it work:

- System-independent => template based
- Language-independent (IEC 61131-3 and all its interpretations)
- Works directly from design documents, in any possible format no matter if it’s Word, Excel, Access, … => open import scripts needed
- Open-source the import-scripts
- Open-source the templates and examples, including complex ones
- Documented and open API
- Fast!
- Version control
- Built around a community and open ecosystem
- Open for integration with other pieces of the puzzle (asset management, digital twin, analytics, …)

I’m a bit impatient so here is already an example of a possible API:
https://factory-x.io/v2/api/

And a working example on Github, including import from Word and Excel, and example templates for Siemens S7 and CoDeSys Structured Text. Also including a full S88 structure with phases, EM and CMs.
https://github.com/factory-x/fx-example

One team is already using this on a Chemical Blending project of about 3000 IO. It can scale to both bigger and smaller projects.

I am looking for a couple of persons/teams who also want to start using this, and give the necessary feedback so we can take away any technical or usability concerns.

Back to where I started:

- The tech community has totally adopted open source. This tool allows you to also start adopting open source in our Industrial Automation world
- Our automation community is very scattered in smaller communities like plctalk.net and other forums. Let’s keep those communities and knit them together by blending in with github, stackoverflow, quora, …
- Let’s step up our game in the way we program PLCs/PACs and DCS systems.
- Don’t wait for the big automation vendors to come up with the next innovation. Look at what is missing, what can be improved, and build it!
 
Ugh, S88 (**shudder**).
I have seen machine projects made with essentially S88, and it is not good. Maybe good for batch processes.

In the sample project on github there is a file "fds_example.docx" with a listing of steps and transitions. There is only one "next" step. It looks to me as a kind of SFC.
I would prefer a genuine state machine rather than SFC.

So, am I wrong that this essentially is an automated tool to generate SFC code based on descriptions in Word or Excel files ?
If so, I guess it is an OK tool, but hardly disruptive.
 
Are you proposing to skip steps 2 through 6 of this?
validation_and%20verification_model_used_in_software_development.jpg
 
I think he wants the "coding" part to be fully automatic.

Anyway, this is by no means "code that writes code".
This is a "use a template system to gather input that is used by a script for code generation". It is still humans that fills in the template with information.
The advantage is that you dont need to sit with a specific PLC coding software to do the inputting. And you dont need special programmers to do conversion from human input to PLC code. And you can in theory switch PLC types easily.
The disadvantage is that there will be no super-generic template that can be used for just any automation task. The template that works with one kind of industry will not work for another industry.

Also, debugging. Going back and forth between 2 systems will not be good for debugging.

There has always been tools that are supposed to enhance the productivity of coding, or let "anybody" do coding.
But a tool that is good for setting up SQL databases, may not be good for writing the next minecraft, or for creating an efficient graphics editor, or for creating the next whatsapp, or ....
 
Various attempt at this has been tried. I was involved in one of those. It ended badly

It ended badly because intentionally or intentionally blindness to the reality of automation world by good folks who doesn't try to understand our industry. The one I played with can generate logic for AB 500 but it generated such huge amount of ladder it easily overwhelmed the processor memory. It also doesn't support online-editing. Which, in the real world, is critically important.

Someday, this will all be null with Singularity but we are not there yet.
 
Functional automation open source software cannot be implemented without open source automation firmware.

An automation controller is not and will never be a consumer class Android device.

There is too much at stake and a great many resources had been invested in order to maintain the current status quo for generations to come; Apple anyone?

I remember Siemens' attempt to bond with Windows; Stuxnet anyone? As soon as they found out the virus' "modus operandi" new "highly-secure" firmware was pushed across all platforms.

I believe there is a disconnect between some amateur futuristic universal approaches and the professionally known current possibilities...:geek:...:unsure:
 
I agree with most of what you said, and I love your optimism. It IS the way things are going, sooner or later. I think you're right that this is a topic that many have tried, and the results are either failures or kept secret. I've heard Siemens talk about Automation Designer practically since I entered the industry, and it always seems to be JUST over the horizon.

I've seen some demos where robot programs have been created automatically based on CAD models and simulation instead of manually teaching points, and I think it was pretty cool. Not a PLC, obviously, but the same concept of automatic code generation.

I think it's a scary topic for a lot of the people on this forum because we'd (in a sense) be automating away a lot of our own jobs. It's the right move for the bottom line, though, so businesses will go there sooner or later. Increased up front cost, but also increased quality and potentially shortened deadlines.

For me, if there's a big "my industry is different because of X" it's the fact that most "programmers" I've worked with are electricians who have grudgingly accepted that they have to use computers sometimes. In addition, the first (and often only) troubleshooting step people take is to go online with teh PLC and monitor the code. Its the reason that at least in my area, basically any code written in anything other than LAD is thrown away, because people won't understand it. "Innovations" like Indirect Addressing (that I could do on my commodore 64 in the 80's) are often considered too complex to understand/troubleshoot. I think that this is at least partially a relatively standard "old timers" problem, but it seems like our industry has the opposite demographics of teh standard software company. For every young engineer I know there are 3 that have kids his age. However, a big part of it is what we complain about on this forum all the time: some people are just too dumb for their jobs, and they get coddled instead of thrown out.

I think automatic code generation could actually be a huge help there, IF mindsets start changing, because it could automatically build in the diagnostic screens an HMI needs so that a PLC code live view stops being the go to troubleshooting tool.

I think open source (or at least open standards) is a great goal. I think you have a huge challenge ahead of you with adapting different PLC platforms, but I'm sure you already know that (Siemens and Codesys in the linked factory-x).

The other problem I see is application based. You may be able to write a great tool that covers 90% of the possibilities for a pharmaceutical plant, but how much of that would carry over to an Automotive plant or an oil refinery? I think it's a solvable problem, but a big part of the solution is the man hours to create lots of templates, and to create the tools to create the templates.

I'm a big fan of open source in general, and I'm honestly really appreciative of the work people put into software that everyone can share. I have no idea where people find the time for it though. I have a 1 year old, and I barely have time in the day to wash dishes after work.

I wish you the best of luck though, and I admire your efforts.
 
I believe there is a disconnect between some amateur futuristic universal approaches and the professionally known current possibilities
Part of it is that. I said it before here, some of the very worst control programmer I ever met came from the desktop side. NO, you can't just roll your little C++ program to take of this "deficiency" in ladder logic.

As for my little mis-adventure with our "code-generator". It was with bunch of DCS guys who wanted to convert PLC to more user-friendly DCS style S88 compliant programming. They wasn't with me when the plant manager spits hits my face 2AM in the morning.

Yes, you can tell that I'm still slightly disillusioned and bitter from that episode.

and, this goes really to the bigger philosophical point; don't assume you know a subject matter outside your own. Sometime, stupid way of doing thing is there for a very logical and rational reason.
 
yep ... and the reason's name is usually something like Gomer or Goober - and he's desperately trying to get the pump to run at 3:00 o'clock in the morning ...

And then you get there, flip a switch from off to on, and everything is running fine.

The fact that our industry accepts gross incompetence as the status quo is holding us back.
 
I suspect that once we have robots that build the machines industry needs these robots will develop clones to program the machines as we sit back, basking in the sun sipping our ****tails. ;-)
 
My thoughts:

- Agree that current software and hardware is extremely lacking vs. PC software/hardware, and there's no real reason for it.

- Related to the point above, this is one reason why software development here is so slow; it's harder to re-use code from proprietary and limited programming languages.

- The idea of automatic code generation is much more difficult than you think, for many reasons. I tried to write a MATLAB to Fortran transcompiler in college, which sounded easy because the the two languages are very similar. The project eventually became very complex until the point where I lost interest.

- "Functional automation open source software cannot be implemented without open source automation firmware." Yes, because without open source automation firmware, we're still going to be stuck with proprietary software packages which impedes progress. Even software that uses IEC languages still really isn't universal, because there's always hardware-specific routines/tags/etc.
 
Anyway, this is by no means "code that writes code". ....

I remember Terry Woods was call out on this years ago, he said that code could modify code but I never saw any produced :geek: At that point it will be artificial intelligence and I think our PLC world is not going to see that for awhile
 
PLC coding is difficult to people who either come from the desktop side or the DCS drag and drop side. That's why you see various efforts in having this "tool" that spit out PLC code with a higher-level language. Frankly, that are too much working against that being a success.

Too many firmware, lack of online editing, etc etc..

Someday though, I do see someone with enough resource to come up with an entirely new automation platform with plug-and-play I/O, machine learning of process, and of course, online change. Someday...

Also keep in mind that our market is relatively small. Someone can make much more $ programming Angry-Bird than spending time working on the next automation platform.
 
PLC coding is difficult to people who either come from the desktop side or the DCS drag and drop side. That's why you see various efforts in having this "tool" that spit out PLC code with a higher-level language. Frankly, that are too much working against that being a success.

Maybe for people who are just plain bad at programming, otherwise PLC coding is on the simple side of programming in general. For most, it should be easier coming from the desktop side. If anything, you see these efforts because PLC programming is in the stone age compared to desktop programming.
 
Going through your github, it looks like you are essentially writing another IDE for programming PLC's. This programs using syntax that I will have to learn. Is this syntax any better than the syntax in the existing IDEs? Is it any better than the tools for generating code/parameters in existing code? Not yet, but there is potential.

The reason in pharma there are so many steps is to pick up problems at each of the stages. Ideally each stage will be handled by a different person. By automatically converting the output of the software design stage to the output of the code stage, you are doing what many other industries do and reducing the number of stages. This is fine and cost effective but there is a belief that it is more prone to errors. But what you are doing is worse because you have to code in ms word, rather than the myriad of IEC61131-3 IDEs.

I agree that the tools we use to create PLC HMI and SCADA code need to get better. I think pushing programming into the design phase is wrong though. Better to write tools to make it easy to create code given your design inputs. Also make sure that designers are aware of these tools so that they can make their designs more amenable to them.

Templates and import scripts for common control tasks are available in most system integrators. These are often industry specific. A lot of effort goes in to making these templates, and for maximum ROI, that integrator will choose not to share those designs. I don't agree with it, but it is how it is at the moment.

Open source for the Automation industry will start with an open source PLe certified safety/standard controller running an open source RTOS with an open source IEC61131-3 IDE.
 

Similar Topics

Hello all- I have a unique challenge using a customers Direct logic 06 PLC. This customer has a DC motor operating at 10 RPM which is turning a...
Replies
1
Views
84
Hi, I have been trying to run drive via Sysmac studio. I can ping the drive. I can see the logic bits going on/off as per command. But, drive is...
Replies
21
Views
443
Hello Guys, I am using 1769-L36ERMS PLC by Rockwell which doesn't let me MOV or COP literal text into string datatype? i very well know the...
Replies
13
Views
350
Good Afternoon , Does Rockwell Automation have an Input Card , maybe in the 1734 series , or CompactLogix series that will receive signals...
Replies
15
Views
773
Hi, I am new here, also I am a beginner in PLC programming and connection. I have a project in which the programming are made for 5 plcs, the...
Replies
1
Views
275
Back
Top Bottom