Motion Control and System Engineering Considerations
Wednesday, February 01 2012
Page 1 of 3
Motion control choices are best
made in light of the whole system
architecture, as the selection
of system architecture will drive not
only the implementation and integration
stages of the project, but also manufacturing
and field service, and even the
ability to ship and install the final product.
We will first review a quick tour of
system engineering, and then go on to
the motion control specifics.
Figure 1. A single cable connects the hybrid servo to its controller to reduce system wiring.
The essence of system engineering is
taming the explosion of the desired and
accidental interfaces in the system, thus
preventing or at least reducing undesired
modes of interaction. This process
is done by thoughtful system partitioning,
with the careful choice of interfaces,
and an eye to robustness, testability, and
margins. Unwanted interactions often
lurk in shared resources. Thus, it is
advised to minimize the sharing of
resources where possible, and where
sharing is needed, use careful planning
and analysis of requirements and margins.
Self-monitoring of critical parameters
within the shared resource can be
used to verify these target design margins.
Examples include providing separate
processors for separate subsystems
to avoid shared resources, and the use of
runtime pressure monitors within a
pneumatic system to verify actual margins
while in operation.
The sharing of low-level power supplies
across diverse systems can also
result in unexpected interactions in
which each subsystem separately tested
shows no problems, but the combination
intermittently fails. This very issue
forced the return of a large fielded
instrument to the factory for investigation.
The problem was intermittent
noise on an analog channel caused by a
crushed catch diode mounted on a solenoid
in a different section of the instrument.
The cause was too far removed
from, and indirectly coupled to, the “victim”
electronics to be located by field
service personnel even after replacing
virtually every PCB and harness in the
system. The accidental interface in this
instance was a shared 12v supply.
Partitioning the System
The key step in the system engineering
process involves partitioning of the system.
Partitioning not only selects the
types and number of interfaces, but also
determines how the system is designed,
debugged, integrated, manufactured,
and serviced in the field. Standalone subsystems
containing the mechanical, electronic,
and software components needed
to operate that subsystem are most easily
developed in parallel, tested in manufacturing,
and reused in later projects.
Physical packaging requirements —
including shipping and installation —
drive system partitioning and must be
addressed from the very start of a design.
Failure to consider packaging requirements
early in the design has caused
major redesign late in the process of
more than one project. Ideally, the number
of interfaces that cross the physical
separation boundaries should be minimized
to reduce packaging time and
installation reassembly time and complexity
at the customer site. Physically
locating control electronics in close proximity
to the mechanical systems they control
makes this type of physical division
easy, whereas the use of a centralized control
system can make for many cables that
must be disconnected before shipping,
and then rerouted and reconnected to
their proper locations at install time.
Figure 2. Bank of continuous-flow, positive displacement pumps for pharmaceutical operation.
Intentional interfaces include power,
communications, and mechanical system
alignment methodology. Unintentional
interfaces can include power system noise
interaction, ground loops, and mechanical
structure deflection, where the motion
of one axis compromises the operations
of another axis. Shared communications
channels can cause system timing to
change in one subsystem, causing
changes in timing in another subsystem
sharing the channel. Standard Ethernet
may work acceptably with low loading and
then randomly show large delays as the
loading increases even slightly.
Shared processor resources may also
have a very similar effect if adequate
care is not given to prioritization and
worst-case analysis considering all systems,
in both normal and fault recovery
modes. These timing effects become
more pronounced if finer-grained, hard,
real-time coordination tasks are moved
to higher levels of the system. This is
caused by having more items in the critical
Subscribe today to receive the INSIDER, a FREE e-mail newsletter from NASA Tech Briefs featuring exclusive previews of upcoming articles, late breaking NASA and industry news, hot products and design ideas, links to online resources, and much more.