OT: Are control systems stuck in the 90s

RheinhardtP

Lifetime Supporting Member + Moderator
Join Date
Oct 2004
Location
Perth
Posts
562
Are control system stuck in the 90s
I read a lot of forums and blogs on the future of control systems and these got me thinking more about our line of work. The more I thought about it the more concerned I got.

The beginning

I started my engineering career in January of 2002. Being fresh out of a tertiary education I was amazed at the technology I got to see and play with with as part of the learning curve.
There was the joy of programming my first PLC, SCADA and touch panel HMI. Designing my first instrument control loop, The joy of figuring out protocols like Modbus, deviceNET and profibus. I will never forget the first time I managed to pull in a deviceNET modules contactor next to me on my desk after multiple failed attempts and hours spent deciphering documents directly translated from Japanese. This was my first experience with fieldbus, the world was green and I was learning quickly.
Mobile phones were simple then, touch screen HMIs were the only link to modern touch pad devices and I found them fascinating, I felt privileged to be in my line of work, I felt like i was part of the future!!!

Fast forward to 2016

14 years later im looking around me and not much has changed. We have controllers that run microprocessors built in the 80s. SCADA pages that look exactly the same as when VGA graphics first came around and interfaces which dont drive adequate operator response in my opinion.

Some questions I would like you too consider...

What about the next generation of control engineers?

Firstly I would say again when I entered the job marked the technology fascinated me, touchpad devices for your home were not around at that point, and part of that is what made me embrace control systems. How will the next generation experience our current technology in the market? Will they find it boring, how will current technology inspire the next generation of control system engineers, when they have newer and greater technology in their own homes?

How can we keep up with Big Data?

In a world where statistical analysis forms the mathematical base of how we analyse processes I think big data will become a problem. Prior to PLCs alarms and processes needed a lot more consideration to be functional and efficient. Although PLCs have made engineers live easier, I think it has made controllers lives a nightmare. We poll tons of information from the controllers and smart devices because we are able to easily and don’t get me wrong I am a big fan of data but how much of this data adds value? I already see system lag due to hardware not being able to keep up with the amount of information systems want to poll. Current process control hardware is lacking in this regard. And our hardware does not keep up with the greater demand in the world for more data.

Years of PLC and SCADA, why are alarms still an issue?

Alarms are no longer designed, they are enabled. This causes flooding in alarming systems and takes away from the controller efficiency. How is it that after countless years of controllers and SCADA systems we as system developers are still bad at this. I find it mind blowing that we still see control system where alarm flooding is a major issue. Don’t we learn from our past experiences?

Food for Thought

One of my primary tasks in my current occupation is developing control system standards for big companies. Alot of these system are new and I look at an estimated life of plant/system. As I have gone through the process I realized that control systems as an industry need to look ahead to the future.

It is up to us to design effective, practice systems that will have a 20 year life-cycle or possibly beyond.
Currently we are not catering for the next generation, would you work in an industry where the technology is old and fast becoming redundant.

I certainly know I wouldn’t.

Would love your thoughts on this.
 
Last edited:
I am always amazed when someone says PLCs aren't "modern" nor SCADA graphics...

Not sure what platform you are using, but a ControlLogix PLC gives you a whole bunch of "Modern" features, far from the 80's or 90's that's for sure. It's not perfect but pretty darn good for the times I think. As for SCADA, well Ignition gives you plenty of ways to make and use "pretty" graphics. Wonderware pushed "Archestra" graphics years ago, which pretty much didn't make much of a dent.

You have valid grips about alarming, I pretty much think it's the last thing engineers want to deal with, so it's pushed to low priority status and rushed just before it's set to commission a plant. If engineers pay attention to something like the "High Performance HMI Handbook", the user experience should improve. However, most controls engineers are far from being graphics designers.

Big data is here to stay, many times it's a design issue that causes problems with getting data from PLCs. Well designed systems will mitigate this. The other issue is transforming bulk data into useful information to a user.

Ultimately, the number of hats a Controls Engineer needs to wear continues to grow, and there is only so much experience/training/expertise that you can cram into a time-frame to become an "expert" at it all. By the time you get good, technology has moved forward.

The many "Hats" of a Controls Engineer:
- Electrican (re-wire want was wrong)
- Instrumentation Tech (scale those instruments 4-20ma)
- Electrical Designer (don't zap anyone)
- Commissioning Engineer (80% travel, 80 hour weeks)
- Network Engineer (Ethernet Design, Managed Networks, Network Security, Firewalls, VPN)
- System Admin (User security, access rights, audit logs)
- Graphic Designer (HA!)
- IT Engineer (Dealing with Windows, Servers, Virtualization)
- Project Manager (scheduling, $$$)
- Component Purchaser (what? I need to get quotes and argue with purchasing??)
- Computer Programmer (get my script on...VBA, python)
- PLC Programmer (Oh, finally! Something I thought I would be doing!)
- SCADA Developer (Ugh, FTViewSE? WW?...Why did I get into this job??)
- Database Admin (SQL, Access #eek)
- Excel Guru (Knows how to use Excel to make life a little easier)
- Process Engineer (Because I know it's not a programming issue)
- Hydraulic Tech (Because I know it's not a programming issue)
- Salesman (Because I don't trust that guy)
- Customer Service Rep (Gotta make sure not to upset the customer)
- Mathematician! (Cuz, numbers)
- The guy/gal that "makes it work" (doesn't work until the black-box-o-magic says so).

-
 
It's not perfect but pretty darn good for the times I think. As for SCADA, well Ignition gives you plenty of ways to make and use "pretty" graphics. Wonderware pushed "Archestra" graphics years ago, which pretty much didn't make much of a dent.

You have valid grips about alarming, I pretty much think it's the last thing engineers want to deal with, so it's pushed to low priority status and rushed just before it's set to commission a plant. If engineers pay attention to something like the "High Performance HMI Handbook", the user experience should improve. However, most controls engineers are far from being graphics designers.

-

i could not agree with you more Paully. The"High Performance HMI Handbook" and ASM Consortium Guidelines are very similar and make sense in my opinion. I guess my point i wanted to bring across was that the next generation will be used used to seeing alot of diversity in modern interfaces, it goes further than pretty graphics. Imagine their ability to follow a link and the ease of navigation around a website, there are underlying functions like knowledge-bases and extended information that play a roll.

One of the challenges we face on a daily bases is the older controllers that tend to be set in their ways. At first sight they kick up against the principles discussed in the above mentioned guidelines. Abnormal Situation management is in its infancy in my opinion but i have seen it work well where the controller team accepts and embraces it.
 
The many "Hats" of a Controls Engineer:
- Electrican (re-wire want was wrong)
- Instrumentation Tech (scale those instruments 4-20ma)
- Electrical Designer (don't zap anyone)
- Commissioning Engineer (80% travel, 80 hour weeks)
- Network Engineer (Ethernet Design, Managed Networks, Network Security, Firewalls, VPN)
- System Admin (User security, access rights, audit logs)
- Graphic Designer (HA!)
- IT Engineer (Dealing with Windows, Servers, Virtualization)
- Project Manager (scheduling, $$$)
- Component Purchaser (what? I need to get quotes and argue with purchasing??)
- Computer Programmer (get my script on...VBA, python)
- PLC Programmer (Oh, finally! Something I thought I would be doing!)
- SCADA Developer (Ugh, FTViewSE? WW?...Why did I get into this job??)
- Database Admin (SQL, Access #eek)
- Excel Guru (Knows how to use Excel to make life a little easier)
- Process Engineer (Because I know it's not a programming issue)
- Hydraulic Tech (Because I know it's not a programming issue)
- Salesman (Because I don't trust that guy)
- Customer Service Rep (Gotta make sure not to upset the customer)
- Mathematician! (Cuz, numbers)
- The guy/gal that "makes it work" (doesn't work until the black-box-o-magic says so).

-

Enjoyed the many hats, wont see any of that in an employment contract though

(y)
 
What I have experienced is a constant pressure and drive to complete projects in an every shrinking schedule and budget. IMO that is the primary reason control systems are not as "polished" as we would like. We are yanked from one project to another without enough time being allocated either during design phase or during standby support to implement the features and details that make a system truly robust and capable of dealing with any scenario.

Sales seems to drive projects more then engineering at times. Standards are important and implementing them efficiently takes a great deal of organization and good management. I have also experienced a lack of good on the job training and many "here, figure it out" scenarios.
 
Interesting - I am in control of my projects from start to finish including design, drawings, build the control system, program and commission - I work for myself. I generally get to specify what I want to use also. If I do not like what is to be used I usually reject the job!
The graphics in Citect have improved out of sight - hi res - tab based screens are fabulous - machines is really good - as with most there are also some old underlying issues but it looks great to the customer who pays the bill!
I have looked at Ignition but no opportunity to try yet.
I have also looked at Archie's free one and plan to give it a go at home automating some orchid growing areas.
I guess you guys work for a boss and have no choice - then sales under quote and you have to fix it! LOL I will never get back to that situation again - by choice. Only have one boss - 'she who must be obeyed'! Best thing I ever did was go and work for myself - at age 56 by the way. Now 72 and still powering along.
I agree with all the hats as listed also - and a few more I can think of but that is life.
There is a demand for more access to plants by way of the iCrap - alarming to mobiles and the like but generally most of the SCADA people seem to be gradually taking care of that.
I guess my time frame is probably another 10 years or so and I think all will be good with the world till then - after that who knows.
With respect to old processors in PLCs that has changed a lot in recent years. Many of the PLCs are now using the Atom processor - from what I have seen they are bloody quick! A lot of scan times and processing times for complex maths functions have gone way down in recent years. I guess this will probably continue.
I guess the main beef I have is that the PLC manufacturers are still using 10/100 for Ethernet - are there any of them that have gone to gigabyte Ethernet yet?
One of the great advances I have seen recently is the use of EtherCat - that is really quick - redundancy on a wire network as well. More to come I guess - they will all do something to gain an advantage and/or make the PLC systems work faster.
The biggest pain I have seen is IEC - and the worst part is tag based addressing with auto allocation. I came up with PLCs with hand held programmers and then there was DOS based software - WOW! The best thing from that was direct I/O addressing - not the way some do it with %I.1.3.14 and the like but the way Omron did it - 0.01 - plain and simple. It is still much faster for me to use the keyboard when programming and using simple addressing in this way - I have resisted the IEC tag based stuff with a vengence! Have had to use it sometimes and generally spend at least 30% more time writing code than the old way. Not an advance at all in my view - oh well.
Grumpy old man? LOL
 
I agree with you BobB

We have come a long way from the early machines driven by a rope-way powered by one massive steam engine with each machine taking power from overhead belts.

But physics hasn't changed one bit.

A machine that wove cloth in those days like that, still weaves cloth today with the same physics - just better control.

I used to write software with DOS programs, now I write them using Win10 but I'm still doing the same thing.

And customers don't really care if it beautiful to look at. Well at first they might think it looks great but they want it to be simple to use, reliable and tell them what is wrong.

I did a recent job where I took great pains to design the opening screen on the HMI.
I incorporated their company logo and took hi res photo's to 'make it pop'
Nobody ever said a word about it............it could just as well have been a screen of plain buttons. :)
 
Fact about HMIs is that it doesnt have to look - it has to be useful and intuitive


This is not quite true. I came across a lot of HMI's which looked great but underneath it was utterly garbage. That speaking of programming and workarounds to get simplest things done.

E.g. stacking multiple HMI objects and make them visible / unvisible depending on plc variables. This is a nightmare to do service.
 
The biggest pain I have seen is IEC - and the worst part is tag based addressing with auto allocation. I came up with PLCs with hand held programmers and then there was DOS based software - WOW! The best thing from that was direct I/O addressing - not the way some do it with %I.1.3.14 and the like but the way Omron did it - 0.01 - plain and simple. It is still much faster for me to use the keyboard when programming and using simple addressing in this way - I have resisted the IEC tag based stuff with a vengence! Have had to use it sometimes and generally spend at least 30% more time writing code than the old way. Not an advance at all in my view - oh well.
Grumpy old man? LOL
Grumpy in certain aspects maybe.
If you have just a slightly large project, I find it almost impossible if all addressing were with absolute addresses. Not only is the code harder to comprehend. "I 2.3" instead of f.ex. "B23_OilTempNC" but it is easier to make a typo f.ex. "I 2.4" when it shopuld have been "I 2.3".
So to me symbolic addressing is definitely a big step forward.

The other big thing is "reusable code". This is a huge timesaver for me, and again also cuts down on typing errors that occur when you do the tedious copy-paste-then-modify of coding in the old way without reusable code.

As for the HMI programming, I think that not much has happened in the last many years. Something has become better, but not much. I miss a really simple (I stress the "simple" bit) "reusable graphic objects" system, similar to the coding of function blocks with instances.

Now 72 and still powering along.
Respect from here. :geek:
 
I miss a really simple (I stress the "simple" bit) "reusable graphic objects" system, similar to the coding of function blocks with instances.

ArchestrA does a really good job here. Not only objects but also graphics can be reused for different projects.
 
What about the next generation of control engineers?

Being one of those "next generation" folks(only been in the controls/automation world for 6-7 years), I've seen two different groups of people in this generation: Those who have respect for the equipment they are working on, and those who don't.

All the exposure people have today with technology and I think it gives them a false sense of security and they get lax in their critical thinking. They want to reinvent the wheel because the stuff we have is older and they saw something shiny at that trade show or whatever. The wheel still works, it just needs a retread, not to be replaced with hover technology. I've nothing against a more efficient piece of equipment or something that makes a process better, but usually when something has been done this way for a hundred years...the bugs tend to be worked out.

Or people rush into things without considering what they are getting themselves into. I have one person I know who's favorite line is "Let's put a robot on it!" or "It's just a simple matter of programming". Then I'm the one who has to go and fix his mistakes because he didn't consider the implications or effects of what he was doing. Things like this give me ulcers, ESPECIALLY when operator safety is involved.

Sorry...I had to rant there for a second...back to topic...

I think the newer folks will slip into working with the technology easier than the folks who were around when it first came out. Since they have been exposed to it all their life, it may come more naturally. They just need to be careful not to rush through things and still apply those critical thinking skills.

Another thing to consider is the reliability of the control system you are installing. Think about how long that cell phone or that home automation system lasts before you have to call tech support. Now, how long does that PLC last?

How can we keep up with Big Data?

I'd rather have the RIGHT data than MORE data. I think more effort needs to be made to really determine what data is required before polling every parameter under the sun just because you can.


Years of PLC and SCADA, why are alarms still an issue?

It's the "magic box" effect. Back in the day, you got a blaring siren and a pilot light on a big alarm panel telling you where the problem is. You called maintenance or fixed it yourself. Now you may still have the siren, but your alarm panel is on that flashy HMI screen. Gotta call the person with the "magic box" because it must be a program issue, never mind the timing belt on the floor or the "factory smoke".

Plus, I think it ties back to "Big Data". You got 40 million parameters that you are told to poll every second and not only record it, but alarm if any one of them wanders out of a safe zone. When only 10 of them are process critical and/or a true alarm...

Sales seems to drive projects more then engineering at times.

+1


Pi
 
[Disclaimer: didn't read through the other posts yet]
Right off the top of my head, yes they are stuck in the 90's because:
- most things don't support 64-bit floats
- paying the amount of money we pay for hardware from that era, you can get $30 credit card sized SBCs now that blow PLCs out of the water hardware-wise
- **** software that crashes, corrupts, and freezes, and frequently is still unaware of Windows UAC even though we've been through Windows Vista, 7, 8, 8.1, and 10.
- still having address instead of tag based programming, no programmer should even have to use hard-coded addresses. DOS is dead

Manufacturers have a lot of catching up to do both software and hardware-wise.
 
no programmer should even have to use hard-coded addresses.
That would be nice if only the software for variable-based programming supported some features that help entering variable names, like in-place search upon the first few characters typed and such. Most if not all of it would not even correct the variable case to match what was declared!

At some point memorizing the hard-coded addresses is easier if you choose them smartly.
 
Are control system stuck in the 90s
No, I think not so much.

Unlike in the consumer markets where a life span of months to a couple of years can be considered a success, for industry, and specifically at this level of industry (programmers and end-user), what thrives and survives is what continues to work over much longer time-spans. You'll not likely be seen as successful if your equipment lasts only as long as the average cell phone.

As an example, a few years ago I made the call to install IP cameras in several non-critical locations for new applications in our facility. Previously, we had used analog cameras in similar applications, but I wanted to move forward with the newer technology. As you can guess, after several breakdowns and two different cameras models becoming obsolete (not to mention their protocols), I am switching back to analog.

Now that's not to say that new technology isn't worth installing, I'm simply saying that industry likes to see some longevity before committing to it and component suppliers work hard to supply what industry actually asks for.
 

Similar Topics

Looking for information regarding something called Flex-Touch control systems. An HMI running this supposed software, that may be an OEM made...
Replies
0
Views
1,290
Hi Guys! Please, I'd like to know how Motor speed Control in Conveyor/Sortation Systems are Programmed/achieved for Factory and Warehouse...
Replies
10
Views
2,039
Hello, I have been tasked with building a new machine( small/medium project)using a European controls company for the PLC/Fieldbus. The...
Replies
2
Views
1,691
We had to replace a Maple Systems HMI with a new one and the programs are not compatible and I can't decode it so I'm starting from scratch. My...
Replies
14
Views
5,915
Hi can anybody help me to develop ladder diagram for the following requirements. Process Descriptions: A conveying system belts consisting of 4...
Replies
9
Views
6,636
Back
Top Bottom