Applications of SPDM in aircraft structural analysis at Embraer

Aircraft structural analysis is a process that involves several engineers working concur-rently to analyze in detail all structural elements of an airframe, as well as the behavior of the aircraft structure as a whole. The airframe has to be decomposed in its major components such as fuselage sections, wings and control surfaces to allow the distribution of the analyses among the engineers. Finite element models (FEM) are created for each major component and used in the analyses. The major components, such as the wing, are further decomposed into its constituent parts, such as spars, ribs, and stringers; which might be modeled in more detail using dedicated FEMs. It’s a great challenge to manage the evolution of the structural modifications that happen during the course of these analyses. Design changes originated from stress analysis using higher fidelity FEMs have to be transferred to the lower fidelity FEMs and an assembly of the whole airframe FEM needs to be created and analyzed once again, using the correct versions of all the FEMs of the major parts. The objective of this paper is to present the results of the solution implemented by Embraer to overcome these challenges, by using the Simulation Process and Data Management (SPDM) technology. Embraer embarked on the SPDM journey eight years ago and during past years has matured various aspects of their SPDM implementation. The focus of the paper is on explaining applications of the SPDM system in the area of structural analysis at Embraer with a couple of representative business processes as examples, including the rapid generation and evaluation of aircraft assemblies and the consolidation and standardization of various simulation methods across the organization, by making those available over the SPDM platform. Key enablers for increasing simulation throughput and data traceability at Embraer are described. In addition, the approach that Embraer took for ongo-ing additions of new business processes to the SPDM system is presented. The results of the SPDM implementation at Embraer are encouraging, showing qualitative and quantitative gains of productivity and management of engineering data. The standardization and automation of engineering processes and the proper management of data generated by these processes are becoming an integral part of any competitive engineering department nowadays.


Introduction
Aircraft structural analysis is a process that involves several engineers working concurrently to analyze in detail all structural elements of an airframe, as well as the behavior of the aircraft structure subjected to previously defined conditions of use. The airframe has to be decomposed in its major components such as fuselage sections, wings and control surfaces to allow the distribution of the analyses among the engineers. An example of this decomposition can be seen in the Fig. 1. Finite element models (FEM) are created for each major component and used in the analyses. The major components, such as the wing, are even further decomposed into its constituent parts such as the spars, ribs, and stringers; which are modeled in detail using higher fidelity FEMs. Structural analyses are performed to verify the initial design, which usually changes to allow reinforcements, weight reductions, or even new design concepts. It's a great challenge to manage the evolution of the structural modifications happen during the course of these analyses. Design changes due to the results obtained using the higher fidelity FEMs have to be transferred to the lower fidelity FEMs and an assembly of the whole airframe FEM, the Global Model, needs to be created and analyzed, using the correct versions of all the FEMs of the major parts. The structural design methods used in each analysis need to be registered to allow the analyses to be reused in the future, in similar designs, and also for certification purposes.
Before the introduction of Simulation Process and Data Management (SPDM), Embraer relied on document centered and file based processes for data management and spreadsheets for automated post-processing. Unix scripts were also commonly used for process management. FEMs were stored in carefully designed folder structures and the evolution of each model was manually controlled. Unix scripts were used to assemble the FEMs of each part to constitute the Global Model, and also to manage the evolution of the assemblies. Scripts were also used to submit jobs to the high performance computing (HPC) cluster and to post-process the result files. Structural analysis methods, originally documented as written procedures, were automated as in-house codes mainly in VBA (spreadsheet macros). These codes were stored in a version-controlled repository and manually executed. Supporting data not directly related to the analyses were stored in network drives with a non-standardized folder structure. Managing simulation processes and data without a proper SPDM system is very time consuming and error-prone, especially with high volumes of data, due to the need for manually creating all the metadata related to the parent-child relationships, which is cumbersome [1,2]. The use of spreadsheet macros to distribute structural analyses methods has the benefit of delivering a user interface that is customized individually by local engineering groups, but the execution speed is extremely slow compared to compiled codes and there is a great risk of losing the track of macro modifications done over a period of time. Spreadsheets macros are also difficult to debug and have a very low level of security concerning both the confidentiality of Embraer's analysis methods and protection against unwanted modifications in the code. To overcome these limitations, Embraer embarked on the SPDM journey eight years ago, starting with in-house data management solutions and later introducing a commercial solution, initially used only for data management and later also for process management, thus achieving centralized delivery of structural analyses methods to the engineering teams.
The objective of this paper is to present the results of the SPDM solution developed and implemented by Embraer in the area of structural analysis. This journey is detailed in the following sections.

Method
The aim of this study is to compare two ways of managing engineering processes: with and without an SPDM system, and to highlight the qualitative and quantitative differences in key process indicators of engineering simulations.

SPDM history at Embraer
In the first days of structural simulation at Embraer, most of the work was performed using local workstations, where engineers performed activities such as mesh generation, loads application, boundary conditions definition, post-processing and interpretation of results. Simulation runs were manually submitted to an HPC cluster using commandline interface and later an in-house web portal. Simulation results were saved in network drives and later copied to the local workstations where they were post-processed by the engineers using spreadsheets, scripts and in-house codes. Data exchange among the engineers was primarily based on e-mail messages. This environment had some inherent drawbacks such as inefficient traceability, possible loss of data and risk of unauthorized access to data, sometimes resulting in rework and difficulties in reproducing the same results from previous analyses, if needed.
As a first attempt to organize the engineering environment, Embraer conceived the so called "EngData", which was an in-house developed database system with basic data management capabilities. It was later upgraded with more capabilities and rebranded as engineering analysis data (EAD), designed as a data repository associated with several metadata, to store all the engineering information related to development and certification reports. Each entry in EAD had a unique identification code (ID) that was referenced in the engineering reports. The metadata associated to each ID allowed the engineer to perform searches in the database. The data traceability improved a lot but there were still opportunities for improvement. The downside of EAD was that engineers usually published all the data related to an analysis as a compacted file, only after the report was written, using a single ID. As this compacted file had no particular standard for storing data inside it, it was difficult to extract the desired information from it. There was also no guarantee that all files needed to reproduce an analysis were properly stored. For example, a finite element analysis (FEA) input deck file could make references to other files and some of these could be forgotten during the storage and creation of the compressed file that would be stored in EAD. As with any other manual process, the EAD was error-prone.
With the evolution and maturity of commercial SPDM tools, it was decided to no longer maintain, support and continue the development of EAD and switch to a commercial platform. After a proof of concept in mid-2010, it was decided to adopt Sim-Manager from MSC Software, a commercial SPDM tool. In this first implementation only computer aided engineering (CAE) content management was implemented, tailored for the Structural Analysis department. Integrations with finite element solvers and pre-and post-processors were not yet considered. The resulting system was similar system to EAD, however it had some significant improvements over its predecessor such as a much more efficient search engine, traceability of engineering data and user actions and a better access control management. The engineering data stored in this SPDM implementation was classified by projects, one for each aircraft program, with a dedicated access control. For each project, the "Work Request" feature was used to define a standard sequence of steps in a guided workflow, executed manually by the engineers, to upload their FEMs, simulation results and supporting data. This feature allowed the first so called "Pedigree" charts to be automatically created, allowing the engineers to see parent-child relationships between the simulation inputs (the FEMs) and the outputs. If changes were needed in the FEMs, the engineers could create a new revision of the models and associate new results. The associations between each model revision and its corresponding results were tracked and kept in the database, allowing the engineers to "rewind" the simulation logs to check and review past versions of simulation data.
This implementation was superior in comparison to EAD, but still the engineers used the SPDM tool only after all the simulations were done and the reports were written, to document and publish their work. The risk of not uploading the right simulation data into the SPDM tool was still present, because the publishing process was still manual. The main functionalities of the SPDM implementation at Embraer can be seen in the Fig. 2.

Data structure for different aircraft programs
One of the challenges in data management for each new aircraft program was to define its data structure inside the SPDM tool. SimManager's out-of-the-box CAE Schema tailored towards CAE data management was used to achieve this objective. This schema consists of Projects, Items, Variants and Representations, in that hierarchical order. The user interface has a default data tree visualization where these elements are shown. The aircraft structure, comprised of the assembly of several components, is represented as a Representations, such as FEMs or simulation-ready input decks for the finite element solver. Initially it was a hurdle to define a data structure that made sense. Should we create a single project for each aircraft in the same family, or should we create just one project for the entire family, as most of the structural components were common to its members? Where should we publish the supporting data, not related to just one particular structural component, but to a group of them? For some time, Embraer tried to represent all kinds of metadata, even the ones not related to structural components, in the form of a data tree of Items and subitems. In a sense, Embraer was applying the same logic of folders and subfolders to the Item structure inside the SPDM tool, which was originally conceived as a hierarchical representation of physical components. With the help of some MSC Software consulting services, Embraer was able to course correct by learning the difference between data structure and data visualization. The data structure is the original data schema of the SPDM tool and should be used as designed. Data visualization is the creation of alternative Data Tree views, based on metadata associated to each object in the portal. In many cases, new object types were created, derived from existing ones, to allow the inclusion of new metadata needed to classify structural analysis data. The SPDM implementer can play with these metadata and create several visual representations of the schema by configuring new data trees to show the data grouped by any combination of metadata.
The data tree visualization approach was used in several aircraft programs at Embraer. As each program had different processes, several visualization options were created. But as the SPDM portal configuration is applicable to all aircraft programs, every engineer sees all the visualization options for all programs, which may not be useful. Hence Embraer is currently working to standardize its data and metadata approaches for all aircraft programs, to make the data navigation easier for all users.

Automated simulation with the SPDM platform
Once the users were familiarized with data management, the first automated simulation processes were implemented. The overall structural analysis process at Embraer is shown in Fig. 3. The first process was the assembly of the aircraft Global Model followed by the submission of a finite element simulation run to the HPC cluster, using the feature "Simulation Generator". Simulation Generator allows automated assembly of the full aircraft model and execution of multiple load cases on the assembled model with a single button click, thus achieving high simulation throughput [3,4]. An example of the Simulation Generator user interface can be seen in the Fig. 4. Upon completion of the simulation, results files are imported and associated to the input FEM, thus automatically creating the corresponding Pedigree chart. Simulation Generator based implementation allowed engineers to easily swap variants of aircraft components and re-assemble the aircraft model thus enabling rapid evaluation of various aircraft configurations and variants. The engineers are also able to launch finite element simulation runs using, as inputs, manually assembled FEMs, bypassing the assembly process. This was a key improvement in comparison to the previous approach, because now the relationships between inputs and outputs are automatically captured, eliminating the risk of mismatch. Also, during the assembly process the engineers can select the proper version of each model being assembled and check later which version was used in the simulation. The SPDM implementation at Embraer was (and still is) a journey of continuous learning and improvement. Once the engineers were able to manage simulations of individual models and model assemblies, other use cases were considered for implementation. One of them was the automatic submission of several simulation runs based on a reference model with small variations in each run. This functionality, called "multirun", boosted the productivity of the engineers and demonstrated the gains that an SPDM tool can deliver to an engineering work environment. For example, the time to configure and launch a group of 15 simulations was reduced from 10 to 2 min, approximately. Considering hundreds of simulations submitted every week, this resulted in substantial time savings. Not only the simulations were automated, but also the capture of the relationships among the individual runs, the reference model and their results, allowing the creation of a comprehensive Pedigree chart.

Automated post processing of simulation results
Then, another use case came into play: the post-processing of results. Now that the engineers were able to submit hundreds of simulation runs automatically, they needed the ability to post-process them. Initially, this was not done using the SPDM tool: all the results were downloaded, post-processed in each engineer's workstation and then published in the SPDM portal. Naturally, these post-processing codes were also made available in the SPDM implementation, along with an implementation of Envelope Calculations, thus allowing the engineer to manage the whole lifecycle of a simulation.
One of the most time-consuming activities of the structural analysis process is the post-processing of finite element solver results, interpretation of them and verification of the current design to check if it is acceptable, given the loads envelope considered in the analysis. If the current design is not acceptable, the engineer suggests reinforcements and the part returns to the design stage, where its Computer Aided Design (CAD) model is revised and a new structural analysis is conducted. This process involves the calculation of Margins of Safety and Fatigue Analysis for thousands of segments. Embraer uses standard in-house methods to make these calculations and they were originally implemented for daily use as spreadsheet macros that read finite element solver results and perform the calculations. Because the spreadsheet programs have limitations in the number of lines and columns, it was not possible to analyze extensive sections of the structural components, which had to be divided among a team of several engineers, each one working on selected parts of the components. The analysis speed was slow, due to the inherent nature of running interpreted scripts. Furthermore, spreadsheets need to be locally executed in the workstations of the engineers, most of the time consuming nearly 100% of their processing power, slowing down their workstations for other tasks.
Another problem was the proliferation of several versions of the same macro, reaching the point that it was nearly impossible to control whether the engineers were using the correct version of the spreadsheet or not.

Structural analysis platform
So, an initiative was conducted at Embraer to speed up and optimize this process. At first, the spreadsheet macros were converted to a C++ code and the inputs and outputs were standardized. The resulting executable, called a "structural solver", was able to run a complete calculation in 22 s, much less than the equivalent 4100 s necessary for running a spreadsheet macro with the same inputs. The calculation times for complete structural components were dramatically reduced. The structural solver development was managed and documented using an Application Lifecycle Management (ALM) platform composed of the software Confluence, Bitbucket and JIRA. Then the structural solver was made available in the SPDM implementation as part of the overall structural analysis process. This solution was referred to at Embraer as "Structural Analysis Platform". New objects and user interfaces were developed, as well as the relationships among these objects, so that the Pedigree chart was able to show all objects with their right associations. As a bonus feature, the light visualization of Margins of Safety distributed in the structural elements was developed using the software VCollab from Visual Collaboration Technologies. This solution involves the automatic generation of light weight or compressed 3D representation from the analysis results that can be viewed in the web browser using the VCollab plugin. Thus, at the end of the structural analysis process, the engineers could open the SPDM web portal interface and visually check the Margins of Safety along all the aircraft structure, making the first verifications really straightforward. Now as the solver is centralized in the SPDM solution, its evolution can be controlled, making it possible to verify which version of the solver was used in each analysis, eliminating the problems inherent with spreadsheet usage of traceability, execution speed and software configuration control. A sample user interface for a structural solver implemented in the SPDM tool can be seen in the Fig. 5. The Pedigree chart for a structural solver run can be seen in the Fig. 6. An example of the light visualization of results available in the SPDM tool interface can be seen in the Fig. 7.
The structural analysis solvers development process is presented in the Fig. 8. From the calculation methods documented in the Embraer Structural Analysis Handbook, new solvers are developed, tested and certified using the ALM platform. They are later hosted in the SPDM platform, which is the interface used by the engineers to access and reuse them. The structural analysis solvers are one of the components of the structural analysis  processes that are managed and executed in the SPDM platform. An example of these processes can be seen in the Fig. 3. The engineer accesses the SPDM web portal interface in a local workstation and runs a finite element analysis based on a mesh created from an existing CAD model of the component being analyzed. Then, the engineer defines all the necessary input files for the structural analysis such as the Structural Mappings and Load Extractions and uses the interface shown in Fig. 5 to create the input for the structural analysis solver. The analyses are executed in the HPC cluster and the resulting Margins of Safety are analyzed by the engineer using the 3D light visualization functionality, directly in the SPDM web interface, as presented in the Fig. 7. The Pedigree chart showing the relationships among all the simulation objects is automatically created and presented in the Fig. 6.

Automated reports
As a final bonus, Embraer has also developed a functionality to generate engineering reports automatically, based on pre-defined report templates and post-processed simulation results, which will improve even more the productivity of Embraer's engineers in the future. As with any other object in the SPDM tool, the reports are associated with the results that originated them and these associations are shown in the Pedigree charts. Even with manually created engineering reports, the use of an SPDM tool helped to speed up report elaboration. A management decision was made, stating that only the data published using the SPDM tool would "exist" or be valid for product certification purposes. All other data stored in network folders or other systems would not be considered. Before SPDM, engineering reports contained lots of tables listing all the results needed to be presented to the certification authorities, resulting in reports with hundreds of pages. With the management decision of considering the SPDM portal the official repository for certification data, only the links to the tables were published in the certification reports. If certification authorities needed to audit any table, they could be given read-only access to them in the SPDM web portal. This approach allowed Embraer to reduce the time of the structural analysis certification process.

Data exchange with contractors
Embraer makes use of subcontractors to develop some of the structural components of its aircraft. Subcontractors used their own processes and tools to design the components and at the end of the project, uploaded all the results and reports to a secure FTP site or even delivered DVDs with all the required data, which was later uploaded by Embraer engineers to the official repositories. With the advent of the SPDM implementation, subcontractors were also given access to it, where they can publish their simulation models, analysis results and reports. Subcontractors have dedicated projects inside the portal, where they can only have access to the data published by them. However, Embraer engineers have access to all the data published by the subcontractors and can audit and reference them in their simulations. Bringing the subcontractors to use the same data management portal used by Embraer's engineers also saved a lot of time in the design process, because Embraer engineers no longer needed to move the data published in other sources to the SPDM portal.

Data exchange between Embraer's departments
SPDM is currently implemented in the Structural Analysis departments at Embraer. The Loads and Aeroelasticity departments supply the internal loads used in the structural analyses. This data exchange between departments was originally informal, made using temporary directories in network drives. There is also an initial interaction between the two departments, because the FEM used by the Loads department is not the same used by the Structures department, being a less refined one. Thus, the finite element nodes of load application are numbered differently in the two models and a conversion is necessary during the data exchange. This method introduces risks of losing the control of the correct versions of the transferred data, including the correlation of the load application points between the two models. To eliminate this risk, a data exchange process was developed using the functionalities of "Work Request" and "Approval Lists". This process involves a step-by-step guided procedure, implemented using a Work Request, where engineers from both departments take turns in publishing data and verifying them. An example of the Work Request user interface can be seen in the Fig. 9. Upon verification, engineers from both departments approve or reject the published data using Approval Lists. Besides providing a regular and official shared repository of the internal loads, this process also guarantees that the data was verified and approved for use.

Traceability of CAD models
When a mesh model is created using the SPDM tool, the engineer has the option of referencing the CAD model used to create the mesh. Although there is not a logic link with ENOVIA VPM from Dassault Systèmes (the system that manages the CAD models at Embraer), an indirect integration was developed to notify the engineer when there is a modification in the CAD model used to generate the mesh. The first step is to create a CAD model object in the SPDM tool and enter the part number attribute as one of the metadata. Then, the SPDM tool automatically imports from ENOVIA VPM other attributes used to monitor the model modifications. These attributes can be seen in the Fig. 10. When creating the mesh model, the engineer creates a "derived from" link to the CAD model. A "chron job" runs every night and lists all mesh models with referenced CAD parts and checks if there was a revision in VPM. In the case of changes in the CAD models, the mesh model is flagged and the owner receives an automatic e-mail message from the SPDM tool containing the updates. Then the engineer can access the new CAD model in VPM, generate a new mesh and update the structural analysis.

Future developments
Keeping the pace of the steady improvements made to the SPDM implementation at Embraer, a long list of new developments is on the horizon for being implemented, including: • Integration of the SPDM solution with Material Data Management platforms, allowing the materials data to be referenced from it rather than being stored as models in the SPDM solution. This will allow a better management of material data in the structural analysis process. For instance, it will be possible to list all the analyses performed using a given material, and to share the same material information among the several aircraft programs at Embraer; • Integration with ALM platforms. Currently, structural solvers and other executables are stored in controlled network drives and called by the SPDM tool upon the execution of the simulation processes. The same executable files are stored in the ALM platform, along with the source codes and documentations. When a new version of the solver is developed, a copy of the executable file to the network drive expected by the SPDM tool has to be done. There is a risk of publishing the solver version only in the ALM platform and not in the SPDM platform. To eliminate this risk, Embraer envisions a new process where the executable is stored only in the ALM platform, and the requested version of it is downloaded to the temporary directory created by the SPDM tool in every simulation run. This approach guarantees that the right version of the solver will always be used; • Expansion of the traceability breadth. Today, the Pedigree charts are limited to show the associations among the simulation objects it manages. Ideally, they should also be integrated with the overall Systems Engineering process involved in the development of complex products and show other artifacts such as requirements, CAD models, manufacturing scripts, test cases and test results, being a visual representation of the Digital Thread.

Conclusions
The results of the SPDM implementation at Embraer are encouraging, showing qualitative and quantitative gains of productivity and management of engineering data. The standardization and automation of engineering processes and the management of data generated by these processes are becoming nowadays indispensable if an organization wishes to remain competitive in the market and particularly fundamental for handling huge amount of simulation data. However, it's still difficult to prove the value of SPDM technology to the organization's decision makers [5]. The initial investment is usually high, including licenses, consulting services and the buildup of a skillful team including several people over a long period of time to develop, implement and support all the solutions. To assure the success of the initial deployment it's important to ensure that the initial investment is large enough to take account of unknown unknowns with the deployment of a new software solution and that sufficient staff are available to support users of the new solution, otherwise there is a significant risk of failure. However, if the SPDM implementation project is setup properly, the results inevitably come and justify the initial investment.
From the end-user side, the cultural change aspect is very important and a crucially challenging aspect. There must be a strong commitment from the management teams from all departments involved to implement SPDM and the involvement of key-users from each department to support the implementation. SPDM implementations are not trivial because each organization has its own simulation environment, cultural background and in-house processes. A commercial off-the-shelf SPDM tool such as Sim-Manager invariably needs to be configured and at times customized to that specific environment. It is important for SPDM tools to have this flexibility. In addition, software vendors should invest in making their tools as easy to deploy as possible. Attention towards achieving a great user experience is very important, thus requiring the SPDM tool to provide flexibility in defining the end-user interfaces. In order to expand the traceability breadth, SPDM tools should also be more open to standard interfaces with other software platforms, such as CAD and material databases.