How important is it to have flexibility in a process control or safety system architecture?
Modern process control and safety systems provide modular, distributed architectures to deliver flexibility to fit any size project or any application. Flexibility is sometimes seen as a bad thing, because it can introduce complexity and limit ease of use. How important is this when you are designing your control and safety system projects? Is architectural flexibility a virtue or a vice? Is there a limit to the amount of architectural flexibility before system design becomes too complex, or do architectural constraints create more burdens when you are forced to try and make the system architecture fit the needs of your process?
- Login or register to post comments
- 6052 reads
- Permalink
- 12 comments
The level of fault tolerance
The level of fault tolerance at the I/O level can be tailored to meet the needs of the application - mixing and matching single, dual and triple redundancy in the same system. This allows the system to easily accommodate the different safety instrumented function (SIF) architectures that are often required to meet the safety integrity level (SIL).Another side benefit of this flexibility is that it allows the system to be distributed which in turn can help reduce common cause issues caused by physical stressors.
Mission Hills Real Estate
Additionally w/ regard to
Additionally w/ regard to usability from a system maintenance perspective, you could be decreasing the breadth of the overall work and expertise requirement in favor of narrow expertise, which presumably DCS engineers, vendors, or service contractors could provide without relying on others as much.
diabetes tratamiento
Flexible architectures
What exactly is meant by "infinitely flexible architecture"?
I was not aware that this type of system exists. I am getting the strong impression that I am talking to marketing people here instead of engineers. Am I wasting my time?
Every system, centralised or distributed, has its physical limits.
Limits/contraints for distributed systems:
- Network loading as they all have to communicate
- depending on vendor - no transfer of analoges possible.
- Power consumption: more controllers is more power
- Heat dissipation: more controllers generate more heat
- Foot-Print: one controller per 16 or 32 IO will take more space
- Reliability - see my previous comments
- How to scope as IO segratation at proposal stage is not known.
My advice:
Ask for guarantee that the proposed number of controllers will be capable of handling the application as per spec.
Ask for guaranteed response times per your spec.
Ask for guaranteed first up detection.
Ask for guarantee that your Bypass management principles can be applied.
Ask for guaranteed that you can actually add addtional HW without overloading the network.
Ask for guaranteed SW additions and not merely wired IO spare.
Ask for guaranteed footprint.
Limits constraints for centralised systems:
- overkill for small applications (<150 IO)
- ?
MiekBoudreaux says: "During a project, you need to design your control system architecture to fit your process, with the right amount of I/O in the right mix of I/O type"
I agree with this...it is all about IO's. What is more flexible? Adding an IO card and a new software block versus adding complete new controller with respective HW, SW and integration additions?
I choose for adding an IO card. And if I reach my system limit of e.g. 1000 IO, I will add a new controller on my network.
So maybe the question is: How many IO do I need to be flexible in covering most applications? My personal opinion: I do not want to add a controller every 16 or 32 IO - If I plan properly, I will use my installed spare for this. About 750 to 1000 IO per controller seems a good number. This will give me the flexibility to cover most applications, from 100 up to 1000 IO, and I can fit this into 2 cabinets
PS: From a safety point of view, I could see a benefit is splitting my different 3 SIL levels in 3 different controllers. This would actually help my maintenance and periodic proof testing. However, several vendors of the larger systems have elegantly solved this issue in the software (certified by TUV)
PS2: Our engineering best practices require the systems cabinets to be in the air-conditioned control and instrument room. We will never put our control systems out in the field.
Neil
Limited Project Budget - But Consider the Lifecycle
I think this is something that needs to be considered in the project scope and what the project can afford to pay for. When building a new control system for an old process - the methods are more well-known/established/fixed and the need for flexibility is reduced. However with new processes where there will be a lot of learning and optimizing during the lifecycle, you need to build in the flexibility to make changes to support this. You don't want to limit yourself later on. Certainly in a later optimization project you would not want to rip out all the hardware and replace it with what is needed for the flexibility of the new requirement.
Where flexibility is obviously needed (pilot plant, multi-purpose facility, growth market) then I would expect to see this in the design -- even though the later usages may not be yet known.
An additional comment about product design...
Don't forget also that system usability is in part a function of product design and not strictly product flexibility. Anyone who uses twitter, for instance, understands that technology can be dead simple, flexible, and easy to use. The keys are modularity, extensibility, and ease of integration into existing systems.
Good points: modularity, extensibility, and ease of integration
You correctly point out common design goals that can contribute to usability. I have previously used these definitions from the ReadySET glossary that is used in many open source projects:
Modularity - Concerns are clearly separated so that the impact of most design changes would be limited to only one or a few modules.
Extensibility - New features or components can be easily added later.
Ease of integration - The components will work together.
I agree about Twitter being dead simple, flexible, and easy to use. However, I find that the 140 character limitation can make Twitter difficult to use. This would be an example of an architectural constraint that limits the product flexibility (it is difficult to hold a conversation on Twitter for example). On the other hand, if you remove this constraint then would Twitter become less useful?
distributed architectures to deliver flexibility
Flexibilty can have different meanings. I give my view as a plant engineer. Clearly a "Vice"
Of course vendors want to differentiate from the competition by offering unique, state-of-the-art, superior, award-winning, flexible, modular, intelligent, smart, modern, one size fit all, you name it, systems.
Reality is that control systems currently available in the market offer enough level of flexibility and modularity for any engineer to make it fit the application. Control systems are becoming/have become(?)a commodity. I will buy the control system that best fits my current engineering process and resource situation independent from the offered gadgets. So I do believe MikeBoudreaux is asking the right question. I hope vendors not use the arguments to make and sell more gadgets.
In general, large applications will lean towards the larger centralised systems, small applications will tend to select modular systems. If you verify which systems are used for Refineries versus Pharmceutical plants, than you will find that this is reflected in the industry today. "One Size fit all" is a marketing invention. Of course I can use my porsche to drive off-road, but my 4WD does a better job there.
Rules of Thumb:
The engineering effort will increase exponentially in proportion to the level of modularity. I agree with MikeBoudreaux that indeed the level of complexity increases with more flexibility.
The reliability will decrease in proportion to the level of modularity. Simple Physics: more components means more failures. Using 10 controllers for 1000 IO, will be 10 times less reliable than using 1 controller.
The cost will increase in proportion to the level of modularity. Simple finance: 10 controllers, need 10 power supplies, 10 cabinets, 10 sets of documentation, 10 tests etc...
The operating and maintenance costs will increase in proportion to the level of modularity. Operating and maintaining 10 controllers will cost more than maintaining one controller.
Gadget factor: The lower the number of engineers with on-site hands-on experience in the R&D department, the higher the level of "flexibility". Typically a designer will add features - because it is a differentiator - that will never be used in a plant.
Neil
I do not agree with your Rules of Thumb
While I agree with some of what you say,
Reality is that control systems currently .. offer enough ..to.. fit the application
I do not agree with
"The engineering effort will increase exponentially in proportion to the level of modularity"
Certainly not exponentially, in fact good modularisation reduces overall effort, at least for the software.
"The reliability will decrease in proportion to the level of modularity. Simple Physics: more components means more failures. Using 10 controllers for 1000 IO, will be 10 times less reliable than using 1 controller."
Most definitely not true when you lookat the entire process. Suppose as is typical that 1000io is associated with 10 equipment items that can run with some independence (eg through process buffers) and you have one controller then a single failure could stop all production, whereas if here is a controller per equipment item a single failure may only reduce prodction but not stop it.
"The cost will increase in proportion to the level of modularity. Simple finance: 10 controllers, need 10 power supplies, 10 cabinets, 10 sets of documentation, 10 tests etc..."
Not in proportion because the cost of smaller modules is going to be much smaller than the one system
Francis
www.controldraw.co.uk
Rules of Thumb
Engineering efforts:
Software programming is a very small part of engineering.
Putting that aside - Why would it be more difficult to apply modular software in a larger centralised system?
With reference to single loop controllers, I would agree with you if the modularity is implemented in a way that functions are segregated per modular unit.
Nice in an ideal world but hardly reality. For many different reasons you will have functions going accross the different modules. Safety Interlocks are a good example.
Let me share with you some of the issues we encountered after we acquired a distributed safety system.
It started with the use of cause & effect logic.
Issue 1: Cause and effect program had to be split into separate functions to be distributed over solver units.
Issue 2: the functions themselves had to be split since these modular solvers have limited capacity.
Issue 3: Due to the splitting of the logic into more units both reliability and safety rating decreased (more units means more failure rates and PDFavg to add up).
Issue 4: Due to the product required splitting, the number of signals going between the different solver units reached its limit. Re-evaluation of safety loops and re-engineering of our functions was required to make it fit. In addition, we were running out of space.
Issue 5: Changes in the logic. Again the above exercise to make it fit. System is up and running. I dread the day when a change requests comes in.
Issue 6: Timing issues giving headaches on process sequence, system response time, Event Logging, bypass requirement due to logic in different units, with different processing speeds. These issue are still not solved today.
Issue 7: How to download all these different units in the proper order? One by one? all at the same time? which one first?
We could have avoided the issues by:
a. buying a larger, proven system for our application
b. Changing our engineering process to please one or two vendors
Which option would you choose?
Reliability:
You are right with your example. However, you are describing availability.
Reliability and availability are different. Reliability is a function of operating time interval and failure rates.
The failure rates basically are a sum of the failure rates of the individual components used. Hence, the more components, the lower the reliability.
To avoid that this failure will shutdown production, you have to implement it properly, and add reduncies where needed. This brings me back to the engineering and cost rules of thumb.
Cost: I advise you to verify before you purchase. The price for small modules for 100 IO including the software licenses cost us more than the large system for 1000 IO. We expected to save on engineering and operations due to highly praised features that were very compelling but useless in our application.
Neil
Clarification - how architectural flexibility effects usability.
Francis makes some very good points about the rules of thumb provided by Neil. They seem to make sense from a very general standpoint, but when you look at actual applications they don't hold true because process equipment is more modular than Neil's 1000 I/O example assumes. Isolating single points of failure to the associated equipment increases the reliability of the overall process. This is why it is considered a best practice to specify I/O in smaller increments (8 or 16 vs. 32) for critical applications. Modularity also provides other reliability benefits such as isolation for online changes and maintenance. The multiplication factors for cost don't add up either.
My question is more related to the usability of architectural flexibility. During a project, you need to design your control system architecture to fit your process, with the right amount of I/O in the right mix of I/O type. An infinitely flexible architecture would provide the ability to fit your process exactly - with the exact amount and type of I/O that you need. Additionally, an infinitely flexible architecture would make it very easy to change your design when your process design changes later in the project, with limited effects on control logic, wiring design, and power/cabinetry/etc. This seems very clear to me.
What I'm trying to figure out is whether there is a tradeoff in usability that accompanies this flexibility. Or, does limiting the flexibility of a control or safety system architecture actually make it harder to use, because you end up having to fit your process needs into the system's capaibilities. For example, without sufficient modularity you might install hardware that is too large for your application (incurring higher costs), or you outgrow the hardware that you installed and are stuck with a huge incremental cost to add just a few additional I/O.
Are there really usability tradeoffs associated with increased hardware flexibility? Is this even important, since you only design your system once - if it is somewhat more complicated to design then does this matter when compared to the benefits that increased flexibility provides?
Mike - with regard to system
Mike - with regard to system design, I think architectural flexibility can actually save customers money in project implementation, at least for big projects. When we're talking about change management (which is the single biggest issue with these projects), anything which limits the scope of the change is a win for the customer. As an engineer or designer, you are usually talking about a very small detail which would have to be configured - one that in a large project would be handled in a systematic way.
There are other advantages to this: by pinning down a larger portion of the scope, you are also increasing the accuracy of the project estimate.
Additionally w/ regard to usability from a system maintenance perspective, you could be decreasing the breadth of the overall work and expertise requirement in favor of narrow expertise, which presumably DCS engineers, vendors, or service contractors could provide without relying on others as much.
Overall I agree with your last sentence. The usability tradeoff (in system design) is probably not significant compared to the system maintenance benefits. On top of that, however, it may not even be a system design problem once the project change management considerations listed above are taken into account.
Flexible architectures
Over three decades ago (1978) Honeywell introduced the DCS and process control changed for ever. Now fast-forward to what a truly flexible control and safety system architecture could be.
My 21st century flexible automation architecture includes BPCS, SIS, HMI, digital fieldbus, wired & wireless I/O points, MES integration, plant wireless network (i.e., video, audio, mobile workers, etc.), and every other bell and whistle vendors are promoting today and talking about delivering in the future.
My ideal and truly innovative 21st century control & safety system architecture would include two ways to configure an application solution. The first application development method would be based on the assumption that by now we should have configured just about every possible process and piece of equipment known to modern man. My 21st century flexible automation & safety system would use a highly-sophisticated wizard. My “intelligent” wizard would begin by selecting an industry (i.e., minerals & mining, petrochemical, pulp & paper, etc.), then a process (i.e., Bayer alumina process), then a piece of equipment, etc. A few more questions and the wizard would produce a pre-configured, editable solution that is based on industry recognized best-practices including both controller-based and control-in-the-field solutions. Everything my intelligent wizard used (i.e., graphics, control logic, equipment modules, etc.) would have come from my pre-engineered template library. If the process was known to require safety-functions (i.e., over-pressure protection, exothermic reactors, burner management, etc.) the wizard-built solution would include the appropriate SIS configuration. To accommodate that “Oh we always do it this way” argument, the wizard-built solution would be editable with the option of saving the one-off configuration version being saved in to the Wizard’s library.
My flexible automation systems second configuration method of my flexible architecture 21st century process control system would allow me to select pre-configured processes and pieces of equipment. I would be able to create my own unique process (i.e., column) configuration and save it into the wizard library; again with any SIS related solutions being a part of the “saved” solution.
Impossible, you say? Perhaps; but hasn’t mankind repeatedly revealed that we are mostly limited by our imagination?
Dave