The idea of a digital twin should be easy for anyone in aerospace to understand. After all, pilots learn to fly planes on simulators of various kinds, which are digital twins. There are two main types, the cheaper ones have the cockpit and graphics but don't have hydraulics that actually move the cockpit around in space (like Star Tours at Disney, which is basically a giant flight simulator). A pilot in training starts in the first type to get familiar with everything and then proceeds to the more expensive type. This means that time on 6-axis hydraulic motion platforms is not wasted trying to learn things that don't benefit from the feeling of movement.

I've actually been in a 737 simulator, the type without the hydraulics. Singapore's FlightExperience is open to the public, and you fly with an experienced retired 737 pilot. They have data for many places in the world, so I asked the pilot what would be a good choice since my natural inclination was to try San Jose to San Francisco. We ended up flying from the new Hong Kong airport and landing at the legendary old Hong Kong airport, where you literally fly between buildings towards a mountain, before making a turn at the last moment to line up with the runway. It was scary even in a simulator!

My father lives near Newquay airport in Cornwell. Since Newquay is a small resort town, although it is a legendary surf spot, you'd expect the airport to be small. But it is enormous. Actually, it is RAF St Mawgan and Newquay airport is just a tiny terminal building off to the other side of the runway from the RAF base proper. When you take off in a commercial flight, they warn you to ignore the little bumps you will feel because they have arrestor wires across the runway to practice aircraft carrier landings. But having a huge runway and limited traffic means that it is a place that airlines practice without passengers on board. Last time I was waiting for my RyanAir 737, a Virgin Atlantic airbus 340 landed, taxied back to the beginning of the runway, and took off again.

Obviously, flying a real plane is a lot more expensive than the simulation approach, and that is why digital twins are used so extensively for training. Another benefit is that you can do things in a simulator that you can't do in a real plane—most obviously, crash it, but less dramatically things like stalling or engine failure. In fact, they are so accurate that the top level-D ones are certified to allow zero flight time training, where the pilot doesn't do any of those flights to Newquay, and his or her first flight is a revenue flight with real passengers. Now that is a true digital twin.

Paris Air Show

For my overview of the Paris Air Show see my post Aerospace: the View from Paris.

At the Paris Airshow, Cadence's Frank Schirrmeister presented on digital twins in the world of electronics. His presentation was titled Systems of Systems Verification and Digital Twins for Aerospace Applications. He started with an example, the F35 Lightning II, also known as Joint Strike Fighter or JSF, which is a true system-of-systems, with 8.3M lines of code, complex interactions between the various systems, multiple domains of expertise such as mechanical, electronic, security, and more.

The two big challenges in aerospace system design are either to get the software developed early (for a new program like the JSF), or to verify that the previously certified software runs on the new hardware (for upgrading the electronics of an existing platform). In both cases, the solution is hardware/software co-verification during the SoC design. 

The ideal tool would be one that can do everything. In German (Frank is German), there is something called an Eierlegende Wollmilchsau, the ideal farm animal, the egg-laying wool-milk-sow. Of course, it doesn't exist, and neither does the single tool that can do everything.

Well, there is no one-size-fits-all verification environment. But there is a continuum of dynamic engines that can interoperate. On the left of the above diagram are approaches that can be used early in the design cycle, before the RTL is complete. SDK OS Simulation ignores the hardware completely, but it allows software development to get started. The next level of accuracy is the Virtual Platform, which uses inaccurate hardware models but runs fast. Once RTL is available, then simulation can be used to verify its correctness (along with formal approaches). Simulation is the best approach for hardware debug but too slow for software debug. Emulation is attractive and is ideal for software debug, since it is faster...but there are never enough emulators and it is harder to bring up the design. Finally, using FPGA prototyping is the best approach once the RTL is stable enough. It is not great for hardware debug, but it runs the fastest (before prototype silicon is available). Once silicon is available, of course, the software has to be run there, but it is not a great debug environment and usually one of the earlier approaches needs to be used for root-cause analysis of difficult bugs found very late.

The digital twin approach can be used to apply real data to check for issues, and front-load analysis to find them early. It can be used with live data to tune performance and predict maintenance issues. The software load can be changed over time as the design advances (and the software advances if it is not a legacy software design).

Emulate Before You Fabricate

The catchphrase for all of this is "Emulate Before You Fabricate", meaning that you use the digital twin to ensure that when you tape out the SoC, that it will work correctly to run the software when you get the prototypes back from the foundry.

UPDATE: Watch the Presentation

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.