Windows NT Workstation, the VMEbus, and Real-Time...

Windows NT Workstation, the VMEbus,

and Real-Time Control Warren D. Carew and Karl J. Prince

ith advances in computing power, W the design and simulation of complex control algorithms has become relatively easy. However, the application of these algorithms as robust, real-time control systems is a nontrivial exercise in computer systems engineering, requiring careful choice of hardware and software platforms. Flotation processes are important in the mining industries and because of their multivariable nature, require a more advanced approach for the control systems. The level control used in the flotation process is not a trivial problem and needs to be addressed so as to optimize the entire multivariable system.

Windows NTTM Workstation is be- coming a more prevalent choice of a robust operating system, providing features such as multi-tasking, a Graphical User Interface (GUI), and hardware portability. This operating system was evaluated as a platform for the realization of a real-time control system. The personal computer (PC), though popular, is not suitable for use as industrial specification equipment; an industrial hardware solution must be sought. Over the last decade, the VMEbus has emerged as an industrial standard. These computer systems are designed to withstand harsh industrial environments, providing robust, stable solutions for control problems. The system assessed in this

The authors are afiliated with the Con- trol Laboratory, Department of Electrical Engineering, University of Cape Town, Rondebosch, 7700, South Africa. Email: wcarew @ eleceng. uct.ac.za. The research was supported by grants from MINTEK,

article is a VME computer based on the Intel processor, manufactured by OR In- dustrial Computers running the Windows NT Workstation operating system.

This article demonstrates the successful application of the Windows NT- VMEbus computer system to a practical control application. The generalized predictive control (GPC) scheme, which has proven popular in industry, is applied to a multivariable laboratory flotation plant.

Introduction Flotation processes are important in

the mining and minerals extraction industries, serving to separate the valuable minerals from the less valuable materials. Usually it is the interaction between different phases of the flotation process that leads to the complications creating a multivariable system. Because of this complexity it is necessary to use control systems beyond simple designs.

The level control of a ilotation process is an especially complicated and difficult exercise [I]. The simple PI controllers utilized so often in industry are not suited for level control without taking into account the entire multivariable nature of the system. Ideally a more advanced control system needs to be employed for an optimized approach.

Expensive computer systems of the past limited the generation of computer control algorithms and sirnulators to but a few specialized control centers. Today, computing power is inexpensive and freely available in the form of higher-end workstations down to desktop personal computer (PC) systems. Writing complex code has become a daily and common ex-

ercise. While control knowledge is in- creasing, sight is perhaps being lost of the application of the theory and the implica- tions of implementing an overall robust control system.

On the industrial plant the computing power is not the only priority. Almost of greater concern is the reliability of the control system hardware. To meet the needs of industrial computing, manufacturers have developed a number of industrial-grade computers of which the VMEbus is one of the emerging stan- dards. Although the cost of industrial computer hardware is high in comparison to the desktop machines, the savings in terms of reduced downtime and improved plant performance by virtue of the more advanced control system can result in in- creased profits for the plant.

Having an industrial standard hardware platform without robust and reliable software would be ineffectual. An operating system that handles all error conditions in a predefined way is essential to guarantee system stability. While many operating systems are available, cost and accessibility are important. The Micro- soft Windows platforms have proved popular and the Windows NT Worksta- tion is a suitable solution.

An adaptive control algorithm, of some complexity, is the Generalized Pre- dictive Control (GPC) algorithm by Clarke et al. [ 2 ] . A study of the performance of GPC on an industrial multivariable problem of the flotation process was done [3]. In this article, the technical application problems and the results of ap- plying four GPC controllers to a 4x4 laboratory flotation plant are presented.

August 1997 77

The purpose of this article is to give in- sight into the technical issues that arise when control algorithms are implemented on real plants. In particular, this article demonstrates the features of Windows NT Workstation and a VMEbus industrial computer system that are necessary to re- alize a real-time multivar-iable GPC control system on a flotation plant.

The Flotation Plant The flotation process is central to the

mineral extraction industry. Essentially, it concerns the separation of valuable solid raw materials from a slurry (a mixture of water and particles). The minerals are re- moved as a frothy concentrate which is in- duced by air bubbles introduced into the

In order to demonstrate the effective- ness of a GPC control system in stabiliz- ing and controlling a flotation plant, it was employed on a laboratory flotation plant. The flotation rig is large enough that noisy industrial conditions are generated and represents a fair test of the control system. The control problem is a simple level control exercise but is complicated by the fact that the entire process is multivariable (i.e., there are interactions between plant variables). A photograph of the flotation rig is shown in Fig. 1.

slurry.

Fig. I . The flotation plant.

The four tanks in the circuit emulate the rougher, scavenger, cleaner, and recleaner of a flotation process. The transfer function matrix model of the system is:

where y l = Rougher Level yz = Scavenger Level y3 = Cleaner Level y4 = Recleaner Level

u1 = Rougher Valve u2 = Scavenger Valve u3 = Cleaner Valve u4 = Recleaner Valve

and glj' are estimated plant models of the form

Tank Level [VI bo + - -- g [ r = Valve Position [VI 1 + a,q-'

for i # j , representing interaction terms

Capacitive level probes are used in each tank and return a voltage signal pro- portional to the level. The product dynam- ics of the flotation plant are controlled via the pneumatic valves installed on the tail- ing outputs of each of the flotation cells. Each valve has a current to pressure con- verter to convert the electrical control signal into valve action.

The Generalized Predictive Control Algorithm

The generalized predictive control (GPC) method was developed by Clarke, Mohtadi, and Tuffs [2] in the mid-'80s. It is one of a number of adaptive predictive control algorithms that has proven popular. It has been applied to various control applications [4,5,6]. The basic GPC aigo- rithm is outlined in Table 1.

The GPC strategy predicts the process outputs based on future sets of control signals and minimizes some cost function in order to select the appropriate control action for implementation.

A simple example demonstrating the implementation of the GPC algorithm is given in Appendix A. This example also shows that the algorithm is fairly mathe- matically complex and would require a

substantial amount of computing power for real-time implementation.

Since the flotation plant is a 4x4 system and the GPC algorithm used is essentially a single-input single-output method, a diagonal control matrix of four GPC controllers is applied to the plant. While this may not be an optimum solution, it would demonstrate the adaptive ability of GPC in ac- commodating for the changes in plant model. Note that this method makes no at- tempt at eliminating all of the interaction between plant inputs and outputs [3].

Implementation Issues By definition from the uninet comp.re-

altime real-time FAQ: A real-time system is one in which the

correctness of the computation not only depends on the logical correctness of the computation, but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred.

Thus a real-time system requires that all I/O operations and calculations take place at the correct time instance. This im- poses the following requirements:

* Sufficient processing power (the factors being CPU and RAM)

* Sufficiently high-speed I/O periph- erals (ALD and D/A hardware)

In industrial applications, where every minute is money, reliability is essential and so is robustness-on a plant nothing is guaranteed. The system hardware must be able to endure harsh environmental conditions, and the control system must be robust in terms of noise and plant model variations. Extending the list of requirements: - Reliability (the factors here are

hardware endurability and operating system stabiliv)

I Table 1. The Basic GPC Algorithm

- Consider a particular time t as the present. A prediction model is generated based on the plant state at time t.

* For a given future setpoint, the process output is calculated, using the prediction model, over a prediction horizon. The prediction horizon being the range of future times used for predictions. Various sets of control actions arc suggested for the prediction but only the best strategy (i.e., one that minimizes some appropriate cost function of output errors and control actions) will be selected. The chosen set of control actions is applied at time t.

I - The procedure moves on to the next time instant, t + 1, and is repeated

78 IEEE Control Systems

HAL - Hardware Abstraction Layer DD - Device Drivers K - Kernel

Fig. 2. The Windows NT “core. ’’

Robustness (control algorithm and the predictable response of the operating system under all conditions)

The combination of Windows NT Workstation and VMEbus Industrial Computer system give a sound platform for the implementation of an industrial control system. In the following two sections, the critical features of Windows NT Workstation and the VMEbus Industrial Computer are discussed.

Windows NT Workstation Overview. Windows NT Workstation,

or just NT, is a 32-bit multi-tasking multi-processor operating system which has a graphical user interface (GUI). It is designed to be robust, responding pre- dictably to both hardware and software error conditions. One unique feature of the operating system is its portability. Win- dows NT has been designed to be run on different hardware platforms, such as x86, MIPS, and ALPHA. User-written applications need only be recompiled for the particular platform in order to be ported.

Windows NT is a reliable and robust system, having “exception checking” as an integral part of the operating system as opposed to leaving it to the application writer. A modular approach has been adopted-in concept as well as in coding. This has resulted in NT being a layered and serverklient-based operating system. The lowest level, known as the Hardware Abstraction Layer (HAL), isolates all the platform-specific code, presenting the kernel and executive with the same virtual machine irrespective of the underlying hardware. The kernel at the heart of NT is a dispatcher; i.e., when events (interrupts, thread scheduling, time-outs, message posting, etc.) occur within the system, it

dispatches a call to the relevant routines to deal with the situation. Device drivers ex- tend the operating system by telling it how to deal with specific devices (virtual or real) when events occur. These are the only procedures that have a privilege level high enough to directly access the hardware. By using the HAL interface, platform and processor dependency is avoided.

The Windows NT kernel and the device drivers form the basis of the operating system executive, the Windows NT “core” (see Fig. 2). The executive controls all the allocation and use of system resources. This includes allocating processing time-NT employs pre-emptive multi-tasking to provide time slices for each application. This is significantly different from the way Windows 3.1 niulti- tasks, since it uses cooperative multi- tasking, i.e., the process would tell the operating system when it was done and another process could continue execution.

The executive exists within its own memory space, referred to as system space, and all its parts execute at privi- leged processor level ring 0. This implementation of the executive ensures that user applications are not able to interfere with the operating system and that the op-

erating system has available the full processing power of the CPU available.

Within NT resources are dealt with as objects, each carrying its own data and operational code, being independent of other code. This approach has facilitated easy maintenance-as long as the interface remains fixed, code can be improved without adversely affecting other procedures. Since the operating system controls the creation of objects and therefore the resources, it is able to isolate user applications and prevent conflicts from oc- curring. Security has also been ensured by the calling of the security system on the creation of any object. All applications-or, rather, processes-are assigned their own memory space and set of resources, thus existing in their own virtual machine managed by the Virtual Ma- chine Manager (VMM) in the executive. This memory space is termed the linear memory, as opposed to the physical system memory. The operating system and its critical code and data are put in the up- per 2 gigabytes (GB) of the virtual memory and are inaccessible to user-level applications in the lower 2GB, thereby preventing the user application from stall- ing or “hanging” the operating system. User applications can and must still inter- act with the NT executive, and this is

................. ..... ..... ....

...... ..... .......

* a . ,

Services

NT Core a

....... + Lpc .... . . * I

Environment i August 1997

Fig. 3. The extended Windows NT system.

79

Table 2. Reliability and Robustness

Exception handing. Built into all layers of the operating system, assuring that all error conditions are handled in a uredefined manner.

Layering of the operating system The layers have fixed interfacing protocols and are mutually inde- vendent.

Pre-emptive multi-tasking. If an application locks up, the executive will still move on to the next process.

Isolation of applications to their own virtual machines. 1 Applications are not able to crash the operating system.

achieved through a servedclient relation- ship. The currently executing process re- quests a service (through the Local Procedure Call, LPC) from the system (server) and which on completion signals the calling process (client). This allows asynchronous I/O since the client does not need to wait for the service to complete the task before continuing on its own, but this brings in the added complexity of synchronization.

The HAL, device drivers, kernel, and executive form the engine of the NT operating system. Using the facilities and concepts outlined here, NT is able to grow, meeting the needs of the computer platform and applications that are to run on it. This is achieved by adding daemons, services, environments, and applications to the NT engine. For the purposes of this article it is not necessary to enter into these concepts in any depth; for completeness, a brief description on each will be given:

0 daemons and services are user-level background applications that typically handle functions such as printer spoolers, TCP/IP sockets, etc. the native environment is the WIN32 application programming interface (AP1)-NT can allow other environments, such as OS/2, POSIX, DOS- Windows 3.1, and Windows 95 to run on the NT engine. Applications are the user programs; the structure of these will he discussed in the next section.

Fig. 3 shows the complete NT structure, grouping the extended components, the NT core, and user applications.

Reliability and Robustness. Given the structure of NT described above, the inher- ent robustness and reliability of NT can be ascribed to the properties in Table 2.

Real-Time and Multi-Tasking Ca- pabilities. In order to understand the real-time capability of NT, it is necessary to take a closer look at multi-tasking and

related operations that allow the implementation of real-time systems.

To understand how applications are able to “multi-task’’ it is necessary to understand how programs run under Win- dows NT [7]. Once an application is invoked, this instance of the running program is known as a process. No code is executed at this time since processes really only make available address space (and at times other resources) for code and data. In order for the code to be executed, a process must contain one or more threads.

If a process has many threads, they are seen to be able to execute code concur- rently in the process-this is accom- plished by the Windows NT executive, which provides each thread with time quantums. (See Fig. 4.) It is possible to set the priority of threads so that a time- critical thread, with highest priority, is executed first and most frequently.

As mentioned earlier, NT is also a multi-processor system and employs symmetric multiprocessing. This allows the operating system to schedule tasks (execution of threads), including operating system functions, evenly across the

Code Thread n

Time Quantam

Thread 1 Thread 2

Fig. 4: Processes and threads


VMEbus conforms to the 19” standard, which makes fitting components and hardware upgrading easy.

The flexibility of the VMEbus allows it to be used as a development platform as well as for the actual implementation of the control system. This not only saves cost, but also decreases the risk of failure due to porting from the development platform to the implementation platform.

To summarize: the advantage of using the VMEbus is that there are very few concerns after having chosen the hardware for the applications environmental specification. The VMEbus hardware has a modular design based on a common back plane. The choice of CPU and I/O configuration is left entirely up to the en- gineer’s needs. The authors familiarity with Intel processors and PCs influenced the choice of a 486DX2-50 CPU module with 16MB of RAM and a 540MB hard drive. The VMEbus back plane has a number of expansion slots for VO purposes (I 2 in the above system).

For harsh environmental conditions, off-the-shelf solutions are available to the specifications shown in Table 3.

Temperature Range

Compact and Rugged Euro-Card Sizes

Fig. 5. The I/

-40°C / + 85°C

19” rack

available processors. By breaking down the application into threads, the most effi- cient use of the available processing power can be made. Even on a single- processor system, advantages can be gained by this approach as it is possible to set the priority of threads so that a time- critical thread, with highest priority, is executed first.

Threads can be assigned a priority ranging from 0 (the lowest) to 31. De- pending on the priority assigned to the process, its threads can be assigned priority levels within the related range. There are also various mechanisms for the synchronization of threads. These are necessary so that processes that a re interdependent are completed in the correct sequence. Examples of these are “sleeping,” “critical sections,” and “Wai- tOnxxxxObject” concepts, some of which will be discussed later.

To facilitate the synchronization of the system to external events, NT employs a 0 to 31 level interrupt handler. It is possible to mask off interrupt levels, thus not responding to low-priority events, but the system will interrupt any lower-priority event to service a higher-priority interrupt. This is crucial to remember in de- signing interrupt handlers-they must do the minimum amount of processing so as not to hold up the whole system. Note that

High Shock and Vibration Immunity

Conduction Cooling

‘MEbus system.

up to 40G

IEEE 1101.2

in a multi-processor system, only one processor would be interrupted while the others continued their processing as normal.

Asynchronous U 0 has built into the system the ability to queue 110 operations without waiting for slow I/O functions, such as disk access, to complete. Another important feature is the ability to lock a process memory to prevent virtual memory paging of time-critical code.

NT provides two basic forms of timers giving the user a means of measuring time steps. The standard counter, GetTickCount, gives a resolution of 10 milliseconds, and a QueiyPefomunceCounter has a varying resolution depending on the CPUs in the system (on Intel processors, this is approxi- mately 0.8 microseconds) [SI.

VMEbus Industrial Computer The VMEbus has been utilized in in-

dustry for about a decade and is reputedly one of the more popular industrial BUSes. Compared to a PC, the VMEbus is more suited to the industrial environment. The shock and vibration strength and temperature range of the VMEbus boards are su- perior to those of cheaper PC systems. If necessary, the VMEbus system can be protected in watertight and dustproof housings. Noise immunity is a design as- pect that the manufacturers have also taken into account. Furthermore, the

Implementation Software To get the most from NT, the applica-

tion must be written and compiled for NT. As mentioned, NT supports DOS, Win- dows 3.1, and Windows 95 applications; however, none of these operating platforms have all the features of NT and therefore the application would not take full advantage of these benefits. To ex- tract the 32-bit processing power and for ease of interfacing with the Windows Ap- plication Programming Interface (Win32 API), the Microsoft’s Visual C++ and the Microsoft Development Platform were used as development tools.

To implement a controller under NT there are two parts to the problem. The first is that NT needs to be told what hardware is available and how to use it;

I Moisture Protection 1 MIL-1-46058 I 1 *Reference- Embedded Single Board PCs OR also see Motorola VME Module Selection Guide I

August 1997 81

Table 4. The Device Driver

NTSTATUS DriverEntty (IN PDRIVER-OBJECT Driverobject,

This function is called by the Operating System at the time of starting the device driver. Typically its functions are:

Registering hardware resources (IoReportResource Usage) * Creates the Driverobject (IoCreateDevice) e Specifies the functions to be called when the device driver is accessed farther by user applications or the operating system (Device IoControl and DriverUnload functions) * Creates a symbolic link (IoCreateS)ImbolicLink) The specific VMEbus driver functions implemented here are: * Initializing the VMEbus interface e Maps the VMEbus window to linear address space

NTSTATUS VMEbusDispatch (IN PDEVICE-OBJECT Deviceobject,

This function is the entry point for the user application calls to the device driver using the DeviceIoControl function. The Irp structure facilitates the selection of minor functions and the transfer of data between the device driver and application. Specifically the VMEbus driver function implement here is returning the pointer to the VMEbus window.

IN PUNICODE Registrypath)

IN PIRP Irp)

NTSTATUS VMEbusUnZoad (INPDRIVER-OBJECT Driverobject) This function, specified in the DriverEntry procedure, is called when the device driver is stopped. Typically its functions include: * Freeing any resources being used by the device driver * Removing entries from registry * Deleting the symbolic link and the device object (IoDeleteSymbolicLink and IoDeleteDevice)

and the second is the implementation of the mathematics of the control algorithm and user interface to this hardware. The solution to part one is found in writing a device driver and to part two in the development of a user interface for the control algorithm. It is possible to write a console application under NT; this is a proper NT application, but instead of having a Win- dows graphical user interface, it is is a text-based application. Only in cases where processing power is absolutely critical would it be advisable to write a console application. The Windows environment is far more user-friendly and flexible. It makes features such as moni- toring signals and changing parameters on-line a natural part of the application.

Interfacing with the Hardware For the IBM-compatible processor

system, the OR VMEbus (OR Industrial Computers GmbH, Germany) is initialized via control registers found in the ISA I/O space. Through these, the mode of op- eration for the VMEbus system can be selected and the bus activated. There are

several modes in which access can be obtained; for the application discussed here the short address mode is used. This effec- tively maps the VMEbus I/O addresses to the CPU memory space.

Device Drivers The function of a device driver is to ex-

tend NT to deal with devices, whether they are virtual or, as for this application, real hardware. Coding a device driver is a

complex programming exercise, but it is in the complexity that assurance of a robust operating system lies. Device driver code executes at the highest processor privilege level, which means that the in- tegrity of the system can be violated by ir- responsible programming. This level gives access to hardware commands, such as inp() and outp(),as well as access to the entire 4GB CPU address space.

NT maintains a system registry, con- taining the address space and resources used by specific devices. This is necessary so that the operating system can re- solve hardware conflicts, among other reasons. The structure of the device driver is given in Table 4.

Interrupt handlers and direct memory access (DMA) routines for high-speed sampling could have been implemented at this level, but were not essential for this application example. This was due to the relatively long sample time of 1 second required on the flotation plant.

The device driver can be compiled by using the device driver kit (DDK) from Microsoft (available as part of the Micro- soft Development Platform) [9]. For ease of using the device driver functions, a standard C++ class can be developed to hide all the details from the user’s application.

I/O Interface A single instance of the C++ class,

VMEbus, is constructed globally for the application process. All service calls to the device driver with the DeviceIoCon- trol function are made from within this class. This removes concern over the device driver from the application writer. For the VMEbus, the functions that are required are AD reading and D/A writing functions. The public functions of the VMEbus class are given in Table 5.

It is possible that various threads within the process would make calls to these func-


Table 5. The Public Functions of the VMEbus Class

VMEbus:: VMEbusO The class constructor implements the following: 0 Creates a handle for the device driver (CreateFile)

Obtains the pointer to the VMEbus window (DeviceIoControl) Initializes the critical sections (InitializeCriticalSection)

0 Does the standard ADC and DAC initialization through the memory window

double VMEbus :: ADC (UCHAR channel-) Indicates the beginning of a critical section

(EnterCriticalSection) Accesses the A/D through the memory window Indicates the end of the critical section (LeaveCriticalSection)

0 Converts the 12-bit number to a voltage value

double VMEbus :: DAC (UCHAR channel-, double value-) Converts the value- from voltage to a 12-bit number Indicates the beginning of a critical section

(EnterCriticalSection) 0 Accesses the AID through the memory window 0 Indicates the end of the critical section (LeaveCriticalSection) 0 Converts the 12-bit number to a voltage value

VMEbus :: -VMEbus () The class destructor frees the critical sections (DeleteCriticalSection)

User Interface

Doc DOC Doc Scavenger Recleaner Cleaner Controller Controller Controller

Document Controller

Common

Real Time - 1

Common GI Common

I/O Interface a +zL-cla I

Scavenger Recleaner Cleaner Rougher

Hg. 6. The application structure.

tions ‘‘simultaneously.’’ This would obvi- ously cause chaos, with the hardware re- ceiving possible conflicting commands. This problem is a result of the nature of the multi-tasking environment and is known as “Synchronization.” One of the mechanisms for dealing with the synchronization problem is the “critical section.”

“Critical sections” are easily under- stood and implemented. To clarify, “critical” here means that if a piece of code is being executed by another thread, the current call would have to wait for the origi- nal call to finish with that section of code, i.e., a section of non-reentrant code. Within the process a CRITICAL-SEC- TION class for each critical region is defined and then initialized with a call to InitializeCriticalSection. When entering the critical region, call EnterCriticalSec- tion and when ending it, call LeaveCriti- calsection. When another thread tries to enter that region the operating system puts it to sleep until the thread currently in the critical section leaves. Putting a thread to sleep means that the thread will only continue execution after some system event. In this case it would be the flag re- ceived by the Executive that the critical section has been left.

Application Software The application defines the user inter-

face, generates the real-time threads, and constructs the instance of the U 0 interface class, VMEbus. The skeleton of the critical application code is given in Table 6.

Using the Microsoft Foundation Classes (MFC) in Visual C++ facilitates the easy generation of a user interface. The CGPCDoc class, created from the MFC CDocument class, forms the basis for each controller implementation. The user is able to open several documents, or GPC controllers, as separate windows within the application.

Within the CGPCDoc class the real- time thread is generated using Cre- ateThread and the priority set using Set- ThreadPriority. The thread is associated with the real-time process via a pointer in a dummy thread procedure, RealTime- DummyProc.

The CGPCDoc, and any instances of the same, run within the single user interface thread. The primary purpose of CGPCDoc is to allow the user to config- ure the specific controller (e.g., the GPC parameters, running time of plant, VO interface ports, etc.). All these are stored in a common datdstatus area so that the

August 1997 83

Table 6. Critical Application Code

CGPCDoc :: CGPdoc() { /I Initialize variables

//Variable test to true to terminate thread execution bFinished = FALSE; /I Create thread .... hThread = CreateThread (NULL,O,

....

(unsigned long(-stdcall*)(void*) &RealTimeDummyProcedure, this,O,(LPDWORD)&dwIDThread));

/I Set Thread Priority ... = SetThreadPriority (hThread, THRE AD-PRIORITY -TIME-CRITIC AL) ; .... 1 inline long WINAPI RealTimeDummyProc (CGPCDoc *fpObj) { /I This is a dummy function to call the actual real-time thread I/ This function must be included as a friend function to GPCDoc return fpObj->ReaZTimeProcess();

void CGPCDoc :: RealTimeProcess() { // Specify the sample time interval (in milliseconds) long sample-time = 1000; // Specify the idle time interval (in milliseconds) /I / I if the bStarted flag is set long idle-time = 10; I / While thread still active ... while (!bFinished) (

I/ Start process if flag set in Common Status variables if (bStarted) (

this is the amount of time before the thread will wake to check

/I Initialize variables for new run t = 0 ; do (

I/ Get the starting time of this sample instance clockticks = GetTickCountO; I/ Get the current plant output plant-output = VMEbusDAC (channel); / I Calculate the GPC control signal control-signal = GPC (control-signa1,plant-output,t); / I Output control signal to plant VMEbus.ADC (channe1,contxol-signal); /I Post any update screen messages, etc.

I / Sleep until next sample time Sleep (samplectime - (GetTickCount() - clockticks)); t = t + sample-time;

.....

] while ((t < end-time) && (!bFinished)); I else

Sleep (idle-time); 1

1 CGPCDOC :: -CGPCdOC() { /I Indicate that thread must finish bFinished = TRUE; I/ Close thread handle CloseHandle ( hThread); .....

real-time thread has access to the information and can adapt the running of the controller to match these settings.

The timing for the real-time thread comes from the use of the Sleep function. In this instance the thread puts itself to sleep for a specified time interval. When the interval expires, the “Executive” con- tinues the processing of the thread. At the highest priority level, this happens imme- diately after the interval expires.

A 4x4 GPC Diagonal Controller To control the flotation plant, four

GPC controllers are required. In NT, this corresponds to the user opening four controller “documents,” thus creating four instances of CGPCDoc and the associated real-time threads.

Each GPC controller is associated with an input/output pair for the specific tank it is to control. Fig. 6 shows the application structure and tank positioning in the system. The separate threads are indicated as well as the U 0 interface.

Each of the four documents share one user interface thread. On their creation, they generate a separate real-time thread for the controller they represent. The 1/0 interface section, which is driven by the real-time controller, deals with the critical sections, the device driver interface, and ultimately the flotation tanks.

GPC Flotation Results To demonstrate the control system,

one of the tank levels on the flotation plant is stepped and the levels of the other tanks are held constant. A typical run is shown in Fig. 7.

Results for step changes the other tank levels is shown in Appendix B. The control system developed using the GPC method is shown to be capable of controlling the tank levels well. While there is still some interaction present, the dis- turbances via the model changes are eliminated.

An output screen of the program is in Fig. 8. The panels are the four instances of the controllers (CGPCDoc classes): Rougher, Recleaner, Scavenger, and Cleaner.

This run was taken when the plant was in an equilibrium state and the controllers were activated at time t = 0. The time divisions are at 100-second intervals. Fig. 9 shows a maximized view of the Recleaner Tank with the setpoint being stepped.

IEEE Control Systems

8.2

8.4

m a, 2 8.2 [r

c? I i8': 8

8.1 - a,

-1 2 j 8 ln 3

7.9 I Time [SI

50 100 150

Time [SI

I 8.1 - 2 J

c m 0)

$ 8

U

8

7.9 7.9

7.8 0 50 100 200 0 50 100 200

Time [SI Time [SI Fig. 7. Typical results for recleaner stepped.

A typical dialog box, in which the GPC parameters can be altered, is included on the display. As is evident, the interface provides for clear and easy observation and editing of control parameters, view- ing parameters, etc.

Conclusions The application of GPC to the flotation

plant proved successful. The algorithm was sufficiently adaptive to deal with the changes in plant model due to plant interaction. As is evident by the success of the control system, the computing platform has proven adequate.

A necessary realization in the control industry is the fact that real problems need practical solutions. The use of computers in industry requires not only that there be processing power, but that the computer system be rugged and capable of handling the harsh conditions prevalent in industry.

The Microsoft Windows NT operating system is suited to providing a solution for those looking for a robust operating system, yet with an easy-to-use GUI. It has been shown that the system is portable and

can be customized, thus allowing any hardware platform to be used.

From the development of this GPC control system, it has become evident that a general-purpose real-time control system environment would be easily implemented. This would allow different control algorithms to be incorporated into a common interfacing package.

Appendix A The complexity of the GPC algorithm

is demonstrated by a simple example. The plant assumed is of the following order:

U ( f - 1 )

The output is given by y, the control signal by U. The reference (setpoint) signal is indicated by r. q-' is the backward shift operator and ai, bi are real constants.

The GPC parameters are selected to be N1 = 1: min. prediction horizon N2 = 3: m a . prediction horizon Nu = 3: min. control horizon h = 0.1 dumping factor

From the recurrence equations: ej=.tjo ,

Ej+l =E; + q-Jej Initializing:

Fj+1 = Fj - AAej

E1 = 1 F1 = @'(l - A A ) - 1 = (1 - a1) + a1q

eo = 1

Continuing, E2 = E1 + q-'el

f i o = (1 - ai ) f l l = a1

F2 = Fi - AAel = 1 + q- lq = [1 - U l ( 1 - a111

+ U l ( l - adq- el =fia f20 = 1 - at(1 - U11

fil = Ul(1 - a d E3 = E2 + F3 = F2 - AAe2 = 1 + q-'el+ q-2e2 = [ I - al(1 -

al(1 - 4 ) l + Ul(1 - U l ( l -

a1 ))4-1 e2 =f20 f30 = 1 - ai(1 - ai(1 - ai))

For the rest of the example we shall choose a specific plant to demonstrate the procedure (for an on-line GPC strategy the plant is identified via a recursive least squares algorithm-RLS).

f31 = al(1 - al(1 - al))

Let

August 1997 85

__ ___ - Fig. 8 Screen ofwindows NT GPC Controller

Fig. 9. Maximized view o f controller.

A(q-') = 1 - 0.5- ' B(q-1) = 1 - 0.9q-' From the GPC identity: 1 = E,AA +

Note that the C polynomial is set to 1

j = l 1=(1 -1 .5q - 1 -0.5 ) + 3.1q-2 + 1.575q-3

j = 2 1 = (1 + 1.sq- ) (1 - 1 . 5 ~ - 0.5q-2) +q-' (1.75 - 0.75q-')

j = 3 1 = (1 + 1.Sq' + 1.75q.') (1 -

- 0.875q-I) G I = E1B = 1 + 0.9q- G2 = E2B = (1 + 1.5q-') (1 + 0.9q-')

G3 = E3B = (1 + 1.Sq-l + 1.75q.')

1

q-jFI

for this example.

= 1 + 2.4q-' + 1.35q-2

(1 + 0.9q ') = 1 + 2.4q-'

Now find the predicted process outputs, splitting them into information known and not known at time t ,

1 + q-'(1.5 - 0.5q yL2 )

I

1

1.5q-' - 0.5q-2) + q-2(1.875

i = G c + f

. i ( t + q t ) ] I 1 0 0][ Au( t ) 1 ?(t+;?lt) = 2.4 1 0 Au(t+1)

;(t + 3lt) 3.1 2.4 1 Au( t+ 2)

L5y( t ) - O.Sy( t - 1) + 0.9A~( t - 1) 1.75y( t ) - 0.75y( t - 1) + 1.35Au( t - 1)

1.8753/( t ) - 0.875~( t - 1) + 1.575Au( t - 1)

In order to find the control law, we now have to find

( G ~ G + IA)-'G~

0.5250 0.2653 -0.06911 -0.9947 0.1133 0.2653 0.6908 -0.9947 0.5250 1

Using the first row of the above matrix, a setpoint and the previously defined vec- tor f, the GPC control law can be obtained:

Au(t) = first row of(GTG + IA)-'GTI [r - f l

0.5250 1' ' ( t + 1) - LSy( t ) ... 4u( t ) = 0.2653 y(t + 2) - 1.75y( t ) ... [ -0.069 1 e [ Y(t + 3) - 1.875y( t ) ...

_ _ _ + 0.5y( t - 1) - 0.9Au( t - 1) 1 ... + 0.75y( t - 1) - L35Au( t - 1)

... + 0.875~( t - 1) - L575A~( t - 1)

Au(t) = 0.525r(t + 1) + 0.2653r(t + 2) - 0.00691r(t + 3) - 1.1222y(t) + 0.401y(t -

1) - 0.7218Au(t - 1)

The control signal then implemented at time tis:

~ ( t ) = 0.252r(t + 1) + 0.2653r(t + 2) - 0.0691r(t+3)- 1.l225(t)+O0.401y(t- 1)- 0.2782u(t - 1) - 0.7218u(t - 2)

Appendix B For completeness, the typical step re-

sponses of the other tanks are presented here. Note that the scales on the graph of the stepped tank and the graphs of the other tanks are different.

References [ 11 MINTEK, "Level-Control Program for Flota- tion Plants (Floatstar Controller)," Engineering nndMining Journal, vol. 195, pp. 56, September 1994.


8.1 - 8.1 I 7.9 t 7'9 t 8.2 I

Time [SI

8.8

Time [SI

8.6 8.1

a, - a, -I

-

5 8.4 3 L

b g 8.2

g 8 C

2 0 U a,

v)

8 7.9

8.2 8.2

7.9

7.8 0 50 100 150 200

Time [SI

8.8

8.6 - 9 3 8.4 L

a, Is)

8.2 3 0

L

2 8 - g d 0

7.9

0 50 100 150 200

Time [SI

8.2

7 . 8 " " " ' " ' ' ' ' ' " ' ' : ' 0 50 100 150 200 0 50 100 150 200

Time [SI Time [SI Fig. 11. Results for scavenger stepped.

August 1997 87

8.6 8’8 T 8’2 1

7.8 50 100 150

Time [SI

8.2 I

7.8 50 100 150

Time is1

50 100 150 Time [SI

7.84 I ; ; + I ! : ! I ! I : I : ! ! I I ! I ! ! : !

50 100 150

Time [SI Fig. 12. Results for recleaner stepped.

[2] D.W. Clarke, C. Mohtadi, and P.S. Tuffs, “Generalized Predictive Control: Parts 1 and 2”. Automatica, vol. 23, pp. 137-160, 1987.

Proceedings of the IEE-Part D, vol. 139, July 1992.

[6] R. Soeterboek, “Predictive Control: A Unified Approach,” Prentice-Hall International, UK, 1992.

[3] K.J. Prince, “Generalized Predictive Control: A Study and Application,” MSc Thesis, Univer- sity of Cape Town, submitted.

[7] J. Richter, “Advanced Windows: The Devel- for Windows NT

3.5 and Windows 95,” Microsoft Press, 1995.

[4] D.W. Clarke and C. Mohtadi, “Properties of Generalized Predictive Control,” Automatica, vol. Guide to the W1N32

25, pp. 859-875, 1989.

[5] M. Mahouf, D.A. Linkens, A.J. Ashbury, W.M. Gray, and J.E. Peacock, “Generalized Pre- dictive Control (GPC) in the Operating Theatre,”

[81 Microsoft Corporation, “WIN32 SDK: software Development Kit,” Microsoft Development Library, 1995.

[9] Microsoft Corporation, “WIN32 DDK: Kernel-Mode Driver Design Guide”, Microsoft Development Library, 1995.

[lo] K.J. Astrom and B. Wittenmark, “Computer Controlled Systems: Theory and Design,” Prentice-Hall, Englewood Cliffs NJ, USA, 1984.

[I 11 Microsoft Corporation, “Real-Time Systems and Microsoft Windows NT,” R. Asche, “Using Multithreading and C++ to Generate Live Ob- jects,’’ R. Asche, “Multithreading for Rookies,” M. Blaszczak, “Beginner MFC Architecture,” H. Custer, “A Grand Tour of Windows NT: Portable Multiprocessing Comes to Windows,” Microsoft Development Library, 1995.

1121 Microsoft Corporation, “Visual C++ User’s Guide,” Microsoft Press, 1995.


Windows NT Workstation, the VMEbus, and Real-Time...

Documents

Transcript of Windows NT Workstation, the VMEbus, and Real-Time...