What will CAD Look Like When Design Becomes Automated?

I recently came across Spacetime Constraints by Witkin and Kass, a 1988 paper proposing a new methodology for how animators should map out character movement.

Instead of an animator drawing every single keyframe of an animation, which takes a lot of time, why don't we just use our models of physics to draw it for us?

With this approach, the animator specifies what the actor has to do in only a few keyframes (e.g. drawing the starting and ending positions of a jump) and how the character should do it (e.g. "not wasting energy").

Using just Newton's laws and the computers of the time, we form and solve a large, but very sparse, constrained optimisation problem (the details of which we will skip over), and out of this we obtain the actor's position through space and time and can map out the full motion.

The following is an informal generalisation of the "inverse design" system Witkin and Kass produced, and how I think this approach from the '80s might map onto the modern engineering process.

The Generalisation

1. We start with a dynamical system (the character and environment).

The character has an infinite set of possible states within its physical environment, and we seek a specific state trajectory over time.

2. A user describes the solution with a set of datapoints.

These constrain what the solution can be, and this data should be information-dense: the user should describe what they want, and nothing more. In this case, it's better for the user to draw exact keyframes than to describe the general movement in text.

3. We use a built-in prior to compute the result.

A prior on the behaviour of the system (e.g. “this system must obey the laws of physics")  reduces our options down to a unique solution, or at least a manageable set of them. For character animation, the prior is Newton's Laws.

When I think about mapping this approach onto the inverse design of physical systems and hardware (like those represented in CAD models), Number 2 is the first problem that requires some thought:

How can users describe the tool they want, and nothing more?

In engineering, what we want to specify is not a specific geometry or set of dimensions, but a specific effect on the physical environment. How the tool behaves within its world.

*So: how can users describe the physical behaviour they want, and nothing more?

With programs, we can define intended behaviour formally, in terms of pre/post-condition contracts or temporal logic. Informally, with a natural language specification, or with input/output examples (which is analogous to Witkin & Kass' keyframes).

In CAD, we usually only get geometric specifications: the positions of geometric features relative to parameters, written as a set of constraint equations. But geometry is the implementation, not the intent of the engineer. Specifying every feature of the geometry by hand is like specifying a program by its assembly output.

The intent of an engineer is really the physical behaviour of the tool we’re designing.

But it seems intractable to define a tool by describing every valid behaviour trajectory. 

What we need instead is a language in which behaviour itself is a primitive… luckily, one exists. It is called port-Hamiltonian systems theory and has existed in control theory for 30 years.

Objects as Ports

The idea is to represent an object as a set of interfaces (ports) and interconnections.

Two variables pass through a port, an effort and a flow, and their product is power:

(Effort, Flow) = (Voltage, Current) or (Force, Velocity) or (Torque, Angular Velocity)

This is a surprisingly general idea, because it lets us describe basically any physical system in the same language, whether the domain be mechanical, electrical, hydraulic, thermal. And because everything is defined in the language of power exchange, we can define multi-physics systems, like a motor, where an electrical domain and a mechanical domain interact with each other. 

Crucially, a port is exactly what we need for step 2. It tells us exactly what occurs at the boundary of the object, but nothing more.

A Quick Example

Take a torque-limiting screwdriver.

The torque limiter is a safety device between a motor (or your hand) and whatever is being driven. Its job is to disengage if the torque exceeds a threshold so nothing downstream gets damaged. 

This matters in medical settings. E.g. a dentist driving an implant does not want to accidentally exceed the breaking torque of your jaw.

As a port-Hamiltonian system, the screwdriver can be defined with two ports: a handle port and a bit port.

The handle port is where energy enters (effort = torque you apply, flow = angular velocity of your hand)

The bit port is where energy exits into the screw (effort = torque you transmit, flow = screw's angular velocity)

And now we can write the specification as a simple set of equations in terms of what happens at those ports:

For τ_handle < τ_max:

τ_bit = τ_handle

For τ_handle > τ_max:

τ_bit = τ_max

In this way, the language doesn’t need to define the actual material, dimensions or geometry of the device. It just defines the existence of ports and a set of equations relating those ports.  

So, the implementation (whether we design this device with a spring-loaded system vs a magnetic coupling) is just a particular solution that satisfies this specification.

All of these various implementations become the solution space of the design problem. This is the space we want to automatically search over, not the specification. 

Then, What's the Prior?

For Witkin & Kass, the prior was Newton's laws. That was what turned a few keyframes into a full motion.

For us, the prior is the actual structure of port-Hamiltonian systems itself.

A port-Hamiltonian model separates every system into three components: energy storage, energy dissipation, and power-conserving interconnections. 

By definition, when we declare a system in this form, the model must be a physical system, which enforces a strict prior on what behaviours are allowed. And in particular, if the system is passive (meaning it cannot create energy), then certain properties must hold automatically:

1. energy is only conserved or dissipated

2. the system is stable (in a mathematical sense)

Importantly: we can formally prove these physical properties from the structure itself. We don’t need simulation-based techniques. 

These are deduced from the algebra without needing to simulate it, just like how a compiler type checks a program without running it. 

So, now, after we’ve applied the prior, the remaining problem is a constrained optimisation problem: among all the physically valid designs, can we find one that matches the physical speciation (port-Hamiltonian system) and whatever various geometric constraints we enforce?

Compositionality

It is a theorem that when two passive systems are joined through a power-conserving interconnection, the composed system is also passive.

When the systems we design get more complex, this is the differentiating property that separates simulation-based testing from formal proofs.

It means safety-critical properties can be verified part by part. E.g. We can certify the motor, certify the limiter, certify the driver bit, and then the certification of the full assembly can be formally deduced for free from the composition of the parts.

Today, this is certainly not the case: an engineer right now has to check parts individually and then must separately test that the parts compose as we intend. This usually means producing a prototype or using expensive simulations.

So What Does CAD Look Like Now?

Just like we've seen with code: when CAD becomes automated, design will be built on specifications.

Designing probably won't mean drawing the exact geometry of a shape. It will be closer to specifying physical systems (as structures like a port-Hamiltonian system) and then
constraining that system with a small set of geometric constraints.

The geometry of the design will become more like an output of that whole process and be derived (or approximated) from these specifications.