What CCD Is Not—and How to Practice It Responsibly

Common misconceptions¶

“CCD means tuning a controller for several candidate plants.”¶

That activity can support CCD, but it becomes co-design only when plant decisions are coordinated with control decisions under a shared system-level objective and constraints. Controller tuning after plant selection remains sequential.

“Putting all variables in one optimizer automatically creates CCD.”¶

A variable list is not a formulation. The model must represent how plant and control decisions affect dynamics, objectives, information, and constraints. Integrated code with missing physics is not integrated engineering.

“CCD always requires simultaneous optimization.”¶

CCD can use simultaneous, nested, iterative, or architecture-based strategies. The defining feature is coordinated system design, not one solver architecture.

“Open-loop optimal control is directly implementable feedback.”¶

Open-loop optimal control (OLOC) can reveal performance limits and useful dynamic behavior, but it may assume future information unavailable in real time. Implementation requires causal feedback, sensing, estimation, computation, and robustness analysis. Controllers can be classified by how much of that information they actually have when they act:

• Complete horizon: the controller has full information about the environment over the entire time horizon in advance—the assumption behind OLOC. This is appropriate for offline planning problems (a spacecraft reentry trajectory, a manipulator path) but not for a controller that must act causally against a disturbance it cannot foresee.

• Instantaneous: the controller has information only about the current instant, the classical assumption behind ordinary feedback control (tracking and regulation).

• Limited horizon: the controller has information over a short window into the future and re-solves at each step—the assumption behind model predictive control (MPC). Limited-horizon control is a practical middle ground: it can approach complete-horizon performance as the horizon grows, and it recovers instantaneous, purely reactive behavior as the horizon shrinks toward zero.

The gap between complete-horizon and instantaneous information is not a modeling nuisance—it has a measurable performance cost. In one documented active-suspension co-design study, an idealized fully active open-loop benchmark was progressively made more realistic in four steps: an ideal active actuator, an idealized semi-active damper, a semi-active damper with a realistic hysteretic force-current model, and finally a full-state-feedback closed-loop controller with optimized gains acting on real-time measurements. Each step degraded the achievable objective—by roughly $1.8\times$, then $2.6\times$, then $2.1\times$ relative to the previous step—so that the final, genuinely implementable closed-loop design was about $9.7\times$ worse than the open-loop upper bound on performance. None of these steps involved a design mistake; each one simply removed an assumption (unlimited information, an idealized actuator, unconstrained control) that was not physically available. This is why a lower OLOC-based objective value is a benchmark, not a deliverable: it tells you the best that could ever be achieved if implementation were free, which is a useful number to know but not the number a real controller can deliver. Model predictive control’s tunable prediction horizon gives one systematic way to study exactly how much of that $9.7\times$ gap can be recovered as more (but still finite) future information is made available to the controller—a question you will revisit quantitatively in later chapters.

“A lower numerical objective proves a better product.”¶

A lower value is meaningful only for the chosen model, scenarios, objective, constraints, and numerical accuracy. An optimizer can exploit unrealistic assumptions or omitted failure modes.

Limitations and engineering responsibilities¶

Modeling burden¶

A useful CCD model must be dynamically meaningful and flexible with respect to plant variables. A fixed-plant control model may be accurate but unable to predict how geometry changes dynamics. A plant-design model may allow geometry changes but simplify the dynamics that matter for control.

Computational burden¶

Dynamic optimization can require many simulations and thousands of time-dependent variables. Efficient derivatives, sparsity, model reduction, surrogate models, and suitable coordination strategies can become essential.

Formulation sensitivity¶

The optimized design can change substantially with objective weights, scenarios, bounds, and constraints. Engineers must justify these choices and test sensitivity rather than treating them as neutral inputs.

Uncertainty and robustness¶

A nominally optimal pair may fail when parameters, disturbances, sensors, or models differ from assumptions. Manufacturing variation, environmental uncertainty, noise, degradation, and unmodeled dynamics must eventually be included.

Implementation gap¶

An elegant controller may be impossible to implement because of sampling, communication, causality, computation, sensor availability, or actuator limits. CCD should progress from idealized exploration toward realizable closed-loop control and hardware validation.

Organizational challenge¶

Cross-disciplinary teams must agree on the mission, model interfaces, variable ownership, data standards, and verification procedures. Mathematical integration does not remove the need for engineering communication.

A practical CCD mindset¶

Before choosing a solver, ask:

1. What is the mission of the complete system?

2. Which decisions are genuinely free?

3. How do those decisions influence the dynamics?

4. What information does the controller actually possess?

5. Which physical limits are essential?

6. How will the result be verified?

A practical workflow is:

1. define the system mission and requirements;

2. identify plant, control, information, and architecture decisions;

3. construct a coupled dynamic model;

4. define system-level objectives and constraints;

5. select a coordination and numerical strategy;

6. solve and verify the optimization problem;

7. interpret the physical-control tradeoffs; and

8. move toward realizable control and higher-fidelity validation.

Verification should include unit checks, baseline reproduction, comparison with a sequential formulation, multiple starting points, constraint and trajectory inspection, and validation with higher-fidelity models or experiments.

Activity 1.6: Ideal Actuator versus Implementable Actuator¶