Engineering with an S88 Approach (Part 2)

Automation Engineering

Since the I&PD has so many inadequacies, automation isn’t documented enough after the preliminary design in order to fully understand its impact and complexity on the budget and timeline. Still, the project timeline normally needs a control system in place and the software development normally has to begin right away. When things go extraordinarily well, the client approves a Functional Specification in writing prior to creating the software code. Sometimes, people assume that inner client resources have time to do this. However, if this isn’t the case, systems integrators have to create a specification with help of the drawings’ process design and fill in any blanks that need to be filled as they move ahead.

This effort asks for extra collaboration between the process designers and the client as they have to look over everything that has been approved and reviewed thus far – a costly duplication of their efforts. Several original process design architects might not have time for this, though, and to make matters even worse, gaps might appear between the desired functionality and the things that are currently being installed.

Strategic Discussions

These gaps might only appear this late because the strategy was never fully discussed before the design was actually reviewed and already released for actual construction. Because of this, very late changes might occur within the physical entities, impacting the project budget and timeline significantly and resulting in an undesirable outcome for the client overall.

The problem gets worse: the steps of project control and critical planning need to be eliminated since no clear criteria of software design exists and the timeline is shrinking by the day. In fact, some people might have to be added onto the project just to meet its schedule. Since no clear criteria of design exists, every developer has to use his own creativity to reach the end as fast as possible. Usually, this results in just an average outcome as opposed to a perfect one.

Pressured Commissioning and Overall Validation

Because of the late start and lack of documentation, commissioning and overall validation becomes a complete nightmare. This ripple effect keeps going since the test protocols need to be created, even though the design of the software is still in the works. Now, it might not be smart to waste hours developing protocols just to test under-developed and undocumented software designs; but conversely, the money wasted on late starts would be worse. Therefore, the effort of validation will start late and stay in critical waters until the end.

A Better Path Does Exist!

To steer clear of problems like this, the philosophy needs to change. The Functional Specification can’t be optional anymore and cannot be developed ‘later on’ anymore, either. Instead, it has to become a vital factor of the process of engineering – a deliverable just as vital as the equipment specifications and drawings. The Functional Specification needs to start at conceptual design to describe the Block Flow design concepts and unit operations. It has to keep growing in preliminary design to describe the I&PDs’ control strategies and equipment functions. It has to mature in detailed design as each device’s function is defined. The Functional Specification has to keep going from there, serving to be a vital design document that supports the configuration of the control system, commissioning, validation, and change management for the facility’s entire duration.

Education

It shouldn’t be surprising that the majority of process engineers aren’t very worried about understanding S88. After all, S88 is a standard of batch control and is thus specified by somebody else. Traditional engineering company engineers hardly have any S88 exposure, either, since the former approach had somebody else creating the control strategy. Well, unless brand new approaches are looked at and turned to, traditional engineering company clients will go to somebody else for their business, as well. Because of this, it would be vital for lead engineers to start understanding that great automation practices have to be designed in as early as possible. Whenever the opportunity arose, control system engineers and process engineers involved were raring to learn more about S88 since it made the complicated task much simpler, more manageable, and more understandable overall. Plus, the customers were more satisfied in the end.

Still, the customers need to buy this idea, too; not knowing about a better method and the disadvantages of the former process of engineering can be completely avoided. Client project leaders don’t feel the pain all the time anyway like the project validation and automation managers do since they simply wait for data as time goes by. They might not understand that the strategy of process control actually needs to be tied to the facility design, either, so they need somebody to speak up and let them know that the overall responsibility tied to creating and documenting the strategy has to be moved from somebody else to the process design developers and that they need to start now as opposed to later.

Applying the S88 Models

A lot of helpful models exist in ANSI/ISA S88.01 Batch Control Part 1: Models and Terminology, but the ones that would be the most applicable in the early design phases would be the Procedural, Process, and Physical Models.

The reader needs to have some S88 knowledge and have access to this particular document. Other great resources for in-depth S88.01 discussions can be found under the section of References. The next paragraphs will offer up a short overview on the different models as applicable to the project and as documented within the Functional Specification. Look to the illustrated figures as needed and take note that the document’s collapsible features that will let reviewers drill down into the models are illustrated much better in its electronic and interactive form.

Models

When it comes to the Process Models, there are different Process Stages with Process Operations that have Process Actions in them. To create Physical Models, physical enterprise entities are organized depending on their Sites, which have Units, Process Areas and Cells in them, which conversely have Control and Equipment Modules in them. Procedural Models state that a Procedure has Unit Procedures, Phases, and Operations in it.

With S88 inside the Functional Specification, the process of engineering moves towards a more object-oriented and modular design. In its early stages, design entity similarities are pinpointed and exploited in order to bring about standard objects or entities with similar attributes that can make them carry out certain functions. Such concepts are continually developed through the process of design and exploited through the facility’s life cycle.

By understanding how this brand new approach came about, the process of engineering can finally be traced through the project’s phases of Conceptual Design, Preliminary Design, and Detailed Design.

Summary:

This article shows that the terminology and models described within ANSI/ISA S88.01 are actually vital factors within this particular methodology, offering up a framework wherein concepts of batch control within the Functional Specification and the drawings could be organized and created throughout their lifetimes. Now that this is understood, the process can be properly seen through the different project phases.

Author

Mark Richardson
Network and Infrastructure Expert

References

Various ISPE Material

Further Reading

What do you think about this story? Have your say by leaving your comments below.

Author

Mark Richardson

Technical Expert Kestrel Life Sciences