F
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
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