Upload
aras
View
2.045
Download
1
Embed Size (px)
DESCRIPTION
Advatech Pacific Simulation Data Management with PLM from Aras and Microsoft SharePoint
Citation preview
SIMULATION DATA MANAGEMENT AND REQUIREMENTS TRACKING
FOR NASA MISSION DESIGN USING ARAS AND SHAREPOINT
Phase II SBIR
Tyler BischelDr. Peter J. RohlAdvatech Pacific560 E Hospitality Ln, S. 400San Bernardino, CA 92480
2
Contents
• Advatech Pacific Overview• NASA SBIR Project Goals• NASA Ames Mission Design Center• The “Simulation Bill of Material”• Requirements Management• Integration with SharePoint• Desktop Clients• Analysis Tool Integration• Summary
Engineering Research & Development Company Founded in 1995
Primary Business Focus Aerospace Vehicle Physics Based Modeling and Simulation Integrated System and Cost Analysis Tool Development Communications Systems Interoperability Engineering Design, Analysis and PLM/PDM Services
Annual Revenues over $10M (Small Business) Approx. 50 Full Time Engineers / Scientists Locations
San Bernardino, CA (HQ) Palmdale, CA Dayton, OH Tempe, AZ
3
Advatech Pacific Company Information
4
Communications HardwareSatellite Tactical Comm.Disparate Network IntegrationMilitary & Civilian applications
Modeling and SimulationStrategic Missiles and RocketsSpacecraftSatellitesExpendable & Re-useable Launch
VehiclesRe-entry VehiclesSpace Shuttle PayloadIntegrated Design with Cost AnalysisHypersonicsRange Safety Analysis
Aircraft & SystemsDesignDraftingAirframe structural analysisEngineering support for compositesManufacturing support
Gas Turbine EnginesAnalysisDesignPerformanceApplications
Aerospace, Defense, and Commercial
NASA SBIR Project Goals
5
• Develop a seamless environment for satellite mission design
• Introduce PLM approach to NASA mission design
• Develop a structured approach to simulation data management
• Facilitate reuse of engineering analysis models
• Integrate requirements and engineering analysis
• Integrate fragmented engineering analysis tools
• Leverage existing tools as much as possible
Customer: NASA Ames Mission Design Center (MDC)
6
• Focused on small satellites
• Performs three types of mission design studies:
• Center directives
• Announcements of opportunity
• Research proposals
• Studies range from “back-of-the-envelope” studies of a few days to fairly detailed mission designs of six to eight weeks duration
• Customers are both internal (NASA/government) and external
• In all cases, the final “product” is a mission proposal in the form of a report with supporting analysis data
The Problems Faced by the MDC
7
• Simulation models and data scattered all over individual engineers’ desktops and shared network drives
• No revision control of simulation models and data
• No tracking of relationships between simulation models
• No mechanism to flag simulation models that are out-of-date because the assumptions/models they depend on have changed
• No reusability of engineering analyses
• No relationships between requirements and engineering analyses to support the requirements
• Engineers spend a lot of time moving data from one analysis tool to another
• Commercial solutions for simulation data management are out of reach for the MDC from a cost standpoint
Advatech Pacific’s Solution
8
• Development of a “Virtual Satellite Integration Environment”consisting of:
• A simulation data management solution,based on Aras and Microsoft SharePoint,integrated with the conceptual mission design tool (ATLAS), implementing a “Simulation Bill Of Material”
• A mechanism to link analysis models to requirements
• A “Linked Model Environment” integrating engineering analysis models and tools
• Automation and optimization
Challenges Faced by Advatech
9
1. Cultural
• “Mission Design is different”
• “PLM is for manufacturing companies”
• “Every mission is unique”
• “Standardized processes limit the engineers’ creativity”
2. Resources
• The MDC operates on a shoe-string budget. The budget to purchase software licenses is very limited. A lot of licenses are shared with other NASA organizations.
• Always operating in crisis mode. The next mission design is always due yesterday. We are trying to do an engine upgrade while the car is in the middle of a race.
Virtual Satellite Integration Environment
10
Science Traceability Matrix
SharePoint
Linked Model Environment
SolidWorks
Thermal Desktop
STK
Aras InnovatorSimulation Bill of Material
Mission
Requirements Design
Atlas
STK
SolidWorks
Product
Thermal Desktop
User ChangeNotifications
AutomatedCAD Interchange
Simulation Traceability and Revision Management
RemoteCollaboration
The “Simulation Bill of Material”
11
• Extending the notion of the classical BOM to management of simulation data and their relationships
• Tracks the relationship between versions of analysis models
• Supports release process for simulation data
• Notifies users automatically when their analysis models may be out of date
• Links analysis data to requirements
• The classical BOM is represented as a tree structure, whereas simulation data form a graph structure
• Root of the SBOM is a “Project”
SBOM Structure in Aras
12
• Custom item types defined in Aras to support satellite mission design
• Items are containers for simulation data/ documents
• Derived from out-of-the-box Aras items, support their lifecycle (versioning, release status, workflows, etc.)
Aras Innovator SBOM Item Types
13
• A number of custom Aras item types have been generated, supporting the specific types of data in the SBOM
• Their behavior and metadata is specifically targeted to suit their functions
• Accessible through the Aras user interface
Item Type “Project”
14
• The Project item type is at the root level of a mission design project
• It has associated with it a customer proposal, requirements, the actual mission design and the end product
Item Type “Proposal”
15
• Every mission design project is the result of a proposal
• The “proposal” item type captures all proposal-related information, including the proposal documents
Item Type “Requirements Document”
16
• Ultimately, mission design and analysis is driven by requirements
• Since MDC lacked a requirements management system, we decided to develop this functionality inside Aras
Item Type “Design”
17
• Top level collector item for a mission design
• Contains all simulation and analysis models/data/results
• Exposes top-level metadata for the mission
Analysis Component
18
• Captures metadata and behavior relevant for a particular simulation code
• Derived all from the same root class (Simulation Data)
Item Type “Product”
19
• The final product resulting from a mission design study, which can be a white paper, a PowerPoint document, a full proposal or a concept study
Simplified Class Diagram
20
Wrapper Interface toAras Environment
MDC-specific services
Presentation Layer for UI
Implements three levels of abstraction
Revision Control of Dependent Models
21
1. Dep. node gets revised. New rev points to original master node.
2. Master node gets revised. Owner of dependent node is notified. New rev of dependent node points to new rev of master node.
Dep. SimR1
MasterSimR1
Dep. SimR1
MasterSim R1
MasterSim R2
Dep. SimR2
MasterSimR2
Dep. SimR1
MasterSimR1
Dep. SimR1
MasterSim R1
Dep. SimR2
Dep. SimR2
Access to the SBOM
22
Three primary mechanisms for the user to interact with the SBOM:• From the desktop: Desktop Clients• Through SharePoint: SharePoint Client• Directly through Aras Web Client
23
Exposure through SharePoint
• Project level information
• Requirements data
• Final product
SBOM View as SharePoint Webpart
24
• SharePoint web parts are standard objects a SharePoint developer can use to implement custom functionality
• Users are familiar with tree-type structures
• We use a SharePoint Tree webpart to expose the project dependency structure in SharePoint
• The root is the satellite mission project
• All data related to a project is contained in the tree structure
SharePoint View of Requirements
25
SharePoint Data Upload
26
Simulation Data Packages.
• User fills fields with metadata and uses a file browser to upload files
• Dependencies identified manually by the user
Desktop Clients for the SBOM
27
• “Drop Box” interface for easy upload/download of analysis data
• “Science Traceability Matrix” for requirements capturing
File Browser Interface
28
Ease of Use:
• Engineers were used to storing their models on shared drives
• Wanted a mechanism to store and retrieve data as easy as accessing a shared drive
Science Traceability Matrix
29
• The “Science Traceability Matrix” is NASA’s way of capturing and categorizing mission requirements
• Typically done in Excel spreadsheets
• We developed a “live” application that links individual requirements to analysis models
Analysis Tool Integration
30
• Analysis tool integration implements the concept of a “Linked Model Environment” developed earlier at companies like GE
• Central to analysis tool integration is the geometric representation of the artifact (CAD model). Many downstream applications are consumers of geometry.
• “Tagging” geometric entities with information needed by downstream applications facilitates tool integration
• Both tight coupling and loose coupling solutions were developed
• Tight coupling leverages the respective tools’ APIs and is code specific
• Loose coupling leverages third-party integration tools, e.g. Comet (Comet Solutions), iSIGHT/FIPER (Dassault) or ModelCenter (Phoenix Integration)
Tight Coupling: SolidWorks-STK
31
• SolidWorks (SW) is the primary CAD tool in use at the MDC
• Satellite Toolkit (STK) is used for orbit and mission simulation
• STK needs geometric information that is resident in SW(solar panels, their articulation, a tessellated representation of the outer shell of the satellite, mass properties, material properties, etc.)
Solidworks to STK
32
• Tight coupling approach works with the tools’ API
• Here, we developed an “STK exporter” inside SolidWorks
• Standard SolidWorks look and feel, user does not have to learn a new tool
• Requires software development and maintenance
Solidworks to STK (ct’d)
33
1. CAD designer downselects in the assembly tree the components to be exported to STK
2. CAD designer defines the solar panel group(s) for STK
3. CAD designer defines articulations of the solar panel group(s)
Solidworks to STK (ct’d)
34
4. CAD designer saves STK model file
5. Satellite analyst reads model file into STK
Loose Coupling Using Comet
35
• The Comet integration framework by Comet Solutions builds on the so-called “Abstract Engineering Model”
• It creates a layer of abstraction between the CAD model and the downstream engineering analysis or meshing tool
• This layer of abstraction, or AEM, builds on the notion of entity tagging
• One instance of geometry is easily replaceable by another instance carrying similar tags, even if the geometry itself is significantly different
• Comet had been successfully applied to a number of satellite design applications
Satellite Thermal Analysis
36
• Satellite thermal analysis required complete rebuilding of the geometry inside the thermal analysis tool (Thermal Desktop)
• Using the Comet framework, we developed a seamless process that guarantees data consistency across the tools
• The thermal mesh is generated by Comet’s own meshing tool
Detailed Geometry
37
• The detailed geometry contains too much detail not needed for thermal analysis
• This geometry is associatively simplified to the appropriate level of detail
Preparing the CAD Model
38
• Small features not necessary for thermal analysis suppressed/hidden
• Geometry tagged with Comet tagging engine
• The tags are used by the thermal analysis model generation process to apply thermal loads and boundary conditions
Geometry for thermal analysis
Thermal Analysis Mesh
39
• Thermal analysis mesh linked to geometry via the AEM
Modeling of Thermal Contacts
40
• Thermal contacts are automatically applied based on the tags stored in the AEM
Thermal Results
41
• Thermal analysis results can be displayed in Comet’s post-processing tool or directly through the native postprocessor of Thermal Desktop
42
Summary
Contact Information:
Dr. Peter Rohl email: [email protected] Mgr, PI Phone: 909-307-6218 x580
• A simulation data management solution based on Aras Innovator was developed for NASA
• The concept of a “Simulation Bill of Material” was introduced, linking all engineering analysis models and data to the mission design project
• Engineering analyses and their driving requirements were linked
• Automated user notification was implemented to alert users when their models are possibly out of date
• Ease of use was a key design driver as engineers don’t like the overhead oftentimes associated with a PLM solution
• Both tight and loose coupling solutions for engineering analysis models were successfully implemented
43
Acknowledgment
This work was sponsored by NASA through SBIR Phase II Contract #NNX09CA16C.
Contact Information:
Dr. Peter Rohl email: [email protected] Mgr, PI Phone: 909-307-6218 x580