As I’ve mentioned on occasion, my degree is in Control Engineering. Well, that’s what we used to call it deep in the mists of time (circa the late 1970s) when I was a bright-eyed, bushy-tailed student—although the years, it must be said, have not been kind.
The idea was to have a core of math, accompanied by electronics, mechanics, hydraulics, and fluidics. In hindsight (the only exact science), my cohorts and I were blithely ignorant that we were balanced on the cusp of a significant transition (the “blithely ignorant” part means I was playing to my strengths).
Around that time, classical control theory (Laplace transforms, Bode plots, Nyquist criteria, root locus, etc.) still reigned supreme. Analog control systems that were built around op-amps, resistors, capacitors, and maybe a few 555 timers were still dominant in the industry. Digital control was emerging, but the microprocessors of the day (8080s, Z80S, 6800s) were barely fast enough to close low-bandwidth loops, and analog-to-digital converters (ADCs) and their digital-to-analog converter (DAC) counterparts were expensive and coarse (low-resolution). We’re talking about an era when 8-bit ADCs and DACs were the norm, 6-bit parts were used for speed or economy, and 12-bit devices dwelled in the rarefied realm of high-end laboratory gear.
Bang-bang (on/off) and proportional–integral–derivative (PID) controllers were the main practical options for most control applications in those days. This was because they were simple, robust, well-understood, and implementable using relatively cheap analog components and a good dose of analog signal processing (ASP). Digital Signal Processing (DSP) as a named discipline didn’t really emerge until the early to mid-1980s, when the first dedicated DSP chips (such as the TI TMS32010, 1982) appeared on the scene.
As an aside, although it isn’t really relevant to this column, I always had a soft spot for fuzzy logic-based control systems. This concept was first introduced in 1965 by Lotfi A. Zadeh, who was a professor at UC Berkeley. Zadeh’s key insight was that not everything in the real world is true or false, on or off, 1 or 0; instead, many things are only partly true. This was a radical idea at the time, largely ignored or even ridiculed by traditional control theorists.
Through the 1970s, fuzzy logic stayed mostly within academia. Some researchers proposed fuzzy controllers, but with predominantly analog computers and limited digital capability, it was more theory than practice.
It wasn’t until the 1980s that fuzzy logic started to make its presence felt in the real world, especially by Japanese engineers who embraced fuzzy control for practical applications. For example, the Sendai Subway system (1987) employed one of the first major commercial fuzzy control systems, providing smoother acceleration and braking on automatic trains. Also, companies like Matsushita, Hitachi, and Toshiba began using fuzzy logic in appliances like air conditioners, washing machines, and rice cookers. These systems used fuzzy rules to adapt control behavior smoothly; for example, “If the rice is nearly done but still slightly firm, gently reduce the heating.”
In the early 1990s, fuzzy logic became a buzzword in engineering and marketing alike, often paired with “expert systems” and “neural networks.” Around that time, I remember attending a live debate at a conference in which Bob Pease—ever the analog iconoclast—sparred with a fuzzy-logic champion. Pease made a spirited case for well-tuned PID over fashionable fuzz, and the room was absolutely buzzing with “for” and “against” opinions and pontifications.
Although most of us rarely hear the term “fuzzy logic” today, it never really disappeared; it just stopped being fashionable as a label. Many modern systems, especially AI hybrids, still use fuzzy reasoning under the hood for rule-based control, adaptive tuning, and sensor fusion. (In the engineering or modeling sense, an AI hybrid is a system that combines traditional physics-based models with artificial-intelligence models to get the best of both worlds.)
As another aside, if you ever feel like the language of a control-system practitioner is being spoken in a foreign tongue, you’re not alone. There’s the classic video of the Rockwell Retro Encabulator—a spoof presentation in which the solemn narrator describes things like “…six hydrocoptic marzlevanes so fitted to the ambifacient lunar waneshaft that side-fumbling is effectively prevented,” while the visuals show nothing more exotic than a standard motor-control center.
This is exactly the kind of cross-domain, jargon-laden layering that characterizes modern system design, and it’s hilarious precisely because we engineers recognize ourselves in it.
But I fear we’ve wandered away from the point of this column (“No!” I hear you cry, “Tell me it isn’t so!”). Someone reached out to me to see if I was interested in talking about “Model-Based Design for Control Systems.” Given my background, I, of course, acquiesced, which is how I came to find myself chatting with Jason Ghidella, the Technical Marketing Manager for the Simulink Platform and Controls Products at MathWorks.
While the official topic of our talk was “Model-Based Design for Control Systems,” Jason actually spoke far more broadly. His framing was model-based design (MBD) as a system-level methodology that includes control systems but extends well beyond them.
Jason summed up MBD as follows: “Model-based design replaces documents with executable models.” In other words, instead of writing a long specification and hoping everyone interprets it correctly, you build a living, breathing simulation of your system and start testing it from day one. Models in Jason’s world cover the entire electromechanical and software system, not just the controller. He repeatedly emphasized:
- Physical system modeling (motors, joints, hydraulics, etc.)
- Software and algorithm modeling (including AI, PID, fuzzy logic)
- Integration across domains (mechanical, electrical, logical, and AI layers)
- The digital twin continuum — from concept to deployment and field operation
So, while control algorithms are a core component, our conversation clearly positioned MBD as a multi-domain, system-of-systems design philosophy that’s about modeling the entire product lifecycle, not just tuning control loops.
Model-based design (MBD) has its roots in control engineering—flight controllers, engine ECUs, and feedback loops that keep everything stable. But as Jason explained, it’s now much more than that. “The key is to model the physical system,” he says, “but a lot of systems today are software-defined. You’re modeling the algorithms, the electronics, and the logic that all interact.”
Dyson, for example, used MBD to develop a wet-and-dry vacuum cleaner, modeling everything from roller dynamics to suction flow to motor control. Bosch applied it to e-bike controllers. Danfoss built its electric drive systems on the same platform. In each case, MBD unified mechanical, electrical, and software teams within a single simulation environment.
The results? Faster iteration, reduced rework, and fewer “what on Earth went wrong?” meetings (I’ve attended a lot of those in my time). Jason noted that companies typically see a 30-50% reduction in development time and cost, with a corresponding boost in team confidence.
Then there’s the concept of the digital twin. This is one of those buzzwords that actually mean something: a virtual representation of a real-world system that behaves like the physical thing it mirrors, continuously updated with data from the real device, machine, or process. Jason’s take on this is refreshingly practical: “I need not just one twin, but many.”
From Jason’s point of view, each twin serves a purpose. Early in design, it’s a conceptual model used for simulation. Later, it mirrors the deployed system in the field, helping engineers analyze behavior, diagnose issues, or even test over-the-air updates before releasing them to customers.
Ather Energy, which develops electric scooters and charging systems, uses MBD this way. When field issues arise, engineers replicate them in simulation, debug the problem virtually, and push fixes wirelessly to vehicles already on the road. The same framework that sped up design now accelerates maintenance and innovation.
During our chat, I couldn’t resist steering things toward AI (as one does). After all, the line between control theory and machine learning has never been blurrier.
Jason agrees. “Within model-based design, we have a spectrum,” he says. “You can model from first principles—your differential equations and transfer functions—or you can use data directly. AI gives you another way to represent a system.”
This is a key insight: AI isn’t just for making decisions—it can stand in for the physics when the underlying equations are too complex or unknown. If you have real-world input-output data but no detailed model in between, you can train an AI to be that model. MathWorks’ tools even let you combine such AI-based subsystems with physics-based ones in the same simulation, automatically quantizing and generating deployable code for your microcontroller or GPU target. This lets you build a hybrid system that marries physics-based insight with data-driven intelligence—and test the whole lot virtually before committing to silicon or steel.
Of course, like many things, this all sounds easy if you say it quickly and wave your arms around a lot, but how can you get started? Suppose, for example, that you’re designing a desk-mounted robot arm. This is going to be a neat little device to pick parts off a conveyor. It’s going to have multiple motors, myriad sensors, and maybe even vision input.
Where will you begin? Jason’s advice is to start small. “Take one subsystem—maybe the drive electronics—and model that first. Learn the workflow, get it working, and build from there.”
MathWorks makes this easier with reference models on GitHub and the File Exchange, plus “on-ramp” tutorials that walk newcomers through building 3D mechanical models and adding joints, motors, and control logic.
And you don’t have to start with full-blown physics. Begin with a simple transfer function or differential equation, validate the algorithm, and add fidelity only as needed. The idea is to use the right level of abstraction for each stage of the design. This is at the heart of MBD’s appeal—to always be working on something that runs.
MBD isn’t just a productivity tool; it’s a survival strategy for modern engineering teams. It helps you manage complexity, reuse designs across projects, and collaborate across disciplines without playing telephone tag as you desperately try to navigate a labyrinth of spreadsheets and PDFs.
A few decades ago, a vacuum cleaner just needed to suck (I well remember the slogan “Nothing sucks like an Electrolux,” which was used in the United Kingdom in the late 1950s and 1960s by the Swedish appliance manufacturer Electrolux to promote its vacuum cleaners). Today, a vacuum cleaner may embody a distributed cyber-physical system with sensors, power electronics, and embedded AI. As Jason put it, “Everything has become so much more complex, which is why model-based design is growing at such a rate.”
We ended our conversation with one of Jason’s favorite phrases: “Fail quickly and fail often, but fail virtually.” That’s the essence of modern engineering. Don’t wait for the prototype to tell you what’s wrong. Let the model do it for you before you spend a cent on a real-world implementation.
We used to imagine our systems, then draw them. Now we can run them before we build them. And that’s the real power of model-based design—not just for control, but for everything we create.
