A schematic of the closed loop controller environment for a radial AMB is shown in Figure 1.1 (note that for simplicity, the axial components have been removed from the schematic, however it must also be controlled by our controller implementation platform.).
For our AMB example, the rotor displacement is first monitored by a set of eight eddy current sensors, paired up differentially. Second, these sensor signals are conditioned by a set of sensor electronics which in turn produce four signals which are proportional to the relative displacement of the rotor with respect to the housing along the lower X, lower Y, upper X, and upper Y directions. Third, each of the sensor signals is then filtered via a set of anti-aliasing filters. Fourth, the output of the filters is then fed to the controller. Next, the controller produces effort signals for each of the four control axes. Finally, these effort signals are sent to a set of amplifiers which in turn produce the necessary currents to produce forces that act on the rotor via the magnetic actuators.
For most ACSs, the controller is bound to go through many revisions, including implementation, structural, and parameter changes. Consequently, the controller implementation platform must be flexible enough to allow for all these changes. Most importantly, we must recognize that with each new success with a given controller, new controllers or improvements will be made which will complicate the controller implementation. As a consequence, the controller implementation platform must provide a high degree of flexibility.
Implementation revisions, for example, entail the migration of the controller to faster and more robust computational engines or I/O components. These upgrades would be implemented as these new components become commercially available.
Structural revisions, for example, entail changing the entire controller from a five degree of freedom PID controller, to a state space controller, to an LPV type controller. Other structural changes could entail sampling style (e.g. either clock or event driven).
Parameter based revisions would assume a fixed controller structure but would assume that the controller parameters are incorrect. An example of a parameter based revision is the actual changing of either a proportional gain in a PID controller, or a full matrix in a state space controller.
The controller implementation platform must simplify the implementation process for all of the above. In summary, controller implementation requirements for the CTR are as follows:
Architecturally, the controller implementation platform must meet the following requirements:
Traditionally, DSP systems have been used in controller implementation for magnetic bearings. Most of these have been based on the Texas Instruments C40 DSP. As of late, the emphasis has been moving towards much faster Texas Instruments C62 and C67 (without and with floating point registers, respectively) DSPs. As of the time of this writing, however, there are not many commercially available control boards based on this latter form of DSP. Consequently, implementation of a controller solution that satisfies all of the aforementioned controller and architecture criteria using a DSP system is not plausible.
A DSP based solution would further complicate matters. DSP RAM is
extremely limited due to the high cost of high speed RAM.
Consequently, logging of variables during an extensive control run is
certainly not possible. For example, most DSP systems have memory
sizes of at most to
kB. Therefore, a controls engineer wanting to
log ten variables (e.g. five position signals and five control
efforts) plus a time variable at a rate of
kHz would only be able to
log data for less than one tenth of a second, or
seconds for a
kB system, and twice that for the 64kB system1.2.
The design cycle of a DSP based embedded hardware system also limits controller growth. First, the embedded system design company (the vendor) selects a chip from the existing ones in the market. Second, it designs and manufactures a board and a set of software routines to go along with it. Third, the vendor promotes and markets the embedded system, at which time the controls engineer (the end user) purchases it. However, by that time, the chip that was originally used in the embedded system has become obsolete, while newer and faster chips are already in the market.
From the above then, a leading edge controls company is limited by both the turnaround time necessary by the embedded system vendor to develop an embedded system with the latest chip technology, the physical RAM in the device, and the degree of flexibility of the embedded system. Furthermore, the complexity of the controller that a controls engineer can implement is limited by both the availability of a chip that is fast enough to calculate the controller algorithm, and the hope that an embedded controller company will design both the necessary DSP and the desired I/O features into the embedded system. Even then, once the new embedded system is released, the controls engineer must learn its use.
Vendors of embedded systems rarely make provisions to interface older boards with the newer ones. It follows then, that when a controls company decides that their embedded system is too slow to handle a given controller algorithm, the embedded system is both usually either discarded or forgotten and replaced with a newer, faster system. Not only is this wasteful, but it also becomes extremely expensive in the long run, especially since controller algorithms are increasingly more complex and require faster computational engines.
Controls engineers are limited by the proprietary hardware of the embedded controls system. If the manufacturer of the board does not create the appropriate plug-in or interface that is applicable to the immediate design problem of the controls engineer, then the controls engineer cannot use it, even if the rest of the market is saturated with boards and plug-ins for other non-proprietary systems. For example, during the controller implementation phase for a five degree of freedom magnetic bearing suspending the impeller for a centrifugal flow ventricular assist device, five A/D inputs, nine D/A outputs, and one digital input pin were needed [Hil98]. However, the affordable DSpace Boards boards did not have either enough I/O ports nor computational capacity to satisfy this criteria. Consequently, a Pentium II-333MHz computer was purchased with three I/O boards which together were able to satisfy the I/O requirements.
Fortunately for most controls applications, commodity personal computers (PCs) and hard real time scheduling algorithms exist which will satisfy the computational requirements of most of the controllers that are to be implemented. Thus, it would be possible for the control development team to use commodity PCs for hard real time control. Furthermore, due to the extremely fast rate at which faster commodity CPUs hit the market, it would be possible to implement increasingly complex controllers at a rate that match market demand of commodity CPUs for a price that is well acceptable for the controls engineer's budget.
The field of Real Time computing has made considerable advances in the last decade. That is, powerful scheduling algorithms have been developed which schedule tasks in and out of the CPU in a predictable manner. These scheduling algorithms are then implemented in hard real time operating systems, which in turn supply all the appropriate real time services needed by an application. The real time application communicates to the operating system via a set of built in Application Programming Interface (API) functions - the mechanics of which are completely hidden from the programmer, but for which explicit response timing is known.
Traditionally, most PC based real time applications used by controls engineers are still based on DOS based computers and thus lack GUI, networking, scheduling, and prioritizing functions [Rip89]. These computer codes have been ``hard wired'' for a particular control algorithm to give both the correct timing and scheduling. In the event that the control algorithm changes, then the timing and scheduling may no longer be correct. On the other hand, by using a real time operating system, the programmer can not only change the control algorithm, but also provide networking and GUI functions without needing to worry too much about timing, since the operating system will switch between these tasks according to some powerful built in scheduling algorithms and the CPU states1.3 1.4.
Most ACSs requires multiple computational tasks. For example, in an AMB system these would include (in order of importance)
Commonly, each of these tasks is implemented digitally as a sequence of commands which are interpreted by a digital computer, one command at a time. Normally, all of these tasks are easily implemented if enough independent computational engines are available unless restricted by factors such as hard disk, network, or bus access times [Sta88,SB95].
However, many applications of AMBs have a need for highly efficient inter-task communications, controller weight limitations, controller size limitations, cost limitations, or other factors. Thus, the solution is to implement all of these tasks in one single CPU (or a collection of networked CPUs) by the use of Real Time systems, using some of the many optimal scheduling algorithms that are currently available in this field.
Full embedded control most ACSs usually requires significant computational effort. In AMBs, for example, the only way to stabilize an AMB system is via a properly designed closed loop controller executing at an extremely high rate. However, in order to correctly tune an AMB controller, the controls engineer needs to fully evaluate AMB performance via considerable access to plant input/output (I/O), controller states, and controller parameters. Most importantly, and for safety reasons, in high speed AMB applications the controls engineer needs to get access to this data from a safe location which may or may not necessarily be even in the same building.
The success of the ACS is heavily dependent on the proper design and implementation of the controller. In turn, the controller relies heavily on a priori knowledge of the plant dynamics. Thus, considerable modeling, characterization, and controller parameter calibration effort is necessary during the early controller implementation stages for a given application.
An important aspect of real time computing is the effectiveness of resource allocation strategies so as to satisfy stringent timing-behavior requirements [Sta88]. The proper design of a real time control system requires solutions to many interesting problems - for example, specification and timing behavior, and programming languages semantics dealing with time, and the use of timing constraints. The correct functioning of the system depends upon an implementation which evaluates the logical power of different forms of timing constraints in solving various coordination problems and determines the least restrictive timing constraints sufficient for the control system. Unlike other combinatorial scheduling problems in operations research which mostly deal with one shot tasks, in real time control systems, the same task may recur very often, either periodically or a irregular intervals, and thus may have to synchronize or communicate with a number of other tasks [SB95].
The primary objectives of real time systems design for automatic controls include
Reliance on clever hand coding and difficult to trace timing assumptions - as is normally done in PC-DOS applications - are major sources of bugs in real-time programming that can be avoided with recent advances in real time structured computing resources such as Linux and Real Time Linux. Real Time Linux is an add-on to the Linux operating system which converts the Linux OS into a hard real time environment by implementing any of many powerful Real Time scheduling algorithms.