S88 recipe management techniques use many of the same terms and embody many of the same principles as OOP, so OOP is particularly well-suited to S88 implementations.
Although S88 was originally conceived for batch processes, Procter & Gamble and other large processors are now using S88 concepts for continuous process control.
According to David Chappell, a technology leader with Procter & Gamble in West Chester, Ohio, his company has successfully created several hybrid (batch & continuous) process control applications. "These hybrid systems benefited greatly from the modular approach described in the S88.00.01 standard," says Chappell.
OOP for GUIs
At Deseret Labs, GUIs are developed using Microsoft's MFC. MFC is a set of classes (or a library) designed to implement GUIs. It is provided when one purchases Microsoft's Visual C++. Text editors, buttons, and other GUI elements are part of MFC. Such libraries are often contained in programming language software packages.
GUI elements contained in MFC are referred to as controls and ActiveX controls by Microsoft. These elements are user interactive object entities that a user can click on to simulate operation of a knob, button, or dial.
When creating GUIs, it is important to manage the position, size, and other attributes of all its elements using the same routines. Otherwise, separate routines have to be written to manage each GUI element. The OOP inheritance scheme is perfect for this task.
With Visual C++, GUI elements are derived from (children of) CWindow. CWindow (part of the MFC library) is a core window functionality class that contains the generic position, sizing and other functionalities inherited by nearly all of the MFC classes. See Figure 1 for a diagram of the inheritance linage of a simplified GUI class hierarchy.
GUIs generally operate with what is called event-oriented programming. That means that there is a never-ending loop which scans the system for events like a mouse click or a key stroke. The loop then hands off information about the events (as well as CPU control) to event recipients.
With Visual Basic (VB), if one object receives the CPU control from the event loop and doesn't give it back, the entire application freezes. With VB, it is also possible for a particular window to grab the event loop for itself and stop the rest of the application. VB.NET and other OOP languages such as Visual C++ also can solve this event loop problem.
With Visual C++, the event loop/GUI architecture is thread-safe. A thread is a collection of code, like an event loop, that executes simultaneously with other threads. More precisely, a thread is a collection of data managed by the operating system.
The operating system examines data as it schedules tasks for CPU time. The operating system will set up the CPU, begin executing code, stop and come back later to do more.
Because separate threads access the same data space, they can trip over each other by trying to change the same data simultaneously. Avoiding this mishap requires synchronization, which means that threads block each other from accessing resources. Synchronized code becomes thread-safe and can tolerate multiple simultaneous threads without crashing.
Visual C++ programs can therefore operate multiple GUI windows without having them block each other while effortlessly managing I/O access at the same time. The cost for these advantages is elevated programming effort required by OOP in general and C++ in particular.
Control algorithms can be easily programmed as objects with OOP. Keeping algorithms generic is a key concept, because generic control algorithms are reusable where specific algorithms are not.
Many OOP libraries support advanced control concepts like fuzzy logic and neural networks. Fuzzy logic algorithms can be very good for managing extreme complexity. Neural networks are prized for their ability to learn what to do with just a few training examples. Fuzzy-neural systems combine the two.
Finite state machines are a common example of OOP control algorithms. If a process machine has several different behaviors rather than just one, a finite state machine keeps track of which behavior is currently running with a state variable. Example states might be drying, stirring, and heating.
Events such as button pushes or reaching an end-point can trigger a change of state. When the state changes, different code executes and the machinery behaves differently. Finite state machines are very debuggable, easy to validate, inherently well organized and stable.
Matt Scott is the engineering team leader for Desert Laboratories in St. George, Utah. He holds a composite masters degree in technical computer science/physics from Humboldt University of Berlin. Scott can be reached at email@example.com.