System Independent Process Automation Design

F

Thread Starter

Francis Lovering

Hi
I have followed various threads, notably "Ideal PLC Programming Language and
Software" and "Why do you pay for PLC programming software", not the mention
DCS v PLC debates.
This is an attempt to move the discussion away from the particular systems
to the place where the real issues arise, the application and design
engineering.

I believe that the 90% of the design can be the same whether regardless of
the system that you are using. I think that the software architecture, such
as the breakdown of the total system into modules such as control and
equipment modules, the graphics etc can be the same. And of course so can
most of the documentation.

Lets face it all the systems on the market provide basically the same things
and they are more than enough to do most things.
Just as you can design software and choose at the last moment whether to use
C or Java, you can do the same with Process Automation. Requirements
Analysis is the process that identifies in detail what the system must do,
and can be done without knowledge of a particular system's addressing modes,
numbering system etc.

The mapping into a specific system is one of the last things you need to do.
But it seem to me that most people on this and other forums and those that I
meet at suppliers are obsessed with the implementation and start going on
about what this PLC or that DCS does and what bits to use before they have
done any design work.

Suppose we did have a complete (IEC1131 type) standard that so the same
software will run on any system. What would happen from the design
viewpoint? (I don't mean the effects on the suppliers who do not want it)
It might concentrate the integrators on the design, but more likely I think
it might just move the debate into the virtues of different programming
packages - but that still misses the point. Which is that the requirements
analysis is more important than the platform.

Francis
www.controldraw.com
 
M

Michael Griffin

In reply to Francis Lovering: Software application design is what Grafcet (SFC) and state diagrams are intended for. Software design methodologies are well established. They're just not used by many people.

IEC 61131-3 even includes SFC as a supported language. Some PLCs (e.g. Control Technology) can be programmed with state diagrams. Both of these allow the design to be directly transformed into a program without a manual translation step. Manually translating a Grafcet or state diagram to ladder isn't difficult, but you have to be meticulous about keeping the diagram up to date as you go along.

I have to strongly disagree though about your statement "you can design software and choose at the last moment whether to use C or Java". This may be the case for simple programs, but it isn't true for all cases. Most non-trivial programs have to make use of libraries and other dependencies beyond those in the language standards, and the availability and capability of these libraries will have an important influence on the software design. Settling on a specific language should be one of the early design decisions in a software project.
 
N

Nikolas Kinze

Who uses SFCs any more? In my 20+ years of experience with PLC's Sequential Flow Charts, oops now they are called STATE flow charts, are the most irritating way to program, not to mention troubleshoot, and Grafcet in my opinion is a poor tool.

Francis did hit the nail on the head though. The REAL issue that makes us good at what we do is in the design and upfront documentation. I can't begin to count the number of times at the last minute either the customer or engineering standards have changed, and the PLC originally spec'd was replaced. With proper design documentation, it's just a tiny bump in the road.

No matter HOW detailed the IEC standards get, you will NEVER be able to buy a piece of software that allows you to program Omron, AB, Modicon, Siemens, etc... There are 2 reasons for this:

1. Profit, software is the MOST profitable part of Rockwell. If you don't beleive it, total up the amount of money you spend on it.
2. LIABILITY. The PLC manufacturers must test not only the Kernel for the PLC, but the OS as well. Can you imagine opening it all up to every Tom, Dick & Harry? The bugs would replicate just like in MS Windows.

I frankly do not understand all of the complaints. If you are a proficient PLC programmer and have a good understanding of the process, changing boats should not be that tough.

If it is, then you are probably working in the wrong industry.

I personally like many different portions of different PLC programming packages, but usually that's particular to the processor they run on. If you try to dumb it all down to a common denominator, then you lose efficacy and innovative thinking will no longer be put into PLC design.

Next thing you know, there will be standards for hamburgers, etc. How about going to Burger King and getting a standard hamburger? Would it taste like McDonalds? Or an automobile, let's all standardize the parts, YES, let's save time & money.

I am not going to even apply the paradigm to people. We all have diverse abilities, strengths and weaknesses. We can complement and help each other.

One last thought.
If you make it simple enough a 5th grader can do it... What are you going to do for a living? I actually PREFER to be in a high demand, low supply profession. If you make it simple enough for anyone to do it... All of us, (except the ones who couldn't do the job in the first place) lose wages.
 
M

Michael Griffin

In reply to Nikolas Kinze: Grafcet (SFC) and state diagrams are not the same. In fact they are each often best suited for different purposes, and may both be used to design different aspects of the same program.

Note that I am referring to Grafcet and state diagrams as a software design method, which is what they were intended for. I am not recommending any particular company's attempt to program PLCs directly via diagrams. Used as a programming language, you lose some of the advantage of Grafcet or state diagrams as a design tool, which is the ability to provide a high level overview of the program (that is, to see the forest rather than the trees). When properly used as a description of what a program is intended to do though, they are very clear and concise.

Who uses these any more? Well, anyone who actually does any software design. In fact, state diagrams are also very well established as a standard software design tool outside of the automation field (they are very popular for large Java projects). In the automation field, there really is no established alternative design method, unless you count hacking away at something until it looks like it is going to work as a "design method".

You can do some very nice Grafcet and state diagrams using the line drawing functions of common word processors. Translating these into ladder manually isn't difficult. It isn't necessary to use an SFC programming package to use SFCs.
 
C

Chris Jennings

Don't let any maufacturers read that!

By making it easier for people program a PLC yes you open it up to more people, which can lower wages, which then reduces installation cost and
maintenance cost which reduce the total cost of ownership and therefore improves the bottom line. If we aren't looking at improving company's profits then what are we doing? As an engineer I need to look at the big picture. If the majority of the costs associated with PLC programming is
with the software then I am obliged to try and reduce this cost while still providing the same level of service.

Or am I missing something?

Chris Jennings
 
F

Francis Lovering

In my experience, LOTS of people are using SFCs to design control sequences, and to implement them on platforms such as DeltaV, and IEC1131 PLCs.

I am not sure what "STATE flow charts" are. State Transition diagrams yes, and they have a role too. They are not the same as SFCs.

The secret is not to use SFCs for things that they are not designed for. For example an SFC that drives an equipment module from state to state is
great, using an SFC for what is easily done with simple logic is not.

Francis
www.controldraw.co.uk
 
F

Francis Lovering

> Software application design is what Grafcet (SFC) and state diagrams are
intended for. <

I don't think that is really valid, Grafcet, and State diagrams and other thinks like Continuous Function Charts, are complementary techniques to be used together. The software architectural design would define how they are used. And I still say that 90% of the application can be designed the same regardless of the PLC or DCS.

> Software design methodologies are well established. They're just not used
by many people. <

Well, if you are talking about UML then that is true for Control systems and that is because UML Modelling tools are hopeless with process automation.

> I have to strongly disagree though about your statement "you can design
software and choose at the last moment whether to use C or Java". This may
be the case for simple programs, but it isn't true for all cases. Most
non-trivial programs have to make use of libraries and other dependencies
beyond those in the language standards, and the availability and capability
of these libraries will have an important influence on the software design.
Settling on a specific language should be one of the early design decisions
in a software project. <

It's a fair point - and one that is worth looking at from the point of view of what 'libraries' come with the systems. Most systems -provide the low
level libraries that handle IO, how and SFC executes, scanning etc etc. What they rarely provide is any decent application level libraries, such as how to control a motor, and vessel, etc.

Francis
www.urswriter.com
 
D

DAVE FERGUSON

I think we should write a program that captures the knowledge of the Engineer. Then when we have new project, we answer some easy questions and the program provides all the answers and then we can eliminate the Engineers job and improve the bottom line. We will call it OPENEngineer, let's start a team.

Then we can farm out the CEO's job overseas for 11 cents and hour and we can eliminate his job. The bottom line will now be even better.

Be good at adding value no matter which hammer (tools) you use. Be about making better widgets and you will have value. Be about commoditizing everything and soon it will be you getting the pink slip.

Dave
 
C

Curt Wuollet

Hi Dave.

Good plan. The problem I've seen over the years is that if you don't follow the trend to commoditization, some one else commoditizes it first and you get the pink slip. A lifetime of knowledge and experience is valueless to people who don't want to do, they just want to buy.

Regards

cww
 
N

Neil Crompton

Capture the requirements accurately using the latest tools that yes employ state and transition as a part of the life cycle design and believe me the code is a 'push of a button'.

The future's already here!
 
N

Neil Crompton

No, the latest tools not only reduce cost but improve speed, accuracy, quality and compliance.
Requirements capture still requires competent engineers but it enables the engineer to carry out 4 x the work and all at a high integrity level.
 
Top