This Year’s Model

Engineers designing chips have long been accustomed to using software models, and software engineers are well familiar with the process of testing code on hardware models. It’s also long been common to start designing products with models of both the hardware and the software.

More recently, that process has also been extended to large, complex systems with mechanical elements – automobiles, for example, and farm machinery, and more. Among the more prominent buzzwords associated with that is “digital twins.” Those are models of a complete electro-mechanical system that can be used in lieu of the system to understand how it would be affected by any changes, whether hardware or software. We touch on that concept in a previous podcast from the end of last year. It’s entitled, “Live at the Digital Summit.” That Summit was held in Shenzhen in China. There’s a link to that podcast on the web page.

The upshot here is that modeling may be common, but as systems get more sophisticated, so too must modeling technology. To explore how that’s working out, we called up Pete Darnell, the senior vice president of Model-Based Embedded Tools at Altair.

Altair develops software and cloud solutions for data analytics, simulation and high-performance computing. And, yes, that includes support for digital twins.

Your company comes from a background of mechanical design. The industry has long since gotten to the point where it’s combined mechanical with electronic with the software. Pulling those three elements together seems to be the trick. There’s a word for that, you just told me.

PETER DARNELL: Mechatronics. That’s right. It’s a discipline that is used by control engineers. So the controls guys have this big body of theory and software that they wheel up to these sorts of things.

Typically you want to start with a model-based development system (something like Simulink or Mathworks or Embed from Altair) and you build a model of the thing you want to control, plant, and the controller itself. You simulate those together, and you get your controller tuned up. Typically you’ll have some control gains (if it’s a PID controller, you have proportional, integral and derivative gain) per element you want control. And you can actually, in a pure simulation, use optimization techniques to come up with gains of your controller that give you the response you want. It might be minimal time to set point; it might be minimal time to set point without overshoot, or keeping overshoot within some delta.

Once you have your controller where you want it, you can generate code for the target processor, which you probably selected maybe based on a prior project you worked with, you got comfortable with. Maybe you were given an existing board that has ADA Ds on it. Then there’s something called Hardware In the Loop, or HIL, that lets you communicate with your controller as it’s doing its thing. And it can either control the actual real-world system or, if that has some danger to it, you might want to control a simulated physical system. If it’s a large electric motor or a vehicle that could crash into things, you’d want to control a simulated thing that responded as the real-world system would to make sure your controller’s working well before you actually plug it into the real system.

BRIAN SANTO: In the example you just gave us, you already have a controller in mind, you have a processor you want to work with in mind, and models probably exist. Does it complicate matters when you’re working with a model of something that hasn’t been… of a product that’s also being created in parallel with what you’re doing? For instance, you might know that you want to have an Arm or an X86 processor you want to work with, but you know you’re going to be using the next generation and it hasn’t been spun yet; or you’ve got some hardware that you want to build but you haven’t built it yet. You kind of know what the properties might be, but you don’t actually have a physical thing yet that you’ve measured. How does that complicate the process of design?

PETER DARNELL: It complicates it a lot. And it’s actually more the rule than the exception. For instance, we had a very interesting project at Altair with a very large company who gave us a task that we can’t talk about because it ended up working so well! But the mechanical guys saw it as primarily a mechanical problem, but it was a very large haptic device that was actually moving the bulk of a human body.

It turned out that the mechanical guys quoted a timeframe to this company when they could deliver it, thinking in their mind what it would take to build all the mechanical pieces. And oh yeah, there was this controller that was going to make things happen, but in their mind, that was sort of the cherry on top. It was not a big deal.

BRIAN SANTO: Oops.

PETER DARNELL: And so we started with a model of the thing we thought they were going to build. They had shown us working diagrams of how it was going to work. And then we built a prototype controller. You mentioned, What if you don’t know what the controller’s going to be? And what if you don’t know what the target hardware’s going to be? The controller really isn’t the problem. As long as it has enough computation to finish within your framing rate.

You have a certain time-step that you’re going to periodically calculate control value updates. Maybe it’s 100hz; maybe it’s 10khz. As long as you can get your computation done in that frame, the target processor you’re using doesn’t really matter. If you’re doing ADA Ds in, you’re doing PWM signals out for actuation, whether it’s an SD Micro or a Texas Instruments or an NXP or Infineon. It doesn’t really matter. It’s how much infrastructure do you have in place for that particular part?

I think in this case we used a TI Concerto, which was dual-core, half C2000/half Arm Cortex M3 I think it was. Which made life interesting to get those two cores talking to each other.

I believe we had our hands on the actual final… We had a prototype to play with for months. But the real system was totally different. Over ten times the masses and inertias involved. And I think we had two weeks to tie off the control system. So there was this mad scramble (20-hour working days, very little sleep, lots of coffee) of not only changing the control, but having to change our models. Because the actual physical system didn’t quite correspond to what we thought it was going to be.

So a lot of the data acquisition of applying a force through the voice coils and seeing how the system responded had to be correlated back into the model and make sure that it did what you expected. There were some interesting periodic forces involved. I just spoke to one of the guys on the project yesterday. I mentioned I was going to be talking to you, and I said, “I’ve got a question: Do you have to update the models very much?” And he looked at me, “Oh, yeah! Like every day we’re updating the model!” And he was particularly proud. This was VJ; I’ll give him a shout-out.

We had this consulting group in a lab in Troy, Michigan. The building itself is a triangle. You walk in the point of it, and as you walk into the building, it goes up. And in the very back, it’s no longer office space, it’s all kinds of… originally it was like super-hopped-up, modified cars. They have a bus they designed from scratch back in there. And it’s got a weird sort of hydraulic…

BRIAN SANTO: A “toy shop” is what you’re telling me.

PETER DARNELL: It’s a toy shop for big kids, basically. This is a full-size bus, mind you. And they have giant slabs of metal that are like a foot think and like ten feet by ten feet for stable platforms you work on, which I think they were on and using. And it’s quite noisy back there. So when I get a phone call from those guys there’s a little shouting involved.

He was back there, and they’re constantly having to total the model, figure out a new controller. This periodic frequency, he figured out in his controller if he could invert the force at the same frequency and sort of cancel it out, then he could come up with a way to control much tighter to the tolerances we were looking for. And it all worked out.

BRIAN SANTO: Nice. I want to let people know out there that you have been absolutely scrupulous about not telling me what this thing is. But I’m telling people that I’m expecting an exoskeleton that somebody can jump inside and walk around in.

PETER DARNELL: That would be cool! We are working with a company that does that. But I can say it wasn’t that.

BRIAN SANTO: Aha! We’ve narrowed it down.

Anyway, that’s fascinating. Part of the reason to do design the way you’re doing it with sophisticated models that bring in the mechanical, the electronic and the software elements is to accelerate design cycles.

PETER DARNELL: Yes.

BRIAN SANTO: Does it always accelerate?

PETER DARNELL: Well, to be honest, I’ve only done it this way, but I would have to think it does. Can you imagine having to control this weird beast? It was a big system. Kilowatt voice coils physically large, several meters by several meters. And being handed I think it was a three-week period and saying, Okay, make the control system run to within very tight tolerances. Unless you’ve been able to sort of develop in parallel on models, I don’t see how you could have done it.

BRIAN SANTO: So this type of modeling will sometimes accelerate design cycles, or will often. I’ve got to imaging that at least one of the other benefits is that it allows you to design stuff you might not have been able to design before. You’re bringing in multiple disciplines and designing in parallel to make sure that all of these subsystems work well with each other in simulation time, if you will.

PETER DARNELL: Yeah. That also gets into a safety aspect and a validation verification. In fact, there are safety standards out there like ISO 26262, DO-178. And I just heard about something — today I stumbled across it — SOTIF, Safety Of The Intended Functionality. So the ISO 26262 standards are to make sure each submodule performs the function as it was designed.

BRIAN SANTO: In an autonomous device of some sort, right?

PETER DARNELL: Well, in any kind of device. But yeah. Safety-critical. It could be a respirator, but it could be an autonomous car. In fact it was an autonomous vehicle site where I came across this, now that you mention it.

The SOTIF requirement is that once it’s all assembled, with these validated parts and each subsystem works as it’s intended, does the whole system work as it intended?

BRIAN SANTO: Right.

PETER DARNELL: So that’s the piece that has I guess historically been left out. And that’s again where modeling lets you explore the space better than a physical system. In a physical system, you want to make sure that if I go down the highway, it is ever going to swerve into oncoming traffic? In a modeling simulated case, that’s a bad outcome obviously, but…

BRIAN SANTO: You want to know what happens just in case and what conditions will get you there, right?

PETER DARNELL: Exactly. A real system would be quite costly and dangerous to try it out. So simulation is key. Absolutely.

BRIAN SANTO: This is kind of a smart ass question, but are there such things as “simulated” crash test dummies?

PETER DARNELL: Oh, absolutely!

BRIAN SANTO: Cool!

PETER DARNELL: In fact, Altair kind of specializes in that. In fact, we have a special software that is just used for crashing things. And the cell phone companies, instead of dropping $1,000 cell phones, they can drop these simulated cell phones and see how they crack up.

BRIAN SANTO: That’s a beautiful thing.

PETER DARNELL: It really is. I think Apple and all the major guys use it.

BRIAN SANTO: Okay. We were going to talk about smart objects. In a previous conversation you and I had, we were talking about how this kind of modeling is still fairly sophisticated and still fairly expensive. So naturally it’s been adopted by the people who can afford it most, perhaps. Automotive companies, for example.

PETER DARNELL: Aerospace.

BRIAN SANTO: Aerospace. Right. When you start talking about smart objects, you’re talking about the Internet of Things and consumer electronics.

PETER DARNELL: And the thing itself is prohibitively expensive.

BRIAN SANTO: Yeah. So how does that work?

PETER DARNELL: Well, it depends what you want to do. If the thing is just reporting temperature and humidity, probably you don’t need model-based for that. If it’s doing something sophisticated like an energy analysis where it’s taking a count of temperature, humidity, maybe a prediction of the future weather, and trying to override OEM controls on rooftop HVAC units (which we happen to have a user doing), they find it much easier to do a simulated, model-based approach where they can simulate the controller against a variety of scenarios and using actual weather data and verify that they were getting the energy savings that they were looking for, before they ever install it on a rooftop.

Then it becomes convenient for them. They can drop in the MQTT block; they can drop in real-time clocks; they can drop in GPIOs and just have that go. So the actual interfacing of the lower-level hardware becomes fairly easy.

But the big win for them was this simulation capability. Not for safety purposes, but for verification of the intended outcome for their control.

BRIAN SANTO: From the creation side, what are the requests you’re getting for improving modeling systems?

PETER DARNELL: Quite typically, new processors — maybe TI or ST Micro — comes out with a brand new one, and there’s some pressure to support it. We kind of look at this never-ending growth of silicon with a bit of dread, because you never know what the silicon guys is a hot new idea, and then we have to support it.

We can’t just support it in a simple, one-off way. Like if it was some new communication device and you had a need, well you’d get it work in your case for your need, but we have to get it to work in every possible case. So we really have to totally get our arms around exactly what this new device can do and make sure we presented a nice user interface to it.

BRIAN SANTO: So you’re actually looking forward to the end of Moore’s Law so that you don’t have to keep revising.

PETER DARNELL: Exactly. The sooner the better! Now the problem is, they can always lay down more gates and do more stuff. So one of the things the chip guys are trying to do is look at a typical board, and then look at all the chips out around their chip and suck those onto their microprocessor.

It’s really surprising how many peripherals there are on a microprocessor these days. Infineon’s got one with radar processing on it.

BRIAN SANTO: Is there anything I’ve neglected to ask you about that’s fun, pertinent, just plain groovy about the modeling business these days?

PETER DARNELL: It’s surprising how much stuff you can model. That’s sort of what Altair brings to the table. They let you simulate model just about anything. You can model the angle of repose of grains of corn or sand. You might think, Why would you want that? Well, if you’re loading a ship or you’re extracting from a ship, you come in with a big scoop, you pull it up, you dump it in a container, and then you want to do it in such a way that you minimize how many of those you do. And by calculating how the stuff’s going to shift or if you’re designing a container for maximal strength and lightest weight, you can do that.

It’s surprising how much stuff there is out there that you can simulate now.

BRIAN SANTO: All right, Peter, thank you so much for your time.

PETER DARNELL: Thank you, Brian. It’s been a lot of fun.

BRIAN SANTO: At the beginning of that last discussion, Pete Darnell mentioned “Mechatronics.” A colleague of Pete’s at Altair has written a textbook on the subject. If you’re looking to learn more about the intersection of system modeling, simulation, sensors, actuation, real-time computer interfacing, and control, we’ve got a link to the book on this podcast episode’s web page, which you’ll find at www.eetimes.com/podcasts.