File: node2.html

package info (click to toggle)
rtlinux 3.1pre3-2
links: PTS
area: non-free
in suites: sarge, woody
size: 4,892 kB
ctags: 4,228
sloc: ansic: 26,204; sh: 2,069; makefile: 1,414; perl: 855; tcl: 489; asm: 380; cpp: 42
file content (463 lines) | stat: -rw-r--r-- 18,656 bytes
parent folder | download | duplicates (2)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<!--Converted with LaTeX2HTML 2K.1beta (1.48)
original version by:  Nikos Drakos, CBLU, University of Leeds
* revised and updated by:  Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
  Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>Motivation</TITLE>
<META NAME="description" CONTENT="Motivation">
<META NAME="keywords" CONTENT="rtic">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="LaTeX2HTML v2K.1beta">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

<LINK REL="STYLESHEET" HREF="rtic.css">

<LINK REL="next" HREF="node3.html">
<LINK REL="previous" HREF="node1.html">
<LINK REL="up" HREF="node1.html">
<LINK REL="next" HREF="node3.html">
</HEAD>

<BODY bgcolor="white">
<!--Navigation Panel-->
<A NAME="tex2html140"
  HREF="node3.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
 SRC="/usr/share/latex2html/icons/next.png"></A> 
<A NAME="tex2html138"
  HREF="node1.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
 SRC="/usr/share/latex2html/icons/up.png"></A> 
<A NAME="tex2html132"
  HREF="node1.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
 SRC="/usr/share/latex2html/icons/prev.png"></A>   
<BR>
<B> Next:</B> <A NAME="tex2html141"
  HREF="node3.html">Real Time Systems</A>
<B> Up:</B> <A NAME="tex2html139"
  HREF="node1.html">Introduction</A>
<B> Previous:</B> <A NAME="tex2html133"
  HREF="node1.html">Introduction</A>
<BR>
<BR>
<!--End of Navigation Panel-->

<H1><A NAME="SECTION00110000000000000000">
Motivation</A>
</H1>
Implementation of the controllers for an actively controlled system
(ACS) must satisfy several criteria. This section describes these
criteria as well as describing the important components for the ACS.
For elucidation purposes, this manual will refer to controller
implementation in active magnetic bearings (AMBs). However, note that
many of the requirements of AMB systems are applicable to many other
ACSs.

<P>
A schematic of the closed loop controller environment for a radial AMB
is shown in Figure <A HREF="node2.html#closed_loop">1.1</A> (note that for simplicity, the
axial components have been removed from the schematic, however it must
also be controlled by our controller implementation platform.).

<P>

<P></P>
<DIV ALIGN="CENTER"><A NAME="closed_loop"></A><A NAME="318"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 1.1:</STRONG>
Closed loop schematic of the AMB ACS</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">
	
		<IMG
 WIDTH="542" HEIGHT="288" ALIGN="BOTTOM" BORDER="0"
 SRC="img6.png"
 ALT="\includegraphics[width=0.98\textwidth]{Figures/closed_loop.eps}">

</DIV></TD></TR>
</TABLE>
</DIV><P></P>

<P>
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.

<P>
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.

<P>
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.

<P>
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). 

<P>
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. 

<P>
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:

<P>

<UL>
<LI>the controls implementation platform must be <I>organic</I>,
meaning that once the controls engineer implements a controller to run
in one computer, then this same controller should run virtually
unchanged in a faster computer. In other words, we want to be able to
immediately begin using the fastest CPUs as soon as they become
available in the market,
</LI>
<LI>algorithms must be easily changed with minimal down-time for the
test rig
</LI>
<LI>soft real time monitoring capabilities must exist that allow for close monitoring of:
	
<UL>
<LI>controller states
</LI>
<LI>plant inputs
</LI>
<LI>plant outputs
	
</LI>
</UL>
</LI>
<LI>soft real time updating capabilities must exist to be able to update:
	
<UL>
<LI>controller gains/matrices
</LI>
<LI>set point
	
</LI>
</UL>
</LI>
</UL>

<P>
Architecturally, the controller implementation platform must meet the
following requirements:

<P>

<UL>
<LI><I>low cost</I>
</LI>
<LI><I>easy to use</I>: the platform must be familiar to the user or
easy to learn
</LI>
<LI><I>extensible</I>: it must allow for future controller growth, or
for easy replacement of the computational engine
</LI>
<LI><I>graphical</I>: it must have a graphical user interface
</LI>
<LI><I>predictable</I>: it must maintain the timing requirements 
</LI>
<LI><I>remote monitoring</I>: all controller information and
parameters must be accessible from a remote location, especially for
applications which may potentially be dangerous or physically
inaccessible by an operator.
</LI>
</UL>

<P>
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.

<P>
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 <IMG
 WIDTH="25" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
 SRC="img7.png"
 ALT="$32$"> to <IMG
 WIDTH="25" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
 SRC="img8.png"
 ALT="$64$"> 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 <IMG
 WIDTH="16" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
 SRC="img9.png"
 ALT="$8$"> kHz would only be able to
log data for less than one tenth of a second, or <IMG
 WIDTH="40" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
 SRC="img10.png"
 ALT="$0.09$"> seconds for a
<IMG
 WIDTH="25" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
 SRC="img7.png"
 ALT="$32$">kB system, and twice that for the 64kB system<A NAME="tex2html6"
  HREF="footnode.html#foot165"><SUP>1.2</SUP></A>.

<P>
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.

<P>
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.

<P>
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.

<P>
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 [<A
 HREF="node64.html#hiltonMS">Hil98</A>]. However, the
affordable <I>DSpace Boards</I> 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.

<P>
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.

<P>
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.

<P>
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 [<A
 HREF="node64.html#Ripps-1989">Rip89</A>].
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 states<A NAME="tex2html7"
  HREF="footnode.html#foot319"><SUP>1.3</SUP></A> <A NAME="tex2html8"
  HREF="footnode.html#foot170"><SUP>1.4</SUP></A>.

<P>
Most ACSs requires multiple computational tasks. For example, in an
AMB system these would include (in order of importance)

<P>

<OL>
<LI>periodic fixed rate closed loop suspension loops,
</LI>
<LI>a spin rate measuring system, 
</LI>
<LI>open loop balancing controller,
</LI>
<LI>data transfer and plotting tasks, 
</LI>
<LI>network transfer tasks, and 
</LI>
<LI>miscellaneous additional tasks such as screen refresh or shell
programs.  
</LI>
</OL>

<P>
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 [<A
 HREF="node64.html#Stankovic_misconceptions">Sta88</A>,<A
 HREF="node64.html#Stankovic_scheduling_implications">SB95</A>].

<P>
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.

<P>
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.

<P>
The success of the ACS is heavily dependent on the proper design and
implementation of the controller.  In turn, the controller relies
heavily on <I>a priori</I> 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.

<P>
An important aspect of real time computing is the effectiveness of
resource allocation strategies so as to satisfy stringent
timing-behavior requirements [<A
 HREF="node64.html#Stankovic_misconceptions">Sta88</A>].  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
[<A
 HREF="node64.html#Stankovic_scheduling_implications">SB95</A>]. 

<P>
The primary objectives of real time systems design for automatic
controls include

<OL>
<LI>automation of the process by exploiting optimizing
transforms and scheduling theory and 
</LI>
<LI>the synthesis of highly efficient code and customized resource
schedulers from timing constraint specifications.  
</LI>
</OL>

<P>
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.

<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html140"
  HREF="node3.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
 SRC="/usr/share/latex2html/icons/next.png"></A> 
<A NAME="tex2html138"
  HREF="node1.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
 SRC="/usr/share/latex2html/icons/up.png"></A> 
<A NAME="tex2html132"
  HREF="node1.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
 SRC="/usr/share/latex2html/icons/prev.png"></A>   
<BR>
<B> Next:</B> <A NAME="tex2html141"
  HREF="node3.html">Real Time Systems</A>
<B> Up:</B> <A NAME="tex2html139"
  HREF="node1.html">Introduction</A>
<B> Previous:</B> <A NAME="tex2html133"
  HREF="node1.html">Introduction</A>
<!--End of Navigation Panel-->
<ADDRESS>
Michael Barabanov
2001-06-19
</ADDRESS>
</BODY>
</HTML>