Preparation Pays Off
Anyone who has painted a room or a house, hung wallpaper or tile, or planted flowers or a vegetable garden understands the importance of preparation. Unless the surface or soil is properly prepared, the most expensive paint, wallpaper, or plants won't yield the desired results. The same is true with control and automation systems.
Anyone who has painted a room or a house, hung wallpaper or tile, or planted flowers or a vegetable garden understands the importance of preparation. Unless the surface or soil is properly prepared, the most expensive paint, wallpaper, or plants won't yield the desired results.
Before the staff at a major nutritional baby food production facility began replacing its obsolete control system hardware and software, they knew the project's success relied on understanding every detail of what the current system could and couldn't do. Control Engineering seeks to name end-users in applications, but granted an exception here because of a business situation that emerged just before press time.) The complexity of the company's control system, installed in the 1980s, grew to accommodate more than 400 product and CIP (clean in place) possible flow paths.
Engineers at the company sought a systematic, good manufacturing practice (GMP) approach to document and review existing automated and manual procedures. They knew any approach would need to utilize ISA's S88 batch control standards, accommodate an iterative development process, and be operator and process engineer friendly.
Producing nutritional baby food requires blending and dosing wet and dry products together, running the product through homogenizers, chilling, storage, sometimes drying to a powder, and packaging.
Depending on production requirements—low iron, lactose free, soybean-based, etc.—34 base liquid products can produce more than 200 unique branded products.
In addition to several stand-alone panels, the old process control system included more than 3,000 I/O points with 270 being analog I/O points. The view-only MS-DOS-based (Microsoft disk operating system) operator interface contained more than 20,000 tags. Process control coordination was achieved via proprietary communication among six Allen-Bradley PLC 3s.
More than 20 years of process changes had left the baby-food producer's drawings, process descriptions, and software code in less-than-stellar condition.
Many at the company could explain how various processes were supposed to work, but very little was well documented. In addition, operators performed several procedures manually. Therefore, the company needed to know exactly what the existing control system was doing, so the engineers began by updating all drawings and translating PLC ladder logic into flowcharts.
Armed with "as-built" and "as-controlled" documentation, a project team was formed that included a process engineer.
About a year before launching the replacement project, the project team purchased and used Spec-Soft's PFS-Definition (process functional specification) software. The modular, equipment-centric hierarchy of the software and S88 batch control standard help establish an iterative process to develop detailed control and automation requirements, which is why it was used.
Project teams began by educating operator teams about S88 models and definitions and how Spec-Soft PFS software would document the project to match the S88 models.
Project and operator teams drew production and CIP flow paths onto the drawings and held group discussions to ensure the implemented solution would provide maximum operational flexibility. Any differences of opinions were reconciled, and a note was entered into a "discussion book," thereby creating a road map of project decisions and progress.
Use of an iterative design process was instrumental in the company's ability to develop a flexible control system solution. Engineers at the facility described it as being a lot like seeing the same movie multiple times—each viewing revealing important elements missed in previous viewings.
A key S88 feature is its emphasis on establishing a modularized physical and procedural process hierarchy that focuses on defining what equipment entities can do. Such a focus helps avoid injecting product specific requirements and helps S88 implementations maximize operational flexibility and maintainability.
Shaul Shaked, president of Spec-Soft explains, "Novice S88 developers and users seldom struggle in identifying process cells and units, but often become confused by what does or does not constitute control and equipment modules."
Questions often asked by novice S88 users include, "Can or should a control module be a collection of other control modules?" The answer is often 'Yes.'
"For example, a coordinated control strategy might require one or more proportional, integral, derivative [PID] control algorithms, multiple process measurements [transmitters] and one or more final control elements [split-ranged control valves]," says Shaked. "Additionally, the coordinated control strategy might require lead/lag, mathematical, and/or tracking interlock functions. Some S88 purist could argue that such a coordinated control strategy should be implemented as an equipment module, and not as a 'super-set' control module."
In practice, the farther down that control can be implemented in the S88 physical hierarchy, the greater the flexibility and easier it becomes to coordinate process units and cells.
That said, maintaining consistency is very important in how control and equipment modules are defined. For example, if the scenario above is implemented as a coordinated control module, then similar coordinated control modules should exist for equally complex pumps and on-off valves.
The 400 CIP valves involved in the baby-food manufacturer project provide a good example of where it's better to implement, maintain, and manage the valves as coordinated control modules. In laying out the physical models for that project, a production and a CIP model became necessary. By defining the CIP valves as coordinated control modules, it was easier for the company to develop CIP procedural model instructions.
URS to detailed design
Frequently, URS documents have little relationship to detailed design specification used to develop software code. This is unfortunate and often results in missed expectations between what those persons involved in developing the requirements specifications believe will be developed and what's actually delivered in control system software code functionality.
Because PFS supports an iterative development process that produces a highly detailed URS, engineers at the baby-food manufacturing facility could use the PFS documents as detailed design specifications, thus simplifying the documentation package provided to the system integrator (SI). Also, because the project and operator teams were adding layers of detail to a design they already understood, everyone involved was confident that the SI would deliver was what was required.
Moment of truth
While defining and documenting its control requirements, the manufacturer also evaluated potential replacement control system platforms. Several control systems were considered, with Rockwell's ControlLogix, RS-BizWare Batch, and RS-View eventually selected.
Once the control system had been selected and control and automation requirements were in-hand, Spec-Soft was asked to work with the SI selected to implement the project to ensure the final implementation conformed to the S88 models.
Shortly after implementation began, Spec-Soft released an early version of its automatic code-generator software.
The resulting application contained several hundred control and equipment modules, plus phase logic, calculations, and interlock condition logic. SPEC-Soft and the SI divided the implementation effort with the SI focused on the control modules, and SPEC-Soft developing the phase logic, calculations, and interlock condition logic.
Because no two batch control system manufacturers implement recipe information in the same way, automatically generating recipe information from generic software, such as PFS-Definition, would be difficult if not outright impossible. However, PFS-Definition did contain all information necessary for manually exporting recipe information into the RS-Batch application via aMicrosoft Excel spreadsheet.
Outside the U.S., FDA (Food and Drug Administration) compliance isn't required. However for the baby-food manufacturer's worldwide production facilities to support one another, all plants are striving to achieve GMP and GAMP (good automated manufacturing practice) compliance.
FDA regulations require IQ, OQ, and PQ (installation-, operational-, and performance-qualification) testing and documentation of the results. Because the company did a thorough job of preparing the control and automation requirements, completion of IQ and OQ was completed with few surprises.
Every month, small adjustments are made to the application software, so the engineers haven't completed PQ yet. However, they believe the tight linkage between URS and implemented control system software will enable them to pass an FDA audit.
Originally developed as a process functional specification (PFS) application, Spec-Soft has since evolved PFS into a complementary suite of applications titled:
PFS-Definition: Functional specification development and documentation software;
PFS-Review: Verifies specification accuracy using simulation;
PFS-Code: Converts specification information into controller code; and
PFS-Test: Automatic generation of testing protocols.
Based on Microsoft's SQL Server database, PFS Suite applications are available to support any size project including single users to unlimited users, and 100 to unlimited tags.
Where application information already exists, PFS Suite supports common import/export file formats, including drawing files developed and saved using the dxf file extension.
PFS-Suite tracks changes made to imported drawings and database elements, as well as changes to manually entered data and provides detailed reports of what was changed, by whom, and when.
According to SPEC-Soft, PFS-Code can generate about 80% of an application's software code in the IEC 61131 instruction list format.