S88 Builder Construction Blog
In the first part of this two-part series, I blogged about how S88 Builder is different than custom code. In this part I will address how S88 Builder is similar to a “normal” custom code, custom HMI application, system.
“Nobody ever got fired for buying IBM,” was a well-understood comment 30 years ago. I knew a number of IBMers who regularly reminded customers of this in one way or another. Do what has been successful before and, even if things blow up, you don’t get fired.
S88 Builder is a paradigm shift. As far as I know, no one has ever written a controller program that can be configured to control literally any process or developed HMI panels that exist and contain information that is configured outside of the HMI package. Sounds too good to be true. Sounds risky, but is it really?
Different, but the same
Although the S88 Builder Engine is different than any other controller program because you load it once and don’t change it, it is the same as every other controller program. The S88 Builder Engine for Rockwell’s ControlLogix platform was developed with RSLogix 5000 using the IEC standard languages. The data table is complex, but is made up of arrays of user-defined data structures just like any other program might be.
The code that supports a certain class of Control Modules (CMs) can be thought of as a sub-routine. A simple example is a common valve. The same valve code—
- Verifies that the valve is available to be acquired for a specific task, not in use or interlocked
- Opens or closes the valve
- Checks the valve’s indication limit switches, if they exist, and indicates its status
- Times for fail-to-open and fail-to-close faults
is developed, tested, validated, version controlled and used for every valve of that class in the system. S88 Builder ships with definitions for many CM classes. More can be added either by ECS or by an end user.
The code that supports a certain class of Equipment Modules (EMs) can also be thought of as a subroutine. A simple example would be delivering an amount of a material via a route of several valves, a pump and an instrument. The same EM code—
- Checks that all CMs assigned to it to accomplish its tasks are available
- Acquires or interlocks all CMs required
- Tells CMs to act according to the parameters passed (open or close, control to setpoint, etc.)
- Monitors for normal or abnormal completion of the EM task
is developed, tested, validated, version controlled and used for every task of that class in the system. S88 Builder EMs are very flexible.
The code in the S88 Builder Engine doesn’t change because the code is only concerned with equipment capability, not with how the equipment is to be used in a particular process.
Not a crazy idea, a proven standard!
S88 Builder is not a crazy idea, it is a careful and complete application of the ISA-88 standard. This standard encourages system developers to separate control of the equipment or what the equipment is capable of from control of the process or how the equipment is to be used. A valve only opens or closes. That is what it is capable of. A specific valve may direct flow to reactor “A” or reactor “B”. That is how the valve is used in the process. The code in the S88 Builder CMs is almost purely for controlling equipment to its capability. The code in the S88 Builder EMs is mostly about what to do with the equipment. Phases and Procedures are purely about what to do with the equipment. For more detail on the ISA-88 models, please see “Using the S88 Models to build a Control System” and “ISA-88 Physical Model Part 1” and following.
S88 Builder simply helps control equipment. An S88 Builder user builds a model that includes all the equipment in his system, then configures how the equipment is to be used. The model itself, that is, the set of all equipment in the process, and how the model is to be used is contained in data structures, not in code. In the S88 Builder Studio, the data structures are a Microsoft SQL Server database. In the controller the data structures are structures, such as arrays, native to the particular brand of controller being used.
It is still a controller…
The S88 Builder Engine controller code and data structures are native to the controller, just as with a custom program. They can be backed up, restored, added to, managed, etc. just as any other controller program can.
What if a plant has some equipment that needs to be separate from the S88 Builder system? S88 Builder doesn’t take over your controller! Just add some I/O and some code to run in parallel to the engine code in the same controller.
What about some custom stuff on the Human-Machine Interface (HMI) application? The HMI is still the HMI. The displays, objects, panels and pop-ups that are part of the S88 Builder solution do not have to be the ONLY displays, objects, panels and pop-ups in the HMI application.
The S88 Builder Engine is native controller code, just like any custom application. The S88 Builder model is in native controller data structures, just like any custom application. The S88 Builder HMI is just native HMI displays, objects, panels and pop-ups, just like any custom application. S88 Builder is proven, tested, and validated. A new, custom, application is, well, new, custom, needing proving, needing testing and needing validation.
So, is S88 Builder or custom code riskier? Tell me what you think below.
Stay in control!
Custom code is the traditional method for developing a process control system. ECS and I personally have developed many one-up, custom, control programs over the years. Custom programming was our only legitimate approach with the controllers available to us.
All of us have learned how to make programming easier. Reuse. Whether starting with a licensed or downloaded library object, like the Rockwell Automation Process Objects or with a program snippet that worked well on the last project, reuse of previously developed code gets us going faster and easier. I, and I suspect a number of my peers, have succumbed to writing a code generator, a program that processes a database or spreadsheet of device data to generate a controller program import file. The golden goose of reuse is the subsequent project that is so “identical” that an entire program can be reused. Just tweak out the few differences and collect the check!
- It is (theoretically at least, the above discussion of reuse aside) developed specifically for the use to which it is put. It should execute more efficiently and use memory more efficiently than a generalized program. This advantage is of depreciated value with the power and available memory of today’s controllers.
- A custom program can be made to do anything that the writer determines to do. Who needs a generalized program like Excel®? With the source code for my own spreadsheet program, 2 + 2 could be 5. The custom code includes the expression evaluation and result determination. The boundaries are limitless.
- Within the discipline of control systems, custom code is what “everyone” does. Control System Integrators (CSIs), like ECS Solutions, have been delivering custom code applications for years. Those CSIs have been successful at making end-users successful. The low-risk choice is to go with what works, right? Maybe not. Anyone still carrying a “dumb” phone?
Custom code also has disadvantages.
- More effort is required to get to a working solution. It is much quicker to add up a bunch of numbers starting with a spreadsheet than starting with a custom code development environment like Visual Studio®.
- More effort is required to add rich features an/or to modify operation after the code is fully created (unless the programmer judiciously uses subroutines and their modern cousins).
- A large project may bear the thumbprints of several programmers, making code more difficult to troubleshoot, maintain and add to through a system life-cycle.
- Custom development tends to extend to extended program debug. It is not unusual for a custom program to take weeks to debug. Conversely, with S88 Builder, ECS has started running product trials on a 12-unit process system 12 hours after the last pipe weld was cold.
The S88 Builder Engine is different than custom code.
- S88 Builder uses more processor memory and more processor horsepower than a custom program. Some applications may require more capable hardware, but the advantages of S88 Builder, including a reduction in engineering costs, far outweigh any additional hardware costs.
- S88 Builder guides development of a project strictly according to the ISA-88 standard and emerging ISA-106 concepts. The ISA-88 standard has proven over many years and many systems to be a powerful, flexible way to control a process.
- Although S88 Builder guides developing according to public standards, it is not limiting. An S88 Builder system may be extended in any or all of the following ways. An application may use S88 Builder expressions to encapsulate specific logic, ECS or a third party may develop a new Control Module or CM Wrapper for a certain use, and/or a separate controller routine which runs in parallel with the S88 Builder Engine code can be developed using all custom code.
- S88 Builder is a different paradigm. S88 Builder does not make programming easier, it eliminates programming. Whether that is a higher or lower risk proposition is debatable. Part 2 of this blog series will specifically address the topic of risk.
- S88 Builder is not custom code. It is not a reuse library used to build custom code. It is an Engine of exactly, line-for-line, the same code used to process very different data models of very different processes. The same, line-for-line, previously validated, program can make spaghetti sauce or beer.
- S88 Builder requires less engineering effort and less commissioning time for an initial system deployment. It is (typically) more flexible to use over a system lifetime because it adheres so tightly to the ISA-88 standard. New equipment can be added to the model and new product recipes written without any programming and without any downtime on the process.
- S88 Builder utilizes a complex data model that describes the physical system being controlled. Because the model is data, not a combination of code and data, it can be modified in the Studio and downloaded to a running system without stopping any processes.
Competent CSIs have long used process simulation to find software bugs prior to deploying a new control system to the field. Simulation is accomplished in two ways. One approach is to write some more custom code. For example, the simulation code may fake the program into thinking that a valve has opened a short time after the output for the valve is energized by the system logic. Another approach is to use a process simulation tool which is configured with a process model. Software simulation tools come in ranges of complexity and capability. Either can have mistakes. Simulation with S88 Builder is different than simulation with custom code. S88 Builder has built-in simulation that has been pre-tested for accuracy by ECS Solutions long before being applied to a project.
Version 2 implements a new Phase Interface with FactoryTalk Batch. This new feature offers a great example of the difference between a configured system and a custom code system. In S88 Builder version 1, or in any custom code program that utilizes Rockwell’s PhaseManager, the following process is followed to add a new report parameter to the batch record.
- The report parameter is added in FactoryTalk Batch
- Batch is synchronized with an offline copy of the ControlLogix controller program
- Code to populate the report parameter is added to the several phase routines that implement that phase for specific units.
- The modified, synchronized, program is downloaded to the ControlLogix controller, requiring all batches to be stopped or causing all running batches to fail.
With S88 Builder version 2, the process is different.
- The report parameter is added in FactoryTalk Batch
- The report parameter is added in S88 Builder Studio, and linked to value to be returned.
- The added parameter data is downloaded to the running ControlLogix controller model without stopping any batches or causing any to fail.
The model is referenced to return the report value to any specific phase instance on any specific unit. No code changed, only data changed. No programmer required; any process knowledgeable individual can be trained to use FactoryTalk Batch and the S88 Builder Studio.
So far we have been discussing controller code. Much of what has been said applies equally well to Human-Machine Interface (HMI) deployments. HMI applications are custom code and/or custom configurations. S88 Builder approaches HMI in a standard way also.
- Each of the elements of the ISA-88 physical and procedural models implemented by S88 Builder, Units, Phases, Equipment Modules and Control Modules, has a standard faceplate or panel. The faceplates and panels are rendered based on the data model. For example, an Equipment Module panel is rendered showing the set of all the Control Modules that it uses. If a Control Module is added to the set, the next time the HMI renders the Equipment Module panel, the new Control Module shows in the list. The same thing applies to the set of Phases that belong to a Unit, etc.
- The text displayed in a panel or faceplate is part of the model. If the name of something is changed in the model, it is rendered properly in all panels and faceplates.
- Devices, even simple ones like pipe segments, are linked to an ID in the data model. The data model for a pipe knows what that pipe is connected to and what material is or last was in the pipe, allowing the pipe to be rendered with a color that indicates it is full of a particular material or has residue of a particular material. No programming required; it is built into the Engine and HMI object. Other S88 Builder HMI Objects are similarly “smart.”
I could go on and on describing the differences between S88 Builder and custom code, but this post is already getting pretty long. Hopefully you have gained some understanding. If you have any questions or comments, leave them here or use our web contact form to reach me.
Until next time, stay in control!
S88 Builder Version 2 (V2) is available for public demonstration. There are a number of exciting improvements in V2 that will improve its applicability to both batch and continuous process systems.
Below is an overview of what seem to be the most exciting features. Check back for further details. S88 Builder V2—
- Is faster and more scaleable—A same-sized system runs faster or on less hardware. Larger systems can be accommodated.
- Is more configurable—Less custom code is required because more capabilities are implemented in the engine.
- Does not rely on RA PhaseManager—Using PhaseManager required a lot of custom code, much of that because PhaseManager does not map phase classes in the batch management system to phase classes in the controller. S88 Builder’s Phase Logic Interface does. OPC can be used with any batch management system.
- Has numerous Human-Machine Interface (HMI) enhancements—Most of the HMI objects have been significantly redesigned to present operators with the normal condition controls they might need without overwhelming operators with hardware and abnormal condition recovery controls unless a guided drill-in condition exists.
- Introduces Unit Actions—S88 Builder Unit Actions are most useful with continuous processes or continuous portions of batch processes to run phases and/or unit procedures.
- Allows configurable EM Coordinators—S88 Builder EM Coordinators are EMs that contain other EMs. In V1, these were custom; now they are configurable via the S88 Builder Studio.
- Introduces configurable expressions—S88 Builder Expressions are used for those little bits of logic that just won’t go into a recipe, such as “Auto Start the agitator if the tank level is above x.”
- Allows Third-Party CMs—The interface between CMs and CM Wrappers or EMs has been defined to allow addition of third-party developed CMs to the S88 Builder Engine and S88 Builder Studio.
The list could continue, but these are the big ones. In the coming weeks I hope to blog about more of these improvements. Please check back to learn more. Of course, if you are in a hurry, just contact us to set up a live WebEx. We would be happy to answer any of your questions.
Stay in control!
Every HMI package has some form of global object. A global object is imported into the HMI project. An instance of that object is placed on a particular display page. The S88 Builder HMI objects are simply global objects. A developer places them into a display page as appropriate and gives them a unique ID that identifies a particular physical device in the S88 Builder Engine copy of the S88 Builder database.
To make the HMI objects more flexible, “all” of the text in them is stored in a controller data structure. This is how a piece of equipment can be renamed in the S88 Builder Studio, the change downloaded to the S88 Builder Engine and the same, new, name will appear on every HMI station of any type throughout the control system.
Likewise, the existence of a set-point field with its default value, last operator set value, scaling, units and permissible range are configured in the S88 Builder Studio, downloaded to the S88 Builder Engine and used by the S88 Builder HMI objects.
When a new phase is added to a unit, the information for that phase, such as its name, any set-points, which EMs it might use, etc. is configured in the S88 Builder Studio and downloaded to the S88 Builder Engine. When the S88 Builder HMI object for Unit Phases is re-opened, the new phase appears in the list of available phases. The button to run it is active. The phase control pop-up can be opened and the set-point changed, within the configured acceptable range, of course.
A pipe object looks to the Engine data structure to see what color it should be. The S88 Builder Engine knows what that pipe is connected to, what status the valves and pumps in the route are in and what fluid is or was last in the pipe segment.
If this seems like a lot of tags and a lot of data flying around then network, you are right. ECS has found that different HMI packages and different OPC interface tools work very differently. However, with the power of today’s controllers and PCs, testing and successful installations have proven that this approach works. In fact, this is essentially how I understand that the Rockwell Automation Process objects (and presumably the GEMS objects) work. Any additional costs of obtaining more or better hardware turns out to be small when compared to the development engineering costs saved, the downtime avoided with shorter commissioning due to using proven code, and the lifetime flexibility of a configurable system.
Your comments are always welcome. WebEx demos can be scheduled at your convenience.
Stay in control!
The S88 Builder Studio is a computer program with an SQL Server database back end. The computer program provides the forms for configuring the many objects that make up a process control system. Wizards, pull-down menus, and error checking help a user build good, accurate configurations.
The S88 Builder Studio program is not required at run time. A representation of the system model is downloaded to the system controller(s) for use by the S88 Builder Engine and S88 Builder HMI Objects.
The major objects to be configured in the S88 Builder Studio include—
- Units (major pieces of equipment where a change is made to the product)
- Phases (recipe steps or tasks that cause changes to occur)
- Equipment Modules (teams of Control modules that work together to perform a specific task)
- Control Modules (process system components such as valves, pumps, agitators, etc.)
- Instruments (process system devices that measure or report on what is happening)
Control Modules are divided into classes. CMs can be further divided into sub-classes. A user can build a class configuration that is applied to all CMs in the class. If the CMs in the class are not truly identical, exceptions to the class configuration are configured in the individual CM. This approach is followed throughout other objects; configure a class, configure exceptions in a sub-class or individual member.
Discrete two-way valves are a built-in class. Normally Open (energize-to-close) discrete two-way valves are a built-in sub-class. The entire class, including the sub-class can be configured in one place for single output operation. A few valves have two outputs, one to open and one to close so that they fail in last position. These valves are configured individually for their exception to the class default.
Equipment Modules are configured by selecting the CMs that are required to define the route plus the control and by selecting the instrument(s) that may be used to manage and/or determine completion of the task.
An EM is used to deliver a batch of finished goods to a filling line surge tank. Material is delivered if the surge tank is not full and recycled if it is. The EM is configured with two tasks, one with the route to the filler surge tank and one with the recycle route. The surge tank level indicator is configured as a discrete instrument, then the instrument configured to select between the two tasks. A scale (analog instrument) on the finished goods vessel is used to determine that the entire batch has been transferred so the EM should shut down.
Phases are configured to align with the batch management system recipe phases. Included in the configuration are the command, status, set-point and information tags that pass between the batch management system and the controller. All S88 Builder Phases are classes, just as batch management system phases are.
Seem complicated? So is programming! In fact, the error checking, pull-down lists and (coming soon!) graphical interface make the configurations much easier than it sounds describing them in a blog. We would be glad to give you a demo via WebEx. Just drop me a line or comment below.
Stay in control!
The current (V2.0) Engine is itself made up of three major pieces and two minor ones. The major pieces are the Phase Engine, the Equipment Module (EM) Engine and the Control Module (CM) Engine(s). In a Batch process where a batch management system (BMS), such as Factory Talk Batch, is used, the Phase Logic Interface stands between the Phase Engine and the BMS. The Phase and EM Engines are tightly coupled. The Control Module Manager (CMM) stands between the EM Engine and one or more CM Engines any of which may be located in separate controllers for performance or reliability reasons.
The engines are developed entirely in the IEC languages. The are downloaded to the controllers just like any other controller program would be, using the controller manufacturer’s development software. End customers can edit, back up, download to a new physical controller, etc. just as they might with a custom controller program developed specifically for their system.
The engines execute against complex data structures which are built from the SQL database system model in the S88 Builder Studio. These complex structures are a big part of how the engines do what they do.
The Phase Engine
The data structures for the Phase Engine describe the general tasks that each Phase accomplishes by using the EM for a specific Unit or Units.The Phase Engine operates on a command from the BMS or the operator to execute a certain task such as “agitate.” The Phase Engine determines which EM to use based on either which Unit is allocated to the current BMS recipe or based on which unit phase face-plate the operator used. It manages the set-points for the phase, such as agitator speed, from the BMS and/or from the operator.
The EM Engine
The data structures for the EM Engine describe how the CMs act within a team to accomplish a specific task. The EM Engine operates on a command from the Phase Engine or the operator. The EM Engine acquires and interlocks the appropriate team of CMs, then starts them on their tasks. It monitors one or more instruments to determine whether to hold, abort or successfully terminate the task.
The CM Engine(s)
The data structures for the CM Engine describe how each component CM is to act.The EM Engine commands CMs through the CMM. The CMM, but not the EM Engine, knows to which controller a CM is attached and routes the command(s) appropriately. Feedback from CMs also goes through the CMM.
The layering of the S88 Builder Engine seems complex, but is done to build in flexibility. It does no good to implement a flexible Batch Management System without flexible controller code to support it. Too often custom programs, particularly those written by inexperienced or low-cost providers, keep the batch management system from operating the process as efficiently as it might.
The S88 Builder Engine is written in the controller native IEC languages, making it as manageable as any other controller program. In some ways it is like the custom program you might receive from another integrator. Except that it is proven, high-featured, extremely flexible and fully configurable to make the products you will make tomorrow.
Contact us at info@ECSSolutions.com if you have any questions, or just leave your comments below.
Stay in control!
One of the key benefits of a control system based on the ISA-88 standard is modularity. Modularity begets flexibility. A flexible process control system brings unforeseen benefits throughout its useful lifetime. Even simple systems can benefit from a modular, flexible control system.—Timothy S. Matheny, P.E., Modular Batch Flexibility Brings Unforeseen Benefits, Control, July 2013
This article, written by another engineer at ECS and me, relates an example of the above. statement. Our customer obtained a 10% process capacity increase. ECS has NEVER put in a batch management system without obtaining some additional efficiency which paid for the software in less than three months.
Efficiency comes from being able to run tasks in parallel. Tasks cannot be run in parallel if they are not independent or modular. Programmed systems are often not modular enough because the programmer rarely sees all of the future needs and requirements the system will have.
This is one of the reasons that ECS developed S88 Builder. S88 Builder is very modular, thus very flexible and very scaleable. With S88 Builder a model of the process equipment is configured then that model is given tasks to accomplish. The database describing the equipment and the tasks is used to control and manage the process. Need to make a change, perhaps a new product with a new ingredient? Configure the new equipment, configure the new tasks, develop the new recipe in the Batch Management package and start trials.
Work with a validated process? No code changed. The valves you added do not run their own copies or own instances of code. They run the same, already validated, code as all the other valves in your system.
I bet that you can benefit from more efficient production too. Drop me a line.
Stay in control!
Even without the standards (ISA-106) in place yet, procedure automation is already streamlining operational changes in continuous processes. —James R. Koelsch, Heard the News about Procedure Automation?, Automation World, July 2013.
As I described in a previous blog, portions of the ISA-88 standard can be applied to continuous processes. However, continuous processes have distinct differences from batch processes. A difference that I described in that previous article is in the verbs used to properly describe what happens in batch and continuous processes. A batch process transfers material from one unit to another where the next change occurs. A continuous processes produces modified material through one unit to the next, through it and so forth.
Both batch and continuous processing involve procedures. In batch processing, the procedures are obvious. Batch processing follows a recipe-procedure that guides material flow from one unit to another and other recipe-procedures that affect material changes within each unit.
Continuous process procedures are less obvious. They may exist as written Standard Operating Procedures only. They may be coded into the custom programming of the Basic Process Control System (BPCS). Types of continuous processing procedures include start-up, shutdown and product change procedures.
Moving continuous processing procedures from paper and from custom code to a flexible platform similar to a batch management system recipe is a laudable goal that will make continuous processes more efficient. It has with batch processes.
Stay in control!
In an earlier post, Using the S88 Models to build a Control System, I promised to discuss how the ISA-88 standard for batch control might be applied to continuous process control.
A continuous process can easily be broken down according to the process model, that is into stages, operations and actions. The process model remains very useful in helping us design an interface by which the operator can effectively interact with the process.
In general, the action verbs of a continuous process are different than those of a batch process. In general, materials are transferred from one batch unit to another, then acted on, then transferred to another unit for further action. If, for some reason, material cannot be transferred forward, it simply sits in a vessel until it can. In a continuous process, a material is produced into a subsequent unit where it is an ingredient in producing another material. If for some reason a continuous process cannot produce forward, it must recycle, divert or crash. A continuous process is continuously moving.
A continuous process can also be broken down according to the physical model into units, equipment modules and control modules, although the ISA-106 committee has chosen to use other words to describe these things. Again, this model is very interesting to us because the software of the Basic Process Control System (BPCS) is generally aligned with the elements of the physical model.
When S88 Builder is used as the BPCS of a batch process control system, recipe phases (part of the procedural model, implemented in a batch management system) are mapped to unit phases (or process cell phases) configured in S88 Builder. When S88 Builder is used as the BPCS of a continuous process control system, Action controls on the operator interface engage BPCs phases. (A batch management system is generally not used.)
The S88 standard offers a control system engineer significant help with breaking down a complex system into reusable unit building blocks (Control Modules) that can be assembled into a reliable, consistent control system. Because this approach retains phases, equipment modules and control modules, it retains these advantages.
By implementing this approach, S88 Builder action controls can be used to provide an operator control over phases that run continuously, phases that produce a material. Yet a batch management system can be used to exercise automatic control over phases that are part of a recipe sequence, even in the same control system.
So, our practical takeaway from this article is that significant portions of the ISA-88 standard can be appropriately applied to continuous process control. Using an appropriate standard to guide design always enhances the resultant design. Until the ISA-106 committee can complete its work, S88 is the best we have.
Stay in control!