How Simulation Is Managed at Embraer

A aerospace engineering cautionary tale. This grainy video of a MD-80’s tail falling off after a hard landing sets up Embraer's presentation. No deaths or injuries occurred as this was only a test flight. (Image courtesy of YouTube.)

It is the stuff of nightmares for aerospace engineers. What if your plane has a hard landing and falls apart? The nightmare is replayed on stage at the NAFEMS conference in Quebec City. Rodrigo Britto Maria from Embraer shows a video of a McDonnell Douglas MD-80 landing so hard that its tail falls off. It was May 2, 1980, and McDonnell Douglas was trying to qualify its latest commercial jet and needed to determine how much runway the MD-80 needed for a landing. No one died in the incident.

The grainy video serves to this day as a cautionary tale in the education of aerospace engineers—just as Galloping Gerty, aka the Tacoma Narrows Bridge, serves as the same for civil engineering students. No engineer wants to be associated with either.

Red Is Bad, Green Is Good


Rodrigo Britto Maria of Embraer. (Image courtesy of NAFEMS)
Britto Maria is a senior engineer at Brazil’s Embraer, the 3rd largest aircraft manufacturer in the world. He works in the department that manages the digital engineering systems and the applications that help ensure that Embraer’s planes run no risk of having a tail fall off during a hard landing.


A bearded, tall and friendly Brazilian, Britto Maria is happy to discuss how the systems he has helped to put in place that oversee simulation at Embraer, including MSC Nastran, will never make his company the butt of a viral video.


Embraer’s commercial aircraft, the E170, simulates a landing. Engines are represented as point masses. (Image courtesy of Embraer.)


At the time of the MD-80’s development, McDonnell Douglas engineers did not have the same advantages available to engineers today. It was a time when slide rules had long since been replaced by engineering calculators, but finite element analysis (FEA), if done at all, was practiced almost exclusively by highly educated full-time analysts using mainframe computers. The interface was a punch card. The output was a stack of 15-inch by 11-inch continuous form green bar paper. You spent the rest of the day—or the week—looking for patterns, highs and lows, in rows of numbers in scientific notation.

Fast forward to now, and the ordinary engineer (or dare we say, a designer) can send their solid model to simulation at the touch of a button and, in the case of real-time simulation (like ANSYS Discovery Live), will be immediately rewarded with vivid graphics. Red is bad; green is good. What could be easier?

The sheer amount of simulation that needs to be done by so many at aircraft manufacturers, like Embraer, necessitates a complete and efficient method for preparing and executing simulation as well as storing the results. This has led to a special class of product data management (PDM) software known as SPDM, for simulation process and data management.

Not the Good Old Days

The proliferation of simulation at Embraer makes for one huge sorting job. Previous methods had failed. One reason Britto Maria gives for this failure is the desire of engineers to “do things their way” and to “break free” of IT constraints.

Like any company with a lot of simulation but no SPDM, Embraer used a document-centered and file-based process for managing all its simulation data that employed data management software as well as Excel spreadsheets to try to automate post-processing and proprietary scripts run on a UNIX system. Models and data were stored in artfully crafted folder structures. Data was often shared as attachments to emails. UNIX scripts were developed to assemble the whole aircraft model from the sections, or individual FEMs. Homemade scripts were used to submit jobs and perform the post-processing. C++, Fortran and Visual Basic Applications (VBA) for spreadsheet programs had replaced many written procedures but still had to be manually executed. Supporting data and documents (Word docs, for example) were stored in network drives.

The attempts at automating the FEA tasks with a collection of small applications and file management skills had grown cumbersome. Clearly, one enterprise-wide solution was needed. Large enterprises often resort to having their IT departments define what is needed and managing a team of developers—often external consultants—to create it. And what’s wrong with that? After all, who else can better understand the intricacies of what is needed better than a company’s own IT department? After the successful completion of a project, the developers move on to work at different companies. The company is faced with maintenance and updates of the software it has created. Integration with other programs that continue to be updated, bug fixes, support and training are often afterthoughts and almost never adequately planned for or resourced. Before long, a homegrown enterprise application will start to crumble from neglect and under its own weight. For examples, witness the big companies that had at one time developed their own CAD programs (General Motors, Ford, Dassault Aviation). Eventually, all discover on their own that software is best left to those in the software business, and that they would be better off returning to their core business—manufacturing cars, planes, or whatever.

Hi-Fi and Low-Fi

Britto Maria breaks down the simulation of an entire plane much as a butcher would cut a side of beef into steaks. Each component is analyzed individually, then later assembled and analyzed as a whole. The “highest fidelity” finite element models are created from an aircraft’s spars, ribs, stringers and other parts. Engineers churn through simulations of these parts, iterating with designers to ensure the parts can withstand their intended environments, cutting weight if they are overdesigned, and so on. The high fidelity results are used to assemble a “low fidelity” collection of part, one scale larger, such as an entire wing, until the entire aircraft stands as a global model. The entire plane model counts on having each constituent FEM faithfully modeled and it its reactions recorded. Across interfaces of the many FEMs, loads and reactions are transferred to neighboring FEMs.

Automation of simulation methods is complicated due to the multitude of simulation tools at engineers’ disposal, ranging from spreadsheets, homegrown software all the way to general-purpose FEA programs.

Before SPDM was implemented, the simulation process suffered from a lack of traceability, difficulty in reproducing results, no version control, a slow execution and little security.

Embraer started using SPDM software called SimManager by MSC Software, the company best known for the most commercially successful version of NASTRAN (conceived at NASA), de rigueur at every established aerospace firm.

SPDM makes results searchable. It now takes Embraer’s engineers 2 minutes to set up a batch run of 15 simulations, a job that had previously taken 10 minutes.

Users fill out a form in the SPDM, which includes all the pertinent simulations for the part of the aircraft, and hit the submit button.



Where SPDM (simulation process and data management) fits in. SPDM, situated between the engineer’s desktop workstation and the solver—in this case on an HPC cluster—manages the running of simulation software and stores the results. (Image courtesy of Embraer.)



What would you rather have? A stack of greenbar paper or neat, attractive illustrated reports—all available securely online.


Engineers, ready to move on the next simulation, have always struggled with creating the reports demanded by project managers and customers. There’s nothing more anticlimactic than creating a written narrative of what just transpired in a simulation. Embraer created an in-house solution integrated with SPDM, which reads the key results from the simulations and creates reports based on templates. Engineers still need to write their comments and conclusions, but the hard work of formatting data as graphs, tables and pictures is largely automated. Most of the data is now stored in SPDM and just referenced in reports, which became much more compact than the previous versions, where all the information needed to be printed and stored in paper format.