ISA S88 Control

LinkedIn discussion Why do so many Automation Projects go wrong?

2012-02-01T03:54:00.000-08:00

Recently there has been an interesting discussion on a couple of LinkedIn groups
You can find it for yourselves on the LI Groups (mostly the Automation and Process Control groups), although that means that you may have to join them,
Why do so many Automation Projects go wrong?
From the Automation Group
This is a very broad subject to which there can be many different responses.
From my personal experience, I have seen automation projects fail for the following reasons :
1. Incomplete brief from the client.
2. Poor selection of equipment. Lack of experienced personnel making unsuitable
choices. Most common mistake is using complicated solutions. KISS principal is
paramount here.
3. Poor planning and scope of work. Again, lack of insight into what is required often
leads to an un-satisfactory conclusion
A general comment here : my credo has always been that I have always asked someone more knowledgeable than myself when in any doubt. Many automation practitioners believe they would disgrace themselves by doing this. The opposite is however true and normally leads to an improved solution.
----------------------------------

Following are my observations:

1.Lack of proper understanding of the "process to be automated" by the automation engineer

2.Improper sizing of Final Control Elements by the owner or their engineers.

3.Additions or revisions of I/O or functional requirements by client during FAT, pre commissioning or post commissioning stages or at SAT

4.Cutting corners by automation company to secure orders!

5.Foolish confidence on the part of automation engineer that he can conquer anything by his programming skills!

7.Wrong assumption by the client that "PLC or DCS" can do anything and everything and "Functional scope" can be expanded at any phase of the project!

----------------------------------

Although the above comments describe some key issues for failures, on a high level there is a serious gap with Automation Managers in adhering to basic project management principles. Most of the projects are executed merely depending on the historical information of the previous projects and the experiance of the project manager or lead rather than analysing facts. I would say that emphasizing on project management guidelines would highly reduce risk and calling out for project failures
----------------------------------

The points raised are excellent and show in-depth understanding of how easily things can go wrong : Taking the first of these, it IS so easy for an outsider to fail to come to grips with the dynamics of the Process when software and indeed, hard-ware are designed and chosen. One should always get an experienced Process professional skilled in the actual Chemistry of the plant to be automated to check out one's ideas. many of these could be flawed.
Then, despite the plethora of Valve sizing software available, my own preference has ALWAYS been to let the Valve manufacturer specify the actual size and trim of the valve in question. ( Fill in the valve sizing data form he provides ) Then if it does not work as per designe criteria, there is always a fallback position. I have worked in so many plants where my pre-decessors have installed oversized valves, that I am very wary of falling into this trap.
Once the design is accepted, the client needs to accept that "Design Freeze" has been reached ( formal milestone in the Project schedule) Any required divergence from this will cost HIM money.
The other points are equally relevant, but I will let others share their views,
regards,
----------------------------------
• It's the lack of clear objectives and definition of the technical and commercial requirements. All the process elements, ranges of tolerances and the variables must be identified and addressed along with the costs and the timing for implementation to ALLOW for success - execution is another matter entirely!
An important point not touched on yet is the long term commitment the customer has to make toward automation. Even the best engineer cannot predict the changing business rules or develop a perfect design. This is especially important moving from a manual system for the first time as the entire business model and resourcing requires changing too.

I've seen many 'system failures' blamed on a few small component, miss-scoped elements or training issues that remain undefined and discredit the entire system.

I agree with Charles around the KISS principle and don't over engineer too soon you are sure to miss-scope and also the Design Freeze however... I recommend starting your improvement program from day one to allow all those scope changes to be collected and distilled. I'm a strong advocate of Agile PM techniques to allow the system to grow into the business rather than spend months fighting over spec's that will never stand up in court anyway...
----------------------------------
From my experience, transforming the Project requirement into a System design is the key aspect of success for any Automation project.

An Automation system design should balance 1.‘Hardware modules (Instruments, motors/actuators, sensor/signal interfaces, etc…)’, 2.‘Software modules’ (UI, signal/image processing, control logic, etc…) & 3.‘Mechanical modules ‘(robot arm, fixtures, etc) in an accurate proportion.

A simple example; while designing a Vision system, when a limitation is hit on achieving a positional accuracy for a mechanical arm in positioning the Part under Camera’s field of view, the designer should know to what extend this deviation in position can be taken care by a suitable Camera selection or by Image Processing, with which an efficient system can be designed to meet the process/project requirement. In many instance, the Automation project will lead to failure only because of bad design or lack of expertise for designer.
The designer should have good experience/knowledge on all of 3 core components (mentioned above) to design an efficient automation system.

Sometimes the respective (Software, Electrical & Mechanical) engineers would step into the project development with assumption/over confidence and without having clear understanding on complete system requirement or other system modules that would lead to project failure in later stage of development or sometimes on deployment at the customer site.

From the Process Control Group
you only know what you know when you know it.
----------------------------------
when we do not give much attention to the fine details ,projects becomes difficult
----------------------------------
From my experience, which is not breweries, there are a couple of main areas that have caused automation projects to be less successful (I hate to say fail). Poor planning up-front with no real vision to what the final product should be (not only look like but how it should function), is one of the first things that comes to mind. The other is not getting all the right stakeholders involved from the beginning to get their buy-in AND give them a sense of ownership.
----------------------------------
I have learned that any project can be managed correctly and will lead to the desired and working result if a good functional design is made and discussed with the client (or made by the client and discussed with the supplier). Also from this document a complete test protocol can be derived quit simple, so testing and approving an application is also easy and complete. The problem is that both supplier and customer have to really read and understand the document.
The document itself can be written in any language and does not have to be technical. It is more important to describe the complete behaviour including all (un)known situations which can be presented to the automation environment.
The choice of hardware and software to realise the solution should be made when the functional design is complete. This can lead to a technical design (for instance to break the software into pieces that can be handled by the team or to design a standard structure to use in all equipment).

In this way both customer and supplier have to invest time in the start of the project but it will definitely pay off in the end of the project (less problems, less discussions, less bugs, etc.). The project will run in a realistic time schedule.

I am afraid the article is pitched as a sales exercise and does little to elaborate on any best practice methodologies, software engineering or requirements engineering that are the silver bullets used to tame the wild beast that every project has the potential to become. Knowledge of an industry alone doesn't give you the skills to actually execute good projects!

If you want good pointers then read the software engineering books by Ian Somerville and Roger Pressman. Look at SWEBOK (Software Engineering Body of Knowledge) an excellent resource!

Don't forget to look at new methods such as SCRUM. Embrace requirements engineering and use good design practices coupled with sound quality assurance and project management.

Following the above doesn't necessarily guarantee a positive result, there is always the totally unexpected but.... ignoring the above will almost certainly cost you time and money and maybe the whole project too!
----------------------------------
I agree in part, although to be fair to René Leven his point is that the Process Expertise that his company can provide (in a specific area, brewing) is beneficial, and I don't disagree with that.
Also the software engineering methodologies that you mention are, like most of them, based in the IT world, and not automation, and I strongly believe that the two, while sharing some things, are different.
I mentioned my old "What goes wrong with batch process control system projects? "
www.controldraw.co.uk/presentations/frspaper.htm
It is a short version of a longer paper, and yes it promotes my software ControlDraw - which you could call a CASE system for requirements engineering but unlike IT systems like UML is actually orientated around automation. It is not orientated around a particular solution.
----------------------------------
Industry knowledge may appear to have benefits but it also has limitations as to its use. Knowledge gained by working on a project for most clients is often proprietary and cannot be readily divulged or utilised on another client's projects without first gaining the consent of the owner of the information often regarded as the intellectual property of that company. We know that most industries are competitive and as a result they defend their process knowledge with a passion and rightly so. After all companies often spend millions of dollars to obtain and perfect that knowledge.

I looked at the question of IT versus IAC software engineering methods a few years ago whilst writing my dissertation "Requirements Analysis in Industrial Automation & Control". I spent a couple of years researching similar topic(s) to the one driving this discussion and the results of my work are contained within that document. If anyone would like a copy then please drop me a line?

Since then I have used The UML as a design tool for a mining project in Australia and Structured Analysis on a project for Petro-Canada with great success. I modeled all of the PLC requirements for the mining project in The UML first and then developed the code templates in GE-Fanuc RX3i PACs. I have an example of this approach if anyone would like to see what I did?

I like ControlDraw and I think it is the best tool yet for modelling IAC specific projects and would recommend to anyone reading this article to try it. But at the same time I would also advocate using some of the methods described within the books I mentioned. They are written to cover IT and IAC related methodologies.
----------------------------------
And I think you used ControlDraw 1 in 1999. Believe me it has been improved beyond what you might even have imagined since then, and yes I have looked into UML and Structured Analysis methodologies a lot in the process of developing version 3.
Re the 'intellectual property' that you find in various projects, it is true that companies often defend it. I have hundreds of models from such projects. But when it comes down to it an awful lot of it (95%+) is virtually the same as other people do.
I would very much like to see your dissertation, you know my direct mail address.
And if you are ever nearby drop me a line.
----------------------------------

My experience is based on spectroscopic/photometric process control.
First 10 years I had sometimes to learn the hard way and and I could see also at
other vendors of such instrumentations solutions had difficulties.
Sometimes it looks that there is a roll back in technology for some years, because the user
have so many bad experiences with few solutions.

The reason is, that big and small vendors try to offer a "product" or solution "as is" and this has to cover the clients application. This can not always works and depending the chosen product setup the risk for mismatching is higher or lower.

For this reason I left the original way to be a "instrumentation vendor" with certain products for sale a certain number every month or year .

Now I have a "building set" of the most critical things I have learned and I add around engineering, consulting, feasibility testing and assistance to choice the right components from third part vendors.

My experience now is, less trouble and mismatch!
Means more successful finished projects!
----------------------------------
My experience is in the APC area and competing Honeywell, AspenTech, Yokogawa, and others is the bidding process is all smoke and mirrors. Clients have no idea what is needed in the bidding for a successful outcome.
----------------------------------
"is all smoke and mirrors." sounds tough, but confirms my opinion
if "dinosaurs" try to rule inovation ...
----------------------------------
To develop a successful automation project should be first of all a functional description and a clear idea of the process to be automated.
After this have to develop the philosophy of control and select the technology that will make the solution. This technology must have a local representative (or at least on the same continent).
Along with a good electrical installation with the electrical protections well calculated should be made a good simulation of the system and a final test of acceptance with the participation of the client.
Prior to the commissioning of the equipment should be thoroughly reviewing installations and wiring terminations.
Other thing you don`t see in the books is that the more the client get involved in the project the more compromise he has to help and solve some issues we can have during the commissioning,so make the client active part of the project.
----------------------------------
A final in-house test with simulation software can indeed be an eye-opener for the client and deliver a great saving in time in the delivery fase (and shorten the final acceptance test). Some of these simulation software are capable of simulating the hardware I/O, which has the advantage of minimal changing of the software (preferably no changing at all), thereby reducing the risc of bugs made by the adaptions for simultion to zero.
In this way both logic, control loops (for instance PID loops) and the look and feel of the Scada can be tested and experienced.
This will lead to more understanding of the proces and the solutions by the client and the supplier (due to the comments of the client).

Together with a functional description and a solid test protocol the automation part can not go wrong in this way.

Note that the electrical installation is made according to a set of electrical drawing which also has to be checked. An active client will demand these drawing in order to check them, before the supplier may proceed with the production of the installation.
The number of installations which are delivered and accepted without a complete or error free set of drawing is too large.
Both client and supplier are capable of changing this habit.

We must conclude that delivering a succesfull automation project needs both an active client and an active supplier.
The assistance of software to make documentation and check the working can be very useful, but is not the key secret for succes.
----------------------------------
The most spectacular successes I have seen had committed champions to lead the various phases of the project who could readily accept going back to the drawing board to overcome any difficulties encountered during the execution and construction of the project
----------------------------------
In any automation, the wekest link is human being. So many new technologies /concepts/operating philospphies are evolving every day.the less we are trained/ updated, the more we fail. No woder, we should end up only in counting.
Thank you very much for the many interesting comments so far.
@Bob, I understand your concern about that the article is a little bit sales focused. However I liked this article written by my former colleague (I work in another field now) and wanted to support it. I am glad that it resulted in a discussion with many interesting and true comments that followed here in this thread.
I agree to many oppinions here that we should involve the customers as much as possible, know the technology and also mentioned inhouse tests can help increasing the projects success and having less stressful commissioning.
----------------------------------
Francis Lovering • It is interesting that this discussion has largely covered exactly the same things that have been known for years and years. Define the User requirements properly, involving the user closely, simulation testing, using modelling techniques and so on. But as I said all this has been known for years. And yet projects still go wrong.

I think that getting the right project manager and empowering them is one key. Among many other things such a manager needs enough technical skills to communicate both ways with the end users and the automation team. They are not common.

An issue that I have not seen mentioned here is one that applies to the frequent situation where an EPC engineers and buys all the equipment for the project including the automation system. Often the EPC produces the URS on behalf of the end user and sits between the user and the Systems Integrator. There are often complex interactions and sometimes conflicts between the EPC’s desire to ensure that the project is held to its cost estimates, and the end users desire to get exactly what they were hoping for.

Another major issue is Change and how to deal with it. Changes arise during a project for various reasons, often a part of the process is changed late and some parts are not completely definable until late in the project, after the system has been ordered. This is particularly true for fast track new process projects.

There are papers that address some of these points www.controldraw.co.uk/presentations/Presentations.htm

----------------------------------
I agree with Francis, but would like to add that there are 4 major items that need to be added to any project, Planning, Planning Planning and testing.
Planning with the sponsor or project initiator for the project, that he has defined what he wants to achieve.
Planning with the user, (often not the project initiator) that he gets what he wants.
And planning with the project delivery team, to ensure they develop an accurate functional spec meeting the needs of the first 2, then plan how to deliver ,review and test the system before delivery to site.
Finally Testing, commissioning the system properly, and testing the "What if" and What can go wrong scenarios not the what happens if it all works scenarios.

This takes time and costs up front, but no where like what it costs to fix later, however it depending on the environment it can be difficult to convince people of the real benefit of this approach especially in a multi disciplined environment where the overall cost means it gets little focus or understanding. However it does buy a lot of good will and acceptance of the project and its outcomes.
----------------------------------
This discussion is getting more interesting with every thread. I would also like to contribute by a background of five >million USD projects as a project manager at the user side.My assumption is; an automation project is either a reinstrumentation project or a project which is part of a bigger grass root project. I will concentrate on the first one.I think there are basically two types of customers; the ones who expects the contractor to create and submit the best project, and the ones who think that the contractor is only a tool to implement the described project. It is not usually black and white like I described above, but usually a mixture of behaviors. Second model usually helps more for successful projects, I believe.Since all the projects have two actors; i.e. the customer and the contractor, the 'agreement', and the succeeding 'communication between them' are the most critical and key elements with any project, especially in automation projects.When both parties' project managers are excited with the imagination of the project, and the agreement is good enough to handle unexpected issues, then we can say that there is a good probability of success.I will stop by a plain fact, before being boring; both parties spend a small fraction of the total intellectual effort involved in a project during the preparation phase, which will cause change orders or reluctant acceptance later. Therefore the main idea, the structure, expected performance should be clearly declared by the user, beside specifications, and database. The contractor should be transparent and specific during the bid.The following document presented in Vienna 2009 PALM Forum, is a short form of my experience on the topic. www.scribd.com/doc/43914146/Improving-Reliability-Thru-Automation-Projects-r3
----------------------------------
Haven't read all the experiences, but I had not seen many projects go wrong.
Almost always they end as expected.

Success=result-expectations.

May be lack of communication of between client/user expectations and manager/integrator objectives.
----------------------------------
We are developers of software for the manufacturing industry (mainly glass and joineries) and about 40% of our projects are factory automation. In my experience there are similarities with our other software projects in that it is almost impossible for the customer to come up with a good specification of his needs at the start. But while agile software development is a good answer to this problem in pure software projects, in factory automation projects the main costs are in the hardware and to change that part in a later stage is not easy and expensive.
However, if the customer becomes aware of his situation it is quite often easy to convince him to design a bit of flexibility into the machinery.
Furthermore we usually convince them as well to do only the basic functionality of our software first and then extend while we get experience with running the line. This has multiple advantages. First, the learning curve for the users is less steep. Second, the users can give us some input on their additional needs and will get improvements, which increases acceptance, and third it is always difficult for us to get proper interface specifications from the machinery manufacturers until shortly before they start installation, so the time window to adapt our software is usually very short, which means we prefer to deliver a smaller but properly tested subset than a final solution with lots of bugs.
----------------------------------
I completely disagree with the topic title , if it often fails I am sure automation would have been replaced. I also agree with Bob , this topic is clearly sales biased.
Automation is never a project on its own , it has many dependencies and interlocks with mechanical, pneumatic, hydraulic, IT , SCADA and people counterparts. If something is not well understood or prepared the automation guy has to adapt.
The problem is that the automation guy always comes last and gets the blame.
So yes we have to adapt and learn , projects live and need to be adjusted.
Don't get me wrong preparation is key but even then it doesn't go as expected, and then the automation guy has to write some funny logics to compensate for example the mechanical problem.
About 10 years ago something went very wrong in space because two mechanical parts did not match , the parts where made by two different companies ( all HAIL to the lowest bidder aleluhja) and they both used different tolerances. it was like one used metric and the other imperial .....so with many years and millions to prepare, enough people and skills it still goes wrong , but we learn and adapt.
----------------------------------
Francis Lovering
Not many people admit to problems with their Automation Projects, publicly at least.
And they tend to get there in the end, perhaps with less functionality than they originally hoped for and with overspends. So the project does not fail overall.
As for "and then the automation guy has to write some funny logics to compensate for example the mechanical problem.", this is a classic failing in the requirements analysis. And 'Funny Logics' are not a good thing to do.
Hans
You may think that " in factory automation projects the main costs are in the hardware", my experience is that there are many projects where this is not the case. And defining the hardware is relatively easy, it is in the software where the projects go most often wrong.
----------------------------------
Francis Lovering - 1st paragraph, BINGO! Exactly what I was trying to say, to answer the original question.
----------------------------------
I agree with you. Automation (Control and Instrumentation) is the last discipline in any project that has to make the project come to its final realisation and always suffers from project cut backs and or discounts. In my experience, automation has always suffered from budget cuts and shortcut. Other engineering disciplines always get their way when it comes to forging a 40" flange or construct a giant piping support with almost a near blank check, just because they are buying a big lump of metal, but if you try to get an extra piece of software license or, more advance control system, getting an extra 1000 dollars is like getting blood out of stone.

In a recent documentary on worldwide resources, one international recruiter stated "If you pay peanuts, you get monkeys", and worst still any monkey with keyboard claims to be control system programmer, just because they happen to learn a few graphic game codes in VB, and all of a sudden they are expert DAQ/SCADA programmers.

This has give automation a bad name in so many industries to a level where human intervention is still seen as safer bet than automatic alarm on a high pressure drill return flow line. And when the operator is fallen asleep on the job which has lead to the rupture and release of effluent into the environment inflicting 100s-1000KUSD of damages, they just record it as human error on their LTIs and lessons learned, as an acceptable practise.

----------------------------------
Francis, of course you are right, in most cases the software costs exceed those of the hardware. This simply reflects the fact that these days all the complexity is addressed in the software. What I should have said is that most providers have the software in some form already; all that’s needed is some adaption to the actual situation.
In our case we only do the overall control of the plant. That is we make sure the right pieces are produced at the right time and arrive at the right point for assembly. To this end we communicate with the machines’ PLCs which are supplied and programmed by the machinery manufacturers. They of course are in the same situation as we are. They have some form of software from previous projects which they have to adapt to the new plant.
In my experience that is where the problems come from. Quite often the customer starts building the factory before they have definitely decided on the machinery suppliers. So we know the details of the machinery and the interfaces to the PLCs only a short time before the machinery is installed. And because the PLC programmers have as little time as we have to do those program adaptions, these interfaces might even change later, because we or they discover problems in the communication.
Thus, although those program extensions usually only take a few man-months we have too many programmers involved on both sides trying to make it work in the short time given. This means a lot of communication overhead with a high potential of misunderstandings. These are then usually discovered during implementation and testing, where you are faced with other problems as well, e.g. machines not yet working properly and of course a customer that does not understand why the whole thing is not working yet.
This brings me back to the point I tried to make before. For a first version, try to implement and install the minimal functionality needed to make the plant work in the standard case. Implement additional functionality later. Usually the customer learns only after a while what all they could do with that new plant. Just recently we had a case where during specification we all agreed, that a certain configuration would never happen on that new production line. It just did not make sense to produce that there. Only half a year of running that line now the customer wanted to run exactly that and it suddenly made sense to all concerned. Fortunately it took us only a few hours to implement the software extension required to make that work.
Maybe this is a way of lowering the customer’s expectation of what they can get initially. But what they get in return are higher flexibility for changes and extensions later in the life of the plant and thus more possibilities in changing ad adapting the line to changes in demand, a changing product mix and new product to be produced over the line.

Note - the discussion is still running, and more points have been added, mostly repeating points that have already been made.

A New Automation Company in the UK

2012-01-24T06:35:00.000-08:00

My long time colleague, Andrew Knott has now started his own automation company.

Knott Automation Projects Limited.

They will be able to provide full life cycle automation and information system consultancy services in the process industries. And they have deep experience with ControlDraw and S88 projects. Do take a look!

Objects contained in P&ID's compared with ControlDraw models

2012-01-13T06:52:00.000-08:00

The diagram below shows how ControlDraw models contain far more then conventional CAD, notably the higher levels of the Automation Objects. Click to see full size.

Example of a ControlDraw P&ID for a BioFermenter

2011-09-27T02:30:00.000-07:00

The diagram below (click for full size) is a 'typical' BioReactor as found in bio pharma plants. This diagram was produced in ControlDraw.

Process Engineers and the P&ID

2011-07-12T06:54:00.000-07:00

This is a recent conversation that I started on the LinkedIn
As the IChemE (Institution of Chemical Engineers) group is closed, non members of the group cannot see this dialog so I have posted it here.

Francis Lovering

Piping and Instrument Diagrams are generally large and quite complex.
They contain a lot of information, some for the equipment engineers, some for the mechanical and piping engineers, some for instrument engineers, electricals etc.
Typically they have to be A1 or even A0 to be readable, such is the level of detail.
They are generally sketched out and subsequently marked up using pencils and a highlighter by the Process engineers. Then they are actually committed to CAD (once upon a time it was paper) by CAD draftspeople, not by the Process engineers.
I am interested why the Process Engineers do not normally do the CAD themselves.
Is the reason for this that the CAD software not easy for the process engineers to use?
Why the marking up on paper? Is it that screens cannot yet compete with an A0 P&ID?

Alex Chatwin
The reason why process engineers should not be doing CAD is a matter of time. What would you rather a process engineer be doing? Cad work or doing process engineering? Where is the best benefit for the company that is employing the process engineer. In Aberdeen rates for Cad work is in the region of 35 to 50 GBP; Process can be paid 45 to 75-80 GBP. Where would you spend the limited number of hours for the process engineer?
I have seen both process engineers doing Cad work and cadders doing Cad work. If the process engineer indicates what he wants drawn then the CAD draughtsman can do a better job of the Cadding. Use the talents of the Process Engineer in assessing the important process critical areas.

Kophyo Win
Computer screen limit your view of PID to a small area, making it difficult to be aware of impact on other parts of the process. It is easier to have a global view of the entire process on a large piece of paper and better for team work too.

Francis Lovering • Alex
How about if the CAD actually made it easy for the process engineer? I mean do they get secretaries to update their spreadsheets and documents. These days? If the CAD was process engineer friendly (and the process engineer more, shall we say, adventurous) much of the drafting process could be eliminated. That saves money.

Kophyo
The thing is that the amount of detail on most P&ID’s actually obscures the bigger picture. You cannot see the wood from the trees
And all those links between P&ID’s (the To and From connectors) make it a real pain to actually work out how major equipment items connect, which is what the global view needs.
I feel sure that there must be some process engineers who do the CAD!

Alex Chatwin
Francis,I have been in a company that employed Process Engineers as those responsible to do CAD. It doesnt work. We were using IPID 2010 and there was a requirement for the process engineers to have a very good understanding on CAD operations. This software would require the engineer to put in all the raw design information. I would rather that a process engineer received a printout on A3 of a template and make the modifications he wanted by hand. It is much easier to draw something by hand on paper then to input the modification electonically. The time by the process engineer wasted is large otherwise. In this company where I worked I had convinced the senior management that it was better to hire some CAD resource than tying up the process engineers. Keep process engineers doing Process Engineering. This is how the process engineer will be more productive. Also as a process engineer, the impact that I can make with the knowledge I have is huge. If we use process engineers to do CAD we are watching the Pennies and not watching the Pounds so to speak.
Alex Chatwin • In regards to having lots of connections, and a P&ID being complicated, this is why you have experienced process engineers that have seen alot of systems before. I have been looking at a gas import problem on an FPSO and the process flows spanned many P&IDs. It doesnt help me in my ability to use CAD to solve the problem. I need to ensure that what is happening is safe and it is technically competent.
Please do not ask process engineers to do CAD as they have been at university in some cases for 7 years. This is not how to best utilise their time.

Francis Lovering
All good comments, thanks. I am interested in the whole life cycle of the P&ID, and one thing that has not been mentioned is how they start. Before the P&ID there are Process Flow Diagrams, again I have often seen them done the same way. But as these are simpler documents would you agree that they are more amenable to being produced by the Process Engineers?
I just want to comment about P&ID's from the perspective of an Automation engineer.
As I mentioned, it is hard to see the wood from the trees. Only a small portion of the each P&ID’s is about control and instrumentation, so it takes time to get the picture. Generally a talk with the Process Engineer will of course save a lot of time.
The is a huge variability between projects as to the content of them. For example some will squeeze a lot of equipment onto each while others will have more P&ID’s with each devoted to a primary equipment item (a Unit in S88 terms) .
Some will show details that others do not, for example each limit switch and solenoid for each valve (3 or 4 balloons per valve) others will show one balloon with a key of some sort to indicate what the valve includes. Some will attempt to show the control loop details and others will not, some show interlocks and some indication of logic functions others do not.
As for the interconnections it is generally one of the first things I try to understand – it would be great if people produced an overview diagram showing the P&ID’s as boxes and the lines connecting them - but it is rare. Often the control engineers have to work that out in order to, for example, design the plant overview graphics and work out the overall flows and the interfaces between equipment (an important part of the functional requirements).
And almost invariably the diagrams are not up to date (the true master being the marked up one that sits on the process engineers desk)
Often P&ID’s are used as a basis for the graphics on the Process Control System, however that is rarely a consideration for the process engineers when producing them.

Alex Chatwin
Process flow diagrams (PFD) are there to describe the process flowrates, the pressures and the temperatures. The composition and density of the streams will also be covered. This is the original design basis for the process and it is the normal starting place for process engineers.
After the PFDs have been generated, the P&IDs will be developed. They start life as a blank piece of paper and intially a red line markup will be made. It may be that this occurs for a feasibility study but not a concept study. There may be several options all of which will be P&IDed. Once the design has been confirmed during the early stages of FEED the design will be set in stone and they will advance through several internal revisions to a final product at FEED. These will then be reviewed at early Detailed Design and modifications will be made. There is naturally much variability in the process depending on the level of complication of the project and the company that is doing the design work.
The types of valve annotations will be different depending on the company developing the P&ID. My humble view is that P&IDs are not commercal purchasing documents and should be made appropirately simple to represent how the system works. If an ESD valve has two soleoids on it, if the type of valve is described in a legend this is fine.
These are my views and I am sure there are process engineers who may disagree.

Francis Lovering
Alex
I do know about PFD's do the ones here show what you mean?
http://www.urswriter.com/index.html?ProcessFlowDiagrams
(Please comment on them so I can improve them.)
Part of my point when applying the term lifecycle to P&ID's is that they do not start from a blank piece of paper, don’t they start from the PFD’s?
The lifecycle that conventional plant CAD products follow tends to lose this. I am unaware of any CAD products that can connect the PFD’s to the P&ID’s - if you know of one please let me know.
As you describe, early stage P&ID's may change a lot (“There may be several options all of which will be P&IDed”)
Would it be reasonable to say that at this point the P&ID’s are actually quite simple, and do not need CAD Skills?

David Greene
I would prefer to do the initial P&IDs myself. With the use of libraries of blocks, it is relatively easy to create PFDs and then transform them into P&;IDs. Simple drawings are easy but most people are using layers and intelligence that involve a much better understanding of the software then I have. So, even when I used designers to draw the real P&;IDs, my preference is to sketch them out in CAD myself.
Ideally a PFD is on a single sheet of paper while each P&;ID should be limited to a single major equipment item or system to facilitate number and allow room for the instrumentation. Back when we were developing Engineers, the thought was that a process engineer would do the drawing and data entry. I'm sure David Cockshoot could tell you a lot more about this.

Alex Chatwin
My preference would be to ensure that process engineers are doing process engineering. WIthin a design house there are so many other tasks that are important for the process engineer to do that they should not be wasting their time CADing. A simple Red Line Mark up will suffice and let a Draughtsman do the drawing. If a process engineer is required to persuade regarding a process idea then it may be appropriate for them to sketch out options. This is as far as a process engineer should take it. Fiddling around with blocks and juggling them around space wise is the realm of the draughtsman. We have to ensure that what is there is correct. Safety, isolation philosophy, emergency shutdown and control philosopy, blowdown and flare assessment, line lists, valve lists, pressure drop calculations, heat and mass balance and this is just a few tasks. These are what the process engineer should be doing, not the drawing.

Francis Lovering
I was peripherally involved with Dave Cockshoot in the early days of Engines (which ultimately became part of AVEVA) so I know the history.
I believe that the idea " the thought was that a process engineer would do the drawing and data entry" was fine but the implementation awful.
As is clear Process Engineers have too much else to do to become proficient in CAD Software. But I don’t see that as preventing them from using something simpler at the early stages of a project when all that detail is not needed.
Part of my intention in this discussion is to research how I can make my software, ControlDraw, into a product that Process Engineers Can use in exactly the way you describe.
It may never be suitable for large P&ID's, but I think it is already more than capable of producing PFD's and much more, including simple P&ID’s that could be used as a starting point for the CAD versions.
To explain my thinking I have put a diagram here
What do you think?

David Greene
I did take a look at your drawings and they do show the sequence of drawing development but as discrete documents rather than a continuum of developing process drawings.
I used Vizio for PFDs and conceptual P&IDs. Several times I tried to do something like you suggest with Vizio and also with SuperPro but was not successful.
We really need a way for the draft to flow into the real P&;ID without losing the initial work. I like the idea of showing relative elevations and sizes on P&IDs, matching lines from P&ID to another, showing remote/computer control/instrumentation away from the equipment, etc. My experience, particularly with batch processes, is that the instrumentation/control representations take up too much space and need to be simplified. In some cases, you can start with very sophisticated controls because its just like something done previously but in other cases, the process design benefits from a progressive development of control steps and then there is the case of cloning an entire process with minor changes which is more amenable to the red lining described by others.

Francis Lovering
David
You should try with ControlDraw rather than Visio, I would be very willing to help you

Visio :
Prettier
Made by Microsoft

ControlDraw :
Designed for our industry
  Hierachical
  Variants - multiple versions of the same diagram with different tag numbers, exclusions etc
  Intrinsic State Model - supports Simulation and such things as Equipment State Matrices
  Simulation - put diagrams into run mode, see process flows etc
  Library of objects
  Easy to re-arrange, moving objects from one diagram to another for example
  Intrinsic Process Database (eg Equipment List)
  Intrinsic version controls
  Hundreds of diagrams in the same model all linked
  Drop a Valve into a line without having to connect it
  Free Viewer with Comment capability

Edmund Fish
I think the problem is that when I started it was skilled draftsmen that did your drawing and they were still a separate breed because CAD had a steep learning curve. But I noticed on the times when I had drawn P&;IDs from scratch that when the draftsman ran over it looked a lot better than my best efforts. That skill in making a drawing clear goes beyond just P&IDs and applies to other drawings. BUT today we have more and more "CAD jockeys" that are little more CAD secretaries; they draw on CAD exactly what get given on paper.
Process Engineers bring so much more to the table that having to learn a large skill set (as distinct from transferring one on to a spreadsheet of word processor) is just a poor use of of everyone's money. I can use a word processor / desktop publishing software but I have friends that are old school printers and the subtle changes that can make to a document can sometimes amaze me.
Adam Smith argues that economic progress comes with increasing specialisation; process engineers doing CAD work is a step backwards.

Jon Baker
I agree with the thread running through this. I don't think its a good use of process engineers time and I think the product they would produce would be inferior than one produced by a good CAD operator. But thats from the perspective of a reasonably sized design office - may be different in a smaller organisation.
My experience of drawing up PFDs in visio or similar is that the CAD people need to start again, because it doesn't have the finesse or intelligence of a proper CAD system.
On the other point of drawing size, we always try to make our drawings readable at A3. It is about deciding on how much to put on a single drawing.

Ken Rollins, FIChemE
I agree with the use of Process Engineers time, but that being said, a CAD-literate process engineer can produce a first draft of a P&ID quicker than he can sketch it. Thereafter he should not waste his time adding instrument tags, line numbers and the mass of semantics that go on these drawings - leave it to the CAD technicians. There is, of course, a more sinister reason. Most clients have definitive CAD standards to do with drawing layer, X-references etc, line weights, font types and sizes etc. A good CAD co-ordinator is required for all of this, and that is not the function of a process engineer.
I endorse what Jon has said about smaller plots being perfectly OK. Use more drawing sheets and make them less cluttered.

Jiri Salek
Our CAD draftswoman works for 10-20 process engineers. She is the best I've ever seen. What she does in one hour takes 2 or 3 hours to other CAD guys. How is it possible? She is specialised process draftperson with 15 years experience. I can produce sketches in visio or similar but there is no way how process engineer could efficently draft PIDs.
Perhaps just updating a text during the review process or adding dates and signatures for the final issue could be efficient.

Adeline Hoo
This is an interesting topic. I have been a Process Engineer in a multinational engineering firm, no, they don't allow Process ENgineer to CAD, we could only comment and guide the dedicated draftsmen/process designer to CAD.
Now that I'm in a much smaller company, my project manager made me do everything, literally from conceptual design to creating P&ID from scratch using AUTOCAD which I've not much experience, but once you're pushed, you'll pick it up.
I'm wholly involved in the process part of the project at the least, designing the systems, putting them onto P&ID (from scratch I stress), generating the subsequent component lists...quite taxing but worthwhile.
But then, it's a relatively smaller project that I'm doing in a biopharmaceutical line, if it's a big one, I prefer dividing the process design and mere drawing work is better.

Francis Lovering
Thanks everyone who has participated.
I would like us to summarise the conclusions of this 'meeting of minds'.
My Conclusions.
Process Engineers have a range of activities to perform that mostly makes it inefficient for them to learn and deploy CAD systems like AutoCAD or even Visio for detailed P&ID’s
Some like to use Visio, or even AutoCAD in the early stages of projects.
Process Engineers are capable of doing the drafting themselves if they have to. (I wonder about this, would I be wrong to imagine that the ones they do may have drafting typos but a better process perspective – can a diagram show a perspective?)
Some of you would prefer to do the primary process diagrams yourselves, before handing it over to CAD Specialists
A Possible conclusion is that P&ID’s need rethinking, they are after all based on a paper model that goes back half a century or so.

Alex Chatwin
Francis, I do not think that the current system needs to be re thought The current system works with the correct work procedures.
I have seen during my time, a range of activities from Process Engineers doing Cadding and others where the infrastructure to do simple updates makes it un workable. The most important ascept to P&;IDs is work flow. It is important to place the level of responsibility at the right level to those that can make a difference in the most effective manner. Process Engineers are responsible technically for P&Ds and it is important to use the technical competency of daughtsmen to ensure that they are drawn correctly.
if it aint broke dont fix.

Francis Lovering • Alex
As I said, a 'possible' conclusion. The current system is certainly not perfect, procedures help to make it work, but it could be improved. In particular to retain the links back to the fundamental process - the Recipe.
And actually process engineers are not 100% responsible for the P&ID's, many other technologies contribute to their development. Arguably cluttering them up and obscuring the fundamental process as they do so. As a control engineer who has been using P&ID's for about 35 years I find it painfully slow to extract the stuff I need from most of them, although there are some exceptions. It might be a good topic for a new discussion - what should the Scope of a P&ID be, how much of the control should it show, how much detail of the piping and so on.
One good thing about P&ID's with good procedures is that they provide a sort of workspace where the engineers from the various technologies collaborate. But is that the most effective way to make that happen?
15 days ago

Alex Chatwin • Francis,
In the oil and gas industry, this is my field, process engineers are responsible for P&IDs, Cause and effects and input into Alarm and Trip setpoints. It is up to us to say how we want it to work. It is then up to the intrumentation engineer to ensure that it works how we want it to. As I was explaining before, once the design of the system and the design set, early to mid FEED, there will be an opportunity for all disciplines to input their comments into the P&ID and this is called an Inter Disciplinary Check, IDC This is always should be done prior to a release to the client and/or before a HAZOP.
For modifications to process systems, everywhere where I have worked, the Process Engineer is responsible for ensuring that Brownfield Work is reflected on the P&IDs correctly. Brownfield meaning modifications to existing installations. There is alot of information to show on a P&ID and should not be the only source of information. The Cause and Effects are a good source together with the Alarm and Trips for figuring out how a system is meant to work. There should also be a Operations Narative together with operational procedures. Often it is the case during commissioning that the set points need readjustment and reconfiguring to ensure smooth and safe operation and the troubleshooting will be the realm of the ops process engneer who then provides feedback to the instrumentation engineer for the required changes. There will be a whole bunch of input at this stage. However, the process engineer needs to ensure that all recommended changes will be acceptable and not introduce additional risk to personnel and secondary to assets.
In my experience, the main criticism I have would be the work flow management in P&ID development. The level of responsibility has to sit firmly where it can make the most impact. It is up to to individual company to decide on the level of detail shown and how much information to show on one P&ID. This will be part of the IDC.

As you can see in the oil and gas industry there is much more for the process engineer to be doing that has a very hgh impact. Another reason to why he should not be sidetracked by drawing.

Joyce Jabane
As a process engineer, CAD is the best thing that happened for development of P&IDs. With AUTOCAD 2011 and ; 2012, it will reduce the time required to carry out designs. For instance, if P&ID is drawn in AUTOCAD 2011, it will be easy to generate the GA, isometrics, structural and civil designs from it. Based on my experience, it will however take longer to develop the P&ID, but less for other drawings metioned.

Juan Cuba
Very interesting topic. I can only say that actual Engineers need to be familiar with CAD/AutoCAD, CHEMCAD and use them according with the size of the project as tools. I agree with Alex, process engineers must be dedicated to do engineering and not drawings.

Alex Chatwin
I agree we have to have an awareness with it as this helps us guide what we desire. Our tasks have a higher impact that just drawing. Leave CAD firmly in the capability of daughtsmen. They are better at it as they specialise in this area.

Red-lined marked ups should be made by the process engineer as quickly as possible. Here is a rough summary of some of the tasks he/she will have to do:

Design Philosophy - temperature and pressure.
Isolation Philosophy
Process Flow Diagram - to include heat and mass balance
Equipment Datasheets - preliminary and detailed at later stages
Calculations - Pressure drops
Line Lists
Valve Lists
P&;IDs red-lined markups
Cause and effects
Alarm and Trip Setpoints
Cv Calculations
Control and Safeguarding Philosophy
Flare Study and PSV sizing
Operational Procedures.

So to add to this list of very important activities, drawing, I will let you decide.

Keith Plumb
I do not work in Oil and Gas but mainly in pharmaceuticals and fine chemicals with largely batch processes. It never ceases to amaze me how much time is spent on P&IDs both process and CAD time.
Actually I think the P&ID is very broken and a serious rethink is required. I used Francis's ControlDraw to carry out the process design and to produce the P&IDs. I thought the software was good but could be better. I also thought it helped the process engineers and control engineers to get their thoughts together.
Sadly the client did not like the result - they wanted conventional P&IDs and my fellow process engineers were not that convinced. For me the generation of the P&IDs feels like the tail wagging the dog and it become a hugh task that should be much easier to do.
Francis when I get the time I would like a serious long chat about this.

Piotr Janowiak
Generally I agree with Alex, but ...
In many cases IDC is done by senior engineers on quite high level of generalisation.
There is a zone where tasks of chemical or/and process engineer may coincide with tasks of other specialists e.g P&ID. The point is that P&ID is just a tool, a way how process engineers share information with other engineering departments. A process engineer must have much wider and deeper knowledge about piping or instrumentation if s/he has to prepare P&ID by him/herself. Reluctance of many process engineers to P&ID is incomprehensible.
A process engineer is the pivot of project. Project information starts and has a source there. This discussion is really about who should know (and understand) more. The question is whether a process engineer should know and understand more about control and instrumentation or a control and instrument engineer should know and understand more about (petro-/bio-)chemical process.
I think that such kind of multidisciplinary approach is needed from all specialists.
Most problems which occur during start-up and commissioning have their source in the lack of communication between a process engineer and other specialist.
For example - a process engineer specified on P&;ID that wanted to measure the liquid level. So s/he gave liquid name (e.g. produced water) and "all" physical parameters to an instrument engineer. I just wonder how an instrument engineer should know that produced water is not some kind of industrial water but the mix of water and HC, how s/he should know that a process engineer decided to add antifoam agent which is stick and may build-up on the sensor.
It is not important who will draw P&ID. What is really important is what information a process engineer is going to share with others.
Software such as ControlDraw can help, but a process engineer must understand her/his role in the project.

Alex Chatwin
Please let me define responsibility. This means that Process Engineers have the final approval on P&IDs. It is not that we do this task solely on our own. I agree whole heartedly with Piotr. This is how we ensure that the right information is communcated to other disciplines.
I have come across a major failing recently where the right service was not described for a valve. This has caused that the valve materials were not scoped properly. This comes down to the process engineer not having enough experience/time to get this right. This has lead to a major failing of a process system involving several hundred thousand pound failure.
IDC should be trying to get everyones comments regarding the design to hopefully pick up these issues.
P&IDs work but the work flow and where the repsonsibility sits to get the overall design correct needs careful evaluation and each organisation is unfortunately different.

Francis Lovering
Alex, thank you for describing the process engineering activities so well, One point I would like you to consider is how well all those tasks are integrated by your CAD systems.
For all the lists I would hope that your CAD can actually generate these from the Lines, Valves etc on the P&ID’s
A very simple question is what happens if a tag name changes? Does that change propagate to all the documents you produce?
Another would be the Cause and Effect diagrams – do these connect to the P&ID in any way other than manually?
And Keith
It’s good the hear about your project and I am sorry to hear that the client would not buy into ControlDraw, I know this happens a lot, not just for P&ID’s either.
I do agree that ControlDraw cannot really produce P&ID’s like the industry is used to. It was never my intention for it to do so, in fact I started as you know from a completely different perspective – defining the automation.
But at the front end of a project as you have found it can do enough, for example for PFD’s and then basic P&ID’s for the conceptual and front end engineering project stages.
Now, if you start your project with simple P&ID’s such as those ControlDraw can do it provides a jump start that can be used first when you commit to CAD and secondly for the Control Engineering activities.
I still think that the P&ID document model is overloaded.

Where should the boundary be between Procedural Control and Basic Control?

2011-06-05T09:56:00.000-07:00

The intent of the standard is to at least in part to alleviate human error by automating the manual procedures that are common today, and of course to do so with a recognised framework so that there is not a proliferation of individualist solutions, and all systems and end users are able to communicate consistently.
A current question is "Where should the boundary be between Procedural Control and Basic Control?"
I think we should start from an operational viewpoint and consider where the Operator interacts with Procedures.
Clearly, when a procedure is being run by an operator it would be unfriendly to say the least if the system had no tolerance of delays in the operators response
Now, that to me implies that the Process should be in a stable state whenever an operator input is requested.
And I think it should apply even if the Procedure is running automatically, in effect replacing the operator.

So I propose that the following apply
Procedures steps that interface with Equipment should do so by via Persistent Process States - Where a Persistent Process State:
Is a State that is set entirely by Basic Control and that can be maintained without operator intervention
Can persist for a time, for example longer than the slowest operator response or until some resource runs out

When procedure steps request equipment to do something they can do so by sending a State Request
A State Request is much like a control loop's Set Point. The PID controller (a type of Basic Control) then adjusts control valves etc to keep a Measurement at the Set Point, or within some limits.
With higher levels such as Equipment Modules or Units, Basic Control Loops and Logic can run to move the process in the desired state and then keep it there, indicating so via an interface back to the procedure.

Procedures could set State Request in peer or lower level physical model entities
So, a Unit level Procedure may set the state of the Unit
Or it may set the state of Equipment in the Unit or of Control Modules in the Unit
They should never set the state of higher level entities
So a Unit level procedure should never set a Plant Area State or set the State of another Unit or an EM or CM that is outside the unit.

And for designing the Procedures it would provide a simple view without the complexity of showing the Module Logic

This shows how a procedure might look as a PFC

ISA106 procedures

2011-06-03T04:13:00.000-07:00

Thoughts on the emerging ISA106 standard. And S88 phases.

What can a step in an ISA106 procedure do?

Ask the operator to do something, from setting up equipment to entering data to confirming that a manual or paper procedure has been completed

Request equipment to do something for example run an equipment procedure or set equipment to a state

Set up something such as set points for control loops

Record some data

By the way that looks like just the sort of thing an S88 batch manager recipe procedure step can do - but of course ISA 106 people don't seem to like S88's' batchness' Comment please.

Let’s look at the second, asking equipment do something and setting equipment states.

What is the difference? If you ask equipment to do something then the equipment might do numerous things and then say Done.

If you set equipment to a state the equipment might still do several things in the process before it says State Established.

There really is no difference in terms of interfacing a procedure with equipment control, but the first of these may run a longer and more process oriented sequence - and in turn set the equipment to states.

Let’s call the 'Do something please' equipment step a phase (following S88 terms).

Because it is run in the equipment - ie by the BPCS (Basic Process Control System ) that controls the equipment , let’s call it an Equipment phase (or if you like an Equipment Procedural Entity) The Equipment phase itself runs a sequence of setting equipment states with transitions (cf feedback) to direct the steps and confirm that the process actions are achieved.

The Phase could of course set all the individual devices one by one (a common practise). Or it could set a state in a higher level physical entity, provided that entity can in turn set the lower levels devices.

That is what Equipment State Matrices are about – they are deployed in the Dow/ABB State Based Control paper (see Tables 1 and 2) and by most ControlDraw users - and they are highly advantageous. Why?

If you don’t know what they are you can look for them on google

They provide logic where all requested states are known easily. And as many states may be used more than once by different steps and even different by procedures they are more efficient. Alarms can be enabled according to the state matrix, Control loops modes set and so on.

In fact part of the Dow/ABB State Based Control paper is about this, and as I blogged before nothing to do with the S88 model where a recipe (cf procedure) speaks to the equipment. And I do mean Speak, since the objective of part 1 was in part to ensure that chemists (and their recipes) could speak to control engineers (and their equipment controls)

I feel that so far S106 is neglecting State Based Control.

Pharmaceutical Fermenter Equipment Modules

2011-05-22T10:16:00.000-07:00

I have recently been looking at ControlDraw models for large scale Pharmaceutical Fermenter Units from 4 different companies. Process wise, all the fermenters are broadly similar, but each client has their own way!
I cannot publish them because because they are confidential, agreements signed!

However I have summarised them using some statistics from the models.

Some differences are immediately apparent.

Why is the IO Count for Client 3 so low? This is because they do not use limit switches on their valves. This is something I have never understood as it seems to me that any cost savings would be obliterated by the downtime cause by the inablity to quickly diagnose valve failures.

Why do Clients 1 and 3 have so many parameters? I think that this is in part because they do not distinguish between critical parameters (that can be changed to define the product or CIP ) and other parameters

Actually the differences are greater than they appear, mostly because of different ways of handling routing and cleaning.
What they all have in common is Equipement modules for:

Agitator Control
CIP / SIP
Dissolved Oxygen Control
Exhaust Filter
Gas Feed
Inoculation Transfer
Media Supply
pH Control
Pressure Control
Product Transfer
Sampling
Temperature Control

Some of the models are Unit Centric (the EM's are driven to states by a Unit Level phase) and some are EM Centric where the EM's run phases in parallel with each other. The former approach is my preference as it results in less complexity

S88 Phase Programming for DeltaV

2010-10-26T04:54:00.000-07:00

With Emerson’s DeltaV and some other systems an S88 Phase is constructed around their version of the S88 “State transition diagram for example states for procedural elements.”

The Emerson structure uses Sequential Function Charts for each of the major state changes, such as that the Running SFC that goes between Idle and Complete. In addition a Fail Monitor evaluates conditions that cause the phase to go into the Holding state.

The diagram below shows an overview of this.

Now, there are other and in my opinion better ways of constructing the phases. For example a Phase could just have one SFC, but with Running Holding, Aborting, Stopping And Restarting logic all handled within the same SFC.

Actually it is quite possible to do that even using the Emerson structure, if you don’t slavishly follow the Emerson examples.

ISA 106 - a Simple Hierarchy diagram

2010-07-12T03:53:00.000-07:00

Just an initial proposal!

Suggestion for ISA 106 - The Production Run

2010-07-10T13:52:00.000-07:00

This ISA 106 Production Run overview diagram shows a suggested high level state model for a Production Run
A Production Run is a suggested new Term that covers the operation of a Unit or Process Cell from shutdown through Starting, Producing to Stopping and back to ShutdownThe Production Run
Click the diagram to see it full size

ISA106 - What is a continuous process anyway?

2010-06-05T09:08:00.000-07:00

You can read about the new ISA106 committee here. It is intended to develop standards, recommended practices, and technical reports on the design and implementation of procedures for automating continuous process operations.
One question this raises is what a continuous process really is! So let's look at a couple of real processes.

The first example is from the biotech world, the second from petrochemicals

Fermentation - there are some very large processes with fermentation at their core. Some use entirely batch whereby the fermentation is done and then the fermentation product is transferred downstream as a single batch. But there are others that run the fermenter continuously for as long as they can (many weeks) whilst periodically taking fermentation product out. Is this batch or continuous? They most certainly have recipes. And either way they spend a lot of time in a single controlled state that is essentially governed by control loops. I know of many such processes and both types use S88 oriented implementations.

The Unipol process. (A nice animation, note the batches appearing in step 6)
Much like the continuous version of the fermentation process this runs with a continuous feed but product is taken from the reactor in batches. Different grades of product can be made by changing the set points (recipe formula!) without shutting down. Is this batch or continuous? This process too spends much of it's time in a single controlled state that is essentially governed by control loops.

It is not really important. but ff the two, the fermentation processes I have seen are more complex, but in part this is due to CIP complexities. On the other hand the Unipol process has more complex control loops and higher level optimisation systems.

I suspect the petrochemical industry is right up 106's street and the biotech industry is not

So what will distinguish the sort of process (or is it industries?) that 106 is to be aimed at?
This is a key point that must be resolved at the meeting

Finally a note - there used to be a link to the Official ISA Part 5 Blog

But this is presently unavailable as controlengineering.com has closed. Supposedly it will return.

ISA106: Procedural Automation for Continuous Process Operations

2010-05-05T07:58:00.000-07:00

A new standard is being proposed, called ISA106: Procedural Automation for Continuous Process Operations
The WBF website provides a description of the forthcoming effort.

In the very early days of S88 Part 1, in October 1995 I presented a paper at the EBF in Dublin titled “Extending SP88 into continuous and semi-continuous processes.”

One point I made was that the Recipe operations for a continuous process are distributed in Space rather than time. So the sequence of process operations to make stuff happens continuously in a stream of equipment.

The essence of this is exactly the same as defined in part 1 for batch, so a continuous operation still carries out a process operation - A major processing activity that usually results in a chemical or physical change in the material being processed .

And in a continuous plant the ‘sequence’ is achieved continuously as the material passes through the equipment, whereas a batch plant carries out the sequence of actions batch by batch and may carry out many of the sequence of operations in the same equipment.

Since then I have further developed my understanding this to encompass how to make continuous processes (or discrete ones) exactly the same as batch..

The essence here is that the procedures needed to make a quantity of stuff or things as from the operation viewpoint can be identical for both batch and continuous.

This is predicated on the idea that the procedural operation of plants, whether batch, continuous or discrete can be the same. And that these procedures do not need to work real time – or at least in the time domain needed to control equipment.

Unfortunately (from an s88 purist’s point of view like mine) the procedural aspects of part 1 have been taken by many to prescribe a means of controlling equipment.

Now the concept of combining sequential control with state orientated control is a very powerful one, capable of controlling highly complex processes. But in my view these equipment sequences are not the same as the procedural level that puts together product independent equipment control to make stuff.

And I have never agreed that the procedural level as described in the original Part 1 was intended for equipment control. It was intended to provide the means to map equipment control to the operational procedures needed to make stuff. And no more.

But practise has not been that, and what we now have is a lot of systems which use recipe managers to perform equipment control - and I am convinced that this has been detrimental to many projects.

Now, referring to the Dow/ABB State based Control architecture I know it very well and I have in fact worked with Dow and Yahya to develop ControlDraw to support it even better than it used to.

But I do not believe that it is really S88 based, apart from the division of units into equipment modules (which by the way are not recipe aware) and control modules. The entire procedural level in the examples of this approach is missing, yes there are sequences to start up and shut down the equipment, but they are not in my opinion even phases as they do not perform process actions. For example, a sequence to start a distillation column is not a phase because it does not perform a process action, it just sets the column into the state where it can perform the distil process.

There is much more to say, for example about equipment requirements and routing etc. But I do ask that the ISA106 group consider what I am saying about the procedural level being an operational level rather than a control level.

What are all these Recipe Defer Functions for?

2010-04-21T11:25:00.000-07:00

If you are programming a Batch Manager, such as DeltaV batch or RSBatch, you will find yourself having to define the Defer Levels of Recipe parameters.

What is all this about?

Well, you can see some explanation on the DeltaV Books Online web site. And by the way Emerson, thank you for that excellent resource. And the explanation of the paints project shows well how to build a recipe in DeltaV.

The basic principle is that the value of a recipe formula parameter used in a phase can be set by a higher level, so that you can ultimately create a master recipe formula containing the settings and define a path through the procedural hierarchy that sets the required value in the phase and hence in the equipment control.
Now, there may be many, perhaps hundreds or more, parameters that are used in the entire collection of phases that are run for a batch, but the actual master recipe formula need only have a small portion of them.
A design rule might be to only defer parameters that have to change for different recipes.

Deferring a Recipe to the Recipe Procedure

Deferring a Recipe to the Unit Procedure

The actual process of defining the paths looks rather tedious, because (as I understand) you have to go through each level of the hierarchy, bottom up, deciding whether a parameter must be deferred, and furthermore if a parameter has to pass though multiple levels, then each level needs to contain the parameter - shown as Pass Thru parameters in the above diagrams. I can't help thinking that there must be a better way.
ControlDraw by the way allows you to link the top level parameters to the bottom level ones and then automatically work out all these Pass Thru parameters. Whether DeltaV would allow you to import these I do not know.

S88 overkill?

2010-01-21T10:19:00.000-08:00

An article in Food Engineering

Balancing Your Automation Standards - Cover Story - Food Engineering

One comment made in the article is

“I’m an ISA guy, but its S88 (for batch processes) and S95 (for continuous) standards are overkill,” asserts Rich DiBernardo, director of project engineering for Lecron Inc., Secaucus, NJ. “Projects that apply them never reach completion.”

Now, I think that is something of a misunderstanding of what ISA S88 is about, but it is understandable.

It is a misunderstanding because in fact the standard (part 1 at least) is only a guideline and does not say you must do all this, you can choose to exclude most of the possibilities in your own application.

But it is understandable because many 'S88' people push it too much, and furthermore they over complicate, seeming forgetting that the standard is supposed to make it easy for recipe designers.

What is your experience?

S88 for Continuous Processes

2010-01-18T15:49:00.000-08:00

There is a new article on ControlGlobal

ISA-88 Works for Continuous Processes Too
Using ISA88 Principles to Address Procedural Operations in Industries Outside the Traditional Batch Realm

But it has no opportunity to make comments on it, so I will blog it.

S88 for continuous processes has been a topic for years.

This article says, "A procedural operation is a set of tasks conducted the same way time after time to achieve a certain goal"

Well, that is not actually the complete story - why? Because it misses out the batch.

And there is always a batch. Even in a continuous process.

I have commented on this before, look at the continuous tagged entries in this blog for more.

Where is the Batch?

2009-11-26T16:27:00.000-08:00

Continuous and discrete processes can be used to make batches of stuff or things. That is the key to using S88 outside of batch processes! There is always a batch!

Is this the most misunderstood aspect of S88? It is not hard to understand at all:

A Continuous process can make a batch by running for a period of time with a set of recipe parameters such an Flow, Pressure, Temperature etc

A Discrete process can also make a batch - in this case a quantity of the items it makes - by running for a period of time.

Information flow from general recipe to equipment entity

2009-11-18T05:14:00.001-08:00

The latest version of S88 has this diagram in it.

It is a nice little explanation of how a recipe maps to equipment. It really does not say anything that the original standard does not, but it does provide a different viewpoint.

There was an surprsingly long debate about how the Equipment Procedural Elements should be shown, should they have Start and End elements just like the Recipe Procedural Elements or not. The thinking was that the start and end implied that the bit in-between might be taking part in a sequence in the equipment, when really it is not.

I liked the idea, but also accepted that the EPE must have a start and end.

Furthermore there is a meaning to these icons, differentiating between where they exist.

So I have played a bit with the diagram - click to show full size.

Equipment Modules in Equipment Modules

2009-11-12T10:39:00.000-08:00

As you all know S88 Part 1 supports Equipment Modules in Equipment Modules as indicated by this in the latest draft update.

I cannot at this moment think of one and nobody has ever shown me a real case that justifies it – if you know different Please Let Me Know. (You can comment here or email us.)

What I have seen is Equipment modules containing some sequential logic. But these are not phases that really perform Process Actions as phases should – I don’t rate sending a set point or prompting an operator as a Process Action by the way.

(I have also seen Common Resources implemented and Equipment modules and then containing equipment modules, but in those cases the Common resources were more like Units.)

Whenever I first review an S88 functional specification I look for this by the way. (If the functional specification is a ControlDraw model it takes about 10 seconds with Word it can take hours).

It is very rare, and always arguable.

Now, I think S88 would be greatly simplified and the implementations improved if the ability to have Equipment Modules in Equipment Modules was removed.

Of course you can do that yourselves when you do an S88 modularisation and without straying from the standard – and I highly recommend that you do.

S88 Part 1 Revised

2009-11-02T04:33:00.000-08:00

As you may know from this, a new version of the ISA S88 Part 1 standard is out for vote. Will you be voting?

Now, speaking for myself, I would not like the revised version to be thrown away, there is useful stuff there. ButI would only like to see it published as a supplement to the original.

But please, don't make the Revised S88 Part 1 replace the original.

And of course it should be free, as should the original but that's another issue.

For me, the revised version adds little to the original, it does not make it simpler and it does not resolve some problems that have been evident since the guidelines were first published.

The revision has been prepared by a group of people that is smaller, less international and has a narrower perspective than the original team.

Much of the 3+ years spent revising the document have been spent re-arguing original issues and indeed re-learning what Part one really said.

I was to my delight accused of being an S88 purist at one point during the debate. I don’t think it was tended as a compliment, rather as a means of dismissing what I was saying as being eccentric.

The ‘standard’ is not a standard – it is about terminology and guidelines based on good, but not definitive models.

For me, the clarifications do not clarify, the diagrams are not improved and the models have only been restricted – that is not a good thing.

Most especially the revisions do not further the objective of making it easy to create recipes, and they do not help to improve control software.

Problems not resolved include:

What Recipe Equipment Requirements really are and how they relate to real equipment.

How Batches can be defined for Continuous and Discrete process

Actually I think all the problems are easily accommodated with the original, if you interpret it ‘Purely’. And avoid trying to use the procedural model in the physical domain.

S88 and Continuous plants

2009-09-29T16:06:00.000-07:00

S88 Batch procedures carry out an ordered set of process operations on a finite quantity of stuff, batch by batch.

This ordered set is called by Part 1 a Recipe Procedure. It can be represented as a sequence of operations in time, typically by PFC/SFC logic .

A sequence of operations may take place in one place (or Unit) or different stages may take place in different units.

Note – this implies transfers, which S88 carefully does not attempt to explain.

Continuous production also carries out an ordered set of process operations, however the quantity of stuff is not finite, instead it grows in time, and more than that, most operations take place in Units that are specific for the operation, the chemistry happening as material flows through the unit.

Thus, the recipe procedure for a continuous process may well be represented as a process flow sheet - without the need for a PFC. And, actually the transfers are then implicitly described.

By the way, yes, PFC’s or SFC’s may be a good way to describe startup and shutdown and grade changes, that does not mean they are Recipe Procedures!

I have before suggested that Part 1 needs what I call a recipe equipment entity model, to underly the equipment requirements that are part of the (master) recipe.

I also suggest that the recipe equipment requirements are best described by a process flow sheet. This works with both batch and continuous.

The recipe view of the equipment should be generic, in terms of types of equipment, whereas the physical model must contain one or more of each of the types required by the recipe.

Where I seem to disagree with the work being done to “improve” Part 1 though (and this is compounded by the emerging Part 5) is that the procedural model is not a good model for actually controlling equipment. I think that State Based Control (check the tags on this blog) is a good example, it simply does not fit conventional S88.

There are ways in which Continuous process can be made to look like batch ones from the scheduling point of view, or even the broader point of view of an ERP or MES

In fact it is quite easy.

ControlGlobal's Process Automation Usability Project

2009-09-14T03:41:00.000-07:00

Recently ControlGlobal.com has created the Process Automation Usability Project, it is an interesting read, with ongoing discussions on Planning, Design, Implementation, Operations, Maintenance, and Security.

It is well worth reading or better still taking part in, so I have added it to the Automation Links on this blog.

Part 1 update - what has changed

2009-08-31T08:42:00.000-07:00

Marcus Tennant has produced an excellent summary of the changes between the latest draft of the updated S88 Part 1 standard and the original.

It must have taken him a lot of time and I have no problem with it.

I do however have a problem with the proposed update itself.

Here is a small example, it shows the proposed changes to the physical model.

Now as far as I am comcerned, the original version, on the left, is elegant and clear whilst the update is frankly a mess.

And the value added is zero.

How do standards evolve?

2009-08-08T16:14:00.000-07:00

I was thinking again about the S88 standard and how it is developing, and the results that we are seeing. That led me to wonder, how do standards evolve?

So I thought that some research was needed. And I have searched a lot, and one noticeable thing about the results on various search engines is the association of standards with law.

Things like metric and imperial, Whitworth and so on are measurement systems and physical and science based. Even if they started with the distance between Napoleon's nose and his finger tip, allegedly. And so De facto standards arrived. Eventually they became consistent, via such thing as the System International (Three nations have not officially adopted the International System of Units as their primary or sole system of measurement: Liberia, Burma and the United States.)

Others like ASCII and perhaps html are language interpretations.

What about Fieldbus or, say Betamax versus VHS ?

Here, competitive companies produced competing standards, and the result became De facto standard.

Some such as XML, maybe UML are somewhere between De Facto and Science based - or at least they involve a lot of meetings.

When we come to Automation is it apparent that the ISA (For me still the Instrument Society of America) that now appears to be the leader in setting the standard.

But I actually think that it is missing the competitive element. I could argue that they should leave the domain alone until a De facto standard arrives!

What's in a Process Cell

2009-07-15T16:39:00.001-07:00

There is currently much discussion about what a Process Cell is as you can see on the Part 5 blog.

As I view it, a Process Cell:

1- is the domain within which batches can be made according to a recipe.

2- contains the collection of equipment (units, and equipment modules) that meet the equipment requirements of the recipes that can be produced in the cell

That is I believe what S88.01 says, but in different words:

S88 (original and latest draft) says

A logical grouping of equipment that includes the equipment required for production of one or more batches. It defines the span of logical control of one set of process equipment within an area.

NOTE - This term applies to both the physical equipment and the equipment entity.

But this really does not define the boundaries of a Cell in the way that we like to put boundaries around Units for example. Why not make an entire plant a process cell? Of course, a cell lives 'in an area' .

So might be that the boundaries of a Process Cell are arbitrary provided they meet the definition.

I have seen several large plants where there are dozens of Units in the Process Cells, and have worked on projects where there were only a few. Why? Because of repetition - if you have many similar units it makes sense to put them into the same process cell because they can run the same recipes. And Recipes execute in Process Cells.

But as Part 1 also says Logical Control

Is that Logical as in mathematics? Or as in intuition?

From the Intuition point of view, it just makes sense to have say solvents handing in a different process cell to reaction doesn't it? Is that enough?

But how about Logical Control? Are we talking about basic control logic - or Procedural Logic?

I think we can forget basic control here so can we somehow make a logical choice based on the Recipes? And one that generally agrees with the intuitive one? I think so.

It depends on finding the Batches, Equipment Requirements and the Routes.

Start by asking where are the batches? If a batch comes out of one unit, and then joins with other batches so that the downstream units are working with bigger batches, or conversely where batches are split up so the downstream units are working on smaller batches then I would have two process cells. In the case of say a plant with feed storage vessels then bioreactor units then intermediate storage then filtration units then product storage I would have something like Feed storage process cell bioreactor process cell intermediate storage process cell filtration process cell product storage process cell And by the way I would call the storage vessels Units.

As for the connectivity, what I mean is that all the euipment in a single Process Cell should permit the transfer connections needed to assemble the instances of required equipment for the Cell's Recipes.

AutomationML and ISA88 Part 5

2009-06-11T03:33:00.000-07:00

According to Wikipedia, AutomationML (Automation Markup Language) is a neutral data format based onXML for the storage and exchange of plant engineering information, which is provided as open standard. Goal of AutomationML is to interconnect the heterogeneous tool landscape of modern engineering tools in their different disciplines, e.g. mechanical plant engineering, electrical design, HMI development, PLC, robot control.

Now, this looks to me to be covering much of the same areas as ISA88 Part 5 is attempting to deal with, in fact possible more. I suggest that the people involved in Part 5 should spend some time investigating AutomationML.

AutomationML is clearly coming from the European side of the pond (ok mostly Germany), whereas Part 5 is largely from the USA side.

I would really like to see something that explains how they relate to each other and whether there are synergies or indeed if they are competing.

DCS or PLC and Systems Integrators

2009-05-25T10:13:00.000-07:00

As I mentioned in the last posting, there can be further reasons why a DCS solution may be better, for example the maintenance of the PLC/SCADA systems may be more involved because they all have different software architectural designs, no two SI's seem to do it the same.

Or the long term viability of an SI - and they are vulnerable - puts a client off compared with the stability of the DCS suppliers.

How can the SI's overcome these issues? At present they largely compete with each other.

What if all the SI's in the CSIA shared their designs?

and used identical documention systems?

and even shared their module libraries?

Then it would be easy for projects to be handed over to another SI if needed.

I think this would help the PLC/SCADA suppliers as a whole to compete with the large DCS suppliers, it could even put them at an advantage over the DCS suppliers.

Is this feasible?

I think it certainly is regarding the documentation systems - and I don't mean word processing, but by using object models, perhaps according to ISA S88 Part 5 - or of course ControlDraw models.

Now, the CSIA has developed some standards, such as CSIA’s “Best Practices & Benchmarks” Revision 3.0.1. This is an excellent document for both end users who want guidelines on selecting an SI and for SI's themselves to review their own business processes. But it is not a standard design.

And by the way, the CSIA is predominately American, few European SI's belong to it, so if you are looking for non US suppliers you need to look elsewhere. Your local PLC suppliers such as Rockwell, Siemens etc will be able to suggest a few.

DCS or PLC?

2009-05-25T08:28:00.000-07:00

This is a topic that has been discussed endlessly over the years ever since there were DCS’s and PLC’s with SCADA on top.

Back in November I noted a great article, do PLCs Eliminate Need for a DCS? on Automation.com that sums up the differences well. It does so from the point of view of the pro DCS Camp, not surprisingly because it is essentially a Honeywell interview.

Refreshingly though, it does not promote Honeywell over other DCS’s and just presents many of the core arguments that all DCS suppliers present. They are well presented good points

DCS's have succeeded for a good reason. They were the first to encapsulate things like PID control, and emulations of control panels. And the PLC people encapsulated relays and won the discrete market.

It would be good to see the other side of the argument presented equally impartially, no one has done so in response to that article, so I am having a little go. It may be because the suppliers of PLC/SCADA systems are more numerous but smaller, and none has the time to present the argument. Perhaps this is something the CSIA (Control Systems Integrators Association) should address.

So, lets looks at the core issues
"Today with open technologies, DCS systems are competitively priced with PLCs."
Maybe – but it is not my experience for the Hardware. This may well be true if the engineering is less, but that is another topic – the next one.

"Simply taking a PLC and adding an HMI and database on top of it requires a great deal more engineering to accomplish integrated control..."
I am one of those who has in the past been responsible for such engineering, and I don't quite agree with the term 'more engineering'. Better maybe, more is dependant on the application. Sure DCS’s are still far and away easiest for plants that have control loops and little else, such as refineries and the continuous chemical industries. And you would never use a DCS controller for fast machine control.
But it is that huge area in-between that the paper suggests is now DCS territory. But there are many case where PLC/SCADA still prevails. The food and beverage industries such as brewing and diaries are good examples.

And I am well aware of projects in the past where the engineering has taken far more that expected, even where a DCS was being used.

Why is configuration better than programming?
First it is highly a debatable point. Much of a SCADA is configured rather than programmed, and no configuration system exists in DCS's for complex sequential control for example.

Also, programming is not actually a bad thing, provided they are designed well, systems with programmed rather than configured applications can be better. This is because there is much more flexibility of design resulting in much less compromising of the functional requirements to fit the standard system.

Other points include:

Future growth

This is disputable as probably the largest (by IO Count) systems in the world are PLC based.

For example many food manufacturers have huge systems.

Need to make changes frequently

Of course if the application is well engineered such changes should be rare. New recipes should not require program changes for example

Integration requirements

Again, at least in the past it has long been easier to interface to other systems.

Even now DCS interfaces are often implemented with ModBus, and where did that start? PLC's!

Fault Tolerance

I think PLC's may have caught up here

The PLC vendors still seem to be struggling with trying to get all the parts and pieces to work together seamlessly.

Really? This may be true from the point of view of a small PLC/SCADA Systems Integrator competing with a large DCS supplier to win a project. But I think this is not a technical issue, rather one of the nature of those two types of supplier

I am convinced that the results using a well designed PLC/SCADA can be far better than using DCS canned functions. Not only in the result, but in the time it takes to write the software, the user interface, the scan time for the program to execute, and the hardware cost.

I could add further reasons that a DCS may be better, for example the maintenance of the PLC/SCADA systems may be more involved as they all have different software architectural designs, no two SI's seem to do it the same. But I will cover that in another blog soon

Automation objects and State Based Control

2009-05-19T01:55:00.000-07:00

State based control is a method of defining the required states of some equipment and then driving the equipment to one of these states, typically where a Phase step sets the Equipment States.
It is an excellent way of describing the required behaviour of an Automation Object, or at least what I think of as an automation object. But I cannot relate it to Part 5 as it stands.
In essence designing a state controlled automation object involves in a large part determining all the required states that you need to set that object to. Please note that these States are not comparable to the Part 1 or 5 'Procedural States', they are things like Open, Closed, Ready to Fill, Filling, Reacting etc.
ControlDraw has long supported this method because it provides a very efficient method of representing functional requirements. And consequently over the 10+ years of designing systems with ControlDraw I now have designs for hundreds of these. You can read more here and here.
They range from basic control modules like motors and valves to highly intricate units, such as BioReactors, semi continuous sterilizers etc.
And looking at these, they have never needed to contain Resource Management. Yes they may have properties that relate to Resource Management, but always the actual Resource Manager is outside them. The lower level ones such as PID Controllers, are contained in Equipment Modules or Units, and the Resource Manager does not look at them, it only deals with the higher levels.
This is one reason for my objections to Part 5 as it stands. But please understand that I don't want to spend my time complaining about Part 5, I want to contribute positively.

As it stands, I cannot. I think it should be completely re-started or abandoned.

Equipment Modules or Control Modules, which are cheaper?

2009-03-31T16:22:00.000-07:00

I heard a good one today. I had emailed the State Based Control paper to a customer asking why parts of their plant model did not have Equipment Modules, perhaps on the lines of those in the SBC paper. I got a very good answer, part of which was that all the operational aspects in those areas are manual SOP guided. And that maybe some procedural control will be added when they understand better how to run the equipment.

But another aspect was that they get charged more for more equipment modules.

Now, I have been looking into the complexity of systems, and hence the time it should take to program them. And part of the point of using Em's is to reduce complexity.
So I suggested that as they do not have to run phases ( just like those in the SBC paper) call them Control Modules!

More on State Based Control

2009-03-30T07:17:00.000-07:00

I spent a lot more time going through the ABB paper on the benefits of State Based Control

And in order to understand it better I have spent some time turning their example into a ControlDraw model. It was very interesting, first finding how easily the example can be modelled (using standard ControlDraw features such as Equipment State Matrices) and how similar the ABB/Dow method is to the way ControlDraw can handle such requirements. One example (of many) is that ControlDraw supports what you might call cascaded State matrices, where the state in a higher level matrix (for example a Unit State) sets the state in a lower level one such as an Equipment State.

Please note - I do not mean the states like Starting, Holding etc in S88 Parts 1 and 5, I mean states like the ones the paper uses like Total Reflux, Empty etc. Well done ABB.

I also looked at some models in my archive where I found examples of Units that have 50 or more states and 20 or so equipment modules as compared with the 9 states and 6 EM's in the paper. Some of these date from 2001. So it really is not new. But nonetheless it is good approach, and as my examples show it is also highly scalable.

The paper says

"One last benefit of SBC is that it is an implementation of process control based on the principles outlined in ISA S88 Part 5"

I cannot see that at all. If anything the paper presents something better than Part 5 has offered, but it is really quite unrelated. I cannot either find any indication that ABB has been involved in Part 5 - I may be wrong, but if I am right, please ABB get involved, and don't make such statements for the sake it of it.

One negative - a detailed review showed how poor the spreadsheet examples in the paper are.

The problem with using spreadsheets for this kind of application are numerous. Typical problems include:

Complex formatting, which while it may make table look pretty actually makes it very difficult to extract the data, for example to help with generating the application.
Multiple lines in the same cell are often a problem
If a tagname changes then there is a lot of work to correct the spreadsheet
You need a spreadsheet for each Unit, and there is nothing to handle higher levels like process cells

Of course these problems disappear if you use ControlDraw !

By the way, the same paper is now available from Automation.com, and you do not have to register.

S88 Part 1 update progress

2009-03-26T09:20:00.000-07:00

The Update to Part 1 is apparently late, it has taken so far 3 years when it should have been done in 2, and there is still a lot of disagreement.

S88 defines hierarchical recipe management and process segmentation frameworks, which separate products from the equipment that they are made in, we all know that don't we?

But I am starting to wonder if the people working on the new version actually understand what that means.

Why do I say this? Well they are persisting with their extension of the Procedural Model into the Equipment, so now they propose, for example, that the Recipe Procedure and Equipment Requirements can be passed to the equipment and that the equipment can contain the procedural hierarchy.

In my opinion this is completely the wrong approach, and it will ruin Part 1.

I really believe that they are confusing Controllers such as PLC's in packages with Equipment. And I can understand that, but I think there is a way round it.

I know that the team has been working hard to improve part 1 and there are no doubt some good things they have done. But that will all be undermined if they continue to follow their present path.

I got some good background from Lynn who was the one who managed to get the original Part 1 published, I won't quote all that he said, but here are a couple of points

I think the basic mistake we made in “part one – the original” was that we drew the diagrams that show interaction of the recipe with equipment control at multiple levels wrong. We took the correct base case (recipe phase references equipment phase) and simply expanded it without coming to grips with what those things we offhandedly labeled “equipment operation” or “equipment unit procedure” above the equipment phase really are. Once we all accepted the flawed diagrams we were stuck with that mode of thought and have been trying to explain how that works conceptually – and when we really try to do that it seem we really can’t.
How did we get into this twisted solution? It was pretty easy. We knew we had a master recipe and that it needed to turn into a control recipe to make a batch. So far, so good.
We also knew that the master recipe needed to be able to direct the equipment at more than one level.
Why? Well there are two pretty good reasons why this flexibility could be needed. First it is possible that someone has invented an operation or a unit procedure that doesn’t subdivide as Paul has pointed out. Secondly, we may just want to create the master recipe based on higher level procedural elements even though the equipment procedural elements the control recipe needs to address is an equipment phase.

Lynn has much more to say, such as

we were so taken with the genius of our hierarchy (it really is pretty neat) that we thought everyone should really use all levels of the model if they want to do the job right. In most cases that is still not a bad idea. But forgive us, we couldn’t stop there. We – in our zeal – had to indicate to folks building packaged equipment that they really need to build these things in a modular way even if we don’t need to actually see anything below the operation or unit procedure level. Thence cometh the diagram that shows the control recipe interacting with the procedural control of an equipment entity at the unit procedure level (or whatever) and – again in our zeal – we included the lower level parts of the hierarchy that we really thought people ought to know we thought they ought to build in

.And

The huge mistake we all bought into and that has affected our thinking ever since is that the diagram showed the control recipe connecting to an EPE at the unit procedure (or other) level when it was the master recipe that was really our concern

So it looks to me like like the update is just compounding rather than fixing a mistake.

I think they should make it absolutely clear that Equipment Control involves only the logic etc that actually connects to equipment. This of course means basic control but also the phase(+) logic that directly speaks to basic control.

As ever comments are welcome.

State Based Control

2009-03-24T02:52:00.000-07:00

There is a new White Paper on ControlGlobal.com called "The Benefits of State Based Control" written by David A. Huffman from ABB

Walt Boyes calls it a "very important white paper". It is quite good and I recommend readers, specially those working in the Continuous process industries, to download it. You have to register with ControlGlobal to get it, but that is worth doing anyway.

The paper does not claim that SBC is new, and indeed it is not. In fact SBC - or something very similar, has been the basis for a lot of ControlDraw models since CD was first introduced, in the mid 90's, and that itself was based on previous paper based ways of specifying State Based Control.

And in turn these models were often then implemented using SBC, and on a variety of systems.

The paper also suggest that implementing SBC is something that ABB with it's 800ax system has removed barriers to. That may be so, but the paper is short on details. Interestingly one of the systems that CD models have been used to specify (and frequently) is Sattline, now owned by ABB themselves. A little known fact is that 800ax is a direct descendant of Sattline, a system that can probably claim to have been the first object oriented DCS, it has been around since the 90's.

One thing the paper mentions is ISA S88 Part 5, but I cannot really relate the paper to anything in Part 5.

Equipment Procedure or Recipe Procedure?

2009-03-10T05:16:00.000-07:00

I see that the latest draft of the updated part 1 spends a lot of words on Equipment Procedural Entities (Phases, Operations, Unit Procedures)

I think that this results from the idea that the recipe to equipment boundary is the same as the boundary between a recipe manager and an equipment controller.

My take on this is that if the 'equipment controller' has the capability of containing higher level procedures such as operations that do no more than sequence lower level ones such as phases then this means that the controller is actually performing some part of the recipe control. And as such this is not equipment control.

If this concept were adopted, then the entire standard could be greatly simplified, and I think without losing any value.

I propose that the only function that an Equipment Procedural entity can perform is one that actually directly controls(or directs) equipment, for example a phase that sends commands and responds to to basic control.

For a bit of background on this, when I first had ControlDraw working properly, soon after the introduction of Version 2 and the object structure that exists to this day I dithered about whether there should be a separate Class for Equipment phases and Recipe Phases.

I decided not to, as I found that the only difference was in their owners (in ControlDraw that is the Parent object that links to the Phase diagram.)

So, if you have a phase in a Recipe procedure that is not also in an Equipment item then it must be purely a procedural phase, if it does exist in the equipment then it is an equipment phase. If in both then it is still an equipment phase, but is referenced by the corresponding Recipe Procedure phase.

Why the procedural hierarchy in Equipment?

2009-03-02T07:15:00.000-08:00

There seems to be an assumption that equipment procedures must themselves preserve the procedural hierarchy, so if you have an equipment Unit Procedure, that must itself be made up of phases. However I submit that this is not a reasonable assumption, because it makes the recipe have to dive into equipment control when there is no need for it, at least if we are going to preserve equipment - recipe independence.

If you can code a unit procedure in your controller that looks to the recipe like a unit procedure then that is all you have to do, S88 is not a standard for writing control software and should not try to be, that is stated in the standard.

If on the other hand you really want Recipes to reference Unit Procedures or Operations that are designed in your recipe procedure but implemented in the equipment, then I say that this means that you have a recipe controller in your equipment. This contradicts the concept of product independent equipment – I think it is part of the misunderstanding (or at least an alternative understanding to mine) of the original part 1 that the update is now perpetuating

Yes, I can see the need for being able to pass equipment requirements down the levels in a Recipe, but not to pass them across to equipment control.

And I can agree that equipment phase+ control might benefit from structuring into levels, to improve controller code. But hey, real time PLC and DCS control – the sort of thing you use IEC1131/3 languages for is not like recipe control.

Who needs the Transient Procedural States

2009-03-02T07:10:00.000-08:00

I always work on the principle that the recipe controller (that handles the control recipe) is a transaction based sequencing and data handling system. It can tolerate short delays. It is in effect the process operator; it cares little about the equipment provided it can do what the recipe asks of it. It can request the equipment to do some process action, then wait until it has.

Basic control that drives the equipment is real time and cannot tolerate such delays.

The original Part 1 provides a lot of suggestions and some basic models that help to specify both the recipe and the basic control. And it shows how they can meet, via Procedural Entities.

To interface the control recipe with the equipment, there must be EPE’s (Equipment Procedural Entities), typically phases, that actually execute the process action.

But think about this – why should the recipe control have any real time capability other than being fast enough to avoid introducing significant delays?

If something happens that requires a quick response then it should not have to require data to propagate up and down the procedural levels of the Control Recipe, that will be slow (and I have seen this cause problems,) and anyway it complicates the recipe procedure.

So, this leads me to my first objection to the Procedural State Transitions, and their extension in the Part 1 update and in Part 5.

Yes the Control Recipe may need to know whether an Equipment phase is running or complete but why does it need to know about Pausing, Starting etc?

Why do these transient states need to be exposed to the recipe?

For example if we are running an equipment phase, as far as the world outside that equipment is concerned it is surely not of any value to know whether the equipment phase is Pausing or Paused. Once it is pausing or paused that is all the control recipe needs to know until it is running again. What the control recipe is supposed to do with that information is not defined – propagating modes to other objects maybe, but that should be only what is reasonable in Recipe Control – the real time stuff should be down in basic control.

And I suspect that the transient states are really about the real time world.

A word cloud from the original Part 1

2009-03-02T06:42:00.000-08:00

I pasted most of the part 1 text into Wordle to generate this

There are Simultaneous Equipment and Recipe procedural elements

2009-02-25T13:53:00.000-08:00

This was recently stated on the Part 5 Blog
"In some cases it may be sufficient to allow the recipe phase to directly control the equipment modules. In other systems where complex equipment modules exist, it may be necessary to implement some level of state model based procedural control in the equipment between the recipe phase and equipment modules in order to better deal with the underlying equipment complexity. Again, it’s an implementation decision left to the developer and thus does not restrict creative efforts."

I don't agree. The Equipment Phase must exist 'in' the equipment. Allowing "the recipe phase to directly control the equipment modules" is not a concept I can subscribe to.

I am assuming in the following a phase level interface for simplicity, but it could be Operations or higher.

The Recipe Phase is that procedural control that speaks to the Equipment Phase, it may just be one step in an operation, which interfaces with the Equipment Phase but does not actually control the equipment module (or Unit) - that is the job of the Equipment Phase. But in my view (and others) both the recipe phase and it's corresponding Equipment phase exist

To further illustrate, suppose we have a PC based batch manager executing the Recipe Procedure (so the PC is the recipe controller) and it speaks to the equipment controller (eg PLC or DCS controller) then the Operation and its steps and Transitions are coded PC, whilst the steps and transitions in the Equipment Phase are coded in the Controller.
These corresponding phases speak to each other via a Phase Logic interface and some data transfer such as recipe parameters

Now, it may be that there are applications of PC Batch managers where some of the equipment control steps and transitions are coded in the PC. That just means that the recipe and equipment control are not nicely separated in the implementation, but they still both exist.
And the S88 standards are not supposed to be about actual implementations, just the concepts and models.

S88 Working Draft 5 Version 4

2009-02-04T03:12:00.000-08:00

This seems to be an incredibly complicated document with no explanation of the reasons for it, or the rationale behind the various concepts that it tries to present.
Why do Automation objects need to contain Functional Manager or a Resource Manager?
A PID controller (a good example of an automation object) is something that has been in existence for around about a century, and it never needed such things, what is the reasoning behind making it so complicated?

Some internet travelling experiences

2009-02-04T03:10:00.000-08:00

I know this blog has been silent for too long, I have been travelling, in fact I still am, this comes from New Zealand, where the connection is excellent. I thought I would share some internet travelling experiences:
The Motel in Brisbane that advertises Free internet.
On arrival the person in reception asks for your laptop and then types in the password, taking care to prevent the password being saved. When you close your laptop lid and it shuts down or hibernates the password is required again when you restart.
Reception closes at 8pm (I immediately cancelled my reservation and moved out when I found this, fortunately before 8pm)
The Hotel in Sydney that charges $30 (AU) per day
The hotel that has a third party that provides WIFI. The signal is strong, but the performance is unusable, the third party, (Jimojo.com), said that there was no problem with their systems. Ha !
And finally using the internet with a mobile phone connected to a laptop via Bluetooth. I can tell you that at least with VodafoneAustralia it works well. But can you believe £10 per Megabyte. That means it can cost about £1000 per hour. At the same time you can get 5Gbyte per month for about £20 if you have a local account. Legalised robbery

The Next WBF topic

2008-12-08T14:47:00.000-08:00

I see that the next WBF is dedicated to “Expanding the horizons of manufacturing”.
That leaves plenty of scope in North Carolina I guess. I was going to suggest "Manufacturing models for a Sustainable future", maybe for the the next one. Or perhaps it fits in with expanding out horizons, so I hope those who are currently working on their presentations for the North Carolina conference will consider the issues in their papers.
I know that we are in a global economic crisis, for maybe a few years. Economic models have long process lags. But the process I am talking about when I refer to the future is much slower moving. And it is one of the areas where those involved in manufacturing can help, from minimising energy consumption to using sustainable resources. Even a control module, such as an agitator or pump can be controlled in ways that save energy, higher up the levels more can be done. I am sure that the forum can find many people with great things to say on the topic.

WBF Barcelona

2008-11-27T05:25:00.000-08:00

The Barcelona WBF was good, it was well organised and of course in a lovely city and even the weather was fine. There were people from 23 countries there. I met many people that I have known for years from previous conferences and working with some of them and also made new friends.

And I was presented with the Guido Carlo-Stella Award, which I am very pleased about, thank you all. I remember Guido from the early years of the EBF.

Much of the conference was oriented toward the S95 domain and Manufacturing Excecution Systems. It is challenging to absorb so much information- 25 papers - in 2 days, so I am reviewing the papers again in my own time, and refreshing my knowledge of S95.

PLC is 40 years old!

2008-10-22T15:03:00.000-07:00

The PLC is 40 years old, time flies, I first saw one when they were maybe 5. In fact I learned much of my Batch control by programming PLC's. That is where control happens, in the controllers, surprisingly enough.

While I may have complained that the WBF does not have enough about Control I had not looked though all the papers presented at this years USA Conference. (It is worth joining the WBF for this alone by the way, some are gems) and found one on implementing recipes in a PLC, by Igor Steiner, Janez Tancek, Marko Svetina at INEA d.o.o.

I hope they won’t mind me quoting a bit from their paper

This is about PC based recipe managers versus writing your own in a PLC

Pros:
High level of abstraction for complexity management
High flexibility&reusability
Rich functionality

Cons:
Unsatisfactory reliability of the PC platform
Poor adjustment to small and medium projects
Unsatisfactory time behaviour of the PC platform
Too low expressive power of phase behaviour mode

An interesting comparison, I generally agree. The Too low expressive power point is one that I think might be based on an over optimistic view of what a Recipe Phase has to do, for me there is very little it has to do apart from starting and monitoring the execution of an equipment phase, via a phase logic interface. I don’t even believe the ****ing states (such as Pausing!) should exist in the PLI, why does a recipe care about that?

The programming of the equipment phase itself of course can be done in the process controller, PLC in this case, and there you can do what you want using the power of PLC instruction sets, which have high expressive power.

The paper also describes the Concept of Tabular Recipes on a PLC, nothing new, to my knowledge something similar was done in Wigan in the mid 80’s using Siemens S5 PLC’s, but worthy all the same. There is by the way a popular misconception that S88.01 revolutionised batch control, I think that makes the point that it did not. It helped to specify it though, I agree with that, and it raised understanding of the issues.

PS - in fact Tabular recipes have existed in ControlDraw for many years

WBF Barcelona

2008-10-20T09:01:00.000-07:00

I case you are wondering, I shall indeed be going to this event, I am looking forward to it.

See you there I hope.

Alarms and Equipment States

2008-10-13T14:34:00.000-07:00

How many reports on hazardous incidents have you read about where the alarms presented to the operators were excessive and the resulting confusion contributed to the incident.

I was reminded by this article

Why Is Safety so HARD?

The problem has been known and understood for decades, and now we all know that alarms should be suppressed when they are not relevant, and that when they are they should be prioritised.

But engineering a solution is time consuming and expensive.

The solution has to be specified, reviewed and approved, and maintained as operating experience is gained and the solution is modified, via an approved change process of course.

Typically these are described by text, cause and effect matrices and logic diagrams.

Mostly the cause and effect matrices describe the responses to potential hazardous events, such as process upsets. The matrices do not often cover the alarms, although some do mention them typically in notes. Some control system actually support Cause and Effect matrix based design, and can translate them into control logic. For example Siemens has one

These are much more constrained than the typical excel version that people produce.

Using a state model provides a highly efficient way to define the enabling of alarms. The safety system, as a complete entity is defined in terms of possible states, a method that vastly reduces the number of states that have to be considered.

Then each possible alarm can be considered for it relevance in each state, producing an Alarm State Matrix.

ISA–TR88.00.02

2008-09-20T16:30:00.000-07:00

Dave Chappell's blog reports that "much anticipated Technical report from Make2Pack" is now available, on the Part 5 blog and indeed subscribers were sent a copy, which I have been perusing.

It is a good document, but not a lot to do with S88.

I did much more than lurk on the postings, I spent many hours reading drafts and making comments about it, to try to align it with the real Part 1, and I took to using the phrase ~Save the Batch during the debate. It got quite intense, and at one point I was told "Better keep looking over your shoulder …the S88 police are coming!"

Needless to say that did not deflect me.

I think that I changed it in several respects - challenge is essential.

I objected initially to calling a machine a Unit as in most respects machines are little more than control modules, albeit complex ones (but only internally, not for the recipe).

I accepted that they could be called Units because each machine in a filling line might be processing a different batch, thanks Dennis for reminding me of that and the parallel with continuous processes.

I did not accept that terms such a unit procedure or phases should be used in the report, as they were originally, and they are not there now.

S88 Graphics

2008-09-17T03:38:00.000-07:00

I have seen many automation system HMI's. Often the process graphics have been produced based on the P&ID's. But P&ID's are not normally a good basis for graphics as they are not designed for operational purposes. Using the S88 Hierarchy can be much better.
There is at least one plant where the S88 Physical Hierarchy is used as the basic for the HMI graphics structure.
I believe this is a good structure, not only because it makes for simple uncluttered graphics but also because it exposes the S88 modules of a system to the operators.
Here is an example
The Plant overview shows a graphic that contains several Process Cells
Clicking on a Process Cell object opens the Process Cell diagram, which shows all the Units in the cell. Note - these can use colour and text to indicate the status of each Unit.
Clicking on a Unit object opens a Unit diagram
Note that this does not show all the valves etc in the Unit, it just shows simple objects for each equipment module but again with colour and text to highlight status of the equipment modules

Clicking on an equipment module object then opens an equipment module diagram where you can see the valves etc in the em.

From here you can also go to an Equipment Module Faceplate

Or of course a to Control Module Faceplate.

In this case, the automation for the plant was designed with ControlDraw, and the graphics correspond to relevant objects (diagrams) in the ControlDraw model.

Comments are as ever welcome.

Download S88 Part 1

2008-09-13T17:31:00.000-07:00

Yes, you can download the entire ISA-88 (S88) Part 1 standard for free, the original and best version.

- note - this has now disappeared
I mention this because it is one of the most common searches on the controldraw web. Of course it is not there, it is not supposed to be free - though I think it should be.
I did not put it there, but someone (not me) has put a link on the Wikipedia S88 section. I found it just 2 clicks from Jim Cahill's blog - which is worth reading by the way.
So get it while you can.
Updated May 2011
Some Chinese person has now posted the standard here
http://wendang.baidu.com/view/148a9bb91a37f111f1855be3.html

More on ISA S.5.06 Functional Requirements

2008-09-05T16:49:00.000-07:00

I have spent some time delving into this standard, and the examples it provides.
Further than that, I have now created a ControlDraw model that captures basically everything that the standard shows. This is for me the best way of understanding a process.

One thing that amused me about the batch reactor example is that it has nowhere to send the batch it makes apart from down the drain! It calls dumping the product down the drain the Dump Phase, part of the Transfer operation, I suppose dump is appropriate, but Transfer? Maybe I missed something - here is the P&ID

S5.6 has this thing called a Sequence matrix. This is a condensed overview of the example process, but I suspect that it really would not be workable when scaled up to a real, and more complex process. Furthermore it conflates too much into too little, and if you are trying to do in in Excel demands lots of formatting. ( And the example manages to avoid the most complex issue, the transfer.)

So my model does not use that method - it is optional, you can also use Sequence charts - and instead uses those, in the form of SFC's and PFC's
Maybe a complex query could generate the matrix from the combination of the sequences and the equipment - it is possible but it would be a huge table compared to the example sequence matrix. Even without adding a real transfer!

Will S88 improve - or should it?

2008-09-02T15:47:00.000-07:00

Will ongoing developments of S88, specifically Parts 1 and 5, improve automation?
I am far from sure, in fact I think they will not.
I think it is arguable that even the original Part 1, for all the applause it has received, has actually had the effect of damaging the development of innovative automation products.
Why do I say that?
For a start, the ‘Procedural State Transition’ model given in the original Part 1 (which does not need updating imho) as an example is but one of many possible alternatives, and certainly not the ‘best’. And it may well have constrained product evolution. There are plenty of other similar issues, not least the handling of common resources that the same could apply to.
And now, in the Part 1 update and Part 5 the standards committee is further limiting opportunities for designers to come up with something much better, by refining that which did not need refining.
Standards have their place, we would hardly be able to function without standards such as the metric one for measuring, but S88 is not in that domain at all, there is no science behind it yet, and no sign of one emerging.

Part 1 update latest.

2008-08-28T13:03:00.000-07:00

According to the latest Posting on the Part 5 blog, S88 part 1 has now been made 'Stronger' and has resolved all the outstanding comments except for one
The committee is alleged to be feeling confident it can be ready for the whole ISA88 committee before the year is out.
Apparently, the latest face2face had some of the original framers of the approved ISA88.00.01 standard present and the group worked well together in clarification of several contentious parts of the standard, creating what all felt was a greatly improved document that is easier to understand.
Sorry, but from this side of the Atlantic Ocean I beg to differ.
Why? Well, for a start my European contacts are far from sure that the new version improves on the old one. For a start it needs to be made simpler, not more complex.
Many comments were somehow removed from the commenting process, in meetings that were attended by just a few people.
The 'the original framers' were largely not present, some were but most (those from my side of the pond) were not. And let's face it, it all started in Europe, probably with Namur, in Germany.
The blog also states "While there are some in the community who claim the update work is diluting the batch standard to address other industries, I would challenge them to take a good look at the work and identify through constructive comments exactly how this is occurring. As I view the state of the work I only see a stronger “BATCH” standard that is now even more capable of being leveraged in other industries."
Well, In part I hope this blog actually does comment constructively.
I also have no problem and have not had for years in relating the 'batch' S88.01 to continuous and discrete production. There is always a batch, Save the Batch.
What do Y0u think?
PS I would like the Part 5 blog to link to my blog, as I do to theirs.

Equipment Heavy,Recipe 'Lite'

2008-08-26T15:33:00.000-07:00

A friend commented privately about my blog that it is equipment heavy.

I take that as a compliment, it is my hope that this blog, and my software will help to improve Equipment Control.

I think he also means that the blog is Recipe 'Lite', so it's time to talk more about how I view the Recipe and Procedural side of Control.

I am sure that good equipment control makes recipes simpler. And Recipes Can Be Simple (or Lite).

And intrinsically I think they are and I think that the S88 originators (and it goes back long before S88) knew that.

A recipe describes how to make stuff given some equipment.

A recipe does not care how to control equipment, it does not even need to define the chemistry, which means that it can be described very easily. And as Part 1 says, a Procedure should be essentially an Ordered Set - or sequence.

It is the sort of thing that operators have done for many decades.

Please readers, when you see anything that claims S88 compliance or benefits or profits or whatever, remember that S88 is not about how to program a control system.

Show us your graphics

2008-08-20T16:42:00.000-07:00

The next WBF meeting will be in Barcelona. That is a great place worth visiting even without the Meeting of Minds the forum promises. I have been to many WBF – and before that EBF meetings, and have always enjoyed them, sometimes too much. Perhaps I really should not have gone sampling all the strongest Belgian Trappist beers with the Irish and the Danes in Brussels. Making beer is of course something that S88 can describe perfectly, whether it is the largely manual processes used by small scale brewers or the highly automated ones used by the biggest. And how you make beer is interesting, but we don’t get paid for being interested. More to the point especially for a control engineer trying to justify a ‘WBF Jolly’ is to be able to learn how others automate making beer – or chemicals – or ice cream, or any manufactured product.
For control engineers the problems that are the same whatever you make are interesting - beer makers can learn from chemical makers how each solves the same problems.
Now, S88 did a good initial job of separating the product (the recipes) from the control of equipment . And it covers both.
So, looking at the agenda for the next WBF, where is the equipment control? (Apart from Part 5! )
I can’t see anyone on the agenda talking about how they control their plants. How do they handle their equipment - from simple things like agitators, to CIP and multi-purpose flexible plants. What standard objects do they use. How do their operators interact with the processes, their levels of manual control, and so on. How they deploy the great products that are available from the majors?

The WBF Charter says
WBF - The Forum for Automation and Manufacturing Professionals, is an association of end-users, vendors, consultants and academics with a strict, non-commercial agenda.
But is it really non-commercial?
I remember fondly the days of the European Batch Forum, it’s agenda was 50% commercial and 50% open. That is half of the presentation time was commercial suppliers demonstrating their wares, the other half was generally independent of the suppliers. The richer suppliers paid for (sponsored) most of it.
I found that this worked very well. There were for example many supplier presentations that were far more illuminating than most of non commercial ones. DCS and PLC suppliers and Systems Integrators could demonstrate how they had solved control problems - believe me you can learn far more from watching live demonstrations that you can from PowerPoint. But you are not allowed to do that at the WBF. It makes it much more boring. And yet even as it is the WBF is still used by most presenters as a marketing vessel and is actually highly commercial in it’s dealings – it now uses sponsorship in different ways. Fair enough, a different model. But where is the Control?

Hacking Safety Systems

2008-08-14T14:57:00.000-07:00

I don't normally comment on this area, but I do track what is going on.
Walt Boyes has written on his 'blog' about a demonstration of compromised Safety System, read it all here
I have resp0nded, not least because many year ago I was delegated the job of checking out alarming reports about Y2K faults that might blow by up refineries. I had a free hand to investigate the truth about such tales, and invariably I found bad science.
The dialog so far follows.

Walt,
When you say things like “blow up a refinery” it suggests that some software fault (eg caused by some hacker) might have the capability of doing that. But as you know the ultimate protection, and a great deal of effort goes into it, is at the lowest physical level possible, relief valves for example. And hard wired logic, high integrity safety systems etc. I had this argument over Y2K many years ago. Don’t you think you may be feeding the trolls? Francis www.controldraw.co.uk
Comment by FrancisL Posted on August 12, 2008 @ 11:26 am

No, I am not feeding trolls. Francis, I saw a live demonstration of a hack against an SIS system last week. It took 26 seconds to cause the valves to fail open. The danger is in fact real.
Comment by waltboyes Posted on August 12, 2008 @ 12:01 pm

More details please Walt. My mind boggles that anyone could engineer an SIS to permit such a hack, and how such an SIS could be even called a safety system. And does the situation not imply that a failure in the SIS (hacked or not) could open the valves? So how can it be called an SIS? Francis
Comment by FrancisL Posted on August 13, 2008 @ 11:47 am

Your guess is as good as mine. Fact remains, this product is being sold as a SIS. I do not know the vendor. Anytime a SIS is connected to the plant network, it becomes open to an attack. Nearly all PLCs, including safety PLCs are vulnerable to DoS attacks unless properly firewalled. I have not much more information, because the demonstrator was unwilling to share too many.

More on Common Resources

2008-08-07T14:31:00.000-07:00

Good old Anonymous has made some good comments about Common Resources.
Anonymous people are founts of infinite wisdom, if only you could meet them over a pint!
Read the whole comment - at the end Anon says
By your definition, these EMs would be common resources. I am not sure I agree with that, as their primary function is with the parent unit (Reactor), plus all the problems which would be associated with P&IDs, tagging etc.What about the concept of expanding and shrinking Units? How would this fit in with the concepts of common resources?
Great point, but what are these Units that expand and Contract? The comment explains it well, We do need expanding and contracting Units, for example after a mixing vessel has been filled and closed the inlet valve, what happens on the other side of that valve no longer matters. So long of course as it does not fail but that's another story.
One way of handling this is to have 'Virtual Units'. These are Units that the recipe can see, in it's view of the physical model, but that do not exist in the physical plant. These can expand and contract. (Also you can use them to point to selected equipment so the recipe does nto care wich equipment it is using - more later)
Good PLC and DCS programmers can easily construct them by the way, provided that they are prepared to use indexing and a little logic. It might help to have that rare thing, an object oriented PCS, so for example the equipment could inherit the current batch formula.

Another solution may be to eliminate Units and Equipment Modules completely and just have
Equipment Procedural Entities - EPE's. Then the recipes that are running (for example several batches and several cleans running simultaneously) can acquire the equipment that is required dynamically, using only the EPE's needed at any one point.
You can call the EPE's Units, EM's or Common Resources if you like, I don't care. The EPE's can be very small or quite large, it just depends on equipment the batch occupies.

Now, where all this gets hard is the fact that equipment control has to be fast and safe, and can be complex. Of course the safety aspect can normally be handling by simple logic that is close to the IO. The fast aspect is also easy - but not with a transaction based batch manager running on a busy PC on a busy network- this sort of performance needs controller software.

Australia

2008-08-05T14:41:00.000-07:00

I am going to Australia again. I first went at the age of 1, in 1951, but returned to England in 1955. I think my mum found it particularly hard there.
Back then it was somewhat behind the times for a woman, especially one who considered herself (as she is) equal to men. But it may also have been something to do with the weather, and pining for the English countryside. And having small children.
My dad was a teacher and engineer, sadly he has gone, 10 years ago, at the age of 84, Mum is still fine, at the age of 94. Let me know if you would like her email address, she is still totally with it, but hates spam. I have not got her into blogging yet!
Anyway, I arrived back in England at the age of 5 , and ever since then I wanted to return. I did it 4 years ago for 3 weeks or so. I saw more than my mum did in her 4 years there! But 3 weeks is not enough, so I am coming back for 6 weeks.
Wherever I go I like to meet the engineers, so if you are in Australia and working with process automation, please contact me, to chat or for a fee I can do a great S88 tutorial.
I look forward to meeting you Oz

Back on the Tea - off topic

2008-07-29T16:43:00.000-07:00

As I was talking about cups of tea, here is The Tea Rap on YouTube

Common Resources

2008-07-27T16:44:00.000-07:00

What are these Common Resources?

If more than one unit can acquire or request the services of a single resource, the resource is
designated as a common resource. Common resources are often present with complex batch
processes. Common resources are often implemented as either equipment modules or control
modules. A common resource may be either exclusive-use or shared-use.

That definition is pretty good for me, but there is still disagreement, and to a degree I think that they are the bits where the original S88 parties could not agree. For example, some give the example of Storage Tanks, but in an alternative perspective (not just mine) Storage Tanks are Units.

Another good example is transfer systems. Surely these are common resources?

Actually some of the best batch implementations I have seen treat them as units. They call them X units, but as far as controlling them they are exactly the same as 'normal' Units, including having Equipment Procedural Elements.
The viewpoint once described to me was that if contains even part of the batch it then it is a unit.

Something like steam supply or other utilities are for sure common resources aren't they?

Can a resource be a Unit and a Common Resource?
So, is there any prospect of the revised part 1 coming up with an improved wording that will stop the divergent interpretations, of things like storage tanks, transfer systems?

Of course, the definition that CR's may be made as equipment modules implies that they can have EPE's, and take part in recipes.
To be continued

Unit State Model

2008-07-17T16:42:00.000-07:00

Latest on Part 5 developments
What is a Base State Model?
It says. The Base State Model defines a complete fixed set of defined unit states, unit state commands, and unit state transitions. Each Equipment Unit Procedure will comprise a subset of the same base sta...

This dates back to 1996, it works well. It integrates exception handling with Unit Control in ways that the conventional S88 Procedural States do not.

Equipment Procedural Entity

2008-06-21T16:52:00.000-07:00

There have been discussions in the S88.01 Update meetings about Equipment Procedural Entiies (EPE's)

This is how I view EPE's -

They are objects such as Phases that can be executed under the command of a Recipe - for example an SOP, or a Production batch, a Batch manager Control or MES Recipe - but which are contained in - and controlled by - the equipment controllers.

The Equipment Controller might be an Operator who runs the equipment manually or if the equipment is automated, the Process Controller - PLC/DCS, Relays or whatever - that is connected to the physical equipment. (Most times it is a mix of the two)

EPE's are part of equipment control.

In Object oriented terms they are like the Methods of Objects
The Equipment that contains the EPE is a Unit or an Equipment module depending whether the Recipe-Equipment Interface is at the Unit or EM level.
Note, the S88 standard says that Control modules cannot have EPE's. But this is no problem - if you must control one CM from the recipe, create an EM to contain it. There is no law against it.

The EPE's can be Phases, Operations or Unit Procedures.

Now, the standard does not say this, but what follows is I think consistent with the models. It is also a configurable aspect of ControlDraw.
Equipment that contains EPE's must also be Acquirable, which mean that the Control Recipe takes control of the Equipment when it needs to carry out some processing in it. And to take control of it means preventing others from controlling it. Which to me implies Acquiring the equipment.

There is a direct correlation between the Equipment Requirements of the Master Recipe and the Equipment that contains EPE's .

That means that the Recipe Equipment Requirement maps to the physical equipment.

This can be one for one in cases where the recipe must use specific equipment or one to many in cases where the Recipe can use different (but similar) equipment.
For example a Recipes' Equipment Requirements might have a Reactor and a Filter but the plant has several Reactors and Filters. The Acquire process involves reserving the equipment for the current batch.

The last draft has a diagram, "Figure 18 – Referencing equipment entities at different levels within a control recipe procedure."

See also
Think of batch standard as design philosophy
Much more to come !

S88 Control System Designs

2008-06-17T16:03:00.001-07:00

I think that it is a very good idea to use the S88 part 1 models as a framework for a batch (and indeed other) control systems. If you have a reasonable Control System design then it should be possible to use S88.01 Models and Terms to write a fairly precise description of the design.
That does not mean that S88.01 is a design for a control system. And that is clearly stated in the original standard.
Part 5 as it stands appears to be attempting to go into areas (such as a generic model for equipment and control modules) that are explicitly excluded in the introduction to Part 1.
Most worryingly the Part 5 fans are now trying to change Part 1 by introducing their models into Part 1. It is bad idea that would undermine the beauty of Part 1.
Now, Part 5 fans, please understand that I do realise that you may have some very good Control System designs (tho mine may be better) but that is not the point, Part 1 is not at all about designs for Control Systems.
If the objective is have a standard design for re-usable Control System Objects, then it should have a major input from the suppliers just as the development of FieldBus and the like has had.
They are notable by their absense from the Part 5 - where are ABB, Emerson, Yokagawa, Siemens etc. Mostly they are lurking - they are on the mailing lists but rarely take part.

Equipment for Making the Tea

2008-06-17T15:41:00.000-07:00

The Turks do it another way

But that is for a completely different type of Tea.
So let us look at the Boil Water step in our English Tea Recipe.
Disregarding for the moment that this is probably control in a Common Resource, the typical English Kettle has a switch that once you have put water in it will boil the water and then stop.
The Recipe to make tea hands over to the kettle for that process action.
While the kettle is boiling it is executing the Boil Water part of the Control Recipe for your cup of tea.
Of course you do not Have to have an Electric kettle, you could use a pan on a gas ring, or a camp fire, just for example.

A Batch Recipe

2008-06-12T16:21:00.000-07:00

Header
Name : A cup of tea:
Version: Typical English
Equipment Requirements
Teapot
Process Inputs:
Dried Tea Leaves (optionally in 'Bags')
Water
Energy for Heating
Parameters
2g of leaves per cup
Procedure:
Pre-heat teapot by using a short flush with nearly boiling water.
Put tea in Hot Teapot, then Add boiling water to a teapot.
Stir (optional).
Wait 3* minutes for tea to brew. (*time is a operational/user choice)
Put Milk in Cup - This can be done while the tea is brewing.
Please note - the milk Must be added to the cup Before the Tea!, (This is a Critical Recipe Parameter).
Pour tea into cup.

Slurp it up

Good things found in Vista:
Windows Key the type the name of the application - :
Bingo!

Sequences are not Recipes

2008-06-11T14:58:00.000-07:00

Dave
I completely disagree with a heck of a lot of what you say part 5 blog.
The latest is
Is that a Sequence or is that a Recipe? The answer is - You say Yes
I say no, in fact I say do not even compare them. To do so undermines the great concept that S88 provides, - separation of Recipes and Equipment.
S88. 01 is not actually about Control, it is about how to describe recipes and the physical equipment they have to run with. The cookbook and the kitchen.
Chop with knife number 42, turn on the power for the cooker, rotate knob 3 to set the temperature on the oven, etc is in the equipment sequence.
Chop the carrots, put in preheated oven is in the recipe.
These are not the same, they interface but are not equivalent.
The formula in a packing machine, just like the temperature of the oven in the recipe and the set point for the mixing tank are local copies of the recipe formula - part of the control recipe and derived from the master recipe.
Your statements on this blog are potentially damaging to the value of S88 Part 1.
Part 1 by the way should be left unchanged, if I had a vote I would vote against the update and for the original.

MS Vista

2008-06-11T14:42:00.000-07:00

I make and sell software for Control Engineers to design their systems with. Of course it is Microsoft based, sorry you open source people out there, but MS is so much more productive for me.
I have wondered whether, or even when, it will be feasible to convert ControlDraw to a web served application, like those that Google does. Maybe I could stuff it full of adverts and retire on the revenue, but that is not my intention yet.
My customers, at least those who work sometimes from their new gleaming home PC's are buying Vista machines these days, and I found that some of them could not run CD
So, ControlDraw Ltd bought me a new Laptop with Vista, and in a day the problem was fixed.
However, I have just had 3 black screens in succession, after installing Vista SP1 and Visual Studio 2008. It took a Safe Start then another reboot to get the machine running properly again.
I thought Vista was not supposed to to that. I guess Vista is still Beta- but in reality so is all software. And Standards. They have flaws that get fixed over time. (unlike S88, but that is not fair as S88 is not like that, it does not need fixing)
Vista is nice, but another big flaw is that I cannot get VB6 Service packs to install.
That looks to me like MS forcing up their revenues, I cannot find an excuse for it. I should be able to use my existing development setup, that I have paid them for.
Notwithstanding, I am now playing with the latest and greatest development tools from MS

Recipe Control

2008-06-05T16:40:00.000-07:00

I see that Dave has blogged about Recipe Control

"No where that I can find does the ISA88 standard deal with “Recipe Control” as it does with “Equipment Control.” it says. My jaw dropped when I read this so I posted a fairly mocking response, but as usual it takes days before comments on that 'blog' appears if at all.

I think that the post indicates that the most fundamental purpose and meaning of Part 1 is not understood by the poster. Let me explain why I say that.

The entire Original Part 1 is all about Recipes and how to make stuff according to a Recipe.
And keeping the Recipes independent from the equipment and yet being able to run the recipes in the available equipment. The Equipment gets Controlled Yes. The Recipe provides the Set Points and the Procedural Sequence, but the Equipment Does the Control!

Part 1 quite rightly strictly excludes defining how to program either recipes or the control of equipment. Part 1 as it is does a very valuable job of providing a framework in terms of the words that can be used, and models that can provide a structure where those words can be used to describe the required Recipes and the Equipment Control.

Recipe Control is a meaningless term - unless we are talking about how to manage the Recipes themselves. Such as making sure that they are kept safely, version management, ensuring that a Recipe is up to date and approved for use etc.

When thinking about Recipes, it always helps to use the cooking analogy. So what do the cook books say about Controlling a Recipe. Try Searching for Cooking Control. Did that help?

By the way, Dave's 'blog' is not really a blog, but never mind. If you comment on this one it will appear - immediately, please feel free.

The History of Diagrams

2008-04-01T16:43:00.000-07:00

After my comments about diagrams and UML I checked out the history of diagrams.
I found a very nice presentation on the topic here, it follows them from the earliest - Maps, Geometrics etc on - thanks Nottingham university and Thannasis.
It happens to be also a very good introduction to UML. Now, my types of diagram such as those for Unit and, Equipment Modules, Operations and Phases etc are not really part of the classic UML set, but it is quite easy to see how they could be part of a Control Modeling Language that conforms with much of the UML rules.
Maybe if I get time I will write it up. Or introduce the idea to S88 Part 5.

WBF 2008 USA Conference

2008-03-26T16:31:00.000-07:00

No, I am not there, but it is good to see Walt Boyes reporting at Sound Off in near real time from the latest WBF conference.
Walt has kindly summarised several papers - those that can be put into words - perhaps not the flashy graphics ones.
Nothing new that I could see there, but it all stands repeating.
One paper about the Zen of Project Management makes plenty of good points, slow down to speed up, improve the equirements analysis and so on. Really not new but totally valid. But here we go again, UML. Sorry but no, we do not need UML for process control, and believe me I have tried, years ago. Control Engineers have had better diagrams than UML provides (for our stuff) for decades. And the software tools too.

Lynn Craig Webcast

2008-03-19T16:57:00.000-07:00

This should be worth hearing, Lynn usually is:
WBF Web Sem: Using ISA88 - Approaches, Opinions & Caution
There is unfortunately a charge of $95. Which will greatly reduce the audience, a great shame. It should be free and on YouTube. And Part 1 should be a free download.

Part 1 update gets sensible

2008-03-13T16:36:00.000-07:00

One of the issues that I have been on about is that Equipment Phases are only phases if they directly relate to the Recipe Phases. I always believed that the original Part 1 says as much, and more than that that the people who wrote it meant it that way.

Somehow over the years some people seem to have not understood that, but I am very pleased to hear that the update commitee has re-affirmed it. Here it is:

General Discussion – What makes an EM different than a CM?

The entire call was spent discussing the equipment module / control module clarification. Key agreement was that an equipment module could have two forms of procedural control logic. First, it is clearly stated in the standard that EMs are the lowest part of the physical hierarchy that can perform procedural control and thus have an equipment phase. By definition, this type of procedural control logic is intended to be directed by a recipe phase and that association should exist. It was also agreed that there may be another type of procedural logic which may be performed by an EM which is not directed by a recipe phase. In this case, such logic should not be called an equipment phase, but some other name (possibly “equipment task”). This non-phase related procedural logic may be commanded by operator interface or by another (possibly superior) EM. The key difference then from a control module to an equipment module is this capability and existence of procedural control logic. Control modules do not perform procedural control. An equipment module is used to support the lowest level execution of procedural control, either as directed by a recipe phase (causing an equipment phase to process), or as directed by a non-phase entity (causing some currently un-named procedural logic to process).

Personally I would have gone further and reserved the word procedural as belonging to the recipe as well, and found another name (perhaps sequential) for the second type of equipment control. But it is better than it was looking a few weeks ago.

Documentation Standards

2008-03-08T15:33:00.000-08:00

There is a new standard, ANSI/ISA-5.06.01-2007 Functional Requirements Documentation for Control Software Applications.
It reminded me of an older one from Norsok, that I came across while researching control systems diagrams. I would be very interested to hear from people who are actually using this standard.

I am of course very interested in such standards, as much as I am in S88, because this is my livelyhood, as well as an abiding interest. I look at these standards to see if they have any bright ideas, such as new diagram types or models that might be added to ControlDraw.

I-005 System Control Diagram, (Rev 2 2005) - includes:

Present extensive use of computerised systems and 3D modeling provide efficient tools for specifying and handling of physical equipment in a standardised manner. However, the development of methods and tools to specify functional relationships has not reached a corresponding level.
During the plant development the process engineers specify the process through the development of the P&IDs. Throughout this work process the process engineers acquire a thorough understanding of the total plant behavior. However, the P&IDs provide limited facilities for documentation of the overall functionality as well as operational aspects of the plant.

The SCD approach has been developed with a view to industrial processes controlled by state-of-the-art process control systems, but as it provides a general process oriented approach for development of thedocuments, no field of application are explicitly excluded.

It says a lot more (Search like this)

And the ISA standard (also known as S5.6) says

Learning and configuring today's control software packages is easier than ever before. Documentation, however, is not such an easy task. With the increased capabilities of software packages to handle more process and operator interfaces, the complexity of defining and documenting these requirements increases. This standard directly addresses this documentation issue.

I have no idea whether the ISA looked at the Norsok standard when they were developing S5.6, I wish they had though. It even covers much of what S88 Part 5 is aspiring to, such as Modes and States (in some depth and with precise meanings and State Charts, templates.

Part 1 update

2008-03-07T01:00:00.000-08:00

There is a new version of S88.01 being developed.
The development is being conducted by means of draft copies and comment forms being distributed via a mailing list, periodic meetings, and some dialog on the mailing list. It has to be said that in these days of Social Networking, Wiki’s, Blogs and excellent help groups such sites as eng-tips.com and plctalk.net/qanda, that the ISA and WBF are truly archaic. Although they do use internet online meetings, which is good.

I remember an esteemed WBF member at an EBF meeting in the mid 90’s at about the time the WBF started up speaking of one day ‘Surfing the Batch Web’. Niels I don’t think we are there yet!

Notwithstanding I have been following the Part 1 update process and occasionally throwing in a comment. It is clear that even now there are still big conflicts about what Part 1 actually says.
I used to think that all it needed was some examples and the problems could be resolved.
But now, I realise that it is unlikely because the disagreements are at present too entrenched.

These differences are greatest in the use of procedural models in equipment control. To me, and some others, it seems that some want to use the procedural terminology for parts of control software and even push the models as architecture for the real time control in the PLC’s and DCS’s. That is not what they are for, and they do not always fit.

Some just want to agree and follow whatever it becomes, but that is not the answer, since if it gets it wrong the result will be all of us having to be inefficient. And, no doubt, some good designs being rejected because they do not fit the standard.

S88 Part 5 Resource Managment

2008-03-02T16:01:00.000-08:00

Part 5 has it seems started on a path that includes recource management in some way, tho I have yet to undertand what way.

Part 1 has no model for Resource Management so Part 5 has not got a chance of having anything worth saying in that context.

First, Part 1 should refine resources

Standard Control System Objects

2008-03-02T15:09:00.000-08:00

One thing that Part 5 seems to be aspiring to is to provide frameword for a common set of objects. By this I mean Devices, (primitives) and perhaps higher levels in the recipe independant physical model.

Yep that is possible, in fact there are already for example ISA templates for at least one aspect of that, Instrument Specifications.

And they are indeed useful. So why not extend them to other parts of the Physical model? Or to the functional aspects of these instruments? If you like, from the Object Oriented viewpoint, the ISA instrument specs define standard properties of Instrument Objects, can we extend them to cover their methods? Further, can we define a set of ISA classes for the physical model?

To a degree, this is what users have been doing with ControlDraw model classes - I think has given me some insight. One thing that is showing up is the difference between system specific classes and those that are just about the generic objects.

It seems though that the Part 5 writers have not understood yet.

OMAC and Part 5

2008-02-29T17:09:00.000-08:00

I see that the part 5 ‘blog’ has attracted another blog comment
OMAC should maintain a simple focus on packaging
Note the statement OMAC should proceed with extreme caution!

S88 Part 5 - Standard Profits - ?

2008-02-29T16:57:00.000-08:00

How will this help us? How will it deliver standard profits? Do you even want standard profits?
The part 5 ‘blog’ has a couple of new entries , will they help?

A Device is a Device is a Device; But what if it is not? Now, I was at an early S88 meeting where device were seriously being considered for inclusion as standard terms. There was much discussion and it was agreed that the more generic term Control Module handles them perfectly within the Batch domain of the standard.
Now can anyone explain this statement?
“In many other implementations outside of where the ISA88 standard is applied the term Device is used such that the Device also contains the control that in the ISA88 the Control Module contains.”
OK, a few typo’s maybe, but the rest of the post make little more sense, and then goes on to refer to the MaketoPack report, which in no way helps to define devices.

Then we have
Replace babble of Control Components with understandable language, OPC help Dave believes “that the babble of internal proprietary communications between control components will be replaced by a universal method of communication”. And I hope one day that telepathy will be the normal means of communication, not least because my ears are failing. (No, it was not the Rock concerts, see cookie bite!)

Do we really need this - us the control system designers, plc programmers, systems integrators, and even the automation project managers?
Dave also says
“Until then a way to translate to the world outside the language of the proprietary environment is necessary . ”

Hey Dave, we have had those since the first pneumatic controls 60 or so years ago, not so much the pneumatics as the diagrams. And those diagrams have succeeded representing control for example loops (pneumatic then electonic then DCS) , relay logic, sequences etc
The diagrams have developed and improved over the decades. But I have a dread that someone in Part 5 is driving the standard towards using Ugly, Mangled Logic, or UML as it is known here.

WBF S88 Papers

2008-02-18T15:49:00.000-08:00

I am browsing through my large collection of papers presented at WBF conferences over the years. Google Desktop is a wonderful thing as it make it so easy to search them.

There are various types, many are very interesting, and would apply regardless of S88. Great, the WBF is not just S88.

There are also many that claim business benefits as a result of S88. As an engineer, that seems unexciting. For me it is a given that good engineering benefits business!
The most boring are those that claim X% saving here and Y% there, invariably with no evidence that would stand up to the kind of review that scientific work has to.

Some do extend our understanding in ways that are true S88.

But rare are papers that have anything other than positives to say the standard.

S88 did not come out of the blue - many successful systems had been designed according to what we now think of as S88 long before the standard was even in its early drafts. The German NE33 Standard was one of the feeds into S88 Part 1.

And some real problems occurred in the early stages of the standard, you only have to read the paper on CIP that was contributed to the (ancient) EBF - for demonstration imaginary plants, which incidentally, preceded the Part 5 Best Glue Plant by 10 years.

Most of the papers are written by - or at least presented by - people in managerial positions.

But I would really love to hear from people with experience from the Process Controller end - the programmers. So, if you are out there I would love to hear from you and about your experiences with S88 from the control code end.

Control modules

2008-02-15T16:57:00.000-08:00

And how great control modules are pure S88.
Control modules know nothing about the stuff you are making. They do not even know how stuff might be made. Part 1 is clear about that, as the recipe has no interface with control modules.
That does not mean that they cannot do a lot, in fact they are the bedrock of any application. The better they are, the easier the rest is.
'Primitive' Control Modules handle the Inputs and Outputs, from the plant and the operator and from higher levels in the system. They then make sense of it, setting and monitoring the state of the physical equipment that is connected the to IO and driving things like Faceplates.
Primitive Control Modules can be quite intricate, and supposedly simple things like motors can have a surprising number of states and parameters. They are little models in theselves.
Higher level Control Modules such as a PID loop or a one that handles a valve cluster also have states and parameters etc. They may even have sequences to move from one state to another or to perform a cyclic function. Some S88 practitioners choose to all these sequences 'Phases'.
I don't like to, but that is another story that I will return to.
I also use Control Modules for things like resource management - take a look at this Cyclic Request Handler . This is a small simple module to share a common resource among a number of users. These request the resource via a boolean flag, like holding your hand up in class.
They remove that flag when their demand no longer exists. The Module just looks at each in turn, and supplies if the 'hand is up'
The method guarantees First come at most Nth Served where N is the number of users. It is easy state control and avoids needing any form of queue and could easily be implemented in a PLC. Is it a Control Module? If not what is it? I hope Part 5 will find a space for it, and not a procedural one, as it does not need to know anything about making stuff!

Save the Batch

2008-02-14T03:11:00.000-08:00

Or how to be an S88 Purist and how it will improve your controls, be it batch, discrete or continuous.
Often when analysing a process people start by dividing the process into Units and Equipment modules, but without thinking where are the Batches?
It greatly helps if you start by looking for the batches. And Everything can have a batch, even storage tanks.
Once everything has a batch, you can use S88 terms through all your application without confusing the recipe with the equipment.
An important thing about the batches in a plant is that they are not often one for one. For example a pallette of chocolate bars, a tanker full of milk, a delivery of hazel nuts can all be seen as batches.
Drawing a Batch relationship diagram is a good way to crystallise your ideas.
Once that is done you can find the units and the recipes, and decompose them.
Then you can match the procedures to your elemental basic control. Which you can get straight from the equipment for example a P&ID.
Adding higher levels level control modules in Basic Control can makes this far easier.
I will try to extend this in time, but for the present take a look at "Is a storage tank a Unit?" which shows how to run a control recipe in a storage tank just like any other batch control recipe .

On ISA Part 5

2008-02-14T02:30:00.000-08:00

The ISA part 5 developments appear to me to be trying to take Part 1 concepts into areas it was never designed for, such as the inside of machines.
In the process of doing this they are inventing new meanings for those Part 1 concepts such as Control Recipe and Procedural Control. This will only confuse, especially the use of terms like Operation and Unit Procedure. They think that an Equipment prefix means that they are not the same thing. I cannot find anywhere in Part 1 that says that - the Equipment prefix adds the ability to direct basic control, but does not remove the Recipe meanings.