Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
Incorporation of mission scenarios in deep space spacecraft design trades
(USC Thesis Other)
Incorporation of mission scenarios in deep space spacecraft design trades
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
Incorporation of Mission Scenarios in Deep Space Spacecraft Design Trades by Timothy Weise A thesis presented to the Guidance Committee in partial fulfillment of the PhD requirements for the Astronautical Engineering Department, Faculty of the USC Graduate School University of Southern California May 2016 ii Incorporation of Mission Scenarios in Deep Space Spacecraft Design Trades Approved by: Professor Joseph Kunc, Advisor Department of Astronautical Engineering Viterbi School of Engineering University of Southern California Professor Daniel Erwin Department of Astronautical Engineering Viterbi School of Engineering University of Southern California Professor Azad Madni Department of Astronautical Engineering Viterbi School of Engineering University of Southern California Associate Professor Geoff Shiflett Aerospace and Mechanical Engineering Viterbi School of Engineering University of Southern California Approved on March 11, 2016 ii Acknowledgments This project is the culmination of an eight-year journey. This time has been very rewarding with many ups and downs. The high points were working on the Dawn mission at JPL with its highly successful encounters of Vesta and Ceres, accomplishing the various requirements of this degree program, as well as celebrating 20 years of marriage. Some of the challenges were overcoming a couple of major medical issues myself and losing two family members. Completion of this program would not have been possible without the support of so many in my life and my sincere and heartfelt appreciation. I would like to thank several people who have contributed to my efforts in this thesis. First of all, Dr. Kunc, my advisor, who took me on early in the process while I was still getting my feet wet. During this time, Dave Barnhart at ISI, who allowed me to observe the various projects at ISI to see what was happening. Also, Dr. Dan Irwin, the department chair, has always been supportive of the off campus PhD student. I would also like to thank my qualifying exam committee, which included Drs. Kunc and Irwin, as well as Dr. Madni, Dr. Wang, and Dr. Shiflett, who took time out of their busy schedules. I would like to thank Dr. Madni specifically for finding time during a family emergency to participate and provide invaluable feedback on my research area. I must also thank all of my family members who have always had faith in me to finish this massive project, most importantly my wife, Lorna. She has always encouraged me to take on challenges beyond my comfort zone and has made me a better person for it. My sons, Noah and Isaac, who have seen me study all these years and understood (I hope!) when I had to balance family life and studies. iii Finally, this work is dedicated to the memory of my older brother, Thomas, and mother, Irene, both of whom passed within months of completing this project. Thomas always told me to set a goal of writing just one sentence a day to complete my dissertation. I now see the wisdom of that because it is impossible to stop at one sentence. iv Table of Contents Acknowledgments ....................................................................................................................... ii Table of Contents ........................................................................................................................ iv List of figures ................................................................................................................................ vi List of tables ................................................................................................................................ viii List of symbols and acronyms: ............................................................................................... ix 1 Introduction ............................................................................................................................. 1 1.1 Overview ......................................................................................................................................... 1 1.2 Background ................................................................................................................................... 2 1.3 Approach ........................................................................................................................................ 6 1.4 Motivation ...................................................................................................................................... 6 2 Background Literature Review ......................................................................................... 8 2.1 MBSE ................................................................................................................................................ 8 2.2 Systems Modeling Language (SysML) ................................................................................ 11 2.2.1 Overview of SysML Diagrams ........................................................................................................ 13 2.2.2 More MBSE Aspects ........................................................................................................................... 16 2.2.3 Modelica .................................................................................................................................................. 22 2.3 Spacecraft Design Process ..................................................................................................... 25 2.3.1 Development Phases ......................................................................................................................... 25 2.4 Design Trades ............................................................................................................................ 26 2.5 Design Process ........................................................................................................................... 27 2.6 Brief comparison of Earth orbiting with deep space missions ................................. 31 2.7 Jet Propulsion Laboratory’s Evolution of Project Formulation ................................ 33 3 Statement of the Problem ................................................................................................. 36 4 Methodology ......................................................................................................................... 40 4.1 Background ................................................................................................................................ 40 4.2 Initial Approach ........................................................................................................................ 40 4.3 Payload Size versus Orbit Modeling and Visualization ................................................ 43 4.4 Adding Model Details .............................................................................................................. 50 4.5 Finding a New Modeling Environment .............................................................................. 53 4.6 OpenModelica ............................................................................................................................ 55 4.6.1 Parameters and Variables ............................................................................................................... 57 4.6.2 Planetary Body Record ..................................................................................................................... 57 4.6.3 Mission Design Package ................................................................................................................... 58 4.6.4 Spacecraft Package ............................................................................................................................. 59 4.6.5 System Package .................................................................................................................................... 77 4.6.6 Setting Parameters For Study ........................................................................................................ 80 v 4.6.7 Parametric Studies ............................................................................................................................. 81 4.6.8 Summary ................................................................................................................................................. 83 5 Investigation ......................................................................................................................... 85 5.1 Dawn Mission Comparison .................................................................................................... 85 5.1.1 Dawn at Vesta ....................................................................................................................................... 86 5.1.2 Dawn at Ceres ....................................................................................................................................... 90 5.2 Applications of the Model ...................................................................................................... 91 5.2.1 Mission to Ceres .................................................................................................................................. 92 5.2.2 Comparison of Target Bodies ........................................................................................................ 98 5.2.3 Comparison of Electric Propulsion to various target bodies ......................................... 101 5.3 Evaluation of Hypotheses .................................................................................................... 106 6 Conclusions ........................................................................................................................ 110 7 Future Work ....................................................................................................................... 112 8 Appendix ............................................................................................................................. 114 8.1 Modelica Models ..................................................................................................................... 114 8.1.1 Planetary Body Record ................................................................................................................... 114 8.1.2 Mission Design Package ................................................................................................................. 115 8.1.3 Spacecraft Package ........................................................................................................................... 117 8.1.4 Example Instances ............................................................................................................................ 130 8.1.5 C-‐code to interface between Modelica and Matlab ............................................................ 131 8.1.6 Matlab Orbit Propagation and Footprint Visualization .................................................... 134 8.2 Perl Code .................................................................................................................................... 142 8.3 Matlab Code to Read Results ............................................................................................... 151 9 Sample Diagrams in SysML Model .............................................................................. 157 10 References ....................................................................................................................... 173 vi List of Figures Figure 2.1 MBSE Road Map [4] ................................................................................................... 10 Figure 2.2 Arbitrary Block Diagram ............................................................................................. 11 Figure 2.3 SysML Diagram .......................................................................................................... 12 Figure 2.4 Example SysML Diagram Showing Interface Content [1] ......................................... 13 Figure 2.5 Spacecraft Subsystem Breakdown SysML Diagram ................................................... 18 Figure 2.6 Payload Subsystem Block Diagram ............................................................................ 19 Figure 2.7 Parametric Diagram ..................................................................................................... 20 Figure 2.8 Modelica Inheritance Example [14] ............................................................................ 23 Figure 2.9 Modelica Inheritance Example, part 2 [14] ................................................................. 24 Figure 2.10 Team-X Structure [27] .............................................................................................. 34 Figure 4.1 System Level Block Diagram ...................................................................................... 42 Figure 4.2 Subsystem Block Diagram .......................................................................................... 43 Figure 4.3 Example Coverage Map .............................................................................................. 48 Figure 4.4 Example Image Location ............................................................................................. 48 Figure 4.5 Example Coverage Per Orbit ....................................................................................... 49 Figure 4.6 Solar Array Sizing Parametric Diagram ...................................................................... 51 Figure 4.7 Gravity Gradient Torque Calculations ........................................................................ 52 Figure 4.8 Modelica System Model Package Structure ................................................................ 56 Figure 4.9 Example of good ground track .................................................................................... 73 Figure 4.10 Example of a bad ground track .................................................................................. 73 Figure 5.1 Dawn at Vesta Cost Breakdown .................................................................................. 89 Figure 5.2 Dawn at Vesta Mass Breakdown ................................................................................. 89 Figure 5.3 Dawn at Vesta Selected Subsystem Parameters .......................................................... 89 Figure 5.4 Dawn at Ceres Cost Breakdown .................................................................................. 90 Figure 5.5 Dawn at Ceres Mass Breakdown ................................................................................ 90 Figure 5.6 Dawn at Ceres Selected Subsystem Parameters .......................................................... 90 Figure 5.7 Cost Breakdown for Chemical Mission to Ceres ........................................................ 94 Figure 5.8 Mass Breakdown for Mission to Ceres ....................................................................... 94 Figure 5.9 Power Breakdown for Mission to Ceres ...................................................................... 94 Figure 5.10 Subsystem Performance for Mission to Ceres ........................................................... 95 vii Figure 5.11 Mission Operations Duration .................................................................................... 95 Figure 5.12 Statistical Variation of System Cost .......................................................................... 95 Figure 5.13 Orbit Altitude as a function of resolution and FOV .................................................. 97 Figure 5.14 System cost as a function of deltaV required ............................................................ 98 Figure 5.15 System Cost Variation ............................................................................................... 99 Figure 5.16 Wet Mass Variation ................................................................................................. 100 Figure 5.17 Encounter Duration Variation ................................................................................. 100 Figure 5.18 Solar array performance .......................................................................................... 101 Figure 5.19 Cost Breakdown for EP Mission to Ceres ............................................................... 103 Figure 5.20 Solar array and telecom parameters for EP mission to Ceres ................................. 104 Figure 5.21 Power breakdown for EP mission to Ceres ............................................................. 104 Figure 5.22 Statistical Variation of Cost ..................................................................................... 105 Figure 5.23 Statistical Variation in Spacecraft Wet and Dry Masses ......................................... 105 Figure 5.24 Statistical variation in encounter duration ............................................................... 106 viii List of Tables Table 4.1 Planetary Body Record ................................................................................................. 58 Table 4.2 Orbital Parameters Class Variables .............................................................................. 59 Table 4.3 Transfer Orbit Class Parameters and Variables ............................................................ 59 Table 4.4 Generic Subsystem Class Variables ............................................................................. 61 Table 4.5 ACS Subsystem Class Parameters and Variables ......................................................... 63 Table 4.6 CDH Subsystem Class Parameters ............................................................................... 64 Table 4.7 FSW Subsystem Class Parameters ............................................................................... 65 Table 4.8 PWR Subsystem Class Parameters and Variables ........................................................ 66 Table 4.9 PROP Subsystem Class Parameters and Variables ....................................................... 68 Table 4.10 TEL Subsystem Class Parameters and Variables ....................................................... 69 Table 4.11 THERM Subsystem Class Parameters and Variables ................................................. 71 Table 4.12 Optical Payload Subsystem Class Parameters and Variables ..................................... 74 Table 4.13 Spacecraft Class Parameters and Variables ................................................................ 76 Table 4.14 Ground System Class Parameters and Variables ........................................................ 77 Table 4.15 Mission Operations Class Parameters and Variables ................................................. 78 Table 4.16 Launch Vehicle Class Parameters and Variables ....................................................... 79 Table 4.17 System Class Parameter and Variable ........................................................................ 80 Table 5.1 Dawn at Vesta and Ceres Parameters ........................................................................... 86 Table 5.2 Dawn at Vesta Results .................................................................................................. 87 Table 5.3 Dawn at Ceres Results .................................................................................................. 90 Table 5.4 Mission to Ceres Parameters under Investigation ......................................................... 93 Table 5.5 Telecom Configuration ................................................................................................. 96 Table 5.6 Target Body Properies .................................................................................................. 99 Table 5.7 Parameters chosen for EP Missions to Small Bodies ................................................. 101 ix List of symbols and acronyms: a .............................................................................. semi-major axis (km) B ............................................................................. bit depth (bits/pixel) BCA max ................................................................... Max body central angle (deg) CSV ......................................................................... comma separated value D ............................................................................. aperture diameter (m) d .............................................................................. width of square detector pixel (m) DR ........................................................................... data rate (bits per image) EP ............................................................................ electric propulsion f ............................................................................... focal length (m) FC ............................................................................ framing camera FOV ........................................................................ field of view (deg) FP ............................................................................ angular field of view (deg) GaAs ........................................................................ Gallium Arsenide GM ........................................................................... standard gravitational parameter h .............................................................................. orbit altitude above surface (km) HGA ........................................................................ high gain antenna HAMO ..................................................................... high altitude mapping orbit IA ............................................................................ incidence angle (deg) IFOV ....................................................................... instantaneous field of view (deg) I sp ............................................................................. Specific impulse (sec) JPL ........................................................................... Jet Propulsion Laboratory K ............................................................................. scale parameter (unit less) kbps .......................................................................... thousands of bits per second ∆L ........................................................................... node shift (deg) M ............................................................................. payload mass (kg) MBSE ...................................................................... model based system engineering MLI .......................................................................... multi-layer insulation M ref .......................................................................... mass of reference payload (kg) NASA ...................................................................... National Aeronautics and Space Administration x NICM ....................................................................... NASA instrument cost model N p ............................................................................ total number of pixels (unit less) P .............................................................................. orbit period (s) P p ............................................................................. payload power (W) Q ............................................................................. quality factor (unit less) R ............................................................................. aperture ratio (unit less) R b ............................................................................ radius of body (km) RCS .......................................................................... reaction control system R s ............................................................................ slant range (km) RWA ........................................................................ reaction wheel assembly TWTA ...................................................................... traveling wave tube amplifier USCM ...................................................................... Unmanned Space Vehicle Cost Model V g ............................................................................ velocity over surface (km/s) X ............................................................................. resolution at nadir (km) Z c ............................................................................ number of cross track pixels (unit less) ε .............................................................................. elevation angle (deg) η .............................................................................. sensor look angle (deg) λ .............................................................................. wavelength of detector (m) µ .............................................................................. gravitational constant (km 3 /s 2 ) ρ .............................................................................. angular radius of body (deg) P b .............................................................................. spin period of body (s) P ref ........................................................................... power of reference payload (W) 1 1 Introduction 1.1 Overview Spacecraft are becoming more and more complex, able to achieve more complex and challenging tasks. This is especially true for deep space missions, or planetary missions, where a spacecraft leaves earth’s orbit for a destination in the solar system. The accompanying mission designs are also becoming more complex, attempting to collect more data, visit new worlds, and pave the way for human exploration of the solar system. Often times these spacecraft and mission designs are resource constrained on many fronts, such as mass margin, data resolution, data volume, data bandwidth, mission duration, and perhaps most significantly, cost. One of the major challenges is being able to produce realistic size and cost estimates, which include mission scenarios, very early in the development phase, while the mission is just an idea or concept. There are methodologies, such as Model Based System Engineering (MBSE), that are beginning to address this issue, but haven’t quite closed the loop directly. The problem trying to be solved here is to determine if a single system model that computes spacecraft size and cost estimates that respond to mission scenario impacts can be developed. In short, many components or subsystems of a spacecraft can be modeled to determine their mass and cost. The mission scenarios can also be modeled to evaluate the mission operations cost, however, these models have not been connected, nor has a direct link been made between the cost of operation and a specific design trade. Each model, if a model is being used, is evaluated independently at worst, or concurrently at best, but iterations must be done between each model. By connecting the size and cost models across the spacecraft, mission design, and mission operations, meaningful trade offs can be made based on informed cost and performance data, 2 without requiring as many resources to evaluate a design concept and enabling a much smaller team to evaluate many more design options. As described in the next section, early mission concepts are typically developed with a small group of people, so providing them with a more complete picture of various performance or design trade offs, and their impact on the overall mission cost, allows them to zero in on a particular design point that meets their criteria very early with minimal cost, allowing more time to be spent working out the design details and having a mature design concept. MBSE is still a relatively young field that is continuously growing, but most use cases apply MBSE to modeling a system design that is being developed resulting in a model this is unique to a particular design. This type of use case has focused early development of MBSE on methodologies and tools to capture and represent that design, while generic modeling capabilities haven’t gained as much traction. Furthermore, some aspects of MBSE, such as System Modeling Language (SysML), which provides a standard to represent system models, has semantic limitations that inhibit its use as a method to explore many different design parameter combinations. Finally, software that can numerically solve a combined set of models, or equations, has only recently emerged in the last ten years or so. This type of software allows the modelers to focus on the engineering equations to be modeled, as opposed to translating those engineering equations into software code that solves them. It is for these reasons, that this problem hasn’t been successfully tackled in the past. 1.2 Background Many solar system exploration missions are funded in a large part through the National Aeronautics and Space Administration (NASA). Typically, NASA releases ‘Announcements of Opportunity’ (AO) for a particular class mission – for example, a Discovery Program AO will 3 outline general guidelines for launch vehicle, partnerships, and most importantly a cost cap and schedule. Obviously, a proposal will only have a high-level concept design of the spacecraft and mission. Several of these proposals may be selected for funding to refine the concept further, before making the final selection to proceed with the mission. During this process, the concept is further refined until the design is complete and ready to start the manufacture of the spacecraft. The cost cap provides a clear limit on how much money can be spent to develop and operate a mission. The schedule requirement is typically stated in the amount of time from mission selection to launch. Therefore, all of the design effort after selection must be completed rapidly and accurately so that the spacecraft can be built and tested in time to meet the schedule requirement for launch. Additionally, as the spacecraft design is being refined, the mission operations concepts are also being developed. These include the day-to-day operations concepts that describe all of the roles required to operate the mission, as well as the concepts for collecting the science data that will meet the mission requirements. The types of factors going into these designs include the resolution, signal to noise, and coverage requirements. The mission designers must combine these factors with the spacecraft capabilities to design a mission that will meet its objectives. It may become obvious to some that this process is iterative, within the spacecraft design itself, and between mission design and spacecraft design. As the spacecraft capabilities are defined, the mission designers begin laying out the mission, which could, in turn, affect the spacecraft design. For example, based on the spacecraft capabilities, the mission could take a certain amount of time to map the surface, resulting in a fuel requirement to maintain the orbit for that duration. If that fuel requirement is higher than the current spacecraft design allows, then the team iterates. 4 Another aspect of this iteration is to question the requirements. Often times that can be more challenging because there may already be a contractual aspect to meeting particular resolution or coverage requirements. However, some requirements may not have strong enough justification to drive costs up. For example, the baseline resolution requirement might be something like 10 m/pixel. A large effort might go into achieving 10 m/pixel, and it might drive up the cost for a bigger camera, or operating at a lower altitude, when relaxing the requirement to 11, 12 or even 15 m/pixel could provide a significant relief to the spacecraft and mission design. However, a clear set of tools and processes that enable the effects of requirements and spacecraft design trades, along side the corresponding mission design trades, to be studied are required, but do not yet exist for a generalized design. From the mission operations aspect, some of the early design trade outcomes can increase or decrease operational complexity, which poses a significant question: How can operational complexity be traded against potentially hard factors like mass and cost in development? The types of trades can range from flight software (FSW) capabilities to fault protection design to hardware configurations. As an extreme example, there could an early trade where the cost of building a time-based command sequencing capability in the FSW is determined to be too expensive. The operational impacts of that choice would then require communications with the Earth when ever a command needs to be issued, personnel, or ground software (GSW), must be on hand to issue the commands the correct time. But the issue doesn’t stop there. All of the ground operations must then be designed with consideration of missing commands, and/or building in redundant communications systems to reduce the likelihood of problems on the ground from impacting commands getting to the spacecraft. Obviously this is an extreme case 5 and the mission operations impact should have swayed the trade based on mission risk alone, regardless of cost. However, other trade studies do not have such a clear answer. While spacecraft are getting more complex, system-engineering methodologies and processes are improving to attempt to keep up with the challenge. MBSE provides the methodologies to model the system across various levels, from components to subsystems to systems. The recent advances in this area are aided by computational methods to support more complex models as well as software designed for the task of system modeling. However, most of the work in this area focuses on spacecraft size or cost separately from mission scenarios and operational complexity impacts. All of those must be integrated into a single model in order to quickly evaluate the impacts of various design requirements or trade offs. Integrating component models into a single system model is a relatively young practice and requires new standards and tools, which have been in development and are coming of age. One of the challenges of system modeling is that there hasn’t been a standard method to represent the system nor its components. For example, the electronics industry uses a well-established standard to draw schematics – any electrical/electronic engineer can look at anyone else’s diagram and understand what it means. System engineering will need to achieve something similar in order to be able to share, review, and understand diagrams of systems. That effort has been underway for some time by the Object Management Group (OMG) in the form of Unified Modeling Language (UML) and now System Modeling Language (SysML). The first SysML standard, 1.0, was released in 2007. The latest release is version 1.5, released in September 2015. As with any nascent field, there are challenges emerging as more practitioners work to greater levels of detail, which leaves room for growth. These types of efforts are paving the way for future modeling efforts. 6 1.3 Approach This project consisted of several phases beyond the initial literature review, which continued in parallel with the later phases. The first major phase consisted of studying MBSE, in particular SysML and associated software tools. This exploration and study of SysML morphed into the next phase, which consisted of development of basic spacecraft and optical payload sizing models within SysML utilizing the MagicDraw software application. These sizing models were developed from textbook equations to size individual subsystems, but combined into single model. As the models grew in complexity, it was determined that more utility could be had by linking the MagicDraw model to Matlab functions to take advantage of some of Matlab’s built in functionality. This phase culminated with a determination that MagicDraw and SysML would not suffice, as the models grew more and more complex. This resulted in exploring Mathematica and Modelica as alternatives, with Modelica being chosen and the models being translated to that format. The next phase consisted of refining the model to include more detail, as well as building an infrastructure to perform parametric studies. This infrastructure included Perl and Matlab scripting to execute the parametric studies in Modelica and visualize the results. The models were updated through incremental enhancements that were validated by manual computations and comparisons with similar designs. Finally, the last phase consisted of applying the model to a variety of deep space target bodies to compare the relative size and cost of these missions. 1.4 Motivation The idea for pursuing this work came from first hand observations of operational missions, particularly the Dawn mission, that already has a fixed design and the operations team planning the operations accordingly. The flight system design, coupled with resolution requirements, drove operations in certain ways – the altitude had to be low enough or science data couldn’t be 7 collected while transmitting data to Earth. This led to speculation about how would the mission be different if the flight system was different in some way. Could the mission return more data if it had a gimbaled high gain antenna? Would it help operations if the camera was higher resolution, allowing for a higher altitude orbit which would be less sensitive to the complex gravity field at Vesta? With these observations relating to the operations team responding to a design point, coupled with the emerging MBSE work at JPL, a connection was made. Could meaningful models be made that would provide the insight to the early concept developers to fully understand the ramifications of design trades on mission operations? This research intends to provide a methodology that would indeed combine spacecraft sizing, mission scenarios, and operational complexity into a single model that provides rapid turn around of design trades and a more complete understanding of cost implications. As the model becomes more refined, a clearer connection between subsystem design options and operational complexity can be made and further refined, allowing for a more accurate operational cost to be traded against subsystem design trade costs. 8 2 Background Literature Review A literature review was completed to determine what is being done in the world of system modeling, particularly coupling spacecraft design and operational concepts or scenarios, as well as spacecraft cost and sizing techniques. 2.1 MBSE “Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” [1][2] MBSE is a key aspect of solving this problem because it provides a mechanism to formally capture the design and interconnect related aspects in models. Modeling aspects of spacecraft design is not a new concept. In fact most subsystems already have established detailed models that are used throughout the various phases of development. The MBSE concept is to apply overarching modeling of the entire system across most phases of development. In early concept phases, these models may be very high level and only provide enough fidelity to approximate the mass, power, and performance of the system. As the design progresses, these very same models are refined to great detail in order to support the later phases of development. In fact, enough detail can be added to the models such that they can support everything from requirements definition to verification and validation. What is a model? Friedenthal describes models this way: “A model is a representation of one or more concepts that may be realized in the physical world. It generally describes a domain of interest.” [1] As described earlier, the models can be of varying fidelity, with a key concept that they are an abstraction of the real entity being modeled. Therefore, the model can be made 9 more generic for re-use or as detailed as necessary to accomplish the requirements of performing the modeling in the first place. As space missions become more complex, more costly, and the taxpayers become more failure averse, there is more pressure to ‘get it right.’ MBSE is one of the techniques that are being utilized to help in that endeavor. In fact, the Jet Propulsion Laboratory (JPL), has been undertaking MBSE for more than a decade. S. Wall describes the JPL Model Based Engineering Design (MBED) initiative in his IEEE paper in 2004, “Model-Based Engineering Design for Space Missions.” This paper describes the effort to integrate model-based engineering from the early development phases through to the detailed design phases by increasing the detail of the early models as the design details emerge. [3] Additionally, it describes the concept of executable requirements, instead of text-based requirements, where requirements encoded in the model can be checked against the design contained in the model. The can reduce, or even eliminate, the typical book keeping iterations through the requirements process into the detailed design phase that ensure consistency when using text based requirement documentation. The International Council on Systems Engineering (INCOSE) has been very active in promoting and developing MBSE. Their efforts range from defining standards, such as SysML 1.3, to defining MBSE theory and ontologies. This can be seen in Figure 2.1, from the INCOSE Ontology Summit 2012. [4] 10 Figure 2.1 MBSE Road Map [4] In order to advance the MBSE effort, the Space Systems Working Group (SSWG) within INCOSE created a Space Systems Challenge team which applied MBSE methodologies to an actual CubeSat mission, the Radio Aurora Explorer (RAX) mission. This effort resulted in accurate operational scenarios being modeled at the system level including overall power and telecom signal strength performance parameters. [5] Recently, JPL has continued with its effort of infusing MBSE into the project development timeline, most notably on the Europa Mission concept studies. These were a follow on to the Jupiter Europa Orbiter (JEO) mission, which invested heavily in MBSE during the pre-project work. That mission effort did not become an active project and the team focused on how to reduce the costs of a mission to Jupiter or its moons. That investment in MBSE paid off with a little extra investment to create a very agile infrastructure to study various mission concepts and INCOSE MBSE Roadmap 2010 2020 2025 Maturity MBSE Capability Ad Hoc MBSE Document Centric 2010 Well Defined MBSE Institutionalized MBSE across Academia/Industry Reduced cycle times Design optimization across broad trade space Cross domain effects based analysis System of systems interoperability Extending Maturity and Capability Distributed & secure model repositories crossing multiple domains Defined MBSE theory, ontology, and formalisms Emerging MBSE standards Matured MBSE methods and metrics, Integrated System/HW/SW models Architecture model integrated with Simulation, Analysis, and Visualization • Planning & Support • Research • Standards Development • Processes, Practices, & Methods • Tools & Technology Enhancements • Outreach, Training & Education Refer to activities in the following areas: 4 11 trade performance and cost very rapidly compared with typical missions of this class. [6] Clearly, MBSE is influencing academia, small CubeSat missions, and large interplanetary missions. 2.2 Systems Modeling Language (SysML) Coupled with MBSE is the Systems Modeling Language (SysML), which provides a formal nomenclature for model definition. The Object Management Group (OMG) maintains and releases the specification of SysML, the latest being V1.3 released on June 8, 2012.[7] This specification allows software developers to create software applications to support MBSE and Figure 2.2 Arbitrary Block Diagram SysML to a common specification. Prior to SysML, a diagram similar to the one shown in Figure 2.2 may be used in the design process. Notice that there are lines drawn between the boxes, but no indications what those lines or the boxes themselves mean. The lines could be power, data, or control signal lines, or a functional decomposition of the subsystem. SysML provides the structure and formalism of the diagrams within a model so that it is absolutely clear what the Subsystem 1 Unit A Part X Part Y Unit B Component 1 12 different boxes, and lines between them, on the diagram represent. This greatly improves communication across the development team because everyone will be speaking the same language. Figure 2.3 shows a similar diagram, but using SysML to formalize the meanings Figure 2.3 SysML Diagram of the elements. This figure shows that a subsystem is made up of zero to many components, with each component having at least three properties- mass, power, and data. The units for those properties are clearly defined. The ‘constraints’ section of the top block represents the mathematical constraint that the subsystem level mass, power, or data are computed from the components. Figure 2.4 shows a SysML diagram with interfaces between components specified. The icons with the arrows show the direction of the data flow, with the labels explicitly defining the content, such as light, or an image. Not only do the diagrams help the engineers visualize the system, the software will actually enforce the data flows by flagging errors when connections are 13 made between different types of interfaces. There have been comparisons between SysML for Figure 2.4 Example SysML Diagram Showing Interface Content [1] systems and electrical schematics for electronics. The symbology defined for electrical schematics has been in use for years, now Systems Engineering is catching up. 2.2.1 Overview of SysML Diagrams This section will provide a brief overview of SysML diagrams. Most of the information contained here was taken from “A Practical Guide to SysML” by S. Friedenthal. [1] SysML defines a hierarchy of diagram types with corresponding content. These diagrams begin forming the model of the system of interest. It should also be noted that the diagrams are really a view into the model to provide the engineer with a clear view into the system. Therefore, when creating a model, there can be several diagrams of the same entity, but each diagram focuses on different aspects so that the reader of the diagram can easily discern the key information quickly. Therefore, the diagram content will be specific to the type of diagram, as well as the purpose of the diagram. For example, a Requirements diagram will contain requirements, but could also include references to the entity that satisfies the requirement, so if the purpose of a particular diagram is to show all the requirements, that’s all it will show, but if 14 the purpose is to show the linkage to the parts satisfying the requirement, those parts will be shown as well. SysML, being typical of modern software architecture, supports, even encourages, modularity, since many aspects of the systems being implemented with SysML are made up of components that can be reused. For example, when modeling passenger automobiles, they all have wheels and being able to re-use a wheel model will save time, effort, and money. A Package diagram (PKG) is used to capture the model elements and will show the packages and sub-packages that make up a particular model. The software tools developed to implement SysML models take advantage of this and provide methods to share and reuse models or model components through SysML packages. Most of the physical representation of a system will be defined in a Block Definition diagram (BDD), which shows SysML blocks, as could be expected. Blocks are the ‘building blocks’ of SysML. When modeling a spacecraft, the entire spacecraft is defined as a block, which is then made up of other blocks, such as a power subsystem, all the way down to the level of detail specified in the model. Each block can have attributes, and can share attribute definitions, in a parent-child relationship, similar to classes and subclasses in object-oriented programming. For example, in a spacecraft model, every subsystem will have attributes such as mass and power, and those are rollups from the subsystem components, and rollup themselves to the spacecraft level. Therefore, it can be beneficial to use various relationships between blocks to ensure consistency and allow for straightforward model analysis. In order to define the interfaces between parts, as well as other interactions, the model will contain Internal Block diagrams (IBD). These will show the very specific interface between components. Each item on the diagram will have connections that have a type associated with 15 them, and the modeling tools will not allow a connection between dissimilar types, making it obvious to the engineers that there is an interface problem. The connections can also be directional, as in the case of a data flow, and that is also captured in the diagram. Typically, a model will have a set of diagrams, referred to as Structure diagrams that represent the physical components of the system. These are just specific instances of Block Definition and Internal Block diagrams A Behavior diagram is the generic term for any of these diagrams: Acitivity (ACT), Sequence (SD), State Machine (STM), or Use Case (UC) diagrams. These are used to define behaviors, cause and effect relationships, and order of events type information. Each of these captures a specific type of information. Activity diagrams show the order of actions by the components based on when the inputs are available and the control signals that interact with parts. It will also show the relationship between the inputs and outputs. The Sequence diagram is specific to representing messages flowing between components or systems. As could be expected, the State Machine diagram shows the model states and the transitions between them. Finally, the Use Case diagram represents how a system is used and shows interactions with users, for example. Finally, Parametric (PAR) diagrams contain equations, in the form of constraints, which provide mathematical connections between components. For example, a parametric diagram would contain the equations that perform the mass rollup computations for the spacecraft and subsystems. This example is one of the clear benefits to system level modeling – when a subsystem model is updated with a new mass value, that information is immediately available to the system engineers so that the next time they look up the total mass in the model, it will include the updated subsystem value. 16 While the type of diagram provides the context for the data on the diagram, the specific shapes provide clear and consistent information. The shape of a box indicates what it represents, and the style of connector between boxes indicates the type of relationship. For example, a BDD of the spacecraft and its subsystems will have boxes that represent logical groupings, like subsystems, and the lines connecting them will indicate that the system, or spacecraft in this case, is made up of subsystems. For the interconnections or interfaces between components shown on an IBD, the shapes of the connections on the lines between them define the interface. Additionally, these connections have ‘types,’ which means that the components on either end of the connection must be expecting that type. For example, a connection could show a data interface, and each component must be defined to have that data interface. Typically, the software tools developed to support SysML will perform automatic error checking to ensure consistency. 2.2.2 More MBSE Aspects While the diagram specifications provide the framework to represent a system and its components in a structured fashion, and to define the interfaces and interactions between them, they are really just a view into the model, where the model is the entire representation of the system of interest. There are many underlying attributes required to fully define a system that if displayed on every diagram, they would become utterly confusing and unreadable. It will be up to the modeling engineer to know the target audience of a diagram – is it for a preliminary design review, interface discussion meeting, or system documentation. A significant benefit of MBSE is that the model becomes the system documentation. Prior to MBSE, stacks of documents, from requirements specifications to interface specifications and user guides, defined the vast majority of complex systems. Given the iterative nature of 17 developing extremely complex systems such as space systems, a design change can result in a significant amount of work just tracking down all of the affected components. While this work will be focusing on MBSE and SysML, the German Aerospace Center (DLR) recognized the need to capture all of the connected information and focused on Knowledge Management (KM) tools that captured things from documentation to models and simulations. [8] In this day and age, all spacecraft design work is performed on computers. Implementing SysML is no different, with several applications that implement the standard. This work will focus on the application MagicDraw, developed by No Magic, Inc. The SysML models are developed within this application, with the user creating model elements, diagrams, and reports. With the entire system in a single model, that model effectively becomes a database that can be queried to gather particular information, such as the mass roll ups, the component lists, requirements, requirement verification status, etc. When implemented correctly, this can be an efficiency booster. MBSE has been in work for some time, but is still an emerging trend. As with any emerging methodology, it will require dedication by companies and institutions to incorporate it into their processes. Before doing that, however, they must determine an appropriate methodology of MBSE for their industry. Further reflecting the international emergence of MBSE, the International Journal of Engineering Trends and Technology (IJETT), published a paper that evaluated several different MBSE methodologies. [9] A little closer to home, JPL’s use of MBSE on the Europa Mission Concept Study reinforce the need for the institution to commit to using MBSE, as well as developing useful tools and frameworks to get the most benefit from MBSE. [10] 18 Figure 2.5 Spacecraft Subsystem Breakdown SysML Diagram Figure 2.5 shows the block diagram for a spacecraft. Note that each subsystem block has attributes, but are hidden for this view to simplify what is being displayed. For example, Figure 2.6 shows the payload subsystem block, with its detail expanded. This shows all of the attributes, calculation names, and other reference items. For example, since the payload calculations rely on the orbit altitude and period, there are references to the parts of the model that contain those elements. 19 Figure 2.6 Payload Subsystem Block Diagram 20 The motivation is to research MBSE and spacecraft sizing, particularly for numerical results, the primary diagrams of interest here are the block definition diagram, to capture the breakdown of components, and the parametric diagram, to capture the mathematical relationships. Figure 2.7 Parametric Diagram Figure 2.7 shows how a parametric diagram represents mathematical relationships between components and parameters. The green shaded boxes with rounded corners and the label ‘«constraint»’ represent calculations between parameters. The box near the lower right corner with the label ‘«block»’ shows parameters that are part of a different model component. This is 21 showing that those parameters are not duplicated – these calculations are using the same parameters that are used in the ‘Orbit Parameters’ block, represented on a different diagram. One of the challenges of system engineering complex systems is ensuring that every engineer and document have the same value. For example, the mission designers might be evaluating several orbital altitudes and determine a new altitude to be used. Meanwhile, the payload engineers have been working with the previous baseline altitude. Without checks and balances, or the very tedious job of reviewing all of the documentation for each subsystem to ensure consistency, this difference may not show up until very late, possibly even after launch. SysML, and the software that implements the standard provide a very straightforward mechanism to keep everyone on the same page. The other boxes with square corners labeled ‘«ValueType»’ represent parameters within the payload subsystem it self. SysML defines constraints as equations that relate different values or properties of the system. The constraint blocks have attributes consisting of each parameter in the equation, as well as the equation itself. Being able to define these relationships in a consistent and reliable way is great, but the real benefit is being able to execute the calculations to solve for the actual numbers. This is where the software application implementation of SysML controls how that actually functions. The application MagicDraw provides full support for the SysML standard, but relies on plugins to perform the parametric analysis. The plugin is called ParaMagic by InterCax. This tool is very powerful because it contains a solver that can determine the order of equations, even solve for elements on the right hand side of the equation if the left hand side is given or comes from a different equation. When the computations are made, the solver evaluates all of the expressions, along with the given values, to solve the system of equations. In addition to the 22 standard mathematical operations available, users can create scripts and functions for other applications, like Mathematica and MatLab, allowing for more complex algorithms. 2.2.3 Modelica Modelica is a system modeling language that is developed and maintained by the Modelica Association, which is a non-profit and non-governmental organization. [11] The language is free and provides a standard specification for both a graphical representation of a physical system, as well as a text based representation. [12] Included with the language and specification is a library of models that represent various mechanical, electrical, thermal, or fluid components and systems, allowing for a quick build up of a system of components. There are several software tool implementations of Modelica, such as MapleSim, Dymola and OpenModelica. [13] Because the language is object oriented, there are class definitions and a hierarchy of inheritance from parent to child classes, allowing for tremendous re-use and expansion while maintaining consistency. Furthermore, there are standard connection classes, allowing connections to be made without needing to understand the details of the component model. For example, within the model libraries for electrical components, there are models of various components, such as resistors, inductors, capacitors, etc. In any system to use these, they must be connected to other components. The model of the a resistor includes parameters for the two connections in the form of Pin 1 and Pin 2. Instead of starting from scratch, the resistor is a subclass of two pin components and inherits the pin definition form the parent class. Of course, the definition of a pin is also another class with associated attributes, specifically connections. The resistor class extends the two-pin class by adding resistor specific elements, like the resistance and the equations for voltage and current through the resistor. [14] 23 By treating the model as something built up of physical components, the engineer can build a model that maintains the physical representation in graphical sense, and the tool will interpret the connections between components to assign values and build up an executable set of code to simulate the model. Modelica is really tuned to simulate dynamic models, something as a function of time. It has tremendous power built in to solve differential equations so that the user can keep the model a close to physical as possible. For example, the equation for an inductor remains of the form d dt i=v /L where i is current, v is voltage, and L is inductance. Because the inductor model inherits the pins from a connection class that includes the relationships for voltage and current already, this is the only equation that needs to be added. See Figure 2.8 and Figure 2.9. Figure 2.8 Modelica Inheritance Example [14] 24 Figure 2.9 Modelica Inheritance Example, part 2 [14] The figures show equations with different numbers of variables on the left, as well as the right, hand sides of the equals sign. That is because the Modelica language actually allows equations. Most typical software languages use the equals sign as an assignment operator; store the value of the stuff on the right into the memory location of the name on the left. The difference here is that the Modelica language supports an acausal solver, which is similar to the Paramagic plug-in mentioned in the earlier section on SysML. Again, this type of equation solving allows the relationships to be defined in ways that engineers are used to seeing them, keep the code of the model more similar to the physical representation. Another very appealing aspect of Modelica is that model components are ‘replaceable.’ This means that a model could be developed with several attributes for a specific case, but if one or more of those attributes must change in order to model a different case, the attribute that must change can be replaced by a new definition. This allows the extension of an already modeled 25 component to reuse everything except the attribute the needs to be changed. This capability allows for greater reuse and less time spent validating completely new models. In fact, Pulecchi describes a Modelica library that was developed to model space flight dynamics. [15][16] These papers reflect all of the benefits listed earlier with object oriented models, replaceable components, and dynamic simulation. The library takes advantage of many of the existing Modelica libraries, such as the MultiBody library, to avoid duplication of work. This library consisted of a world model to simulate the space environment of an Earth orbiting satellite, a spacecraft dynamics model to capture the dynamic equations of motion, and a spacecraft model containing the various components of an attitude control system. Since this library was intended to be applied to various spacecraft configurations, it takes great advantage of the replaceable feature of Modelica models and classes. This allows a generic spacecraft model to be customized by simply defining a specific spacecraft that consists of the generic spacecraft and the specific changes, again, providing tremendous reuse. This library allows the user to get to the level of the control design relatively easily. 2.3 Spacecraft Design Process 2.3.1 Development Phases All space missions follow one of several standard development cycles, all of which progress from early concept stages, through design and development, into assembly and test, and finally operations. Regardless of the specific flow, each mission will start with the early concept, which needs to be evaluated early on to establish feasibility within the program constraints. This early phase will undoubtedly require assumptions to be made as well as constraints or requirements placed on the system design. This phase is characterized by many trade studies to evaluate 26 different options and capabilities. As the program progresses into a fully funded program, requirements on the system will be established. The top-level requirements will capture the high- level performance requirements necessary to meet mission objectives. The outcome of the early trade studies may place additional requirements on the system as well. Then, as the design evolves and the true capabilities are defined, or discovered, it must be compared to the top-level requirements. This typically results in requirement to design to evaluation iterations that drive changes in the system. This usually does not have a significant impact if it is early in the process, but as more and more of the system is designed, requirement changes can have a large impact on the cost and schedule of the mission. Therefore, being able to define the correct requirements early in development and minimizing later changes will result in lower cost and shorter development schedules. MBSE is emerging as a methodology that can help in that regard. 2.4 Design Trades Typical missions start with an idea or concept to meet some need – study the Earth’s CO 2 levels or explore the moons of a planet in our solar system. At this very early stage, the developers have some understanding of typical performance and capabilities and will begin laying out a system expected to meet the original need and cost constraints. Many of the high level components may be defined at this stage – how many instruments, actuators, redundancy, etc., with detailed components coming later in the process. However, these early concept phases often define performance requirements, such as minimum resolution or minimum coverage requirements. These are usually very specific numbers, like 10 m/pixel, and have some level of scientific justification that links the resolution to the scientific objective, like being able to resolve larger surface features, but not expecting to 27 detect the smaller ones. Once that 10 m/pixel requirement is defined, it becomes very difficult to relax because it is now the customer’s expectation. Therefore, the early studies must establish the feasibility of the 10 m/pixel and ensure that it does not drive the mission cost beyond the available funding. This requirement may become a driving requirement, resulting in significant resources being dedicated to meeting it. However, in a cost constrained development environment, it would be enormously helpful to find the sweet spot in terms of performance versus cost. For example, 10 m/pixel may drive up the cost prohibitively, but an early full mission scenario model may determine that relaxing the requirement to 11 or 12 m/pixel, which may be adequate for the scientific objectives, could have significant savings. 2.5 Design Process There are many aspects to the spacecraft design process. In all cases, the system of interest will need to accomplish some objectives. Defining those objectives must be done first, followed by characterizing the mission to establish the mission architecture. This part defines such items as data distribution on the ground, flight versus ground trades, the communication architecture, and the mission timeline. Next, the mission details are designed and iterated. These details include orbit design, payload sizing, spacecraft sizing, mission operations approach, launch and trajectory design, and costing. [17] Beginning with the basic mission objectives, an early mission concept must be established as a starting point. For deep space missions, those leaving earth’s orbit, there could be some key drivers already. For example, a mission to the outer planets will push solar array technology to the limit, if even possible. NASA’s Juno mission utilizes solar arrays for electric power at Jupiter, which is over 5 times further from the sun than the Earth, resulting in 25 times less solar energy. To meet the spacecraft’s power needs, it has massive solar arrays. [18] On the other hand, a 28 mission to Mercury would require extensive thermal management and special consideration for solar cells at such a close range to the sun. Within the bounds of any specific environmental constraints, the spacecraft architecture will be laid out in a way to support the payload concept. The scientific objective of the mission will dictate what the payload will need to study and how that will be achieved. A mission to characterize the mineralogical makeup of the earth’s moon would need some sort of spectrometer, while studying the atmospheric water content of the earth would need a radiometer. Therefore, the mission objectives will define what instruments the payload will require. Those instruments, will then influence the spacecraft design to support their mass, power, and data requirements. The size of the payload will greatly depend on the orbit design in order to achieve the resolution and coverage requirements. The orbit design could be considered the key connection between the spacecraft design and the payload design, while all three will need to converge in order to have system that will meet the mission objectives. Again, there will be environmental impacts on the orbit selection that will place constraints on the final selection, or drive spacecraft requirements. Juno is a great example, where the observation orbit was designed to be highly elliptical to provide a low altitude observation of Jupiter during periapsis, but minimize the amount of time so close to Jupiter’s damaging radiation environment. By minimizing the radiation exposure, the spacecraft could be designed accordingly, saving mass and other resources. [18] Other solar system bodies also have their own special features, like the Martian atmosphere, or the highly complex gravity field of the proto-planet Vesta. By utilizing these constraints, designers can then trade orbit characteristics with payload size and performance against the mission objectives. Should the orbital altitude be lower to increase the resolution? Or have a larger imaging camera to achieve the same resolution at higher altitude? Which solution provides better surface coverage over 29 time? Does the mission have a hard time constraint, or potential for extended mission operations? Does the orbit altitude or other geometry drive a delta-V requirement? All of these questions must be considered when trading off orbit design against payload size. With the rough orbit design and payload size, the mission operations approach can be established. This step will outline the operation concepts, which will define the necessary infrastructure, such as ground hardware, software, and facilities, as well as staffing levels. Some of the trades that will come in to play will address the level of on board processing, autonomy, and ground monitoring. Finally, the spacecraft can be designed to support the payload, fly the orbit, and ultimately meet the mission objectives. All of the trades so far will have a clear impact on the spacecraft design, and ultimately the overall mission cost. As the orbit is designed, it will define a delta-V requirement, and thus a propellant mass, which will influence the overall spacecraft mass. Similarly, with the payload size and data return plan. The payload mass will drive the spacecraft mass, and the data return plan will drive the data handling subsystem and telecommunications subsystem, as well as ground operations costs to process the data. For example, the New Horizons mission to Pluto will have a relatively short flyby encounter of Pluto, but then take over 9 months to send all of the data back to Earth. [19] Finally, the spacecraft mass and launch trajectory are used to define the launch vehicle requirements and selection. With the launch requirements will come the launch site, which will allow the designers and planners outline the full spacecraft development schedule, transportation needs, and other logistics. All of these aspects will fold into the overall mission timeline and cost. Obviously, no customer in his or her right mind would allow a mission to proceed without having a reasonable, if not accurate, estimate of the overall mission cost. Many factors will affect 30 the cost: spacecraft development and procurement, launch vehicle, mission operations, and mission duration, from initial development through end of mission. There are several methods to estimate costs, including a grass roots approach where experts analyze the system and provide an estimate, as well as algorithms based on prior experience. These algorithms are referred to as Cost Estimating Relationships (CER) and attempt to define the cost of a component as some function of a particular metric, like mass or power. While there are some publicly available CERs, attempting to address cost generically across the aerospace industry is impossible for all practical proposes since each company and institution treats their cost data as proprietary. Since the ultimate award of a contract to complete a space mission is largely based on cost relative to the capabilities of the mission, the revelation of a company’s cost data could damage that company’s ability to win a contract since a competitor could adjust their bid to beat the first company. Much of this work will be based on CERs defined in “Space Mission Analysis and Design,” “Space Mission Engineering: The New SMAD,” and the NASA Instrument Cost Model (NICM). [17] [20][21][22] While the specific costing data may not be available, there are CERs defined in the literature that can be applied to estimate costs, as well as determine the sensitivity of the cost to various parameters, such as mass, resolution, mission duration. Additionally, engineers with access to their company or institution’s cost data will be able to more accurately estimate the cost by applying the correct CER. A key aspect of these design and cost trades is that many of them are not independent, but current methods typically treat them as independent in order to simplify the problem and then iterate the trades to fully understand the design space. Being able to assess all, or at least the key, drivers simultaneously would enhance the design and cost estimating phases by rapidly trading across the design space. 31 2.6 Brief comparison of Earth orbiting with deep space missions Typical Earth orbiting spacecraft can often employ a large variety of mission and spacecraft architectures, while deep space missions tend to have a few more constraints, limiting the possible architectures. For example, spacecraft in low earth orbit (LEO), can utilize GPS receivers to provide spacecraft location and time references, while missions beyond Earth’s orbit cannot, and must perform those functions by other means. Also, the telecommunications options for spacecraft near Earth are many as there are many ground stations, the distance over which the signal must propagate is small (requiring less antenna gain and/or transmitter power), and there are even spacecraft that can relay the signal, amongst other options. Deep space missions, especially United States missions, typically rely on NASA’s Deep Space Network (DSN) for telecommunications. [23] This may pose several constraints on the spacecraft architecture, as well as the mission architecture. First, the telecommunications subsystem on the spacecraft must be compatible with the DSN equipment, such as frequency band and data encoding methods. Next, the DSN consists of three complexes spread approximately 120 degrees of longitude apart around the world. Two of these complexes have four antennas, while the third has five. Since the complexes are evenly spaced around the world, there is minimal overlap in terms of the view of the sky, so there are only a limited number of antennas that can view a mission at any one time, and those antennas must be shared with many missions. For example, the DSN is still communicating with Voyager 1 and 2 on a weekly basis! Therefore, a mission utilizing the DSN must accommodate the DSN scheduling requirements and interfaces. Finally, other aspects of the spacecraft design and mission are highly influenced by leaving Earth’s orbit. For example, solar cells are very well characterized for Earth’s orbit, but missions going closer to (temperature 32 becomes an important factor) or farther from the sun, will need to be able to deal these variations. [24] Another aspect of the difference between Earth orbiting and deep space missions relates to the overall mission objectives and duration. An Earth orbiting mission can be placed in orbit directly from the launch vehicle, or with minimal delta-V requirements on the spacecraft, and start acquiring science data within days or weeks of launch. Conversely, deep space missions may have extended cruise phases during which the spacecraft travels from Earth to the target body. The cruise phase can be months, such as a Mars mission, or years for outer planets missions. The cruise phase places additional resource constraints on the mission in the form of cost and lifetime. Just the orbit transfer from Earth to the target requires mass for propulsion, plus the extended duration increases the exposure of the flight system to the harsh space environment. Additionally, the cruise phase can be very quiet, like the Rosetta and New Horizons projects where the spacecraft were put into ‘hibernation,’ which is a minimal operational state that does not require interaction with the Earth based controllers for years, or be very active like the Dawn mission which uses ion propulsion to maneuver to its targets and requiring ground controllers to make regular maneuver designs and uplink them to the spacecraft. [19][25][26] Clearly, these differences in operations will have a dramatic difference in mission operations cost. Finally, the observational strategy can be significantly different between Earth observing missions and extraterrestrial missions. Extraterrestrial missions typically require more launch energy in order to escape Earth’s orbit and achieve an interplanetary trajectory, which makes the spacecraft mass even more of a cost driver, in turn, limiting such things as camera mass and size. Once at its target, typical mission designs involved mapping or observing the entire surface to 33 some resolution for previously unexplored targets. An Earth based mission may focus only on land, or ocean, observations, thus not requiring a regular global observation. Additionally, the deep space mission will be up against the clock to complete its observations before running out of fuel and/or money. This drives the project to be able to determine how to complete the mission within its resources very early in the development process. 2.7 Jet Propulsion Laboratory’s Evolution of Project Formulation As an institution that has flown many deep space missions, as well as Earth orbiting missions, JPL (Jet Propulsion Laboratory) has evolved its process to deal with the latest trends in funding, project schedule, and project capture process. The onset of the Discovery Program and PI-led missions in the early 1990’s has brought with it many more mission concepts that need early evaluations to determine if it is worth developing further. As a response to this, JPL changed its design process to be more responsive.[27] These changes included many new techniques, tools, and organizations. One of the central concepts was Team-X. This is a team made up of experts from all aspects of mission development that participate in integrated design sessions that would iterate through a concept’s design utilizing a new infrastructure in the form of a database that stored the outputs of the subsystem models to be incorporated into cross cutting system models. Figure 2.10 shows the components of the Team-X concept. It should be noted that at this point in time (1999), Team-X evaluated point designs. 34 Figure 2.10 Team-X Structure [27] As mission concepts evolved with newer technology, different architectures of mission needed to be evaluated to achieve the same or similar science goals. The capabilities of JPL Team-X improved by adding the Rapid Mission Architecture (RMA) capability as early as 2007. [28] This capability allowed a team of experts to evaluate broad trade spaces prior to the normal Team-X point design iteration and evaluation. This team would evaluate many architectures in enough detail to narrow down the list to a smaller selection to be evaluated in more detail. The 35 RMA approach created a scale to rank science objectives, risks, and costs to attempt compare possibly significantly different architectures. The latest evolution of program formulation was the Innovation Foundry. [29] In this paper, Sherwood points out that there are more competitors for NASAs dollars with more complex ideas and fewer resources to develop proposals. Additionally, with the limited resources in early formulation, coupled with inadequate resources in Phase A and B, projects have had trouble bounding implementation risks. A method to evaluate a mission idea, or concept, is to assess its maturity level. In 2009, JPL developed the Concept Maturity Level (CML) scale to formalize this process, assigned specific numbers to maturity levels, with clear criteria for each level. [30] Furthermore, the Sherwood’s paper shows how the CML flows into the NASA project lifecycle, where the CML must get from level 1 to level 5 by the time of the proposal. To aid in this task, the Innovation Foundry formed the A-Team, which is similar to Team-X, but for architecture evaluation. It also operates in a concurrent engineering environment, with team members collocated for design sessions. Typically, any work on a mission concept at this time does not have specific funding from the proposal request. For the Discovery Program, the funding from NASA typically starts when a proposal has been selected for Phase A, so all of the concept development needs to be funded by the institutions that are participating. JPL’s answer to this problem is the Innovation Foundry that allows rapid turn-around with multi-disciplinary teams refining concepts in an iterative cycle. 36 3 Statement of the Problem Many of the early design trades can have a dramatic impact on the mission operations scenarios, which can impact the mission’s ability to get the most bang for the buck. The design trades can be architectural in nature where the team chooses a particular architecture over the other, or size/capability driven. The former category of trades could be things like a gimbaled high gain antenna, which has clear impacts to the operation of the spacecraft, amount of time that it takes to return data, planning resources, as well as development impacts in terms of cost, mass, and complexity. The latter category could include the antenna size, which translates ultimately to the supportable data rate, of the antenna. This sort of trade also impacts operations, but the trades between more performance and less performance seem to be clearer. An engineer could ask how the data rate impacts science data return, and then have to trade a science return objective to a mass trade off. That trade on its own could be very challenging if the spacecraft was reaching mass limits. However, could there be a different place to take mass from to give to the antenna? For example, if the science data could be returned in a shorter amount of time, maybe less fuel would need to be loaded, allowing the mass to fit within limits. But how can that be determined? Operational complexity is another topic that is challenging to assess. The outcome of some design trades may impact operational complexity, resulting in higher or lower mission operations costs, as well as impacts to mission operations development. In some ways, this is similar to the adage that software engineers fix the problems left by the hardware engineers. The operations team can deal with the spacecraft design given to them, but it may take longer to develop the ground system and tools to be able to perform that task. Deep space missions provide a greater challenge to design because they are typically more resource constrained. For example, an earth orbiting mission requires less launch vehicle 37 capability to get to orbit, and once on orbit, typically has more downlink bandwidth and may have an extended duration to complete its mission. Conversely, deep space missions require more launch vehicle capability resulting in being more mass limited, there are fewer earth receiving stations that can support these missions and the extended range of the spacecraft both limit the downlink bandwidth, and the mission design may limit the duration of the science collection phase. Research Question 1: Can MBSE techniques be used to develop a single high-level system model of a deep space mission that incorporates spacecraft sizing as well as mission scenarios for a generic mission design? The literature reviewed found many cases where MBSE techniques have been applied to various space missions. Most of those found were an application of MBSE after the design had been refined so the models were not used for early design trades. There have also been clear successes with MBSE being applied to evaluate detailed architectures – the Europa Mission Concept studies evaluated three concepts in the normal time it would take to evaluate one or maybe two, obviously providing a tremendous improvement in the time it takes to evaluate systems. [10] However, this effort included defining a specific model for each concept. Research Question 2: Can a single high-level system model be used to evaluate hundreds to thousands of parameter combinations to evaluate the sensitivity of cross-subsystem/system impacts? 38 There are many efforts to optimize a system. Sometimes it is not optimal to optimize the system on any one parameter. For example, one could find the lowest cost solution based on optimizing for cost. However, there may be a slightly more expensive solution, which offers some other benefit, like lower risk or other less tangible aspect. Therefore, being able to run thousands of combinations relatively quickly by one person could provide the insight needed before taking a concept to Team-X. Hypothesis #1: MBSE can in fact be applied across the mission concept generically to create a single model that covers high-level spacecraft sizing through mission operations allowing a single user to vary parameters across the system to evaluate the impacts. The literature has shown that MBSE can be applied to a spacecraft design at various stages, from concept studies to detailed design. A generic system level model should be able to be built with enough parameters and connections between subsystems and systems, including operations that can provide a mechanism to perform spacecraft design trades, and nearly immediately understand the ramifications to either the complexity of, or the duration of, the mission design and operations for deep space missions. In order for this concept to be effective, accurate estimates of mass, power, and cost, the typical drivers for spacecraft design, must be available in parametric form. Many of these are proprietary, making an absolute tool impossible, but the general guidelines available in literature will provide a proof of concept. A particular company or institution could then apply their proprietary models should they wish to utilize this process. 39 Hypothesis #2: With the increase in personal computing power, the complex parametric studies can be done rapidly, allowing a single user to evaluate ten thousand combinations in a workday. Being able to evaluate thousands of cases would allow an engineer to explore the trade space in great detail in order to understand the envelope of the system. Modern hardware and software have progressed to the point of solving complex systems of equation with ease – the amounts of memory and CPU cycles allow equation solvers to converge very rapidly to a solution. Summary The goal of this research project is explore the usage of MBSE, applied across the spacecraft as well as mission design, to determine if a single model implementation can be used to optimize the balance of requirements, instrument performance, and mission duration for deep space missions. There are many references to MBSE when developing a space mission, but most are later in the process, after the design trades have been made. By incorporating the mission design aspects, such as the imaging coverage, the overall spacecraft design may well be different if these aspects are not incorporated in the early trade studies. MBSE should facilitate the various model aspects in a way that meaningful trades can be made rapidly. 40 4 Methodology 4.1 Background The intent of this project is to define a new technique for accounting for mission scenarios in early design trades. The following sections will describe how the application of MBSE methodology could be implemented with particular a particular set of software tools. The basic concept is to be able to generate models that solve simultaneously to determine the cost driving parameters, such as mass, power, and data throughput. Ideally, it would include the ability to perform sensitivity analyses, contain objective functions to drive the solutions to a particular design point, such as minimum cost, mission duration, or mass, for example. 4.2 Initial Approach This project started by building a system level model in MagicDraw, a software tool implementing SysML, in a series of progressions to build up more detail. The parametric capabilities of MagicDraw are quite powerful employing 3 rd party a-causal solvers. However, one of the first challenges was being able to visualize imaging coverage on the surface of a body. Luckily, MatLab has many built in functions to help do this task, so an early effort was made to determine if MagicDraw could reliably call a function in MatLab and retrieve the results. A high-level system model that covers the entire mission system, from the launch vehicle to the mission operations, from the payload performance to the spacecraft mass roll up has been developed in MagicDraw. The top-level block diagram is shown in Figure 4.1. This model established the architecture of the model and allows each component to incorporate specific sizing models that can depend on other components of the model. For example, the mission 41 operations model will depend on the mission duration, which depends on the payload performance and the orbit design. Furthermore, this model architecture takes advantage of inheritance by utilizing a generic subsystem block which contains standard parameters, like mass, power, and data rate. See Figure 4.2. The subsystem block is also made up of some number of components, that each have their own mass, power, and data. The subsystem block also contains the parametric equations to sum up the mass, power and data for the components into a subsystem total. This construct proved to be very useful since the model progressed with different levels of detail for each subsystem, so the less detailed subsystem models did not use components and just contained a total, demonstrating the ability to have different levels of detail for different subsystems. The spacecraft is then made up of a collection of subsystems with names like ACS, CDH, etc with parametric equations to roll up the total mass, power and data requirements at the spacecraft level. 42 Figure 4.1 System Level Block Diagram With a high level model structure defined, detailed work of creating a payload model that computed the size of an optical payload and corresponding altitude in MagicDraw, then sending some parameters to MatLab to propagate the orbit and visualize the orbit coverage. The next section will layout in detail how that was developed. 43 Figure 4.2 Subsystem Block Diagram 4.3 Payload Size versus Orbit Modeling and Visualization The initial spacecraft development begins with defining the mission concept and characterizing the mission architecture. This includes things such as defining what type of observations are to be made, how much processing is on-board versus on the ground, and a basic mission operations concept. With these over arching architectures defined, at least initially, the spacecraft can begin to be sized. Here is the first circular reference in trying to define the spacecraft. If the orbital altitude is known, then the payload can be sized appropriately to meet the resolution requirements. However, if other constraints do not pre-define the altitude, then the 44 payload size can be traded against the altitude. The nature of the Earth orbital environment helps narrow down the altitude because going too low is impacted by atmospheric interactions, medium altitudes are impacted by the Van Allen belts, and the geostationary altitude is very specific. Non-Earth missions may not have such features that allow a broad trade of altitude and payload size. The help explain the thought process going into this development, a few highlights from the Firesat example in “Space Mission Design and Analysis” will be described and contrasted with deep space mission requirements.[17] For this example, the altitude was established first to be between 600 km and 800 km, using 700 km as a starting point. This was based on the Earth orbit factors, such as launch vehicle performance, radiation environment, resolution, and communications, which do not necessarily apply for extraterrestrial targets. Additionally, this mission did not require polar coverage, so it could have a non-polar orbit. Global coverage is usually a goal for exploring other planetary bodies, requiring a polar orbit. From the altitude (h), several orbital parameters must be determined to understand how to define the payload. These include the period (P), velocity (V g ) over the ground, and node shift (∆L) as follows: a = R b + h for circular orbit (4.1) P = 2π(a 3 /µ) 1/2 (4.2) V g = 2πR b /P (4.3) ∆L = P/P b • 360 deg (4.4) Next, the viewing geometry must be determined. The parameters of interest include the angular radius of the target body (ρ), the sensor look angle (η), maximum body central angle (BCA max ), elevation angle (ε) and the slant range (R s ). For this example the maximum Incidence Angle (IA) is pre-constrained as a performance specification. 45 ρ = sin -1 (R b /(R b + h)) (4.5) ε = 90° - IA (4.6) η = sin -1 (cos(ε) sin(ρ)) (4.7) BCA max = 90° - ε – η (4.8) R s = R b (sin(BCA max )/sin(η)) (4.9) With the geometry defined, the observing resolution comes into play to define the detector size and data rate, both of which influence the overall spacecraft size. Given a specific resolution (X) at nadir, the instantaneous field of view (IFOV), which is the equivalent of one pixel’s view of the target, can be determined. The number of pixels across (Z c ) is then related to the width of the target based on the sensor look angle. Depending on the instrument type, it could have a single row of pixels that image a cross track strip of surface fast enough to not leave a gap, or it could be a square detector that obtains a square image, then waits for a new portion of the surface to be in view to take the next image. This example will assume the latter case; therefore the equations are as follows: IFOV = X • 180 / (h • π) (4.10) Z c = 2η/IFOV (4.11) N p = (Z c ) 2 for a square detector (4.12) From the number of pixels, and a given bit depth (B), or bits per pixel, the data rate is DR = N p • B (bits per image) (4.13) This data rate will be utilized with the imaging cadence to establish the data volume on a per orbit basis. Finally, the sensor optics can be defined, more specifically, the aperture diameter. This will be used as a reference size to be used for comparison to other instruments, enabling the engineer 46 to estimate key characteristics, such as volume, mass, and power. Three parameters must be chosen that will affect the focal length (f) and diffraction-limited aperture diameter (D). The first is the width of a square detector (d), typically 30 µm. The quality factor for imaging (Q), which can range from 0.5 to 2, with a value of 1.1 providing good image quality, is next. Finally, the wavelength that the sensor is being designed to be sampling, λ, is determined. The following two equations define the focal length (f) and aperture diameter (D): f = h•d/X (4.14) D = 2.44 λ • f • Q/d (4.15) Reviewing the equations above shows that for a given resolution and design parameters, the key size characteristic of the sensor, aperture (D), is proportional to the altitude. Additionally, the altitude directly impacts the sensor footprint on the surface, and thus the imaging cadence, which will define the data rate from the instrument. This data rate will influence other factors on the spacecraft, such as data storage and downlink capabilities. To compare the design with other instruments, the aperture ratio (R) is defined to be the ratio of this aperture to a similar, or reference, instrument. Then this is used to scale other parameters, such as mass and power as follows: M = KR 3 M ref (4.16) P p = KR 3 P ref (4.17) The parameter K is used to double the scaling when scaling down by more than a factor of 2, therefore K = 2 when R < 0.5 and K = 1 for all other cases. [17] From here the rest of the spacecraft can begin to be sized to accommodate the payload. However, there is a trade to be made between the sensor, orbital altitude, and mission duration. 47 For an instrument that takes discrete images or samples, the size of the image on the surface dictates the imaging cadence so that there is minimal overlap along the ground track as follows: Sample period = X * N c / V g (4.18) While this provides some measure of surface coverage for a single orbit, it does not account for the ground track overlap orbit to orbit so an orbit propagation model is required to determine how much of the surface is actually covered and how many orbits are required to achieve that coverage. Appendix A contains a Matlab script that uses some simplifying assumptions, such as a nearly circular polar orbit, to map sensor foot prints at a sample period on a body and returns the number of orbits required to achieve a given percentage coverage. The significant concept in this script is to compute the spacecraft’s location at each sample period, and then compute the latitude and longitude of the sub-satellite point at that time. The sensor angular field of view on the surface, or foot print (FP), defined as: FP = tan -1 ((h/R b ) • tan(instrument FOV/2)) • 2 (4.19) The Matlab small circle and geoquad functions are then used to define areas on the surface that have been imaged. At the end of each orbit, the surface is evaluated to determine the percent area that has been imaged at least once. It should be noted that it is important to ensure that a location is only counted once to compute total area covered. The script also determines how many times a particular location has been imaged. For example, the polar regions are typically over imaged while there may be gaps at the equator. Figure 4.3 shows a coverage map indicating the number of times a portion of the surface is imaged. 48 Figure 4.3 Example Coverage Map Figure 4.4 shows each image footprint on the surface of the body. Figure 4.4 Example Image Location The different colors represent different orbits, but in this case the colors have been reused since there were more than 30 orbits in this example. Figure 4.5 shows how the data acquisition is distributed over the orbits to achieve 80% coverage. 49 Figure 4.5 Example Coverage Per Orbit This shows that the first five to ten orbits cover more unique surface per orbit, ranging from about 5% to almost 8% new area covered, but then it falls to below 2% for the later orbits. This last plot also shows that 50% of the surface is covered in about 15 orbits, or half of the time it took to achieve 80%. This information, along with mission operations costs can be use to trade off the cost of getting to 80% coverage. At the time of this integration, the ParaMagic Plugin, which handles the Matlab interface, could only call Matlab functions that returned a single variable. Since the primary objective of the Matlab code was to return the number of orbits required to cover the surface, returning only one variable wasn’t a significant limitation. However, it didn’t allow any ancillary information to be fed back into the MagicDraw model. For example, some orbits resulted in significant overlap of imaging so it would be useful to understand that behavior to trade off different altitudes. As a result, the Matlab script would save plots of the coverage, as those shown previously, to be available later. 50 4.4 Adding Model Details With the visualization and interface with MatLab details worked out, it was time to add more subsystem details. This effort primarily focused on those details that affect the overall spacecraft size and mass. Following the sizing described in [17] and [20], the model structure was augmented to determine the solar array size which is a primary contributor to overall size and inertia of the spacecraft. It was decided to have a pair of single axis gimbaled arrays to maximize symmetry and simplify the assumptions. Attempting to have an arbitrary configuration would be possible by adding many more parameters that could be selected to define the configuration. Adding in the solar array sizing model really demonstrated the interconnections between subsystems and the spacecraft level model. The required size of the array is based on the overall spacecraft power load, but the specific performance of the array is based on the design of the array, which should really be a part of the power subsystem. When developing this model, several iterations were attempted with parameters distributed between the power subsystem, payload subsystem, and spacecraft level models. Figure 4.6 shows the parametric diagram capturing the final version, with the array sizing being captured at the spacecraft level. Note that the solar distance is taken from the payload subsystem since that subsystem has the target body data contained within it. All of the other parameters are at the spacecraft level, as is the diagram, so there aren’t any nested boxes. The next significant sizing effort focused on the reaction wheel assembly (RWA) and desaturation propellant sizing. In order perform these calculations, the spacecraft inertias, as well as RWA and reaction control system (RCS) performance parameters, are required. Figure 4.7 displays these relationships. This diagram shows more detailed nesting in the payload subsystem, 51 showing the number of orbits coming from the Coverage block and the altitude coming from the Orbital Parameters block. Figure 4.6 Solar Array Sizing Parametric Diagram The methodology at this point was to add some capability to the model and then attempt to run the ParaMagic solver compute the overall spacecraft mass and cost, as well as the system mass and cost. Additionally, a method to solve for a minimum cost or mass solution was not evident, so the ParaMagic case study capability was used. This plug-in to MagicDraw allows the user to build a spreadsheet of values to input into the model, typically a row of values for each instance to compute, then use that spreadsheet to batch run multiple cases and gather the outputs into an output spreadsheet. As different model elements were added or changed, a single run of 52 the system was attempted. Many times, this run had difficulty solving the equations, the system was either over or under constrained, or some parameters were not even computed. Figure 4.7 Gravity Gradient Torque Calculations The ParaMagic plug-in relies on parameters being given a ‘causality’ of ‘given,’ ‘target,’ or ‘ancillary.’ These values tell the solver to treat a ‘given’ as a constant input and to solve for ‘target’ value. The ‘ancillary’ value tells the solver to only solve for that value if it needs it in another computation. Another aspect of the solver functionality is that the user creates an instance of the model, which the solver processes. The causality states were not being transferred 53 consistently to the instance, so it became very tedious to manually reset the causalities as instances were being created. Some instances were successfully solved, and the case study capability was verified. Unfortunately, another issue arose around this same time with the version of MagicDraw that was being utilized. The system would crash if the ParaMagic plug-in window was opened twice in a row. This obviously made progress maddeningly slow, to point of being unfeasible. Now, between getting partial solutions, crashes every other run, and the overhead associated with the graphical model in MagicDraw, the implementation came into question. After continued attempts to restructure the model to achieve consistent results, it was becoming apparent that for this application the graphical model was not going to work out. After thoughtful determination, there were many benefits of a MagicDraw model that were not applicable to a solution that focused on a numerical solution. Additionally, a MagicDraw model came with a significant amount of overhead in developing numerical parametric model elements that were very time consuming to develop, test, troubleshoot, and update. Many of the latest MBSE applications modeling a specific design take advantage of the broad modeling capabilities from structure diagrams, to interfaces, to documentation, demonstrating a clear utility and indicating the first direction to take in this investigation. 4.5 Finding a New Modeling Environment Given the trouble with MagicDraw, a different environment needed to be found. Several options were investigated before settling on a solution. Since the ParaMagic plug-in in MagicDraw already called upon Mathematica as it's a-causal solver, it was evaluated briefly. At that point, it seemed like a possible fit, however, the learning curve was daunting with an entire new language and software environment to learn. Additionally, many of the tutorials and 54 examples that were reviewed showed it to be a powerful mathematical solver, but described little of any underlying structure to help with object oriented modeling. Without spending too much time to learn more, another option was investigated. Modelica is an open source modeling language that has been developed with an accompanying standard. Not only is it a language, but it is a modeling language designed to model physical, electrical, thermal, or fluid, systems, to name a few. Additionally, a fundamental construct of the language supports reuse to avoid duplication of models and effort. These attributes made it look promising. After downloading OpenModelica, which is an open source Modelica environment, several tutorials were studied to determine if this could help answer the question of being able to create a system level model. Further investigation showed that the system works by the user creating a model in a graphical environment or a text based environment, then ‘simulating’ the model, and plotting the results. The simulation consists of the environment compiling the models into C- language computer code and executing them. This compiled code incorporates numerical solvers to solve a system of equations, even if the equations are derivatives. So far so good – Modelica may be the solution. The next challenge for Modelica would be to incorporate the Matlab coverage model. That model took great advantage of built in functions in Matlab that would take too much time to port into Modelica, so a connection between Modelica and Matlab needed to be found. Luckily, both Modelica and Matlab had some built in features to assist in this area. Before the full model was ported from MagicDraw, a test case was built to see if Modelica could at least call Matlab and retrieve results. Matlab includes what is called the Matlab Engine API that allows program written in C to call a Matlab function. Also, Modelica includes a construct that allows it to 55 include an external function when compiling models for simulation. The solution was to build a piece of C-code that would call the Matlab function and return the results, then compile that into a library in the Modelica path so that when Modelica compiles, it includes this in the executable. Low and behold, Modelica could call a Matlab function. Finally, the system would need to be able to explore the parameter space in some fashion. OpenModelica consists of several parts – OMEdit, OMNotebook, and OMShell. The initial testing was conducted with OMEdit which is a graphical environment to edit models, in graphic or text form, simulate them, and plot the results. OMNotebook was not utilized. OMShell is a command line version allowing the user to input commands to load models, simulate them, and perform system calls. Rather than encoding a parameter search into the model environment, the OMShell tool was studied to determine if a system could be developed to batch process sets of parameters. This tool provides a mechanism to run a script in the Modelica language, with commands like ‘load model’ and ‘simulate.’ Another capability is the ability to define a model on the tool’s command line. These capabilities provided enough confidence to proceed with digging further. 4.6 OpenModelica At this point, a system model was built up in OpenModelica, again making use of object- oriented techniques with an eye towards batch processing various combinations of parameters. Modelica utilizes a package structure to control inheritance and the name space, with the idea being that a package can contain several class elements that can be imported into another model. Modelica also supports stand-alone class definitions, however it became apparent that it would be slightly more straightforward to package similar model components together. The package structure is shown in Figure 4.8. 56 Figure 4.8 Modelica System Model Package Structure In the figure, the top row of four boxes each have a single file associated with them that contain everything shown below them in the figure. The four files are the planetary body record, the mission design package, the spacecraft package and the system package. The latter three all contain various class definitions that contain parameters, variables, and equations to model the portion of the system represented by that class. This implementation results in a system of 198 equations and variables, when combined with a subset of the parameters being studied, has 267 output values per instance, which will be discussed later. The actual code can be found in the appendix, section 8.1 Modelica Models. System Model Planetary Body Record Mission Design Pkg Orbit class Transfer Orbit Class Spacecraft Pkg Generic Subsystem Class SpeciYic Subsystem Classes Spacecraft Class System Pkg Ground System Class Mission Operations Class Launch Vehicle Class Complete System Class 57 4.6.1 Parameters and Variables In Modelica, there are constants, parameters, and variables. The distinction becomes important when it comes to the compilation of the system into code and the time based simulation. Constants, by definition, are constant and can never change. Parameters are allowed to change but only at the start of the simulation. This means that a parameter value may be set by an initial condition, but then is held constant for the simulation. Finally, variables are what they sound like – variables. Obviously, these can, and will change, based on the computations. Furthermore, the Modelica compiler treats each variable as an unknown in the system of equations, so there must be an equation for each variable in order for the compiler to create a solution. There is also a construct to seed an initial value for a variable as a starting point for the solver. This was used for a few variables because the solver was having trouble converging without the start value. In this case, simulation refers to solving the system of equations and running a time based simulation for some duration. This functionality derived from Modelica’s ability to solve dynamic systems that have time based derivatives in their equations. Since this system is not modeling dynamics, the simulations run for one-second duration and one iteration. The next few sections will describe each of the packages’ contents and provide a list of the parameters that are available to study and the primary output variables for each class. 4.6.2 Planetary Body Record The planetary body record is a data structure that contains the relevant physical characteristics of the body to be studied. These parameters are: name, radius, spin period, solar distance, and GM (body mass times Newtonian constant of gravitation) as shown in Table 4.1. By defining this data record in a separate file, the model can be applied to a new target just by loading a different planetary body constants file. 58 Table 4.1 - Planetary Body Record Parameter Name Description Units name Name of the body N/A radius Radius of the body m spinPeriodBody Spin period of the body Seconds solarDistance Maximum distance from the sun AU gmBody GM of the body m 3 /s 2 4.6.3 Mission Design Package The mission design package contains two classes that deal with the parameters to define an orbit at the target body and the transfer from earth to the body. The orbital parameters class contains variables, and the equations to determine the value of the variables, like the orbit period, radius, altitude, ground footprint, and approximated number of orbits to cover the surface. These are annotated in Table 4.2. The approximate number of orbits to cover the surface is 360° of longitude divided by the ground footprint. This implies that an orbit can be found that will have adjacent ground tracks separated by one field of view. The transfer orbit class has a parameter that allows the model to be configured to use parameter inputs for the transfer, to compute a simple Hohmann transfer, or input parameters for an electric propulsion (EP) transfer. In the first case, the parameters that can be input are the delta-V requirement at the body and the duration of the transfer. In the second option, those parameters are computed assuming that the launch vehicle propels the spacecraft on a Hohmann transfer. Finally, the EP option sets the delta-V requirement to zero (so that the propulsion model does not account for it in the fuel load) and has a parameter input for the duration. Each option also specifies an estimated number of navigation engineers for each option in cruise and in encounter. Th number of navigation engineers changes because an electric propulsion mission requires more analysis and maneuver designs since the thruster is usually firing for most of the 59 cruise phase. The transfer type is also transferred to other subsystem classes to make adjustments in those models. The parameters and variables are listed in Table 4.3. Table 4.2 Orbital Parameters Class Variables Variable Name Description Units altitude Altitude of the spacecraft above the surface m radius Radius of the spacecraft orbit m period Orbit period s groundFootPrint Size of the ground footprint of the imager deg N 360° longitude/ground footprint to get number of orbits to cover surface approximation N/A Table 4.3 Transfer Orbit Class Parameters and Variables Parameter Name Description Units Type transferType Flag to indicate type of transfer (1 = compute dV and duration, 2 = input dV and duration, 3 = EP mission, input duration N/A Parameter dV2Input Delta-V required at the body to get into orbit as an input parameter km/s Parameter durationFixed Duration of the transfer orbit Months Parameter dV2 Delta-V required at the body to get into orbit based on computation km/s Variable duration Duration of transfer orbit based on computation Months Variable cruiseFTE Staffing level for navigation based on transfer type FTE Variable encounterFTE Staffing level for navigation based on transfer type FTE Variable 4.6.4 Spacecraft Package The spacecraft package is the largest package. It contains a generic subsystem class that holds the standard variables that all subsystems must possess: mass, power, data rate, operations staffing levels, and cost. Then, for each engineering subsystem (Attitude Control (ACS), 60 Command and Data Handling (CDH), Flight Software (FSW), Power (PWR), Propulsion (PROP), Telecom (TEL), and Thermal (THERM)), there are class definitions that extend the generic subsystem classes. This implementation ensures that each subsystem contains the minimum set of variables to size and cost the spacecraft. There is also a generic payload subsystem class, allowing for different payload types, with a detailed model of an optical payload further extending the generic payload class. The optical payload class definition imports the orbital parameters class in the mission design package in order to get access to the orbital altitude variable. This linkage allows the altitude to be computed based on the payload parameters, but then keep the other details of the orbit in the orbital parameters class. Finally, the spacecraft package contains a spacecraft class which declares instances of each subsystem and payload, as well as the equations to sum the mass, power, data rate, and cost of the spacecraft subsystems. This class also creates equations between variables within different subsystem classes as well as between spacecraft level variables and subsystems. Each of the classes will be explained in more detail below. Note that the cost models for the subsystems and spacecraft, with the exception of the payload, use the Unmanned Space Vehicle Cost Model version 8 (USCM-8). The payload utilizes the NASA Instrument Cost Model (NICM). The equations of each subsystem, the payload, and the spacecraft were derived with an eye toward the overall spacecraft sizing. The development process was done in incremental iterations, with the first iteration just being the generic sum of the parts. Then, for each subsystem, the following questions were considered: 1. What aspects of this subsystem impact the overall spacecraft size and cost? 2. What aspects of this subsystem depend on other subsystem variables? 3. What aspects of this subsystem affect mission operations complexity? 61 The next few sections will describe the key aspects of each subsystem and interactions between them and the spacecraft. A generic concept that should be noted is that the Modelica environment incorporates solvers behind the scenes that allow what would be iterative solutions to converge on a solution. For example, the power subsystem’s power consumption can be thought of as a percentage of the overall load since there are power conversion losses. Modelica allows the power load for the power subsystem to be equal to the total system load times a percentage, with the total system load being the sum of the subsystem loads. Without a solver, an engineer would try a number, plug it in and see how close it is. Then try a new number and iterate until it is close enough. The Modelica solvers do all of this behind the scenes. Note that Table 4.4 shows the variables contained in the generic subsystem class which all of the specific subsystem classes inherit. Table 4.4 Generic Subsystem Class Variables Name Description Units Type mass Mass of the subsystem kg Variable power Power draw of the subsystem W Variable dataRate Data production rate of the subsystem bps Variable cruiseFTE Staffing level in cruise for operation of the subsystem FTE Variable encounterFTE Staffing level in encounter for operation of the subsystem FTE Variable cost Cost of the subsystem $FY10 Variable Attitude Control (ACS) It was decided to create a generic ACS model that contains standard hardware consisting of two star trackers, an inertial measurement unit, and reaction wheels (RWAs). This choice was based on the fact that for typical deep space missions visiting planetary or small bodies will have similar pointing knowledge and control requirements. The ACS system also assumes that there is 62 a reaction control system (RCS), modeled as the PROP class, to unload momentum from the reaction wheels. Therefore, the primary mass driver would be the size of the reaction wheels. This model computes the required size based on the gravity gradient torque while in orbit and a parameter of how many orbits to store the momentum prior to unloading the momentum from the RWAs. Already the ACS model will need several pieces of information – total spacecraft inertias, the orbit radius and GM of the body, an approximation of the lever arm of the RCS jets, and the I sp of the RCS jets. The class also needs to know if the HGA is gimbaled or not because that affects the spacecraft attitude at the body, which affects the gravity gradient. With connections between the ACS class variables and the other subsystem variables or spacecraft variables in the spacecraft class, all of the ACS equations reside in the ACS class. This is a powerful construct to allow a class to be owned by a subsystem expert engineer but still be part of a larger system model. Since reaction wheels aren’t supplied in a continuum of capabilities, a look up logic branch was established based on Honeywell RWA specification sheets to determine the RWA mass based on capability. This class also computes the fuel required for RWA desaturations at encounter. The fuel usage for cruise is determined by a fuel rate parameter. The reason for this choice is that it is expected that the spacecraft be operated in a minimum disturbance torque attitude/configuration, which makes attempting to model the desaturations in detail fairly arbitrary. The other significant aspect to the ACS model is the transfer orbit type. Since an electric propulsion architecture requires the spacecraft to be firing the EP thruster in a particular direction most of the time, the cruise phase staffing will need to be augmented. The parameters and variables for the ACS subsystem, as well as their units, can be found in Table 4.5. 63 Table 4.5 ACS Subsystem Class Parameters and Variables Name Description Units Type numOrbitsToStoreGG Number of orbits to store gravity gradient (GG) torque to size the RWAs N/A Parameter desatThreshold Percentage of RWA capacity at which to desaturate the RWAs % Parameter offNadirAngleFixedHGA Average off nadir angle to use in GG torque computation for a fixed HGA configuration rad Parameter offNadirAngleGimbaledHGA Average off nadir angle to use in GG torque computation for a gimbaled HGA configuration rad Parameter fuelRateDuringTransfer Fuel burn rate during transfer – since no GG torque, need some value to assume, but will depend on cruise configuration kg/month Parameter starTrackerMass Mass of star tracker, defaults to Sodern SED26 kg Parameter imuMass Mass of Inertial Measurement Unit (IMU), defaults to Honeywell MIMU kg Parameter rwaPower Power for single RWA, default based on Honeywell W Parameter starTrackerPower Power for star tracker, defaults to Sodern SED26 W Parameter imuPower Power for IMU, defaults to Honeywell MIMU W Parameter cruiseFTEdefault Default number of engineers to staff ACS subsystem FTE Parameter encounterFTEdefault Default number of engineers to staff ACS subsystem FTE Parameter cruiseFTEEPAdditional Addition engineers for EP mission FTE Parameter rwaMomCap Capacity of the RWAs Nms Variable rwaMass Mass of the RWAs, based on capacity, modeled after Honeywell Constellation Series RWAs kg Variable gravGradTorque Gravity gradient torque, assumes symmetric spacecraft configuration and uses off nadir angle to compute Nm Variable gravGradMomPerOrbit Momentum build up from gravity gradient per orbit Nms Variable 64 Name Description Units Type burnTimePerDesat Thruster burn time to desaturate the RWAs s Variable fuelMassDesats Mass of fuel to desaturate the RWAs during encounter kg Variable Command and Data Handling (CDH) and Flight Software (FSW) While the CDH subsystem is a critical part of the spacecraft, it has the least complicated model. The CDH components are fairly typical without a significant driver to cause them to deviate much from a generic set. For example, things like uplink decoding and telemetry processing are not significantly challenging tasks to complete unless there was some new technology driving a significantly higher amount of memory or throughput. The only new parameters for the CDH model are the default staffing levels, as shown in Table 4.6. FSW is in the same category where the FSW size and cost are not particularly sensitive to the overall size of the spacecraft. Again, unless there was a driver to undertake some new capability in FSW, like increased autonomy, the FSW cost shouldn’t change too much. Table 4.7 shows the default staffing parameter, along with a lines of code parameter an which to base the cost. Another aspect of FSW costing is that most institutions can reuse FSW from mission to mission, so the cost breakdown depends heavily on the amount of reuse, which can’t be modeled in this generic case. Table 4.6 CDH Subsystem Class Parameters Name Description Units Type cruiseFTEdefault Staffing level in cruise for operation of the subsystem FTE Parameter encounterFTEdefault Staffing level in encounter for operation of the subsystem FTE Parameter 65 Table 4.7 FSW Subsystem Class Parameters Name Description Units Type cruiseFTEdefault Staffing level in cruise for operation of the subsystem FTE Parameter encounterFTEdefault Staffing level in encounter for operation of the subsystem FTE Parameter SLOC Source lines of code N/A Parameter Power (PWR) The power subsystem is another subsystem that depends on, or will affect variables, at the spacecraft level. This implementation assumes a solar array, but a simple replacement of this subsystem class with another architecture should be straightforward. The obvious interaction is that the power subsystem needs the total spacecraft load, plus the PWR load and battery charge load in order to compute the overall solar array requirements. These also depend on the overall mission duration and maximum solar range to account for in flight degradation and performance at the target body. The solar array dimensions, mass, and dimensions are computed based on selection of good, better, or best solar cell performance, which is selected as a parameter in the model. The other big part of the power subsystem is the battery, which is dependent on the orbit geometry for possible eclipses and the system load. Therefore, the power system mass (solar array, battery, and electronics) and solar array inertias are computed in the power class and passed to the spacecraft class. One of the possible parameters to adjust is the solar array cell selection. While there are a variety of cells available, three representative cells and their performance were chosen. Those are choices are silicon, gallium arsenide, and multi-junction gallium arsenide. The silicon cells are the least expensive but are the least efficient. The multi- junction gallium arsenide cells are the most efficient but cost 60% more than silicon cells. The user selects between option 1, 2, or 3 and the parameters are populated for each cell type. Since 66 the cell type affects the cost of the array, the overall power subsystem cost model computes the cost based on the subsystem mass without the array, then the array cost is added based on the cell type. This allows a trade between more expensive and more efficient cells and less expensive and less efficient cells. The PWR subsystem variables and parameters can be found in Table 4.8. Table 4.8 PWR Subsystem Class Parameters and Variables Name Description Units Type cruiseFTEdefault Staffing level in cruise for operation of the subsystem FTE Parameter encounterFTEdefault Staffing level in encounter for operation of the subsystem FTE Parameter cruiseFTEEPAdditional Additional staffing for EP mission FTE Parameter solarCellType Flag to indicate cell type: 1 = silicon, 2 = GaAs, 3 = multi-junction GaAs N/A Parameter chargeEff Charge efficiency % Parameter dischargeEff Discharge efficiency % Parameter eclipseFraction Fraction of orbit in eclipse N/A Parameter eclipseDuration Duration of eclipse, default 1 hour hr Parameter batteryVoltage Battery voltage design point V Parameter batteryDODLimit Battery depth of discharge limit % Parameter batteryEnergyDensity Energy per unit mass W-hr/kg Parameter solarArrayArea Area of solar array m 2 Variable solarArrayMass Mass of solar array kg Variable solarArrayAreaOffset Location of center of solar array area to compute inertia m Variable solarArrayInertiaAboutAxis Solar Array Inertia kg-m 2 Variable solarArrayInertiaPerpAxis Solar Array Inertia kg-m 2 Variable solarArrayInertiaPerpFace Solar Array Inertia kg-m 2 Variable solarArrayPowerReqBOL Solar array required power at BOL W Variable solarArrayPowerReqEOL Solar array required power at EOL W Variable solarArrayPerf1AUBOL Solar array performance at 1AU and BOL W Variable batteryCapacity Battery capacity W-hr Variable batteryMass Battery mass kg Variable solarArrayCost Cost of solar array $FY10 Variable solarArrayWattPerArea Solar array power per unit area at 1 AU, based on cell type W/m 2 Variable solarArrayMassPerArea Solar array mass per unit area, based on cell type kg/m 2 Variable 67 Name Description Units Type solarCellDegradation Percent degradation per year, based on cell type %/yr Variable solarArrayCostPerWatt Solar array cost per Watt, based on cell type $FY10/W Variable Propulsion (PROP) The propulsion subsystem class models the subsystem hardware, which consists of thrusters (a selectable parameter), fuel tanks, pressurant tanks for non-blow down systems, and the fuel. This class is called PROP, instead of RCS, is because it models propellant loading for maneuvers, and not just momentum unloading. The thruster force and specific impulse are parameterized allowing for different sizing options. There is also a parameter to select between a blow down and non-blow down system that affects the total tank mass in the calculations. The fuel for RWA desaturations is computed in the ACS class and passed to the PROP class. The fuel load to include for a maneuver to get into orbit at the body for a chemical transfer orbit is determined by getting the delta-V requirement from the transfer orbit class and applying the rocket equation to compute a mass fraction. This is another area where the simultaneous equation solving eliminates the need to iterate to a solution. For an EP mission, the delta-V requirement is set to zero and several EP relevant parameters are set to non-zero values. These parameters are EP propellant mass, EP power required at the target, and staffing to support EP. Since EP mission design requires modeling the thrust throughout the mission, it is beyond the scope of this work. Two of the significant drivers for EP missions are the propellant mass and the power requirements. For targets further from the sun than Earth, accepting a lower power available at the target is sufficient since the solar arrays will produces significantly more power at the start of the mission at 1 AU. For example, an array that produces 1 kW at 3 AU will produce 9 kW at 1 AU, to first order. This excess power would be available to the EP system. For context, this was 68 the approach on the Dawn mission, with an array performance around 10.4 kW at 1 AU and only 1.2 kW at 3 AU. However, the EP system could only process a maximum of 3 kW resulting in a significant excess of power early in the mission. These parameters and variables can be seen in Table 4.9. Table 4.9 PROP Subsystem Class Parameters and Variables Name Description Units Type cruiseFTEdefault Staffing level in cruise for operation of the subsystem FTE Parameter encounterFTEdefault Staffing level in encounter for operation of the subsystem FTE Parameter EPFTEAdditional Additional engineers for EP mission FTE Parameter thrusterForce Force of each thruster N Parameter Isp Specific impulse s Parameter thrusterMass Mass per thruster kg Parameter thrusterNumber Number of thrusters, assume 2 redundant branches N/A Parameter blowdownSystem Flag to indicate blow down system or system with external pressurant tanks N/A Parameter epPropellantMassDefault Mass of propellant for EP mission kg Parameter epHWMassDefault Mass of EP system kg Parameter epPwrAtTargetDefault Power that should be available to the EP system at the target. W Parameter epPwrHKDefault House keeping power for the EP system W Parameter costEP Cost of EP system – with so few deep space missions using EP, there weren’t models available $FY10 Parameter fuelMass Mass of chemical fuel (desats and deltaV) kg Variable wetMass Mass of fuel and pressurant kg Variable hwMass Mass of prop subsystem kg Variable fuelVol Volume of fuel (based on mass) cm 3 Variable pressurantMass Mass of pressurant kg Variable pressurantVol Volume of pressurant cm 3 Variable totalTankVol Total tank volume liters Variable totalTankMass Mass of tanks kg Variable massFraction Mass fraction of propellant used for orbit injection N/A Variable M0 S/C mass prior to injection kg Variable 69 Name Description Units Type fuelMassManeuver Mass of fuel for injection, based on delta-V requirements kg Variable Telecommunications (TEL) The telecommunications subsystem class models the radio link between the spacecraft and earth. To achieve this goal, the model has three key aspects. First, there’s a parameter to select between a gimbaled high gain antenna (HGA) and a body fixed HGA. For a body fixed HGA, the model doubles the total required spacecraft downlink rate, which is summed at the spacecraft level from the engineering subsystem rates and imaging data production rate. For a gimbaled HGA, the model just uses the total downlink rate as the required downlink rate. It also adds gimbal mass to the antenna. Then, the model computes the HGA diameter based on link performance parameters, including frequency with increased atmospheric losses for Ka band. If this diameter is larger than a parameterized maximum diameter (to ensure the HGA will fit in the fairing), the model computes the achievable data rate with the maximum size HGA. This value is used to increase the encounter duration by the ratio of the desired downlink rate to the achievable downlink rate since it will take longer to send back the same amount of data. Finally, the operations staffing is also adjusted based on the selection of gimbaled or fixed HGA. The full listing of parameters and variables can be found in Table 4.10. Table 4.10 TEL Subsystem Class Parameters and Variables Name Description Units Type cruiseFTEdefault Staffing level in cruise for operation of the subsystem FTE Parameter encounterFTEdefault Staffing level in encounter for operation of the subsystem FTE Parameter fixedHGAStaffingFactor Factor to multiply staffing level for a fixed HGA (because more analysis is required for non-HGA antenna use) N/A Parameter 70 Name Description Units Type transmitterPower RF power output of transmitter W Parameter frequencyDL Downlink frequency (to distinguish between Ka and X band) GHz Parameter antDiaDSN Antenna diameter of Deep Space Network (DSN) m Parameter antEff Antenna efficiency for ground and spacecraft antenna % Parameter SNT System Noise Temperature K Parameter EbNoThreshold E b /N 0 Threshold for link margin dB Parameter fixedHGA Flag to indicate fixed or gimbaled HGA N/A Parameter HGAGimbalMass Mass to assume for gimbal mechanism (only used for gimbaled configuration) kg Parameter maxAntDiaSC Maximum antenna diameter on the spacecraft m Parameter atmLoss Atmospheric loss (based on frequency) dB Variable gainDSNDL Gain of DSN antenna based on DL frequency dBi Variable antDiaSC Diameter of spacecraft HGA m Variable gainSCDL Gain of spacecraft antenna based on DL frequency dBi Variable scTotalDataRate Total downlink data rate for the spacecraft bps Variable geoCentricDistance Distance from earth to target body (worst case solar conjunction = solarDistance + 1 AU) AU Variable spaceLoss Signal losses in space dB Variable powerReceivedDL Power received at the DSN dB Variable SNRDL Signal to noise ratio on the downlink dB Variable downlinkRate Downlink rate based on max spacecraft antenna diameter bps Variable desiredDownlinkRate Downlink rate based on total spacecraft data rate bps Variable desiredAntDiaSC Diameter of desired HGA antenna (not limited) m Variable desiredAntGainSCDL Gain of spacecraft antenna based on desired size (not limited) dB Variable desiredPowerReceivedDL Power received at DSN based on desired size (not limited) dB Variable desiredSNRDL Signal to noise ratio based on the desired antenna size (not limited) dB Variable 71 Thermal (THERM) The thermal subsystem class is another very simple model. The thermal subsystem is usually very configuration dependent and has components embedded throughout the spacecraft. For example, multi-layer insulation (MLI) will cover most of the spacecraft’s exposed surfaces, while the powered components, like computers and other electronics, will be mounted to panels that can dissipate the heat into space. Furthermore, any specific heat sources, like the traveling wave tube amplifier (TWTA) in the telecommunications subsystem is a localized heat source that will receive special consideration and installation to dissipate the heat. Therefore, the thermal mass and power are determined to be a fraction of the total spacecraft mass to roughly size the system. The definitions of parameters can be seen in Table 4.11. Table 4.11 THERM Subsystem Class Parameters and Variables Name Description Units Type cruiseFTEdefault Staffing level in cruise for operation of the subsystem FTE Parameter encounterFTEdefault Staffing level in encounter for operation of the subsystem FTE Parameter heaterLoadToMassRatio Ratio of the total heater load to the mass of the spacecraft W/kg Parameter thermalMassToSCRatio Ratio of thermal subsystem mass to the total spacecraft mass N/A Parameter Payload and Optical Payload (PAY) The payload subsystem is the big driver for the spacecraft sizing. Since the optical payload class computes the required altitude based on resolution requirements, only one optical payload may be present in the spacecraft model. There may be other payloads that would contribute to mass, power, data rates, and cost, but these would be of the generic payload class. The optical payload class has parameters for an imager configuration: field of view, number of pixels, 72 resolution requirement, amongst others. These three specific items are used to compute the required altitude, which is linked to the orbital parameters class where other values, like orbital period are computed. The image footprint size on the surface is computed to help determine the sample period to collect adjoining images. The sample period determines how many images are taken per orbit. This translates into the science data rate from the instrument by multiplying the number of images per orbit times the memory size of each image and dividing by the orbit period. The data per orbit is also divided in two since the images are only taken on the lit side. The instrument size is also estimated by computing the required aperture size and a ratio of the aperture to the aperture of a similar payload. This ratio is then used to scale the mass and power of the similar payload to estimate the mass and power of this payload. The NASA Instrument Cost Model (NICM) was used to compute the cost based on this mass, power, and a design life parameter. This class also contains the construct to call the external Matlab interface code. The original implementation always called Matlab to execute the script to compute the number of orbits required to cover the surface as described in section 4.3. Since that code typically takes minutes to tens of minutes to execute, it became apparent that that would take far too long to run multiple cases. Therefore, the interface code was updated to record the input parameters to the script and the resulting number of orbits in a file. When it is run again, the code looks for the same input parameters in the file and, if found, pulls the number of orbits from the file without running the Matlab script. Since many combinations of parameters result in the same altitude, this implementation saved a lot of computation time. However, the ground track performance was inconsistent based solely on altitude. Since the propagation is a pure point mass gravity model, without J2 precession and a fixed inclination of 90°, picking an altitude purely based on 73 resolution results in a ground track that may or may not result in even coverage. For the cases where the ground track repeated over a small set of longitudes, the script would propagate for 100s or 1000s of orbits, taking hours of computation time. Figure 4.9 shows an example of good ground track with relatively even spacing while Figure 4.10 shows a poor ground track. Figure 4.9 Example of good ground track Figure 4.10 Example of a bad ground track Many hours were devoted to determining an algorithm to always return a decent ground track to no avail. However, a reasonable approximation was found by dividing 360° by the ground footprint of the instrument field of view. This implies that the entire surface would be imaged in 74 that number of orbits. This result was compared the Matlab results where the ground track didn’t result in too much overlap of adjacent ground tracks. This comparison showed the each technique produced similar results. The orbit would need to be designed with the real J2 and inclination to have a similar altitude, but be able to achieve a similar ground track. This type of analysis is beyond the scope of this work, but could be an area to focus on in the future. A parameter was added to allow selection of propagating the orbit or using the approximation so that both options are still available. The full list of parameters and variables can be found in Table 4.12. Table 4.12 Optical Payload Subsystem Class Parameters and Variables Name Description Units Type cruiseFTEdefault Staffing level in cruise for operation of the subsystem FTE Parameter encounterFTEdefault Staffing level in encounter for operation of the subsystem FTE Parameter number OfPixelsX Number of pixels in X direction (assumes square detector) N/A Parameter bitsPerPixel Bit depth per pixel N/A Parameter fovX Optical field of view in X direction (equations assume square field) deg Parameter detectorSizePerPixel Size of the pixels in the detector m Parameter qualityFactor qualityFactor (0.5 – 2, 1.1 is good quality, larger number results in larger aperture for same wavelength) N/A Parameter waveLength Wavelength of interest m Parameter massSimilarPayload Mass of a similar payload to scale kg Parameter powerSimilarPayload Power of a similar payload to scale W Parameter apertureSimilarPayload Aperture of a similar payload to scale m Parameter designLife Design life of payload – factors into cost equation months Parameter globalRepeatFactor Number of times surface must be covered completely N/A Parameter imagesPerStation Number of images to take at each station to account for color filter applications N/A Parameter propogateOrbit Flag to indicate the model should N/A Parameter 75 Name Description Units Type propogate the orbit or use approximation samplePeriod Period to take images to avoid overlap in a single orbit s Variable iFovX Field of view of single pixel deg Variable dataRate Instrument HK rate bps Variable obsDataRate Science data rate bps Variable dataPerOrbit Data volume collected per orbit based on imagesPerStation and samplePeriod bits Variable focalLength Focal length of the optics m Variable apertureDiameter Diameter of the aperture m Variable fNumber f-number of the optics N/A Variable ratioToSimilarPayload Ratio of this payload’s aperture to similar payload N/A Variable ratioFactor Factor of 2 applied if ratio above is less than 0.5 N/A Variable numOrbits Number of orbits to cover surface N/A Variable obsDuration Duration to meet coverage and repeat factor months Variable Spacecraft The spacecraft class is the link between all of the subsystems to the overall spacecraft. This class contains named instances of subsystems to be included, allowing subsystem parameters to be accessed via dot notation. In the declarations section of the class, the follow line is an example of an instance declaration: replaceable acsSubsystem ACS; The keyword ‘replaceable’ means that acsSubsystem class can be replaced by a different class. For example, if one created a non-RWA based ACS subsystem, then that class can be substituted here. The keyword ‘acsSubsystem’ is the name of the class, and ‘ACS’ is the variable name of type ‘acsSubsystem.’ Therefore, variables within the ACS subsystem can be accessed as follows: ACS.scInertiaX = scInertiaX; 76 This line of code is setting a variable (scInertiaX) within the ACS class instance equal to the variable at spacecraft class level (scInertiaX). Note that the names can be the same because the class definitions control the namespace. Here is another line that represents summing the mass of each subsystem as well as a structural mass component computed in the spacecraft class: scDryMass = ACS.mass + CDH.mass + FSW.mass + PAY.mass + PROP.mass + PWR.mass + TEL.mass + THERM.mass + scStructuralMass; The spacecraft class is a mixture of subsystem roll ups, spacecraft level computations, and linkages between subsystem variables: ACS.radiusBody = PAY.orbit.centralBody.radius; ACS.altitude = PAY.orbit.altitude; ACS.thrusterForce = PROP.thrusterForce; The first line above demonstrates the nested classes of the optical payload subsystem. Since the payload needs the linkage to the orbital parameters, it has an instance of the orbitalParameters class named ‘orbit.’ The orbitalParameters class has an instance of the planetary body record named ‘centralBody.’ By nesting the dot notation, the spacecraft level class has visibility all the way down to the planetary body variables. The second line only traverses two dots deep to gain access to the orbital parameters class’s altitude variable. The last line is the simplest with only one dot deep notation. The last two significant parts of the class sum up the operations staffing for each subsystem and compute the cost of the spacecraft based on the sum of the subsystem costs as well as applying cost model based on the total spacecraft mass. The parameters and variables of the spacecraft class can be found in Table 4.13. Table 4.13 Spacecraft Class Parameters and Variables Name Description Units Type cruiseFTESpacecraft Staffing level beyond the subsystems during cruise FTE Parameter encounterFTESpacecraft Staffing level beyond the subsystems during encounter FTE Parameter scDryMass Dry mass of spacecraft kg Variable scWetMass Wet mass of spacecraft kg Variable 77 Name Description Units Type scStructuralMass Mass of spacecraft structure kg Variable scPower Total spacecraft power load W Variable scDataRate Total data rate for HK data bps Variable scLinDim Approximation of linear dimension of spacecraft m Variable scVolume Approximation of spacecraft volume m 3 Variable scBodyArea Approximation of spacecraft area m 2 Variable scInertiaX Approximation of spacecraft inertia kg-m 2 Variable scInertiaY Approximation of spacecraft inertia kg-m 2 Variable scInertiaZ Approximation of spacecraft inertia kg-m 2 Variable costBus Cost of the spacecraft bus (no payload) by summing subsystem costs $FY10 Variable costBusSimple Cost of the spacecraft bus based on spacecraft mass $FY10 Variable costStructThermal Cost of structure/thermal based on combined cost model $FY10 Variable costSC Cost of spacecraft, including payload $FY10 Variable costSCSimple Cost of spacecraft based on spacecraft mass $FY10 Variable scDesignLife Design life of the spacecraft, based on cruise and encounter duration plus margin years Variable 4.6.5 System Package The system package contains the ground system, mission operations, launch vehicle, and complete system classes. The ground system model captures the ground system costs in terms of hardware and software. Since most deep space missions by a single institution will use similar ground hardware and software, especially in cost constrained missions, this model just contains fixed values. These parameters and variables are in Table 4.14. Table 4.14 Ground System Class Parameters and Variables Name Description Units Type hwCost Cost of ground system hardware $FY10 Parameter 78 Name Description Units Type swCost Cost of ground system software development $FY10 Parameter cost Total cost of ground system development $FY10 Variable The mission operations model factors in spacecraft and mission complexity by summing up the workload for each of the spacecraft subsystems, plus any complexity factors that could increase or decrease a typical staffing level. Those factors are parameters that can be input at the mission operations level as a multiplier. If it is determined that single subsystem requires more or less staffing, then the FTE count for that subsystem is changed to reflect the correct level. Then, the workforce is computed for the cruise and encounter phases of the mission. This model also contains parameters to add engineers to the mission staffing level as a parameter and an overhead factor to account for team leads and managers since a larger team will have a proportionally larger leadership team. Table 4.15 lists the mission operations parameters and variables. Table 4.15 Mission Operations Class Parameters and Variables Name Description Units Type opsOverheadFactor Factor to multiply FTE levels by to account for management and supervision N/A Parameter opsCruiseComplexityFactor Factor to multiply FTE levels by to generically increase or decrease staffing levels. The value would depend on an assessment of the operational complexity N/A Parameter opsEncounterComplexityFactor Factor to multiply FTE levels by to generically increase or decrease staffing levels. The value would depend on an assessment of the operational complexity N/A Parameter FTEcost Cost of FTE/year $FY10 Parameter cruiseFTE Sum of FTEs for cruise staffing, with factors applied FTE Variable encounterFTE Sum of FTEs for encounter staffing, with factors applied FTE Variable 79 Name Description Units Type costCruise Operations cost of cruise $FY10 Variable costEncounter Operations cost of encounter $FY10 Variable cost Total operations cost $FY10 Variable The launch vehicle model attempts to capture the impact of spacecraft mass on the launch vehicle. Obviously, launch costs can be a fairly complex subject, but to simplify, the average cost of a launch for three launch vehicles, distinguishing by mass capability, was input. The values were taken from “Space Mission Engineering, The new SMAD.” [20] Since most deep space missions will require a third stage, the mass of a Star-48B is added to the launch mass. This results in the launch vehicle cost stair stepping up as the spacecraft mass increases. Again, the parameters and variables are itemized in Table 4.16. Table 4.16 Launch Vehicle Class Parameters and Variables Name Description Units Type upperStageMass Mass of third stage kg Parameter cost Cost launch vehicle $FY10 Variable Finally, the four major systems (ground system, mission operations, launch vehicle, and spacecraft) are combined in the complete system class. This class ties them all together and allows connections to be made between them, similar to those in the spacecraft class. As shown in Table 4.17, the system class includes a design life margin parameter. It is declared at this level because it factors into the spacecraft components, but also needs the mission operations duration totals. This parameter is used in a system class equation to compute the spacecraft design life variable defined in the spacecraft class based on the cruise and encounter durations. The other equations of the system class include the cost roll up of the four major systems (ground system, launch vehicle, mission operations, and spacecraft), adjusting the mission operations duration based on the telecom rate, and connecting variables between the spacecraft instance and the 80 mission operations instance. The single system class parameter and variable are listed in Table 4.17. Table 4.17 System Class Parameter and Variable Name Description Units Type designLifeMargin Margin to add to the design life over the mission duration N/A Parameter systemCost Total cost of the system $FY10 Variable 4.6.6 Setting Parameters For Study Now that all of the parameters for each class have been listed, each one can be set for a particular instance of a spacecraft design. This is accomplished with the ‘replaceable/redeclare’ constructs that allow an additional file to be loaded that replaces the default values in the various class definitions. The spacecraft class and the complete system class are the two that have redeclaration statements. Here is the spacecraftInstance example: model spacecraftInstance import spacecraftPackage.*; import missionDesignPackage.*; extends spacecraft(redeclare acsSubsystem ACS(numOrbitsToStoreGG = 5.000000), redeclare opticalPayloadSubsystem PAY(fovX = 2.500000, resolutionNadirX = 10.000000), redeclare propSubsystem PROP(blowdownSystem = 1.000000), redeclare pwrSubsystem PWR(solarCellType = 3.000000), redeclare telSubsystem TEL(fixedHGA = 1.000000, maxAntDiaSC = 2.000000), redeclare transferOrbit TO(transferType = 3.000000)); end spacecraftInstance; The ‘redeclare’ statements indicate to start with the already loaded spacecraft class, and redeclare the listed subsystems and set the specific parameters that are listed. Any parameter not listed will use the default value in the class definition. The systemInstance file works the same way. An example follows: model systemInstance import systemPackage.*; 81 extends systemPackage.completeSystem(redeclare missionOperations MO(opsCruiseComplexityFactor = 1.000000, opsEncounterComplexityFactor = 1.000000)); end systemInstance; Note that the name, like ‘ACS’ or ‘PAY’ must be the same as the original, but the class can change, provided that the new class has the same variables that are referenced in any equations that connect between classes. This would be how the default ACS subsystem could be replaced with a non-RWA based subsystem. To sum up, the first four files, planetary body, mission design package, spacecraft package, and system package are loaded into the Modelica environment first. Then the spacecraft instance file, which sets the spacecraft parameters, and system instance file, which sets the system level parameters, are loaded. In this way, the specific instance files supersede the default parameter values. 4.6.7 Parametric Studies Now that the model structure is defined in Modelica, the infrastructure to study parametric effects was built. First, it needed to be scriptable at some level in order to perform many combinations without continuous user interaction so a script was written in Perl. Perl may be a little out dated, but has some useful features for what it needed to do. This script reads a comma- separated file that contains a parameter name (e.g.: PAY.resolutionNadirX) in the first column followed by the list of values to use. Each line contains a different parameter. The script then takes the list of parameter names and values and builds them into an array of arrays, and finally, creates a new array with all permutations. The combinations were computed with the help of a one line subroutine found on the Perl Monks website. [31] With all of the combinations defined, the script outputs several sets of files to ultimately create a single command line to run any number of test cases. 82 In order to explain the test cases, the OMShell tool needs a little more explanation. This tool allows Modelica commands to be issued, but can also run a script of Modelica commands. It can also accept input from the standard input in a Unix environment. In order to model the system, the commands required consist of the following: 1. Change directories to a working area for the outputs (this also allows the compiler to find the Matlab interface) 2. Load the generic model files (planetary body, mission design package, spacecraft package, Modelica library, and system package) 3. Load the specific spacecraft instance and system instance model files 4. Write the current instance number to file to allow progress tracking 5. Simulate the system 6. Move and rename the results CSV file to an output directory 7. Repeat steps 3-6 These steps allow many cases to run in a single instance of the OMShell tool. However, there seems to be a memory leak, or at least the repeated loading of instances uses too much memory, and the system slows dramatically after around 50 simulations. Therefore, the script that runs in OMShell was limited to run 50 simulations and then exit. Then the tool was started again and the next script executed. The final implementation resulted in a top-level file that is run on the command line. This file calls OMShell and redirects a two-line file to it. The first line is a ‘runScript’ command with the path to the script with the commands listed in steps 1-7 above. This script runs for 50 cases, then after it is complete, the second line forces a quit of the OMShell tool. Then it is started again. It is a little tedious, but successfully runs about 25 cases a minute, with 8000 cases taking on the order of 5 hours. In order to prepare a run, the user first generates the CSV of parameters. Then they run the buildInstances.pl script to build the instances. This script generates each of the spacecraft and system instance model files, a pair per test case, then builds the script files to run the cases in the 83 OMShell environment, and builds a configuration CSV that stores the combinations of parameters for each instance. The script also builds a directory structure to store the instance files, output files, and script files. The user then starts the top-level script, which will run all of the instances through the Modelica simulation process. After all of the instances have been executed, the output is stored in a CSV file per instance in the output directory. The CSV file contains one line of output variable names and another line of output values. Modelica doesn’t output parameters or variables that don’t change, which means the default values and specific parameters for the case may not be in the output file. In order to pack all of the results into a single CSV file, another script was written to read the configuration CSV and find all of the output CSV files and merge the results into a single CSV file. This final merged file contains 267 values for chemical missions or 269 values for electric propulsion mission per instance, compared with the 198 equations. In order to visualize the results, a script was written in Matlab to read the merged results into a dataset. Then a second script can be used to generate a standard set of plots and regroup the dataset to make it a little easier to manipulate. 4.6.8 Summary The previous sections describe how a complete space mission model was developed to be able to trade off mission scenario impacts with early trades. The Modelica toolset did not lend itself to performing sensitivity analyses on its own, however, external tools could manage the setup of those analysis to run more cases through the system and review/analyze the results. This work also did not explore the possibility of defining an objective function to refine the parametric solution to meet that objective function, such as minimum cost. However, in many 84 cases, it is extremely useful to compute all of the datasets to allow the designers to select between options. For example, by having an objective function to find the minimum cost solution and not present other solutions, the designer may not notice that some alternate design points may be more desirable for some other reason. The toolset did provide a method to develop subsystem specific models that were integrated at the system level to be simultaneously solved. 85 5 Investigation As the tool set was being developed, several test cases were used to verify the results beyond the incremental unit testing. As stated earlier, each subsystem was fairly simple just to test that all the connections functioned as expected. Then, the specific subsystem models were expanded to achieve a higher fidelity model. With the core infrastructure now in place, parametric studies can be performed at the mission level. Since I am very familiar with the Dawn mission, many cases were used that mimic the Dawn configuration. These runs provided confidence that the models were working correctly. 5.1 Dawn Mission Comparison Dawn was the 9 th Discovery mission and launched in 2007. I am very familiar with Dawn operations since I have been working on it for more than 10 years. All of the references and parameters that have been used can be found in public literature to ensure that no data are released inappropriately. Dawn is a little difficult to compare directly since it is the only mission to orbit two extraterrestrial bodies, so it really had two target bodies to compare, two cruise phases, and an electric propulsion system. However, a comparison can be made for rough orders of magnitude. The first step was to build a parameter set to mimic the Dawn the configuration. The Dawn Framing Camera (FC) used for imaging has a 5.5° field of view with a 1024x1024 pixel detector with each pixel on the order of 14 µm. [32] The equations used in this model attempt to compute the aperture, focal length, and f-number based on diffraction-limited optics. It is not clear how the FC optics were designed and some of the resulting values vary from the FC, however the mass and power metrics come close. The other major configuration is the EP mission with multi-junction GaAs solar cells. Since this tool only allows one cruise period, it was chosen to be 5 years, which nearly approximates the combined Dawn phases, however, will 86 result in a longer cruise to one body. Also, Dawn operated at a variety of orbital altitudes during the encounters at Vesta and Ceres, so a variety of resolutions were input to get representative orbital altitudes and the encounter duration to perform a complete map at each of those altitudes. To perform a true comparison, then each orbit phase would need to be evaluated separately with slightly different imaging objectives. [33] 5.1.1 Dawn at Vesta Table 5.1 shows the parameters that were modified from their default values in order to mimic the Dawn spacecraft. Table 5.1 Dawn at Vesta and Ceres Parameters Name Units Values SC.PAY.ResolutionX m 20, 50, 100, 200 SC.PAY.fovX deg 5.5 SC.PAY.detetectorSize m 14e-6 SC.TEL.fixedHGA N/A 1 SC.PROP.blowdownSystem N/A 1 SC.PWR.solarCellType N/A 3 SC.THERM.thermalMassToSCRatio N/A 0.05 sc.TO.trasferType N/A 3 SC.TO.duration months 60 SC.TEL.maxAntDiaSC m 1.52 MO.opsEncounterComplexityFactor N/A 2 MO.opsCruiseComplexityFactor N/A 2 Note the four values for the resolution requirement. These values drive the models to a different orbital altitude, required data rate and encounter duration. Dawn’s primary resolution requirement was to completely cover the surface at better than 100 m resolution. However, because the mission was designed to observe a various altitudes for different requirements, time was spent in those altitudes as well. The results are in Table 5.2. These results show that the 87 model comes relatively close to the Dawn mass and cost which is pretty impressive starting from a camera field of view and resolution requirements. Table 5.2 Dawn at Vesta Results Name Units 20m 50 m 100 m 200 m Actual systemCost $MFY10 333 322 319 318 472 SCscWetMass kg 1382 1353 1342 1338 1217 SCscDryMass kg 906 895 890 888 747 SCPAYorbitaltitude km 213 533 1067 2134 varies MOencounterDuration months 7.6 2.1 2.4 2.7 varies It should be noted that the imaging requirement for 100 m resolution was met in what was called the High Altitude Mapping Orbit (HAMO) orbit, which took about 2 months to complete. These results show a heavier spacecraft for lower cost. Some of this can be attributed to the shorter mission duration (the actual complete Dawn mission is over 8 years long), resulting in a shorter design life feeding into the cost models. Additionally, the approximations of the thermal and structural masses show the largest deviations from the Dawn spacecraft. These two subsystems are very configuration dependent. The structure clearly depends on the layout of the spacecraft – it could be a cube, a cylinder, or another complex shape – but a relatively generic spacecraft design shouldn’t drive the structural mass out of family. Some configurations could cause the structure mass estimate to deviate if they have more specialized requirements, like oversized antennas, excessively long booms, etc. Additionally, the thermal performance is intrinsically tied to the structural configuration. The structure typically provides the heat path from an electronic component that dissipates heat to a radiator or other location to evenly spread the temperature across a panel. The heat path is provided by the choice of material, thermal interface, and the inclusion of heat pipes with in the panel. Furthermore, the specific designs of the units that dissipate heat will drive specific requirements on the thermal subsystem to be able to maintain a 88 temperature or dissipate enough heat. In these cases, the structure and thermal approximations result in a heavier spacecraft than Dawn, which is conservative, but the cost models are under predicting the total system cost as compared to the total system cost for Dawn. The models resulting in a heavier spacecraft is conservative because starting out with higher mass reduces the likelihood of a mass increase later in the design phase. While these effects may reduce some confidence in the absolute values of the results from the models, they do not invalidate the methodology since they do provide an estimate of the power and mass requirements that depend on the complete spacecraft. As a relative comparison, one can use these models to compare the impacts of various parameter choices to understand the trends, and then refine the thermal and structural models based on engineering judgment or external model sources. Figure 5.1 shows the cost breakdown for each sizing case. The bottom-right plot shows that the cost models for each subsystem come close to the cost model based on the entire spacecraft mass, which comes in higher than the sum of the subsystems. The mass breakdown is shown in Figure 5.2. The structural mass, power mass, and thermal mass are all noticeably higher than the actual Dawn spacecraft. Finally, some selected subsystem parameters are shown in Figure 5.3. The solar array performance at 1 AU from the model is almost 13 kW, while the actual array only produced about 10.4 kW. This means that this model is over predicting the required power required at the target, which translates to a larger array and thus more performance at 1 AU. 89 Figure 5.1 Dawn at Vesta Cost Breakdown Figure 5.2 Dawn at Vesta Mass Breakdown Figure 5.3 Dawn at Vesta Selected Subsystem Parameters Another aspect to consider is the telecom rate for the four configurations. The models set the downlink rate to the data collection rate, or the maximum of the based on the maximum antenna diameter. The Dawn HGA is a 1.52 m antenna and can support 124 kbps. The first case shows a maximum antenna size of 1.52 m and a downlink rate of 114 kbps. The next three cases show a reduced antenna size and corresponding downlink rate because fewer images per orbit are necessary to cover the surface to at the lower resolution. In Dawn’s case, more images were taken with additional color filters plus the two other instruments, which are not accounted for here. 90 5.1.2 Dawn at Ceres To emulate the Dawn spacecraft with Ceres as the target body, the same parameter modifications were made as in Table 5.1. Table 5.3 Dawn at Ceres Results Name Units 20m 50 m 100 m 200 m Actual systemCost $MFY10 372 334 327 325 472 SCscWetMass kg 1493 1430 1408 1396 1217 SCscDryMass kg 981 959 950 944 747 SCPAYorbitaltitude km 213 533 1067 2134 varies MOencounterDuration months 30 4.9 2.8 3.0 varies The spacecraft mass output from the model is a little larger as compared to the Vesta configuration, most likely attributed to the greater solar distance and a larger solar array. Figure 5.4 Dawn at Ceres Cost Breakdown Figure 5.5 Dawn at Ceres Mass Breakdown Figure 5.6 Dawn at Ceres Selected Subsystem Parameters 91 Figure 5.6 shows that the solar array sizing is about 11 to 12 m 2 larger. This array has a correspondingly larger performance at 1 AU. The telecom rates are also reduced based on the greater geocentric distance. However, in actuality, the geocentric range varies by 2 AU as the Earth and target body orbit the sun resulting in greater data rate capabilities for a significant part of the mission. 5.2 Applications of the Model With the baseline functionality verified, there are a multitude of options for running parametric studies with this model. Before going too far, there are a couple of constraints on the system. First, only one target body can be used for each set of runs, so to compare between targets, two sets of instances must be created and run separately. Next, there is a memory limitation in the Perl script generated the combinations of parameters. When defining a set of parameters to vary, the total number of combinations is the number of values for each parameter multiplied together. For example, to vary two parameters with the first having 3 values and the second having 2 values, the total number of combinations will be 6 instances. The script has run successfully for approximately 10,000 instances. It was found that with this many combinations, adding another parameter with just two values doubles the number of combinations. Also, this many instances takes approximately 5-6 hours to simulate. This is about as long as it should be in order for the execution time to be somewhat responsive to the workday. Algorithms that take more than eight hours or so tend to make it very difficult to interact with and iterate on the cases. The two major methodologies that can be applied here are two perform a high-level broad parameter space exploration or a detailed exploration of one or two aspects of the design. For example, a case of the former could be studying a variety of camera fields of view and resolution requirements, with and without a gimbaled HGA, a few HGA maximum diameters, and different 92 solar cell types. This set of cases could provide a view into any large edge cases and provide a broad range of size and cost estimates. The latter type of investigation would be to pick one or two subsystems and vary several parameters in very small steps to get a better understanding of the overall affect on the spacecraft. For example, studying the effects of the I sp , thruster size, RWA desaturation parameters to find the best combination. These two methodologies complement each other such that when they are both complete, the desired specific subsystem parameters can be used in the broader set of instances to re-evaluate those combinations and narrow down the parameter space accordingly. Finally, similar choices of parameters from one set of instances can be applied to a different target to observe if a different target’s size or solar distance changes the optimal parameter set. When the models were being tested, it was found that for any mission to the asteroid belt, the multi-junction GaAs solar cells result in the least expensive power subsystem, so most runs now only use this cell type. 5.2.1 Mission to Ceres The model was applied to a set of parameters to evaluate a mission to Ceres. Instead of fixing the camera field of view, several sizes were evaluated. A range of resolution requirements was also evaluated. The telecom parameters examined the effects of a fixed HGA versus gimbaled, as well as varying the maximum antenna size. The ACS subsystem compared the difference between storing gravity gradient torque for 5 and 10 orbits. Finally, the operational complexity factor was also varied. These parameters result in 960 combinations to be evaluated which took about 40 minutes. The list of parameters that were changed from their defaults can be seen in Table 5.4. 93 Table 5.4 Mission to Ceres Parameters under Investigation Name Units Values SC.PAY.ResolutionX m 10, 15, 20, 25, 30 SC.PAY.fovX deg 5.5, 10, 15, 20 SC.TEL.fixedHGA N/A 1,0 SC.PROP.blowdownSystem N/A 0 SC.PWR.solarCellType N/A 3 SC.THERM.thermalMassToSCRatio N/A 0.05 SC.TO.trasferType N/A 1 SC.TEL.maxAntDiaSC m 2, 2.5, 3, 3.5 MO.opsEncounterComplexityFactor N/A 1, 1.5, 2 MO.opsCruiseComplexityFactor N/A 2 SC.ACSnumOrbitsToStoreGG N/A 5, 10 Several interesting results came from this run. First of all, having the ACS system store momentum for more orbits (10 instead of 5), resulted in larger RWAs with a greater capacity to store momentum. This resulted in larger fuel consumption per desaturation, requiring more fuel. The highest resolution, 10 m per pixel, coupled with a fixed HGA had the largest fuel requirement. This is because the higher resolution requires both more data per orbit and more orbits to cover the surface. Now, each desaturation uses more fuel and the mission duration is longer, needing even more desaturations. With more fuel to carry, the spacecraft must grow with an accompanying mass and power growth. Since the thermal system is sized based on the spacecraft mass, its heater load grows, resulting in a greater total spacecraft power load, which leads to larger solar arrays and batteries, increasing mass yet again. However, only storing momentum for five orbits and not requiring 10 m per pixel resolution can prevent that additional mass growth. Figure 5.7 shows the cost breakdown. Analysis of the results found that the system costs that were above $400M were the cases that stored momentum for 10 orbits instead of 5. The payload cost varies based on the various fields of view in the parameter study. A smaller field of view results in a larger, thus, more expensive imager. It can also been seen that the 94 mission operation costs vary by tens of millions of dollars, with the highest resolution selection costing the most. Figure 5.7 Cost Breakdown for Chemical Mission to Ceres Figure 5.8 Mass Breakdown for Mission to Ceres Figure 5.9 Power Breakdown for Mission to Ceres The mass and power breakdowns in Figure 5.8 and Figure 5.8 also reflect the increased mass and power requirements for the longer momentum storage cases. Note the increased mass of the ACS subsystem to accommodate larger RWAs. Finally, Figure 5.10 shows the subsystem performance, including the selection of different HGA diameters. With the large geocentric distance of Ceres and the higher resolution requirement, many cases drive the antenna diameter out to the maximum allowed antenna diameter. Some of the lower resolution requirement cases result in intermediate sizes based on the downlink rate throughput. The telecom mass and cost 95 also reflect the various antenna size impacts as well as the choice between a fixed HGA and a gimbaled HGA. Furthermore, Figure 5.10 shows the impact on the encounter duration based on a fixed HGA or not. The maximum encounter duration with a fixed HGA is double that with a gimbaled HGA, requiring more RWA desaturations, and more fuel. When all of these affects line up, a maximum mission cost is found. Figure 5.10 Subsystem Performance for Mission to Ceres Figure 5.11 Mission Operations Duration Finally, the minimum and maximum system costs were found for each resolution requirement. Figure 5.12a shows that a resolution requirement of 10 m has both the largest variation in cost and the maximum cost for some parameter combinations. This plot also shows that careful selection of other parameters can bring the costs within about $50M of each other. Figure 5.12 Statistical Variation of System Cost 96 In all cases, the minim cost solutions had the largest payload field of view (20°) and the maximum cost solutions all had the smallest payload field of view (5.5°), as shown in part b of the figure. The telecom antenna size and gimbal selection showed some interesting effects. First of all, the instance of the minimum cost with the highest resolution (10 m) utilized a gimbaled HGA, while all other cases for minimum and maximum cost used a fixed HGA. Also, the minimum cost solutions for the two highest resolutions (10 and 15m) both required the largest antenna diameter available (3.5m), while the others resulted in progressively smaller antennas providing the minimum cost. The smallest HGA diameter of 2 m always resulted in the greatest system cost. These results show that a larger, more massive HGA will result in a lower system cost even though the telecom cost is higher. Furthermore, gimbaling the HGA only helped the minimum cost solution for the highest resolution. A fixed HGA also resulted in the maximum cost solutions for each resolution, but it appears that the additional mass of the gimbal outweighs the other effects when going for a minimum cost solution. Table 5.5 Telecom Configuration Resolution Requirement (m) Min/Max System Cost Fixed HGA? HGA Diameter (m) 10 Min No 3.5 Max Yes 2 15 Min Yes 3.5 Max Yes 2 20 Min Yes 2.5 Max Yes 2 25 Min Yes 2.5 Max Yes 2 30 Min Yes 2 Max Yes 2 The orbital altitude should also be considered before automatically taking the minimum cost solution. The larger the field of view of the camera, the lower the orbit needs to be to achieve a 97 given resolution requirement. Figure 5.13 shows that for the largest field of view (20°), the orbit gets very low – 29 km as compared to 107 km for a 5.5° field of view. This low of an altitude needs to be assessed from an orbit controllability perspective. These models do not model fuel requirements for orbit control maneuvers and a very low orbit may drive those fuel needs up, as well as greatly increase the operational complexity and cost if the team needs to constantly maintain the orbit. Also note that Figure 5.12 shows many solutions in each field of view family to have similar costs to the others, which means that one could impose a minimum orbital altitude and still find a reasonable cost solution. Figure 5.13 Orbit Altitude as a function of resolution and FOV Similar sets of parameters were studied to find the impacts from the deltaV requirement to get into orbit. The impacts matched expectations, which would be higher costs for more deltaV. The main observation would be that there is a significant jump in cost from 1.25 km/sec to 1.5 km/sec as shown in Figure 5.14. This means that the implementers should focus on keeping the deltaV requirement at or below 1.25 km/sec to keep the other design options available and still 98 have a lower cost mission. If the deltaV requirement can’t be reduced below 1.5 km/sec, then there are still lower cost solutions, but may limit the performance in resolution. Figure 5.14 System cost as a function of deltaV required 5.2.2 Comparison of Target Bodies A comparative study of each asteroid that has a GM parameter in the JPL small bodies database was performed to determine if the relative size or solar distance results in a significantly different spacecraft configuration. For all bodies, the same parameters as the Ceres investigation were used with the exception the 10 orbits to store gravity gradient torque since that parameter seemed to drive the cost up – they are shown in Table 5.4. For an additional comparison, missions to Mars, Phobos, and Deimos were also evaluated, but using an 8-month transfer orbit duration. The first item of interest is that the Mars, Phobos, and Deimos runs created some problems for the models when attempting to use the same sets of requirements and payload fields 99 Table 5.6 Target Body Properies Name Radius (km) Solar Distance (AU) Ceres 476 2.98 Deimos 6.2 1.67 Hygiea 204 3.5 Interamnia 158 3.53 Kalliope 91 3.2 Mars 3390 1.67 Pallas 273 3.41 Phobos 11.1 1.67 Psyche 127 3.32 Vesta 265 2.57 of view. For Mars, the body is so massive that it took 150 months to cover the surface on average, with most of the durations between 89 and 330 months (the 25 th and 75 th percentiles) and a Figure 5.15 System Cost Variation maximum of 1009 months. Obviously the resolution requirement and fields of view must be chosen differently for a significantly larger body. The combination of highest resolution (10m), smallest HGA (2m), and fixed HGA resulted in the solvers being unable to converge. Conversely, Deimos and Phobos were so small that the model didn’t find a solution for cases with resolution requirements lower than 10 m, resulting in values of zero for system cost, wet mass, and encounter duration, bringing the statistical plots closer to zero. A brief investigation of the Deimos and Phobos runs was completed, which evaluated higher resolution requirements and 100 narrower fields of view. These runs showed that the encounter duration took longer for lower resolution, which is not consistent with the other body evaluations. It is suspected that some constraints need to be applied to ensure that the geometric relationships used to compute things like the ground footprint are still valid. The system cost variation, wet mass variation, and encounter duration are plotted with and without the Martian bodies in figures Figure 5.15, Figure 5.16, and Figure 5.17. They are shown with and with out the Martian bodies because the scales required to the show the Martian data washed out the resolution to see the details for the other bodies. Finally, why do the missions to Kalliope and Vesta have the lowest mass? Figure 5.18 shows that these two missions have the smallest solar array, resulting in a smaller mass overall. The array is the smallest because these two have the smallest solar distance. Figure 5.16 Wet Mass Variation Figure 5.17 Encounter Duration Variation 101 Figure 5.18 Solar array performance 5.2.3 Comparison of Electric Propulsion to various target bodies The same small bodies were evaluated for a solar electric propulsion mission. Since the propellant mass, power required, and transfer duration are tightly coupled, several combinations of these were chosen, in addition to a smaller selection of the previous payload resolution and fields of view options. The complete set of parameters that were set differently from the defaults can be found in Table 5.7. Table 5.7 Parameters chosen for EP Missions to Small Bodies Name Units Values SC.PAY.ResolutionX m 20, 30 SC.PAY.fovX deg 5, 10 SC.TEL.fixedHGA N/A 1, 0 SC.PROP.blowdownSystem N/A 0 SC.PWR.solarCellType N/A 3 SC.THERM.thermalMassToSCRatio N/A 0.05 SC.TO.trasferType N/A 3 SC.TO.durationFixed months 42, 48, 54, 60 102 Name Units Values SC.PROP.epPropellantMassDefault kg 500, 750, 1000 SC.PROP.epPwrAtTargetDefault W 600, 800, 1000, 1200 SC.TEL.maxAntDiaSC m 2, 3 MO.opsEncounterComplexityFactor N/A 2 MO.opsCruiseComplexityFactor N/A 2 SC.ACSnumOrbitsToStoreGG N/A 5 This number of parameter choices resulted in 768 combinations, which took about 31 minutes for each body. Some of the target bodies produced results where the total system cost was in a relatively narrow band on order of $20M, but then contained some outliers more than $150M above the mean. See Figure 5.19 to see the cost breakdown for an EP mission to Ceres. It was initially thought that one or two of the parameter values drove the mass up, however, investigation of the data showed that it was a combination of parameters resulting in the jump to the higher cost. Evaluating the cost by major system plots, it can be observed that the spacecraft cost is contained in a band of about $50M, but the launch vehicle cost jumps between $56M and $172M for a few cases, which is the difference between a Falcon 9 and an Atlas 5. These results are showing that a combination of parameters can combine to reach a mass threshold that drives the spacecraft into a new launch category with corresponding cost increases. For example, the first few cases jump to the new launch vehicle when the mission duration extended, reflecting the increased wet mass for RWA desaturations, but then other cases with the shortest mission duration still required the more expensive launch vehicle because of a different parameter, like increased power requirements for the electric propulsion system at the target body. The difference between a fixed HGA and gimbaled HGA also drove the system to the larger launch vehicle, with the fixed HGA typically contributing to the more expensive launch. 103 Figure 5.19 Cost Breakdown for EP Mission to Ceres An impact of evaluating a variety values for the required power for the EP system is that there are stratifications in the solar array size and performance reflecting the jumps between 600, 800, 1000, 1200. The groupings of solar array performance can be seen in Figure 5.20. A separate run was made of 7,680 cases, which shows the stratification a little better. Also note that the total array power seems a bit high compared to the Dawn mission, which reflects a need to calibrate the power models. Figure 5.21 shows the power breakdown for the subsystems and total for the spacecraft, less the EP power requirement. It appears that there is a significant variation in the thermal and power subsystem loads. The thermal load is modeled by a percentage of the total spacecraft mass, so as the mass goes up, the thermal load goes up proportionally. Similarly, the power load of the power subsystem is reflecting the losses in power conversion, so as the total load goes up, this becomes a positive feedback loop and drives the load up even higher. 104 Figure 5.20 Solar array and telecom parameters for EP mission to Ceres Figure 5.21 Power breakdown for EP mission to Ceres The comparative statistics are shown for the cost, mass, and mission operations duration. The mission operations costs will reflect the combined effect of the varying cruise duration and encounter duration. 105 Figure 5.22 Statistical Variation of Cost Figure 5.23 Statistical Variation in Spacecraft Wet and Dry Masses Note that the encounter duration would not be affected by the selection of an EP mission. Figure 5.24 shows the statistical breakdown. Note that the bands are narrower because only two resolution requirements and two fields of view were evaluated. In the chemical mission, there were higher and lower resolution requirements, which tended to drive the longest, and shortest, encounter durations. 106 Figure 5.24 Statistical variation in encounter duration In summary, the tool could be used to study a variety of affects, from electric propulsion propellant mass to payload field of view and be able to provide meaningful comparisons. These examples show a review of small body missions because each mission was likely to have similar results and it was desired to determine if there was a target body size threshold where the choice of input parameters would need to be changed to achieve similar cost or performance. There is not an intrinsic requirement that the target body be a small body, however, the range of input parameters must be considered to make a meaningful study. Furthermore, a different payload type model could replace the optical payload to evaluate a design that incorporates a different payload technology, for example using radar instead of optical imaging. In this regard, the methodology is valid, provided that a model can be developed to reflect the specific mission configuration to be studied. 5.3 Evaluation of Hypotheses Now that the models have been implemented and many test results presented, they should be compared against the hypotheses. It should be noted again that the results presented here may have some absolute error as a result of the modeling, however, the relative accuracy should 107 provide the insight required to compare one set of configurations against another. Furthermore, if these models can be updated with more accurate mass and cost functions, or with a specific institution’s models, they will be more accurate. Hypothesis #1: MBSE can in fact be applied across the mission concept generically to create a single model that covers high-level spacecraft sizing through mission operations allowing a single user to vary parameters across the system to evaluate the impacts. This project has demonstrated that MBSE methodologies can be applied at the space mission level to evaluate the impacts of various design choices across subsystems, systems, and operations. The Modelica implementation allowed for simultaneous equation solving which eliminated the need to iterate the computations. For example, the thermal subsystem mass is based on the total spacecraft mass. An iterative solution would find the total spacecraft mass, then determine the thermal mass and add it to the spacecraft mass, then find the new thermal mass until it stops changing. This implementation finds all of the mass in one step. It was clearly possible to connect parameters between systems and subsystems allowing for different parts of the model to have visibility to other parts. Also, most of the subsystem information could reside with the class definition for that subsystem while a few lines of code at the spacecraft or system level would connect the data of different classes together. This maintains the object-oriented nature of the model. Unfortunately, the MagicDraw aspect was not fully investigated because of the software issues at the time. However, it did seem like there was an awful lot of overhead with the diagrams and making the equation connections. At the time, it appeared that the cross system and subsystem connections were causing problems with the solver, so it may not have been 108 feasible to implement this level of parametric modeling within MagicDraw. That is not to say that MagicDraw is not useful, just not in this case. Hypothesis #2: With the increase in personal computing power, the complex parametric studies can be done rapidly, allowing a single user to evaluate ten thousand combinations in a workday. This implementation demonstrated a system that could process a significant number of cases in a workday. Several runs of the models were tracked based on the number of combinations. The runs averaged about 27 cases per minute. Many of the runs contained 8,000 instances and took about 4 hours and 40 minutes. Because of the implementation where groups of 50 are processed in one start of the Modelica environment, each restart of the environment takes a little bit of time. Furthermore, the environment is not optimized for multithreading or multiple cores. The cases were run on a Mid 2012 Retina Display MacBook Pro with a 2.7 GHz Core i7 processor and 16 GB of 1600 MHz DDR3 RAM. It appeared that the biggest impact was memory availability, so when other tasks were being performed, like running Matlab to analyze the data, there were available CPU cores, but limited memory, which slowed things down a little. However, at the observed rates, 10,000 cases would take about 6.2 hours, which meets the hypothesis. However, while this technically meets the hypothesis, a better metric may be for a smaller number of cases in a shorter amount of time. For example, several runs of 960 combinations were performed and took about 40 minutes to complete. This was a decent pace since an analyst could easily spend about 30 minutes evaluating results, considering what parameters to tweak, and setting up a new run while another set is running. In all cases, however, the option of propagating the orbit in Matlab becomes prohibitively long. Part of the issue is that the orbits are not designed to achieve an optimal ground track so the cases with a poor ground 109 track would run for hundreds of orbits attempting to achieve global coverage and the function CPU time is proportional to the number of orbits. Even the best cases still took on the order of 15 to 30 minutes. Since the Modelica model successfully approximates this capability, this does not invalidate the hypothesis. 110 6 Conclusions This project proved to be very enlightening. While working on the Dawn mission at JPL, many of us considered the ramifications of particular design choices and how they impacted operations. These discussions and considerations were the inspiration for this thesis – could one person easily evaluate the ramifications of these design choices. Also, there is a large movement towards MBSE at JPL, with the upcoming mission to Europa establishing the groundwork for a standard implementation. Could the desire to understand the combined effects of design choices be met with MBSE? Yes, they could with the proper models that implement the various interconnections. One of the design choices that come up in hallway conversations is that of a body fixed HGA or not. The study of a mission to Ceres showed that the minimum cost solution did not require the gimbaled HGA, contrary to the impression that a gimbaled HGA is better for operations. Developing these models required analyzing and applying sizing estimates. Some of these had clear hardware connections, like RWA mass based on momentum capacity. Other aspects were more difficult to discern, like the cost of mass memory and other Command and Data Handling design choices. The modeling of these subsystems certainly could use more details and as computing architectures change rapidly, the empirically based cost models will struggle to keep up. Another aspect of this implementation is that these models do not account for reuse or heritage designs. The cost models are based on non-recurring costs to develop the spacecraft plus the cost of building it. Many deep space mission proposals, particularly competitively bid missions, take advantage of heritage architectures and FSW reuse. Comparing with Dawn again, some engineers would have liked to have more mass memory on board, however, the flight 111 component that holds the memory was a heritage design which could have needed significant rework to fit more memory. Attempting to make changes to heritage designs usually results in larger costs because of unexpected consequences so they are usually strongly opposed during development. If one had a tool that could show a measurable system cost savings, then there could be a well-informed decision on how to proceed. Finally, this work validated a methodology that could be used to better inform an engineer or team exploring various design options. This implementation relied on cost and size models extracted from textbooks as well as a particular software tool to implement the models. The important factor is really that a single integrated model can be formulated in order to trade off mission scenario aspects against early development choices. This methodology provides the groundwork to make clear connections between the spacecraft subsystem design models and mission operations scenarios and complexity to more thoroughly inform the designer of a more complete trade space, while not requiring time consuming iterations between various model executions. Furthermore, this work explored a mission to various small bodies as a matter of convenience to study a broad range cases while still being relatively similar. The methodology, as well as these models, does not specifically exclude other mission options, however, the parametric values must be chosen in accordance with the target body. 112 7 Future Work There are several areas to expand on this effort. The first area is the modeling infrastructure. Since the Modelica environment is running a numerical solver, some combinations have results far enough away from the initial conditions that solver can’t converge on a solution. Solutions to this problem could be as simple as providing start values for more variables. The current implementation only supplies a handful of start values so either more variables could have start values or an attempt could be made to make them more realistic. Additionally, there may be a Modelica construct that would allow for them to be parameterized and thus specified like the other parameters being studied. Furthermore, with so many data sets being produced, some effort could be applied to a better file management system, data visualization, and standard reports. Also, the tools to generate the combinations could have a GUI front end built that would make it easier to interact with. There are also some parameters that the user may want to treat as a single set and not make all of the possible combinations. The next area includes various class models that could be improved. In the mission design package, both the transfer orbit and orbital parameters models could be improved. The transfer orbit model could be improved by modeling a more realistic transfer orbit, with a corresponding deltaV requirement, which may link into the launch vehicle model to define the required C3 from the launch vehicle. Furthermore, this model should have options to compute the relevant parameters for both chemical and electric propulsion missions. These improvements would affect the cruise duration and deltaV requirements. The orbital parameters model could include higher order gravity terms, inclination, constraint checks on altitude and geometry. In the spacecraft package, all of the models could be reviewed for improvement, but several are clear candidates. First, the CDH model was the most difficult to find sizing models so the mass and power are 113 loose approximations. Conversely to the recommendation above to improve the parameter combination tools, the models could be updated to have a parameter that selects an option that sets multiple variables according to that option. The solar array model is currently setup like this. The battery model could also be updated to trade between a lithium ion and nickel metal hydride battery type. The propulsion model could also use something like this to choose between different propellant types – bipropellant, monopropellant, and cold gas could be options to select fuel density, Isp, and tankage/hardware needs. The flight software model currently has a fixed number of lines of code, but linkages could be made to reflect subsystem complexities in the FSW code estimate. The last major area of improvement is the operational complexity model. The system currently allows the user to set the staffing levels and some of the models increase the staffing based on options, like EP or a fixed HGA. These connections between subsystem design and operational complexity need to be refined to ensure that the operational costs truly reflect what it takes to operate the mission. 114 8 Appendix This appendix includes all of the code utilized in this project. 8.1 Modelica Models This section has the text version of the Modelica models. 8.1.1 Planetary Body Record The planetary body record is the file defines the physical and orbit properties of the target body. record planetaryBody parameter String Name = "Vesta"; parameter Real radius = 265000; parameter Real spinPeriodBody = 19231.2; parameter Real solarDistance = 2.57; parameter Real gmBody = 1.78e10; end planetaryBody; Each target that was analyzed is stored in separate files, which are included below for completeness: record planetaryBody parameter String Name = "Ceres"; parameter Real radius = 476200; parameter Real spinPeriodBody = 32667.0; parameter Real solarDistance = 2.98; parameter Real gmBody = 6.32e10; end planetaryBody; record planetaryBody parameter String Name = "Hygiea"; parameter Real radius = 203560; parameter Real spinPeriodBody = 99442.8; parameter Real solarDistance = 3.5; parameter Real gmBody = 7e9; end planetaryBody; record planetaryBody parameter String Name = "Interamnia"; parameter Real radius = 158310; parameter Real spinPeriodBody = 31417.2; parameter Real solarDistance = 3.53; 115 parameter Real gmBody = 5e9; end planetaryBody; record planetaryBody parameter String Name = "Kalliope"; parameter Real radius = 90500; parameter Real spinPeriodBody = 14933.9; parameter Real solarDistance = 3.2; parameter Real gmBody = 4.91e8; end planetaryBody; record planetaryBody parameter String Name = "Mars"; parameter Real radius = 3389500; parameter Real spinPeriodBody = 88642.7; parameter Real solarDistance = 1.67; parameter Real gmBody = 4.28e13; end planetaryBody; record planetaryBody parameter String Name = "Pallas"; parameter Real radius = 272500; parameter Real spinPeriodBody = 28127.5; parameter Real solarDistance = 3.41; parameter Real gmBody = 1.43e10; end planetaryBody; record planetaryBody parameter String Name = "Psyche"; parameter Real radius = 126580; parameter Real spinPeriodBody = 15105.6; parameter Real solarDistance = 3.32; parameter Real gmBody = 4.49e9; end planetaryBody; 8.1.2 Mission Design Package The Mission Design package contains the classes to compute the orbital parameters at the target and the transfer, or cruise, phase to the target. It should be noted that comments can be included at the end of the line within the double quotes and before the semi-colon. An entire line is commented by starting with /* and ending with */ package missionDesignPackage class orbitalParameters import const = Modelica.Constants; Real altitude "m"; Real N "number of orbits until repeat ground track"; Real fov "deg"; Real elevation "deg"; Real angRadBody "deg"; Real groundFootPrint "deg"; Real groundTrackVel; 116 Real nodeSpacing; Real period "s"; Real rhMax; Real radius "m"; planetaryBody centralBody; equation angRadBody = asin(centralBody.radius / (centralBody.radius + altitude)) * 180 / const.pi; elevation = acos(sin(fov * 0.5 * const.pi / 180) / sin(angRadBody * const.pi / 180)) * 180 / const.pi; groundFootPrint = (90 - elevation - fov / 2) * 2; N = ceil(360 / groundFootPrint); radius = centralBody.radius + altitude; rhMax = sqrt((centralBody.radius + altitude) ^ 2 - centralBody.radius ^ 2); period = 2 * const.pi * sqrt((centralBody.radius + altitude) ^ 3 / centralBody.gmBody); nodeSpacing = period / centralBody.spinPeriodBody * 2 * const.pi; groundTrackVel = 2 * const.pi * centralBody.radius / period; end orbitalParameters; class transferOrbit import const = Modelica.Constants; constant Real GMSun = 1.327124e11 "km3/s2"; constant Real rEarth = 1.0 "AU"; constant Real AU2km = 1.496e8 "km/AU"; parameter Real transferType = 1 "1 = Use dVinput parameter at target to compute chemical fuel mass and input duration, 2 = compute dV2 and duration, 3 = EP and passed to PROP model, PROP model will have parameters for EP mass, Xe, and additional power, and input duration"; parameter Real dV2Input = 1.0 "km/s"; parameter Real durationFixed = 24 "months - allows a transfer to be specified"; Real r1 "km"; Real r2 "km"; Real v1c "km/s"; Real v2c "km/s"; Real at "km"; Real dV1 "km/s"; Real dV2 "km/s"; Real vT1 "km/s"; Real vT2 "km/s"; Real duration "months"; Real cruiseFTE; Real encounterFTE; planetaryBody targetBody; equation r1 = rEarth * AU2km; r2 = targetBody.solarDistance * AU2km; v1c = (GMSun / r1) ^ 0.5; v2c = (GMSun / r2) ^ 0.5; at = 0.5 * (r1 + r2); dV1 = GMSun ^ 0.5 * ((2 / r1 - 1 / at) ^ 0.5 - (1 / r1) ^ 0.5); vT1 = v1c + dV1; vT2 = vT1 * r1 / r2; 117 if transferType == 1 then dV2 = dV2Input; duration = durationFixed; cruiseFTE = 2 "cruiseFTEDefault"; encounterFTE = 4 "encounterFTEDefault"; elseif transferType == 2 then dV2 = v2c - vT2; duration = const.pi * at ^ 1.5 / GMSun ^ 0.5 * 12 / (86400 * 365) "months"; cruiseFTE = 2 "cruiseFTEDefault"; encounterFTE = 4 "encounterFTEDefault"; elseif transferType == 3 then dV2 = 0; duration = durationFixed; cruiseFTE = 6 "cruiseFTEDefault + EPFTEAdditional"; encounterFTE = 8 "encounterFTEDefault + EPFTEAdditional"; end if; end transferOrbit; end missionDesignPackage; 8.1.3 Spacecraft Package The spacecraft package contains the subsystem class definitions, as well as the spacecraft class itself. Note that the mass and power values for the ACS and PROP components were found from product specification sheets on the suppliers’ web pages. [34][35][36][37][38] package spacecraftPackage class subsystem Real mass "kg"; Real power "W"; Real dataRate "bps"; Real cruiseFTE; Real encounterFTE; Real cost "FY2010 dollars USCM8 Table 11-8 SME-SMAD"; end subsystem; class acsSubsystem extends subsystem; import const = Modelica.Constants; parameter Real numOrbitsToStoreGG = 5.0 "This is to size momentum growth capacity of the RWA"; parameter Real desatThreshold = 0.8 "Design to desat at this percentage of capacity"; parameter Real offNadirAngleFixedHGA = 0.785 "radians - 0.785 is an average of 45 deg if off nadir point for portions of the orbit"; parameter Real offNadirAngleGimbaledHGA = 0.175 "radians - 0.175 is 10 deg"; parameter Real fuelRateDuringTransfer = 0.2 "kg/mo - probably high, but need something TBR"; parameter Real starTrackerMass = 3.7 "kg, Sodern SED26"; parameter Real imuMass = 4.4 "kg, Honeywell MIMU"; 118 parameter Real rwaPower = 20 "W, per wheel"; parameter Real starTrackerPower = 9.9 "W, per ST SED26"; parameter Real imuPower = 22 "W, Honeywell MIMU"; parameter Real cruiseFTEDefault = 2 "Number of engineers to operate the spacecraft in cruise"; parameter Real encounterFTEDefault = 3 "Number of engineers to operate the spacecraft in encounter"; parameter Real cruiseFTEEPAdditional = 1 "Number of additional engineers for an EP mission"; Integer transferType "1 for chemical maneuvering with input values, 2 for chemical with computed dV, 3 for EP, see Transfer Orbit Model"; Real fixedHGA "from TEL model to determine grav gradient"; Real rwaMomCap "Nms Required size of the RWA"; Real rwaMass "kg per RWA, based on fit to Honeywell RWAs based on MomCap requirement"; Real offNadirAngle "radians"; Real gravGradTorque "Nm"; Real gravGradMomPerOrbit "Nms"; Real burnTimePerDesat "s"; Real scInertiaX; Real scInertiaY; Real scInertiaZ; Real scLinDim; Real gmBody; Real radiusBody; Real altitude; Real orbitPeriod; Real thrusterForce; Real Isp; Real fuelMassDesats; Real numOrbits; Real globalRepeatFactor; Real transferDuration "months"; equation if transferType > 2 then cruiseFTE = cruiseFTEDefault + cruiseFTEEPAdditional; encounterFTE = encounterFTEDefault; else cruiseFTE = cruiseFTEDefault; encounterFTE = encounterFTEDefault; end if; if fixedHGA > 0.1 then offNadirAngle = offNadirAngleFixedHGA; else offNadirAngle = offNadirAngleGimbaledHGA; end if; mass = 4 * rwaMass + 2 * starTrackerMass + 2 * imuMass + 10 "4 RWAs, 2 star trackers, 2 IRUs for redundancy, 10 kg of miscellaneous components"; dataRate = 300; power = (3 * rwaPower + starTrackerPower + imuPower) * 1.1 "add 10% for control electronics"; /* RWA sizing calculations */ rwaMomCap = numOrbitsToStoreGG * gravGradMomPerOrbit; if rwaMomCap < 4 then rwaMass = 3.6 "Honeywell HR0610"; elseif rwaMomCap < 12 then 119 rwaMass = 0.175 * (rwaMomCap - 4) + 3.6 "Honeywell HR0610"; elseif rwaMomCap < 25 then rwaMass = 7 "Honeywell HR12"; elseif rwaMomCap < 50 then rwaMass = 8.5 "Honeywell HR14"; elseif rwaMomCap < 75 then rwaMass = 10.4 "Honeywell HR16"; else rwaMass = 12 "Honeywell HR16"; end if; gravGradTorque = 3 * gmBody * abs(scInertiaZ - scInertiaY) * sin(2 * offNadirAngle) / (2 * radiusBody + altitude) ^ 3; gravGradMomPerOrbit = gravGradTorque * orbitPeriod * 0.707 / 4; burnTimePerDesat = rwaMomCap * desatThreshold / (scLinDim / 4 * thrusterForce) * 3 "*3 for 3-axes"; fuelMassDesats = thrusterForce * burnTimePerDesat * numOrbitsToStoreGG * numOrbits * globalRepeatFactor / (Isp * const.g_n) + transferDuration * fuelRateDuringTransfer; cost = (324 * mass + 795 * mass ^ 0.593) * 1000; end acsSubsystem; class cdhSubsystem extends subsystem; parameter Real cruiseFTEDefault = 0.5 "Number of engineers to operate the spacecraft in cruise"; parameter Real encounterFTEDefault = 0.5 "Number of engineers to operate the spacecraft in encounter"; /* need to figure out mass/power based on complexity/mass memory size */ equation cruiseFTE = cruiseFTEDefault; encounterFTE = encounterFTEDefault; mass = 80; dataRate = 125; power = 75; cost = 0 "TBR"; end cdhSubsystem; class fswSubsystem extends subsystem; parameter Real SLOC = 50000 "source lines of code"; parameter Real cruiseFTEDefault = 1 "Number of engineers to operate the spacecraft in cruise"; parameter Real encounterFTEDefault = 1 "Number of engineers to operate the spacecraft in encounter"; equation cruiseFTE = cruiseFTEDefault; encounterFTE = encounterFTEDefault; mass = 0; dataRate = 100; power = 0; cost = 550 * SLOC; end fswSubsystem; class propSubsystem extends subsystem; parameter Real thrusterForce = 1.0 "N"; 120 parameter Real Isp = 220 "s"; parameter Real thrusterMass = 0.33 "kg per thruster, Aerojet MR-103D"; parameter Real thrusterNumber = 12 "number of thrusters"; parameter Real blowdownSystem = 0; parameter Real epPropellantMassDefault = 425 "kg"; parameter Real epHWMassDefault = 130 "kg, (from Dawn design) includes power supplies, controllers, gimbal assemblies, flow system, and tanks"; parameter Real epPwrAtTargetDefault = 600 "W"; parameter Real epPwrHKDefault = 20 "W"; parameter Real cruiseFTEDefault = 0.5 "Number of engineers to operate the spacecraft in cruise"; parameter Real encounterFTEDefault = 0.5 "Number of engineers to operate the spacecraft in cruise"; parameter Real EPFTEAdditional = 1 "Number of addtional engineers for EP mission"; parameter Real costEP = 10e6 "Arbitrary $10M additional cost for EP system"; Real transferType "1 for chemical maneuvering with input values, 2 for chemical with computed dV, 3 for EP, see Transfer Orbit Model"; Real fuelMassDesats "kg"; Real fuelMass "kg"; Real wetMass "kg"; Real epPropellantMass "kg"; Real epHWMass "kg"; Real epPwrAtTarget "W"; Real epPwrHK "W"; Real hwMass "kg"; Real fuelVol "cm3"; Real pressurantMass "kg"; Real pressurantVol "cm3"; Real totalTankVol "liters"; Real totalTankMass "kg"; Real injectionDeltaV "km/s"; Real scDryMass "kg"; Real missionMass "kg at the target body after maneuver"; Real massFraction "ratio at the target body before maneuver"; Real M0 "kg total s/c mass before maneuver"; Real fuelMassManeuver(start = 3700) "kg"; equation if transferType > 2.1 then epPropellantMass = epPropellantMassDefault; epHWMass = epHWMassDefault; epPwrAtTarget = epPwrAtTargetDefault; epPwrHK = epPwrHKDefault; cruiseFTE = cruiseFTEDefault + EPFTEAdditional; encounterFTE = encounterFTEDefault + EPFTEAdditional; cost = 20 * (totalTankVol / 0.001) ^ 0.485 * 1000 + costEP; else epPropellantMass = 0; epHWMass = 0; epPwrAtTarget = 0; epPwrHK = 0; cruiseFTE = cruiseFTEDefault; encounterFTE = encounterFTEDefault; cost = 20 * (totalTankVol / 0.001) ^ 0.485 * 1000; 121 end if; missionMass = scDryMass + fuelMassDesats * 1.2 + 10 "10 kg margin/contingecy, 20 % margin on desats"; massFraction = exp(abs(injectionDeltaV * 1000) / (Isp * 9.81)); M0 = massFraction * missionMass; fuelMassManeuver = M0 - missionMass; fuelMass = fuelMassManeuver * 1.2 + fuelMassDesats * 1.2 + 10; fuelVol = fuelMass * 1000 / 1.01 * 1.2 "adds 20% volume margin"; pressurantMass = 689 * fuelVol / (296.733 * 293 - 689 / 0.2546) / 1000 "kg"; pressurantVol = pressurantMass * 1000 / 254.6; totalTankVol = (fuelVol + pressurantVol) * 0.001; if blowdownSystem > 0 then totalTankMass = 2.36e-7 * totalTankVol ^ 3 - 2.32e-4 * totalTankVol ^ 2 + 0.131 * totalTankVol + 0.264; else totalTankMass = 0.1 * fuelMass + 0.5 * pressurantMass; end if; hwMass = thrusterMass * thrusterNumber + totalTankMass + epHWMass; mass = hwMass + 15 "15 kg for lines, valves, regulator, etc"; wetMass = fuelMass + pressurantMass + epPropellantMass; dataRate = 100; power = 7 * thrusterNumber / 2 "W - power when firing of 6W per thruster, catbed and valve heater power, valve power"; end propSubsystem; class pwrSubsystem extends subsystem; /*The mass and power of the power subsystem are a function of the entire spacecraft power load, so the equations are in the spacecraft class but the solar array mass/size parameters are stored here.*/ parameter Real solarCellType = 3 "1 = Silicon, 2 = GaAs, 3 = multijunction GaAs"; Real solarArrayWattPerArea "W/m2"; Real solarArrayMassPerArea "kg/m2"; Real solarCellDegradation; Real solarArrayCostPerWatt; parameter Real chargeEff = 0.92 "battery charge efficiency"; parameter Real dischargeEff = 0.94 "battery discharge efficiency"; parameter Real eclipseFraction = 0.5 "eclipse dur/(orb period - eclipse dur), highly dependent on mission design"; parameter Real eclipseDuration = 1.0 "hr - arbitrary value to cover launch cases that might go into eclipse"; parameter Real batteryVoltage = 28 "V"; parameter Real batteryDODLimit = 0.5 "Needs to be consistent with battery type (NiH or LiIon)"; parameter Real batteryEnergyDensity = 50 "W-hr/kg from Table 21-18 SME-SMAD"; parameter Real cruiseFTEDefault = 0.5 "Number of engineers to operate the spacecraft in cruise"; parameter Real encounterFTEDefault = 1 "Number of engineers to operate the spacecraft in encounter"; 122 parameter Real EPFTEAdditional = 0.5 "Number of additional engineers for an EP mission"; Real solarArrayArea; Real solarArrayMass; Real solarArrayAreaOffset; Real solarArrayInertiaAboutAxis "kg-m2, Since solar array has a large component of the inertia, these exist, if an RTG is used, just set these to 0"; Real solarArrayInertiaPerpAxis "kg-m2"; Real solarArrayInertiaPerpFace "kg-m2"; Real solarArrayPowerReqEOL "W s/c loads, plus battery charge"; Real solarArrayPowerReqBOL "W s/c loads, plus battery charge increased by the lifetime degradation factor"; Real solarArrayDegradation "factor"; Real solarArrayPerf1AUBOL "W, solar array output at 1 AU, BOL"; Real otherMass "kg This mass includes solar array deployment and attachments, plus control equip and cabling"; Real batteryCapacity "A-hr"; Real batteryMass "kg"; Real solarDistance; Real scPower; Real scLinDim; Real scDesignLife; Real solarArrayCost; Real epPwr "W; power for EP system, not included in battery capacity"; equation if solarCellType == 3 then solarArrayWattPerArea = 382; solarArrayMassPerArea = 2.8; solarCellDegradation = 0.5; solarArrayCostPerWatt = 617; elseif solarCellType == 2 then solarArrayWattPerArea = 252; solarArrayMassPerArea = 2.7; solarCellDegradation = 2.75; solarArrayCostPerWatt = 852; else solarArrayWattPerArea = 191; solarArrayMassPerArea = 2.3; solarCellDegradation = 3.75; solarArrayCostPerWatt = 378; end if; if epPwr > 0 then cruiseFTE = cruiseFTEDefault + EPFTEAdditional; encounterFTE = encounterFTEDefault + EPFTEAdditional; else cruiseFTE = cruiseFTEDefault; encounterFTE = encounterFTEDefault; end if; dataRate = 150; solarArrayPowerReqEOL = scPower + scPower * eclipseFraction / (chargeEff * dischargeEff) + epPwr; solarArrayDegradation = (1 - solarCellDegradation / 100) ^ scDesignLife; solarArrayPowerReqBOL = solarArrayPowerReqEOL / solarArrayDegradation; 123 solarArrayArea = solarArrayPowerReqBOL / solarArrayWattPerArea * solarDistance ^ 2; solarArrayPerf1AUBOL = solarArrayArea * solarArrayWattPerArea "W"; solarArrayMass = solarArrayArea * solarArrayMassPerArea; solarArrayAreaOffset = 1.5 * scLinDim + 0.5 * (solarArrayArea / 2) ^ 0.5; power = scPower * 0.1 "Need to verify the ratio for the power processing electronics TBR"; solarArrayInertiaAboutAxis = solarArrayArea / 24 * solarArrayMass; solarArrayInertiaPerpAxis = (solarArrayAreaOffset ^ 2 + solarArrayArea / 24) * solarArrayMass; solarArrayInertiaPerpFace = (solarArrayAreaOffset ^ 2 + solarArrayArea / 12) * solarArrayMass; otherMass = 15 * 2 + (4 * solarArrayArea + 15 * 2) * 0.15 + scPower * 0.07 + 0.071 * solarArrayPowerReqBOL + 0.15 "Taken from CalPoly 546 course"; batteryCapacity = scPower * eclipseDuration / (dischargeEff * batteryDODLimit * batteryVoltage) "A-hr"; batteryMass = batteryCapacity * batteryVoltage / batteryEnergyDensity; mass = solarArrayMass + batteryMass + otherMass; solarArrayCost = solarArrayPerf1AUBOL * solarArrayCostPerWatt; cost = (64.3 * (batteryMass + otherMass) + 32.4 * (batteryMass + otherMass)) * 1000 + solarArrayCost; end pwrSubsystem; class telSubsystem extends subsystem; import const = Modelica.Constants; parameter Real transmitterPower = 100 "W"; parameter Real frequencyDL = 8.435 "GHz"; parameter Real antDiaDSN = 34 "m"; parameter Real antEff = 0.55 "assuming 55% efficiency for all antenna's"; parameter Real SNT = 27 "K"; parameter Real EbNoThreshold = 0.1 "dB - based on Turbo 1/6 coding 3568 bit code blocks per CCSDS standard - better than BER 1e-5"; parameter Real fixedHGA = 1.0 "1 means body fixed High Gain Antenna, 0 means gimbaled HGA allowing for continuous data transfer"; constant Real AU2m = 1.496e11; parameter Real HGAGimbalMass = 10 "kg - additional mass for gimbal mechanism, structure, cabling TBR"; parameter Real maxAntDiaSC = 3 "m"; parameter Real cruiseFTEDefault = 1 "Number of engineers to operate the spacecraft in cruise"; parameter Real encounterFTEDefault = 2 "Number of engineers to operate the spacecraft in encounter"; parameter Real fixedHGAStaffingFactor = 1.5; parameter Real gimbaledHGAStaffingFactor = 1.0; Real atmLoss "dB"; Real gainDSNDL "dBi"; Real antDiaSC(start = 0.5) "m"; Real gainSCDL "dBi"; Real scTotalDataRate "bps"; Real solarDistance "AU"; 124 Real geoCentricDistance "km - add 1 AU to the central body solar distance to get worst case geoCentricDistance, then convert to km"; Real spaceLoss "dB"; Real powerReceivedDL "dB"; Real SNRDL "dB"; Real downlinkRate "bps - this downlink rate is limited by max HGA diameter"; Real desiredDownlinkRate "bps - this optimal downlink rate"; Real desiredAntDiaSC(start = 3.5) "m"; Real desiredGainSCDL "dBi"; Real desiredPowerReceivedDL "dB"; Real desiredSNRDL "dB"; equation if frequencyDL > 16 then atmLoss = 8 "dB based on figure 16.18 in new SMAD at ~30GHz, 0.3 dB + (cosec(elevation))db (at 15 deg elevation, it is 6 dB), plus 3 dB for Wx variation"; else atmLoss = 5 "dB"; end if; if fixedHGA > 0.1 then desiredDownlinkRate = 2 * scTotalDataRate; mass = 22.0 + 4.0 * antDiaSC "approximation of HGA mass"; cruiseFTE = cruiseFTEDefault * fixedHGAStaffingFactor; encounterFTE = encounterFTEDefault * fixedHGAStaffingFactor; else desiredDownlinkRate = scTotalDataRate; mass = 22.0 + HGAGimbalMass + 4.0 * antDiaSC "approximation of HGA mass"; cruiseFTE = cruiseFTEDefault * gimbaledHGAStaffingFactor; encounterFTE = encounterFTEDefault * gimbaledHGAStaffingFactor; end if; geoCentricDistance = (solarDistance + 1.0) * AU2m; spaceLoss = 10 * log10((4 * const.pi * geoCentricDistance * (frequencyDL * 1e9 / const.c)) ^ 2); gainDSNDL = 10 * log10(antEff * (const.pi * antDiaDSN * frequencyDL * 1e9 / const.c) ^ 2); EbNoThreshold = desiredSNRDL - 10 * log10(desiredDownlinkRate); desiredGainSCDL = 10 * log10(antEff * (const.pi * desiredAntDiaSC * frequencyDL * 1e9 / const.c) ^ 2); desiredPowerReceivedDL = 10 * log10(transmitterPower) + desiredGainSCDL + gainDSNDL - spaceLoss - atmLoss; desiredSNRDL = desiredPowerReceivedDL - 10 * log10(const.k) - 10 * log10(SNT); if desiredAntDiaSC > maxAntDiaSC then antDiaSC = maxAntDiaSC "The complete system model increases ops duration by the ratio of desired rate to max rate"; else antDiaSC = desiredAntDiaSC; end if; gainSCDL = 10 * log10(antEff * (const.pi * antDiaSC * frequencyDL * 1e9 / const.c) ^ 2); powerReceivedDL = 10 * log10(transmitterPower) + gainSCDL + gainDSNDL - spaceLoss - atmLoss; 125 SNRDL = powerReceivedDL - 10 * log10(const.k) - 10 * log10(SNT); downlinkRate = 10 ^ ((SNRDL - EbNoThreshold) / 10); dataRate = 125; power = transmitterPower * 2 + 31 "Table 21-8 of new SMAD"; cost = (26916 + 883.7 * mass * 1.13) * 1000; end telSubsystem; class thermSubsystem extends subsystem; parameter Real cruiseFTEDefault = 0.5 "Number of engineers to operate the spacecraft in cruise"; parameter Real encounterFTEDefault = 0.5 "Number of engineers to operate the spacecraft in encounter"; parameter Real heaterLoadToMassRatio = 0.2 "Ratio of total heater load to rest of s/c power load"; parameter Real thermalMassToSCRatio = 0.1 "Ratio of thermal subsystem mass to s/c mass"; Real scWetMass; Real scPower; equation cruiseFTE = cruiseFTEDefault; encounterFTE = encounterFTEDefault; dataRate = 200; power = scWetMass * heaterLoadToMassRatio; mass = scWetMass * thermalMassToSCRatio; cost = 0 "TBR"; end thermSubsystem; class opticalPayloadSubsystem extends payloadSubsystem; import missionDesignPackage.orbitalParameters; import const = Modelica.Constants; parameter Integer numberOfPixelsX = 1024; parameter Integer bitsPerPixel = 8; parameter Real fovX = 5.0 "deg"; parameter Real resolutionNadirX = 30 "m"; parameter Real requiredArea = 80 "%"; parameter Real detectorSizePerPixel = 30e-6 "m"; parameter Real qualityFactor = 1.1; parameter Real waveLength = 4.2e-6; parameter Real massSimilarPayload = 13 "kg, changed from 239 kg from SMAD. 13 is from page 510 new SMAD"; parameter Real powerSimilarPayload = 12 "W, changed from 280 W from SMAD. 12 is from page 510 new SMAD"; parameter Real apertureSimilarPayload = 0.12 "m"; parameter Real designLife = 60 "months"; parameter Real globalRepeatFactor = 5 "to indicate number of times a complete coverage map must be made"; parameter Real imagesPerStation = 4 "to account for mulitiple filters (ie, clear, and 3 colors) in the data rate"; parameter Integer propogateOrbit = 0 "0 means compute number of orbits as 360 degrees/footprint at equator, 1 means run matlab to propogate the orbit and lay down footprints"; parameter Real cruiseFTEDefault = 0.5 "Number of engineers to operate the spacecraft in cruise"; parameter Real encounterFTEDefault = 3 "Number of engineers to operate the spacecraft in encounter"; 126 Real samplePeriod; Real iFovX; Real dataRate "Instrument HK rate bps"; Real obsDataRate "science data rate bps"; Real dataPerOrbit "bits"; Real focalLength "m"; Real apertureDiameter "m"; Real fNumber; Real ratioFactor; Real ratioToSimilarPayload; Real numOrbits "Number of orbits to meet the coverage requirement based on resolution/fov"; Real obsDuration "months: num orbits for one map * period * globalRepeatFactor"; orbitalParameters orbit; function determine_coverage input Real mu; input Real rCb; input Real alt; input Real wbody; input Real sample_period; input Real reqd_area; input Real inst_fov; output Real numOrbits; external numOrbits = call_determine_coverage_c(mu, rCb, alt, wbody, sample_period, reqd_area, inst_fov) annotation(Library = "determine_coverage.o"); end determine_coverage; equation cruiseFTE = cruiseFTEDefault; encounterFTE = encounterFTEDefault; apertureDiameter = 2.44 * waveLength * focalLength * qualityFactor / detectorSizePerPixel; focalLength = orbit.altitude * detectorSizePerPixel / resolutionNadirX; fNumber = focalLength / apertureDiameter; iFovX = resolutionNadirX / orbit.altitude * 180 / const.pi; fovX = iFovX * numberOfPixelsX; orbit.fov = fovX; samplePeriod = resolutionNadirX * numberOfPixelsX / orbit.groundTrackVel; obsDataRate = numberOfPixelsX * numberOfPixelsX * bitsPerPixel * imagesPerStation / samplePeriod; dataPerOrbit = obsDataRate * orbit.period / 2 "Divide by 2 because only collecting on lit side"; dataRate = 100 "HK only"; ratioToSimilarPayload = apertureDiameter / apertureSimilarPayload; if propogateOrbit > 0 then numOrbits = determine_coverage(orbit.centralBody.gmBody, orbit.centralBody.radius, orbit.altitude, orbit.centralBody.spinPeriodBody, samplePeriod, requiredArea, fovX); else numOrbits = orbit.N; end if; if ratioToSimilarPayload < 0.5 then ratioFactor = 2; 127 else ratioFactor = 1; end if; mass = ratioFactor * ratioToSimilarPayload ^ 3 * massSimilarPayload; power = ratioFactor * ratioToSimilarPayload ^ 3 * powerSimilarPayload; cost = 328 * mass ^ 0.426 * power ^ 0.414 * designLife ^ 0.375 * 1000 "NICM"; obsDuration = numOrbits * orbit.period * globalRepeatFactor / (86400 * 30); end opticalPayloadSubsystem; class payloadSubsystem extends subsystem; end payloadSubsystem; class spacecraft import missionDesignPackage.transferOrbit; replaceable acsSubsystem ACS; replaceable cdhSubsystem CDH; replaceable fswSubsystem FSW; replaceable propSubsystem PROP; replaceable pwrSubsystem PWR; replaceable telSubsystem TEL; replaceable thermSubsystem THERM; replaceable opticalPayloadSubsystem PAY; replaceable transferOrbit TO; parameter Real cruiseFTESpacecraft = 7 "Number of staff beyond subsystems to operate the spacecraft in cruise"; parameter Real encounterFTESpacecraft = 12 "Number of staff beyond subsystems to operate the spacecraft in encounter"; Real scDryMass(start = 1200) "kg"; Real scWetMass(start = 5000) "kg"; Real scStructuralMass "kg, estimate is 15% of dry mass, pg 674 SME-SMAD"; Real scPower "W"; Real scDataRate "bps HK only"; Real scLinDim "m"; Real scVolume "m3"; Real scBodyArea "m2"; Real scBodyInertia "kgm2"; Real scInertiaX "kgm2"; Real scInertiaY "kgm2"; Real scInertiaZ "kgm2"; Real costBus "FY2010 dollars USCM8 Table 11-8 SME-SMAD"; Real costBusSimple "FY2010 dollars USCM8 Table 11-8 SME-SMAD"; Real costStructThermal "FY2010 dollars USCM8 Table 11-8 SME- SMAD"; Real costSC "FY2010 dollars USCM8 Table 11-8 SME-SMAD, NICM for Payload"; Real costSCSimple "FY2010 dollars USCM8 Table 11-8 SME-SMAD"; Real scDesignLife "years"; Real cruiseFTE "Number of staff to operate in cruise"; Real encounterFTE "Number of staff to operate in encounter"; equation scDryMass = ACS.mass + CDH.mass + FSW.mass + PAY.mass + PROP.mass + PWR.mass + TEL.mass + THERM.mass + scStructuralMass; 128 scWetMass = scDryMass + PROP.wetMass; scPower = ACS.power + CDH.power + FSW.power + PAY.power + PROP.power + PWR.power + TEL.power + THERM.power; scDataRate = ACS.dataRate + CDH.dataRate + FSW.dataRate + PAY.dataRate + PROP.dataRate + PWR.dataRate + TEL.dataRate + THERM.dataRate; /* Thermal as a function of s/c */ THERM.scWetMass = scWetMass; THERM.scPower = scPower; /* Structural as a function of s/c */ scStructuralMass = scDryMass * 0.15; /* Solar array as a function of s/c */ PWR.solarDistance = PAY.orbit.centralBody.solarDistance; PWR.scPower = scPower; PWR.scLinDim = scLinDim; PWR.scDesignLife = scDesignLife; PWR.epPwr = PROP.epPwrAtTarget; /* S/C dimensions */ scVolume = 0.01 * scWetMass "Table 10-28 SMAD"; scLinDim = 0.25 * scWetMass ^ (1 / 3) "Table 10-28 SMAD"; scBodyArea = scLinDim ^ 2 "Table 10-28 SMAD"; scBodyInertia = 0.01 * scWetMass ^ (5 / 3) "Table 10-28 SMAD"; scInertiaX = scBodyInertia + PWR.solarArrayInertiaPerpFace; scInertiaY = scBodyInertia + PWR.solarArrayInertiaAboutAxis; scInertiaZ = scBodyInertia + PWR.solarArrayInertiaPerpAxis; /* RWA/gravity gradient/prop sizing */ ACS.scInertiaX = scInertiaX; ACS.scInertiaY = scInertiaY; ACS.scInertiaZ = scInertiaZ; ACS.scLinDim = scLinDim; ACS.gmBody = PAY.orbit.centralBody.gmBody; ACS.radiusBody = PAY.orbit.centralBody.radius; ACS.altitude = PAY.orbit.altitude; ACS.orbitPeriod = PAY.orbit.period; ACS.thrusterForce = PROP.thrusterForce; ACS.numOrbits = PAY.numOrbits; ACS.globalRepeatFactor = PAY.globalRepeatFactor; ACS.transferDuration = TO.duration; ACS.Isp = PROP.Isp; ACS.transferType = TO.transferType; ACS.fixedHGA = TEL.fixedHGA; PROP.fuelMassDesats = ACS.fuelMassDesats; PROP.injectionDeltaV = TO.dV2; PROP.transferType = TO.transferType; PROP.scDryMass = scDryMass; /* Telecom Sizing */ TEL.scTotalDataRate = scDataRate + PAY.obsDataRate; TEL.solarDistance = PAY.orbit.centralBody.solarDistance; /* Staffing levels */ cruiseFTE = cruiseFTESpacecraft + ACS.cruiseFTE + CDH.cruiseFTE + FSW.cruiseFTE + PROP.cruiseFTE + PWR.cruiseFTE + TEL.cruiseFTE + THERM.cruiseFTE + PAY.cruiseFTE + TO.cruiseFTE; encounterFTE = encounterFTESpacecraft + ACS.encounterFTE + CDH.encounterFTE + FSW.encounterFTE + PROP.encounterFTE + PWR.encounterFTE + TEL.encounterFTE + THERM.encounterFTE + PAY.encounterFTE + TO.encounterFTE; /* SC Cost equations */ 129 costBusSimple = (110.2 * scWetMass + 289.5 * scWetMass ^ 0.716) * 1000; costStructThermal = (646 * (scStructuralMass + THERM.mass) ^ 0.684 + 22.6 * (scStructuralMass + THERM.mass)) * 1000; costBus = costStructThermal + ACS.cost + PWR.cost + PROP.cost + TEL.cost + FSW.cost; costSC = costBus + PAY.cost; costSCSimple = costBusSimple + PAY.cost; end spacecraft; end spacecraftPackage; package systemPackage class groundSystem parameter Real hwCost = 0.5e6 "arbitrary $500k equipment TBR"; parameter Real swCost = 1.0e6 "arbitrary $1M software TBR"; Real cost "total GDS cost"; equation cost = hwCost + swCost; end groundSystem; class missionOperations parameter Real opsFTE = 36 "using Table 11-25 SME-SMAD"; parameter Real cruiseFTEOverhead = 4 "Project management, Config management, mission assurance, etc"; parameter Real encounterFTEOverhead = 4 "Project management, Config management, mission assurance, etc"; parameter Real opsOverheadFactor = 1.1 "Add 10% to team size for additional leads and surpervision"; parameter Real opsCruiseComplexityFactor = 1 "Multiplier on cruise staffing based on simpler (<1) or more complex (>1)"; parameter Real opsEncounterComplexityFactor = 1 "Multiplier on encounter staffing based on simpler (<1) or more complex (>1)"; parameter Real devCost = 10e6 "arbitrary dev cost"; parameter Real FTECost = 200000 "$/year,FY2010 dollars Table 11-26 SME-SMAD"; Real cruiseFTE "Sum of FTEs to operate mission"; Real encounterFTE "Sum of FTEs to operation mission"; Real opsCruiseDuration "months"; Real opsEncounterDuration "months"; Real opsDuration "months"; Real costCruise "FY2010 dollars"; Real costEncounter "FY2010 dollars"; Real cost "FY2010 dollars"; equation costCruise = (cruiseFTE + cruiseFTEOverhead) * opsCruiseComplexityFactor * opsOverheadFactor * FTECost * opsCruiseDuration / 12; costEncounter = (encounterFTE + encounterFTEOverhead) * opsEncounterComplexityFactor * opsOverheadFactor * FTECost * opsEncounterDuration / 12; cost = devCost + costCruise + costEncounter; opsDuration = opsCruiseDuration + opsEncounterDuration; end missionOperations; class launchVehicle parameter Real upperStageMass = 2227 "2227 kg is total mass of Star-48B thirdstage"; Real cost "FY2010 dollors, Table 11-23 SME-SMAD"; 130 Real injectedMass "kg including 3rd stage"; Real payloadMass "kg s/c wet mass"; equation injectedMass = payloadMass + upperStageMass; /* if payloadMass < 1500 then (Delta II seems really expensive next to Falcon 9 - removing from mix */ /* cost = injectedMass * 41.7 * 1000 "Delta II, 2010"; the $k/k kg doesn't work so well. Need to use average flight cost */ /*cost = 74910000;*/ /*elseif injectedMass < 4540 then*/ if injectedMass < 4540 then /* cost = injectedMass * 12.5 * 1000 "Falcon 9, 2010"; */ cost = 56750000; elseif injectedMass < 8200 then /* cost = injectedMass * 25.3 * 1000 "Atlas 5, 2010"; */ cost = 172000000; elseif injectedMass < 13130 then /* cost = injectedMass * 16.4 * 1000 "Delta 4 Heavy, 2010"; */ cost = 215000000; else cost = 1e20 "No launch vehicle available to make cost enormous"; end if; end launchVehicle; class completeSystem import spacecraftInstance.*; replaceable groundSystem GS; replaceable missionOperations MO; replaceable launchVehicle LV; replaceable spacecraftInstance SC; parameter Real designLifeMargin = 0.25; Real systemCost; equation systemCost = GS.cost + LV.cost + MO.cost + SC.costSC; LV.payloadMass = SC.scWetMass; MO.opsCruiseDuration = SC.TO.duration; MO.opsEncounterDuration = SC.PAY.obsDuration * SC.TEL.desiredDownlinkRate / SC.TEL.downlinkRate "scale time it takes by ratio of downlink performance"; MO.cruiseFTE = SC.cruiseFTE; MO.encounterFTE = SC.encounterFTE; SC.scDesignLife = (MO.opsCruiseDuration + MO.opsEncounterDuration) * (1 + designLifeMargin) / 12 "/12 to convert to years"; end completeSystem; end systemPackage; 8.1.4 Example Instances For the modeling/simulation to function, there are two additional files that contain the specific parameter modifications for each instance. The first is the spacecraft instance, which 131 contains the specific subsystem and spacecraft level parameter selection. The second is the system instance, which defines the parameter modifications for the classes in the System Package. These two files are generate by a Perl script. model spacecraftInstance import spacecraftPackage.*; import missionDesignPackage.*; extends spacecraft(redeclare opticalPayloadSubsystem PAY(detectorSizePerPixel = 1.4e-05, fovX = 5.5, resolutionNadirX = 20), redeclare propSubsystem PROP(blowdownSystem = 1), redeclare pwrSubsystem PWR(solarCellType = 3), redeclare telSubsystem TEL(fixedHGA = 1, maxAntDiaSC = 1.52), redeclare transferOrbit TO(durationFixed = 60, transferType = 3)); end spacecraftInstance; model systemInstance import systemPackage.*; extends systemPackage.completeSystem(redeclare missionOperations MO(opsCruiseComplexityFactor = 2, opsEncounterComplexityFactor = 2)); end systemInstance; 8.1.5 C-‐code to interface between Modelica and Matlab This section of code was written in C after finding an example on the Mathworks web sites. This piece of code accepts function inputs from the Modelica function call and opens a file that it maintains that includes the input parameters and the number of orbits returned from Matlab to determine if this particular set of inputs has already been evaluated. If it finds them, then it pull the number of orbits from the file and returns it to the calling Modelica function. If not, then it sets up the parameter pass to Matlab and executes the Matlab function, receives the result and logs the inputs and output in the file, and returns the number of orbits to Modelica. // #include <stdlib.h> #include <stdio.h> #include <string.h> #include "engine.h" #define BUFSIZE 256 int match_params (double x, double y) { double eps = 1e-6; int match = 0; 132 //printf("x: %f, y: %f\n",x,y); if ((x <= (y + eps)) && (x >= (y - eps))) { match = 1; //printf ("x: %f, y: %f MATCH\n",x,y); } return match; } double call_determine_coverage_c(double mu, double rCb, double alt, double wbody, double sample_period, double reqd_area, double inst_fov) { Engine *ep; mxArray *T = NULL, *result = NULL; double *num_orbits; double file_num_orbits; char buffer[1024] ; char *record,*line; float instanceNumber; FILE *fstream = fopen("currentInstance.txt","r"); if(fstream == NULL) { printf("\n file opening failed "); return -1 ; } fscanf(fstream, "%f", &instanceNumber); fclose(fstream); printf("Out of while: %f;\n",instanceNumber); int i=0,j=0,lines=0,items=0; double cases[10000][100]; FILE *fp = fopen("coverage_cases.csv","r"); if(fp == NULL) { printf("\n file opening failed "); return -1 ; } while((line=fgets(buffer,sizeof(buffer),fp))!=NULL) { j = 0; record = strtok(line,","); //printf("First record: %s\n",record); while(record != NULL) { //printf("record : %s",record) ; cases[i][j++] = atof(record) ; record = strtok(NULL,","); } ++i ; } fclose(fp); lines = i; items = j; 133 int match = 0; for (i = 0; i < lines; i++) { if (match_params( mu,cases[i][0]) && match_params( rCb,cases[i][1]) && match_params( alt,cases[i][2]) && match_params( wbody,cases[i][3]) && match_params(sample_period,cases[i][4]) && match_params( reqd_area,cases[i][5]) && match_params( inst_fov,cases[i][6])) { file_num_orbits = cases[i][7]; printf("Found case in file, num orbits is %f\n",cases[i][7]); match = 1; return file_num_orbits; //printf("Found case in file, num orbits is: %f\n",*num_orbits); } } if (match == 0) { printf("Call matlab!\n"); /* * Call engOpen with a NULL string. This starts a MATLAB process * on the current host using the command "matlab". */ if (!(ep = engOpen(""))) { fprintf(stderr, "\nCan't start MATLAB engine\n"); return EXIT_FAILURE; } double data[8] = { mu, rCb, alt, wbody, sample_period, reqd_area, inst_fov, instanceNumber}; /* * Create a variable for the data */ T = mxCreateDoubleMatrix(1, 8, mxREAL); memcpy((void *)mxGetPr(T), (void *)data, sizeof(data)); /* * Place the variable T into the MATLAB workspace */ engPutVariable(ep, "T", T); /* * Evaluate a function of time, distance = (1/2)g.*t.^2 * (g is the acceleration due to gravity) */ engEvalString(ep, "num_orbits = determine_coverage_function(T(1),T(2),T(3),T(4),T(5),T(6),T(7),T(8))"); result = engGetVariable(ep,"num_orbits"); num_orbits = mxGetPr(result); printf("num_orbits: %f\n",*num_orbits); //printf("num_orbits is class %s\t\n", mxGetClassName(result)); //printf("Done for Part I.\n"); mxDestroyArray(T); engEvalString(ep, "close;"); engClose(ep); 134 fstream = fopen("coverage_cases.csv","a"); //fprintf(fstream,"%.2f,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f\n", fprintf(fstream,"%f,%f,%f,%f,%f,%f,%f,%f,%f\n", mu, rCb, alt, wbody, sample_period, reqd_area, inst_fov, *num_orbits,instanceNumber); fclose(fstream); printf ("Used matlab, num orbits is: %f\n",*num_orbits); } return *num_orbits; } /* int main () */ /* { */ /* double orbits; */ /* orbits = call_determine_coverage_c(1.75e10,285000,117341.8,19231.2,69.3,60.0,5.0 ); */ /* printf("num_orbits: %f\n",orbits); */ /* return 1; */ /* } */ 8.1.6 Matlab Orbit Propagation and Footprint Visualization This next section of code is the code that was developed to propagate the orbit and project image footprints on the surface to evaluate the coverage. The code uses a numerical integrator written for ASTE-580. function num_orbits = determine_coverage_function(... mu_in,Rcb_in,alt_in,wbody_in,sample_period_in,reqd_area_in,... inst_fov_in,instance_number) % determine_coverage.m % % Author: T. Weise % % % Description: % This program will take as input: % orbit altitude in km % body radius in km % body GM in km^3/s^2 % body spin rate in deg/sec % sample period in seconds % coverage requirement, in percent % instrument angular field of view, in degrees % path to save plots 135 % % The outputs are: % number of orbits to meet coverage requirement % flag if requirement was met % % % It will assume eccentricity of 0, and inclination of 90 deg. % With those starting parameters, it will then start with the the % spacecraft above the equator at 0 deg lat/long (corresponding % to (r, 0, 0 BCI), traveling toward the north pole (+Z) at circular % orbit velocity. It will then compute the position at the input % sample period. Based on the is position, it will compute the location % of the subsatellite point in lat/lon, compute an instrument FOV % footprint, and increment each element of the graticule that is in the % image footprint area. This is repeated at every sample period for one % orbit. The area coverage requirement is checked, and if not met, % another orbit is executed. As the surface is mapped, each additional % orbit will add a smaller and smaller amount of covered area, but much % of the already covered area will get repeat imaging. If the incremental % area does not exceed a limit (0.1 %) or the coverage requirement is % met, the script will stop propagating and report the achieved coverage % and number of orbits to achieve that coverage. % Load inputs from input file. format compact; %infile = load ('input.txt'); %central_body = infile(1); %Paramagic doesn't like passing strings mu = mu_in / 1e9 %398600.433; Rcb = Rcb_in / 1000 %6378.14; %MagicDraw model uses m instead of km altitude = alt_in / 1000 %800; Rsc = Rcb + altitude wbody = 360/wbody_in %0.00417807; %input parameter is spin period sec sample_period = sample_period_in %150; reqd_area = reqd_area_in %5; inst_fov = inst_fov_in %5; inc = 90; %plot_path = ... % '/Users/tmweise/Documents/USC/SysML-UML/MyMagicDrawProjects/ssap- 5/plots/'; plot_path = './'; title_addon = strcat('FOV = ',num2str(inst_fov),' deg, area = ',... num2str(reqd_area),' %, altitude = ',num2str(altitude),' km'); instance_name = strcat('Instance',num2str(instance_number,'%05d')); % Define variables eps = 1e-07; % used in if statements to account for floating point numbers d2r = pi/180; % used to convert degrees to radians r2d = 180/pi; % used to convert radians to degrees tol = 1e-7; % used to solve Kepler's equation r0 = [ Rsc ; 0.0; 0.0]; Vcircular = sqrt(mu/Rsc); v0 = [ 0.0; -Vcircular * sind(inc-90); Vcircular * cosd(inc-90)]; 136 r0_mag = norm(r0); v0_mag = norm(v0); e_vector = (1/mu)*((v0_mag^2 - mu/r0_mag)*r0 - (dot(r0,v0)*v0)); e = norm(e_vector); % Section 2.2 Determine generic orbit parameters % compute momentum vector h = r cross v and momentum magnitude % h = momentum vector, km^2/s % h_mag = momentum magnitude, km^2/s h = cross(r0,v0); h_mag = norm(h); % compute parameter, p, km p = h_mag^2/mu; % compute the Energy, km^2/s^2 Energy = v0_mag^2/2 - (mu/r0_mag); % compute e1, based on Energy e1 = sqrt(1+2*p*Energy/mu); % compute true anomaly, theta, degrees % TBD - what about e = 0??? theta = acosd(((p/r0_mag) - 1)/e); % inclination, i, degrees % h_hat - momentum vector, unitized h_hat = h/h_mag; i = acosd(h_hat(3)); % SHOULD BE 90 deg % Right ascension of the ascending node, OMEGA, degrees % K_hat = [0;0;1] unit vector % N_hat = unit vector along line of nodes K_hat = [0;0;1]; N_hat = (cross(K_hat,h_hat))/(norm(cross(K_hat,h_hat))); OMEGA = acosd(N_hat(1)); % adjust for quadrants if (N_hat(2) < 0) OMEGA = 360 - OMEGA; end lomega = acosd((dot(e_vector,N_hat))/e); if e_vector(3) < 0 137 lomega = 360 - lomega; end % Section 2.3 Compute elliptical orbit parameters % a, semi-major axis, km a = p/(1-e^2); % Ra, apoapse radius, km Ra = p/(1-e); % Rp, periapse radius, km Rp = p/(1+e); % Orbit period, Tau, hours Tau = 2*pi*sqrt((a^3)/mu) / 3600; % Section 4. Propagate orbit forward in time alpha0 = (2/r0_mag) - (v0_mag^2/mu); samplesperorbit = ceil(Tau * 3600 / sample_period); %number of samples to propagate time_stamp = 0; k = 0; %image station index % determine angular size of FOV on surface fp_approx = (atand((altitude/Rcb)*tand(inst_fov/2)))*2; elev = acosd(sind(inst_fov/2)/(Rcb/(Rcb + altitude))); fp = (90-elev-inst_fov/2)*2; %fov = 6; % setup graticule for counting images covering the surface [gratlat,gratlon] = meshgrat([-90 90],[-180 180],[1000 2000]); numgrat = size(gratlat,1) * size(gratlon,2); image_count = zeros(size(gratlat)); prev_area = 0; curr_area = 0; diff_area = 1; threshold = 0.001; sun_unit_vector = [0.7071;-0.7071;0]; %45 deg beta angle j = 0; figure(1) axesm ('craster', 'Frame', 'on', 'Grid', 'on','MeridianLabel',... 'on','ParallelLabel','on')%,'MapLatLimit',[-60 60]); title(strcat('Image footprints ',title_addon)); tightmap plot_colors = ['b' 'g' 'r' 'c' 'm' 'y' 'k']; while ((curr_area < reqd_area) && (diff_area > threshold)) j = j + 1; color_index = mod(j,7); if color_index == 0 color_index = 1; end for i = 1:samplesperorbit time_stamp = time_stamp + sample_period; 138 k = k + 1; x_p = sqrt(mu)*time_stamp/Rp; % upper bound on initial x %compute initial value for x_n based on eqn 2.46 in Prussing and Conway x_n = (mu * time_stamp^2)/(Rp*(F(x_p,r0,v0,mu,alpha0,time_stamp) ... + sqrt(mu)*time_stamp)); x_np1 = 0; delta = 100; % initial value to start loop step_count = 0; while delta > tol x_np1 = x_n - (F(x_n,r0,v0,mu,alpha0,time_stamp)) / ... (dF(x_n,r0,v0,mu,alpha0)); delta = abs(x_np1 - x_n); x_n = x_np1; step_count = step_count + 1; end; x = x_n; r_step = (1 - (x^2/r0_mag)*C(alpha0*x^2))*r0 + ... (time_stamp - (x^3/sqrt(mu))*S(alpha0*x^2))*v0; v_step = (sqrt(mu)/(norm(r_step)*r0_mag)) * ... (alpha0*x^3*S(alpha0*x^2)-x) * r0 + ... (1 - (x^2/norm(r_step))*C(alpha0*x^2))*v0; % Compute dot product of radius vector with sun vector - if % it's positive, then on sunny side. Only compute images on sunny % side. sun_dir = dot(sun_unit_vector,r_step/norm(r_step)); if sun_dir > 0 % Now compute the lat/lon of the ssp. Assumes that orbit starts at % (0,0). Use the x,y,z position in intertial coordinates, then % rotate s/c position about z axis by body spin rate * time_stamp. % Then compute lat/lon from lat = asin(z) and lon = atan2(y/x) gamma = wbody*time_stamp; DCMbci2bcr = [cosd(gamma) sind(gamma) 0;... -sind(gamma) cosd(gamma) 0;... 0 0 1]; % is ZYX r_body = DCMbci2bcr * r_step; r_body = r_body / norm(r_body); ssp(k).lat = asind(r_body(3)); ssp(k).lon = atan2d(r_body(2),r_body(1)); [latsc,lonsc] = scircle1(ssp(k).lat,ssp(k).lon,fp/2); %makes a footprint circle ssp(k).smallcircle.lat = latsc; ssp(k).smallcircle.lon = lonsc; %plotm(ssp(i).smallcircle.lat,ssp(i).smallcircle.lon) [ssp(k).geoquad.latlim, ssp(k).geoquad.lonlim] = ... geoquadline(ssp(k).smallcircle.lat,ssp(k).smallcircle.lon); [ssp(k).geoquad.ollat, ssp(k).geoquad.ollon] = ... 139 outlinegeoquad(ssp(k).geoquad.latlim,ssp(k).geoquad.lonlim,1,1); plotm(ssp(k).geoquad.ollat,ssp(k).geoquad.ollon,... plot_colors(color_index)); % the next step is to go through the lat/lon graticule and % increment the image counter for each cell that is in the image % footprint defined by the geoquad outline. This will also require % keeping track of the graticule's that are counted per image to % make sure that going through each point in the geoquad doesn't % duplicate counts % to ensure no aliasing between size of image and graticule size, % find all graticule indices between the limits of the quadrangle % and mark all of them imaged % the indices below are the graticule indices just outside the % image footprint. Need to loop through each (lat/lon) for low+1 to % high-1. Check if this location already captured by this image, % otherwise increment counter [row,~] = find(gratlat <= ssp(k).geoquad.latlim(1)); latlowindex = max(row); [row,~] = find(gratlat >= ssp(k).geoquad.latlim(2)); lathighindex = min(row); [~,col] = find(gratlon <= ssp(k).geoquad.lonlim(1)); lonlowindex = max(col); [~,col] = find(gratlon >= ssp(k).geoquad.lonlim(2)); lonhighindex = min(col); for latindex = (latlowindex+1):(lathighindex-1) for lonindex = (lonlowindex+1):(lonhighindex-1) image_count(latindex,lonindex) = ... image_count(latindex,lonindex) + 1; end end end end [countzero,~] = find(image_count == 0); [countatleast1,~] = find(image_count >= 1); imaged = size(countatleast1,1); notimaged = size(countzero,1); percentimaged = imaged/numgrat * 100; percentnotimg = notimaged/numgrat * 100; curr_area = percentimaged diff_area = curr_area - prev_area prev_area = curr_area; area(j) = curr_area; diff(j) = diff_area; end for n = 1:8 % just plotting upto 8 images of surface [count,~] = find(image_count >= n); imaged(n) = size(count,1); end prcntimgd = imaged/numgrat * 100; 140 %save('output.txt','j','-ASCII'); %j is number of orbits if (curr_area >= reqd_area) rqmt_met = 1; else rqmt_met = 0; j = 999; % make j (num orbits) crazy high to show issue end coverage_eff = (1 - prcntimgd(2)/prcntimgd(1))*100; otheroutputs = [curr_area; rqmt_met; mu; Rcb; altitude; wbody; sample_period; reqd_area; inst_fov; j; coverage_eff]; fileprefix = instance_name; save(strcat(plot_path,fileprefix,'-info','.txt'),'otheroutputs','-ASCII'); fid = fopen(strcat(instance_name,'-info.txt'),'w'); fprintf(fid,'Current Area: %6.2f\n',curr_area); fprintf(fid,'Requiremnt Met: %6.2f\n',rqmt_met); fprintf(fid,'Mu (km3/s2): %6.2f\n',mu); fprintf(fid,'Radiuscb (km): %6.2f\n',Rcb); fprintf(fid,'Altitude (km): %6.2f\n',altitude); fprintf(fid,'Spin Rate (d/s): %6.2f\n',wbody); fprintf(fid,'Sample Per (s): %6.2f\n',sample_period); fprintf(fid,'Reqd Area (prcnt): %6.2f\n',reqd_area); fprintf(fid,'Inst FOV (deg): %6.2f\n',inst_fov); fprintf(fid,'Number of orbits: %6.2f\n',j); fprintf(fid,'Coverage eff: %6.2f\n',coverage_eff); fclose(fid); saveas(figure(1),... strcat(plot_path,fileprefix,'-Footprints'),'jpg'); figure(2) axesm ('craster', 'Frame', 'on', 'Grid', 'on','MeridianLabel',... 'on','ParallelLabel','on')%,'MapLatLimit',[-60 60]); tightmap; title (strcat('Number of images per location on surface ',title_addon)); surfacem(gratlat,gratlon,image_count); mycolormap = [ 1,1,1; 0,0,1; 0,1,1; 0,1,0; 1,1,0; 1,0,1; 1,0,0; 0,0,0]; colormap(mycolormap); 141 caxis([0 8]); %this will work with the color map to have 8 different colors colorbar('YTickLabel',{strcat('0 - ',num2str(percentnotimg,'%5.1f'),'%'),... strcat('>= 1 - ',num2str(prcntimgd(1),'%5.1f'),'%'),... strcat('>= 2 - ',num2str(prcntimgd(2),'%5.1f'),'%'),... strcat('>= 3 - ',num2str(prcntimgd(3),'%5.1f'),'%'),... strcat('>= 4 - ',num2str(prcntimgd(4),'%5.1f'),'%'),... strcat('>= 5 - ',num2str(prcntimgd(5),'%5.1f'),'%'),... strcat('>= 6 - ',num2str(prcntimgd(6),'%5.1f'),'%'),... strcat('>= 7 - ',num2str(prcntimgd(7),'%5.1f'),'%'),... strcat('>= 8 - ',num2str(prcntimgd(8),'%5.1f'),'%')}); saveas(figure(2),... strcat(plot_path,fileprefix,'-Coverage_Map'),'jpg'); figure(3); subplot(2,1,1); plot(area); title(strcat('Cummulative area imaged ',title_addon)); ylabel('Percent covered'); xlabel('Orbit number'); subplot(2,1,2); plot(diff); title('Additional area imaged each orbit'); ylabel('Additional percent covered'); xlabel('Orbit number'); saveas(figure(3),... strcat(plot_path,fileprefix,'-Area_per_Orbit'),'jpg'); close all; num_orbits = j; function y = F(x, r0, v0, mu, alpha0, dt) % Universal equation... % % Author: T. Weise % y = (dot(r0,v0)/sqrt(mu))*x^2*C(alpha0*x^2) + ... (1 - norm(r0)*alpha0)*x^3*S(alpha0*x^2) + norm(r0)*x - dt*sqrt(mu); function y = dF(x, r0, v0, mu, alpha0) % First derivative of Universal equation... % % Author: T. Weise % y = (dot(r0,v0)/sqrt(mu))*(x - alpha0*x^3*S(alpha0*x^2)) + ... (1 - norm(r0)*alpha0)*x^2*C(alpha0*x^2) + norm(r0); 142 8.2 Perl Code Two routines were written in Perl to manage the parametric studies. The first reads a CSV file of the list of parameters and their values to combine. The second merges the results from each instance into a single merged output file. buildInstances.pl: #!/usr/bin/perl -w use strict; use Cwd 'abs_path'; my $progName = abs_path($0); my $progVer = "v1.0"; { my $instance = "NA"; my $paramFile = "NA"; my $planetaryBody = "Vesta"; my $arg; if ($#ARGV < 0) { print "\nbuildInstances.pl -file <paramfile.csv> -body <bodyname>\n"; print "\nwhere body name matches the name in the planetary body \n"; print "record file name, for example -body Vesta gives: " . "planetaryBody-Vesta.mo\n"; exit; } while (@ARGV) { $arg = shift(@ARGV); if ($arg eq '-file') { $paramFile = shift(@ARGV); } elsif ($arg eq '-body') { $planetaryBody = shift(@ARGV); } } if ($paramFile eq "") { print "Must enter parameter csv file with -file <name>\n"; exit; } ($instance, my $junk) = split(/\./,$paramFile); $instance =~ s/Parametrics//g; print "$instance\n"; if (!-e $instance) {mkdir $instance;} if (!-e $instance."/outputs") {mkdir $instance."/outputs";} if (!-e $instance."/instances") {mkdir $instance."/instances";} 143 sub mix #Algorithm found on www.perlmonks.org 'Re: Generating all possible # combinations from an AoA' posted by JavaFan on 4/13/2011 {@_ ? map {my $x = $_; map "$x,$_", mix(@_[1..$#_])} @{$_[0]} : ""} # # Define which parameters are being studied # my %parameterTable = ('PAY' => # {'resolutionNadirX' => [10, 20, 30, 40, 50], # 'fovX' => [5, 10, 15, 20], # 'requiredArea' => [60, 70, 80, 90]}, # 'TEL' => # {'transmitterPower' => [50, 100, 200], # 'downlinkRate' => [1000, 2000, 10000, 100000]}); open (PARAMS, "$paramFile") or die "Couldn't open $paramFile: $!\n"; my %parameterTable; {local $/ = "\r"; while (<PARAMS>) { my $line = $_; chomp($line); my $fullName; my $subSystem; my $parameter; my @tmpNames; my @varValues; (my @fields) = split(",",$line); $fullName = shift(@fields); #print "Before:",join (",",@fields),"\n"; @tmpNames = split(/\./,$fullName); if ($fullName =~ "SC") { $subSystem = "$tmpNames[0]"."."."$tmpNames[1]"; $parameter = $tmpNames[-1]; } else { $subSystem = $tmpNames[0]; $parameter = $tmpNames[1]; } while (($fields[-1] =~ /^\s+/) || ($fields[-1] eq "")) { #print "TRUE\n"; pop(@fields); } @varValues = map {$_ + 0} @fields; #print join(",",@varValues),"\n"; $parameterTable{$subSystem}{$parameter} = [@varValues]; } } close PARAMS; my @subsystemList = sort keys %parameterTable; my @parameterList; my @valueArray; foreach my $sub (@subsystemList) { print "Sub: $sub\n"; foreach my $param (sort keys %{$parameterTable{$sub}}) { my $tmp = $sub.":".$param; 144 print "tmp: $tmp\n"; push(@parameterList, $tmp); #print "parametertable @{$parameterTable{$sub}{$param}}\n"; my @tmparray = $parameterTable{$sub}{$param}; #print "tmparray: ",join(";",@tmparray),"\n"; push(@valueArray, @tmparray); #print "valueArray: ",join(":",@valueArray),"\n"; } } print "These parameters are being studied: @parameterList\n"; my @combinationArray; push (@combinationArray, mix @valueArray); #This builds combinations my $listSize = scalar @combinationArray; map (chop, @combinationArray); # Removes trailing comma #print join("\n",@combinationArray),"\n"; print "There are $listSize combinations!\n"; my %subsystemMap = ('SC.PAY' => 'opticalPayloadSubsystem', 'SC.TEL' => 'telSubsystem', 'SC.PROP' => 'propSubsystem', 'SC.PWR' => 'pwrSubsystem', 'SC.TO' => 'transferOrbit', 'SC.ACS' => 'acsSubsystem', 'SC.CDH' => 'cdhSubsystem', 'SC.FSW' => 'fswSubsystem', 'SC.THERM'=> 'thermSubsystem', 'SC.PAY2' => 'genericPayloadSubsystem'); my %systemMap = ('GS' => 'groundSystem', 'MO' => 'missionOperations', 'LV' => 'launchVehicle', 'SC' => 'spacecraftInstance'); #OMShell seems to have a memory leak, so break up the .mos scritp # into parts running no more than 50 instances # Open config file to store the Instance name, modified parameters names and # values my $configName = "$instance".".Instance.config.csv"; open (CONFIG, ">$instance/$configName") or die "Couldn't open $configName for write: $!\n"; #Print header row print CONFIG "InstanceName,"; my @tmpList = @parameterList; map (s/\:/\./g,@tmpList); #for my $i (0 .. $#tmpList) { # $tmpList[$i] = "SC."."$tmpList[$i]"; #} print CONFIG join(",",@tmpList),"\n"; my $shellScriptName = "$instance".".sh"; open (SHELL, ">$instance/$shellScriptName") or die "Couldn't open $shellScriptName: !$\n"; 145 my $partNum = 0; my $startInstance = 0; my $endInstance = -1; my $batchSize = 50; do { $startInstance = $endInstance + 1; $endInstance = $startInstance + $batchSize - 1; if ($endInstance > ($listSize - 1)) { $endInstance = $listSize - 1; } $partNum = $partNum + 1; # #Build begining of modelica script my $scriptName = "$instance.$partNum.modelSystem.mos"; my $omShellScriptName = "$instance.$partNum.omshell"; open (SCRIPT, ">$instance/$scriptName") or die "Couldn't open $scriptName for write: $!\n"; open (OMSHELL, ">$instance/$omShellScriptName") or die "Couldn't open $omShellScriptName: !$\n"; print OMSHELL "runScript (\"/Users/tmweise/Documents/USC/PHD/modelica/" . "spaceSystemEstimation/$instance/$scriptName\")\n"; print OMSHELL "quit()\n"; close OMSHELL; print SHELL "OMShell-terminal < $omShellScriptName\n"; print SCRIPT "cd(\"/Users/tmweise/Documents/USC/PHD/modelica/spaceSystemEstimation/" . "working/\");\r\n"; print SCRIPT "loadFile(\"../planetaryBody- $planetaryBody.mo\");\r\n"; print SCRIPT "loadFile(\"../missionDesignPackage.mo\");\r\n"; print SCRIPT "loadFile(\"../spacecraftPackage.mo\");\r\n"; print SCRIPT "loadFile(\"/opt/local/lib/omlibrary/Modelica 3.2.1/package.mo\");\r\n"; # Loop through every parameter to make unique instance .mo, and add to # omshell script. # also log instance name and parameters in master file for my $i ($startInstance .. $endInstance) { my $num = $i + 1; my $scInstanceFilename = sprintf("Instance%05d",$num); print CONFIG "$scInstanceFilename"; my @localValues = split(',',$combinationArray[$i]); open (MODELSC, ">$instance/instances/$scInstanceFilename.SC.mo") or die "Couldn't open $scInstanceFilename.mo for write: $!\n"; open (MODELSYS, ">$instance/instances/$scInstanceFilename.SYS.mo") or die "Couldn't open $scInstanceFilename.mo for write: $!\n"; printf MODELSC "model spacecraftInstance\n"; printf MODELSC " import spacecraftPackage.*;\n"; printf MODELSC " import missionDesignPackage.*;\n"; 146 printf MODELSC " extends spacecraft(redeclare "; printf MODELSYS "model systemInstance\n"; printf MODELSYS " import systemPackage.*;\n"; printf MODELSYS " extends systemPackage.completeSystem(redeclare "; # Now loop through the subsystems and parameters my $prevLocalSubsystem = "NA"; my $prevLocalSystem = "NA"; my $localSubsystem = "NA"; my $localParameter = "NA"; my $localSubNameToPrint = "NA"; for my $j (0 .. $#localValues) { ($localSubsystem, $localParameter) = split(/\:/,$parameterList[$j]); #print "$parameterList[$j], $localSubsystem, $localParameter\n"; if ($localSubsystem =~ "SC") { #spacecraft model $localSubNameToPrint = $localSubsystem; $localSubNameToPrint =~ s/SC.//g; #print "$parameterList[$j], $localSubsystem, $localParameter\n"; if ($prevLocalSubsystem eq "NA") { printf MODELSC ("$subsystemMap{$localSubsystem} $localSubNameToPrint("); printf MODELSC ("$localParameter = %g", $localValues[$j]); } elsif ($localSubsystem eq $prevLocalSubsystem) { printf MODELSC (", $localParameter = %g", $localValues[$j]); } else { printf MODELSC ("), redeclare $subsystemMap{$localSubsystem} " . "$localSubNameToPrint("); printf MODELSC ("$localParameter = %g", $localValues[$j]); } $prevLocalSubsystem = $localSubsystem; } else { #system model if ($prevLocalSystem eq "NA") { printf MODELSYS ("$systemMap{$localSubsystem} $localSubsystem("); printf MODELSYS ("$localParameter = %g", $localValues[$j]); } elsif ($localSubsystem eq $prevLocalSystem) { printf MODELSYS (", $localParameter = %g", $localValues[$j]); } else { printf MODELSYS ("), redeclare $systemMap{$localSubsystem} " . "$localSubsystem("); printf MODELSYS ("$localParameter = %g", $localValues[$j]); } $prevLocalSystem = $localSubsystem; } 147 print CONFIG ",$localValues[$j]"; } print CONFIG "\n"; printf MODELSC ("));\n"); printf MODELSC ("end spacecraftInstance;\n"); close MODELSC; printf MODELSYS ("));\n"); printf MODELSYS ("end systemInstance;\n"); close MODELSYS; print SCRIPT "loadFile(\"../$instance/instances/$scInstanceFilename.SC.mo\");\ r\n"; print SCRIPT "loadFile(\"../systemPackage.mo\");\r\n"; print SCRIPT "loadFile(\"../$instance/instances/$scInstanceFilename.SYS.mo\"); \r\n"; print SCRIPT "system(\"echo $num > currentInstance.txt\");\r\n"; print SCRIPT "simulate(systemInstance, " . "startTime=0, stopTime=1, numberOfIntervals=1, " . "tolerance=1e-4, method=\"dassl\", outputFormat=\"csv\");\r\n"; print SCRIPT "system(\"mv systemInstance_res.csv " . "../$instance/outputs/$scInstanceFilename.results.csv\");\r\n"; print SCRIPT "system(\"mv $scInstanceFilename* " . "../$instance/outputs/.\");\r\n"; } close SCRIPT; } until ($endInstance == ($listSize - 1)); close SHELL; close CONFIG; } mergeParamsResults.pl: #!/usr/bin/perl -w use strict; use Cwd 'abs_path'; my $progName = abs_path($0); my $progVer = "v1.0"; { my $script = "NA"; my $arg = ""; my $paramFile = "defaultParameterFile.csv"; my $path; my $instance = "NA"; my $instanceConfig; my @moFileArray; my %moFileHash; if ($#ARGV < 0) { 148 print "\n mergeParamsResults.pl -script <script.mos> [-name <casename>\n"; print "\n where script.mos is the first omshell script to model "; print "the system, like dawnLike.1.modelSystem.mos\n and casename is optional\n\n"; exit; } while (@ARGV) { $arg = shift(@ARGV); if ($arg eq '-script') { $script = shift(@ARGV); } elsif ($arg eq '-name') { $instance = shift(@ARGV); } } if ($script =~ /NA/) { print "Must enter name of OMShell script, like -script modelSystem.mos\n"; exit; } if ($instance eq "NA") { ($instance, my @junk) = split(/\./,$script); } $instanceConfig = "$instance.Instance.config.csv"; print "Reading $script\n"; open(IN, "$script") or die "Couldn't open $script: $!"; open(OUT, ">$paramFile") or die "Couldn't open $paramFile for write: $!"; #First get the .mo files from the script while(<IN>) { my $line = $_; my $junk; my $file; chomp($line); if ($line =~ /^cd\(/) { ($junk,$path,$junk) = split("\"",$line); } elsif ($line =~ /loadFile/) { if (!($line =~ /Modelica 3.2.1/) && !($line =~ /Instance/)) { ($junk,$file,$junk) = split("\"",$line); $moFileHash{$path.$file} = 1; push (@moFileArray, $path.$file); } } } close IN; my %parameterTable; # Subsystem => ParamName => value my %classInstances; my %parameterList; # Subsystem.ParamName => value # hardcode the spacecraft => SC entry because the spacecraftInstance maps # to spacecraft and is more complicated to capture. $classInstances{"spacecraft"} = "SC"; foreach my $file (sort keys %moFileHash) { open(MO, "$file") or die "Couldn't open $file: $!"; print "Processng file $file\n"; 149 my $line; my $type; my $class = "NA"; while (<MO>) { $line = $_; chop $line; $line =~ s/^\s+//g; #trim leading/trailing whitespace #print "$line\n"; if ($line =~ /^class / || $line =~ /^record/) { ($type, $class) = split(/\s+/,$line); } if ($line =~ "end $class") { #end of class def $class = "NA"; } if ($line =~ /^parameter /) { # parse line to get value if (($line =~ /Real/) || ($line =~ /Integer/)) { (my $before, my $after) = split("=",$line); my @junk = split(/\s+/,$before); my $paramName = $junk[-1]; (my $paramValue, @junk) = split("\"",$after); $paramValue =~ s/\s+//g; $paramValue =~ s/\;//g; #print "$class"."."."$paramName=$paramValue\n"; $parameterTable{$class}{$paramName} = $paramValue; } } if (($class =~ /spacecraft/) || ($class =~ /completeSystem/) || ($class =~ /orbitalParameters/)){# || #($class =~ /payloadSubsystem/)) { if (!($line =~ /class /)) { $line =~ s/\;//g; # remove trailing ; $line =~ s/replaceable //g; # remove the word replaceable (my $classType, my $className) = split(/\s+/, $line); #print "$classType, $className\n"; if (defined $parameterTable{$classType}) { if ($class =~ /spacecraft/) { $className = "SC.".$className; } elsif ($class =~ /orbitalParameters/) { $className = "SC.PAY.orbit.".$className; } $classInstances{$classType} = $className; #print "$classType, $className\n"; } } } } close MO; } foreach my $item (sort keys %classInstances) { foreach my $var (sort keys %{$parameterTable{$item}}) { print OUT "$classInstances{$item}"."."."$var,"; my $tmp = "$classInstances{$item}"."."."$var"; $parameterList{$tmp} = $parameterTable{$item}{$var}; } 150 } print OUT "\n"; foreach my $item (sort keys %classInstances) { foreach my $var (sort keys %{$parameterTable{$item}}) { print OUT "$parameterTable{$item}{$var},"; } } my $mergedResults = "$instance.merged.csv"; open (MERGED, ">$mergedResults") or die "Couldn't open $mergedResults: $!\n"; my $wroteFirstLine = 0; # Now read instance config file to get list of instances and parameters # Use this info to combine with the results.csv open (CONFIG, "$instance.Instance.config.csv") or die "Couldn't open $instance.Instance.config.csv: $!\n"; my $line = <CONFIG>; # get the first line to get the names chomp ($line); my @instanceParams = split(/,/,$line); my %instanceParamHash; for my $i (0 .. $#instanceParams) { $instanceParamHash{$instanceParams[$i]} = $i; } while (<CONFIG>) { #first line already read, new lines should be of the form: #instancenumber,value,value,value... $line = $_; chomp ($line); my @instanceValues = split(/,/,$line); my $instanceName = $instanceValues[0]; # Update %parameterList with values from the config file foreach my $item (sort keys %instanceParamHash) { $parameterList{$item} = $instanceValues[$instanceParamHash{$item}]; } my $instanceResults = "outputs/"."$instanceName".".results.csv"; open (RES, "$instanceResults") or die "Couldn't open $instanceResults: $!\n"; my $resLine = <RES>; chomp ($resLine); my @resultParams = split(/,/,$resLine); my %resultParamHash; for my $i (0 .. $#resultParams) { $resultParamHash{$resultParams[$i]} = $i; } while (<RES>) { $resLine = $_; chomp ($resLine); } #this leaves the last line of the file in resLine close RES; my $run_success = 1; if ($resLine =~ /time/) { #this means no results in the file $run_success = 0; } my @resultValues = split(/,/,$resLine); 151 # now print line of param names, then result names, # then line of param values and result values; if ($wroteFirstLine == 0) { foreach my $param (sort keys %parameterList) { $param =~ s/\.//g; #remove dot notation for Matlab print MERGED "$param,"; } foreach my $var (sort keys %resultParamHash) { $var =~ s/\.//g; #remove dot notation for Matlab $var =~ s/\"//g; print MERGED "$var,"; } print MERGED "\n"; $wroteFirstLine = 1; } foreach my $param (sort keys %parameterList) { print MERGED "$parameterList{$param},"; } foreach my $var (sort keys %resultParamHash) { if ($run_success == 1) { print MERGED "$resultValues[$resultParamHash{$var}],"; } else { print MERGED "0,"; } } print MERGED "\n"; } close MERGED; close CONFIG; open(MERGED, "$mergedResults") or die "Couldn't open $mergedResults: $!"; $line = <MERGED>; chomp($line); #print "$line\n"; my @tmpsplit = split(/,/,$line); my $numElements = $#tmpsplit; print "Number of Elements = $numElements\n"; close MERGED; my $syscmd = "mv $mergedResults $instance.merged.$numElements.csv"; print "$syscmd\n"; system($syscmd); } 8.3 Matlab Code to Read Results This next bit of Matlab code was modified from the Matlab auto-generated code to read a CSV file into a dataset. The autogenerated code from Matlab was generated by using the data/file import tool and selecting generate script. This code read the names of each parameter in the first 152 row and hard coded them into the script. Since some runs of the models result in a slightly different list of outputs, this would not work. So the script was modified to read the names of the parameters from the first row of the file and use them as the dataset column names. This way, the script would not need to change if the a model parameters was added, for example. This code also repackages some of the data to create datasets that just contain the major system costs, subsystem masses and powers, etc. This allows those entire datasets to be plotted with one command and generate a legend automatically. Here is the code to imort the data: function data = importfile(filename, numColumns) %IMPORTFILE Import numeric data from a text file as a matrix. % CERESCHEMSMALL1 = IMPORTFILE(FILENAME) Reads data from text file % FILENAME for the default selection. % % CERESCHEMSMALL1 = IMPORTFILE(FILENAME, STARTROW, ENDROW) Reads data % from rows STARTROW through ENDROW of text file FILENAME. % % Example: % CeresChemSmall1 = importfile('CeresChemSmall.merged.csv', 2, 65); % % See also TEXTSCAN. % Auto-generated by MATLAB on 2016/01/24 17:43:30 % Modified by T. Weise %% Initialize variables. delimiter = ','; startRow = 2; endRow = inf; %% Read columns of data as strings: % For more information, see the TEXTSCAN documentation. %formatSpec = '%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s% s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s% s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s% s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%[^\n\r]'; formatSpec = '%s'; for i=1:numColumns-1 formatSpec = strcat(formatSpec,'%s'); end formatSpec = strcat(formatSpec,'%[^\n\r]'); 153 %% Open the text file. fileID = fopen(filename,'r'); %% Get the first line to get cell column names nameArray = textscan(fileID,formatSpec,1,'Delimiter',delimiter,'ReturnOnError', false); %% Read columns of data according to format string. % This call is based on the structure of the file used to generate this % code. If an error occurs for a different file, try regenerating the code % from the Import Tool. dataArray = textscan(fileID, formatSpec, endRow(1)-startRow(1)+1, 'Delimiter', delimiter, 'HeaderLines', startRow(1)-1, 'ReturnOnError', false); for block=2:length(startRow) frewind(fileID); dataArrayBlock = textscan(fileID, formatSpec, endRow(block)- startRow(block)+1, 'Delimiter', delimiter, 'HeaderLines', startRow(block)-1, 'ReturnOnError', false); for col=1:length(dataArray) dataArray{col} = [dataArray{col};dataArrayBlock{col}]; end end %% Close the text file. fclose(fileID); %% Convert the contents of columns containing numeric strings to numbers. % Replace non-numeric strings with NaN. raw = repmat({''},length(dataArray{1}),length(dataArray)-1); for col=1:length(dataArray)-1 raw(1:length(dataArray{col}),col) = dataArray{col}; end numericData = NaN(size(dataArray{1},1),size(dataArray,2)); for col=1:numColumns+1 % Converts strings in the input cell array to numbers. Replaced non- numeric % strings with NaN. rawData = dataArray{col}; for row=1:size(rawData, 1); % Create a regular expression to detect and remove non-numeric prefixes and % suffixes. regexstr = '(?<prefix>.*?)(?<numbers>([- ]*(\d+[\,]*)+[\.]{0,1}\d*[eEdD]{0,1}[-+]*\d*[i]{0,1})|([- ]*(\d+[\,]*)*[\.]{1,1}\d+[eEdD]{0,1}[-+]*\d*[i]{0,1}))(?<suffix>.*)'; try result = regexp(rawData{row}, regexstr, 'names'); numbers = result.numbers; % Detected commas in non-thousand locations. invalidThousandsSeparator = false; if any(numbers==','); thousandsRegExp = '^\d+?(\,\d{3})*\.{0,1}\d*$'; if isempty(regexp(thousandsRegExp, ',', 'once')); numbers = NaN; invalidThousandsSeparator = true; 154 end end % Convert numeric strings to numbers. if ~invalidThousandsSeparator; numbers = textscan(strrep(numbers, ',', ''), '%f'); numericData(row, col) = numbers{1}; raw{row, col} = numbers{1}; end catch me end end end %% Create output variable data = dataset; for i=1:numColumns data.(char(nameArray{i})) = cell2mat(raw(:,i)); end; Here is the code to repackage the data to group the major systems, subsystem mass and power, and fixed or gimbaled HGA configurations, as well as perform a standard set of plots: %% plotdata will make some standard variables and plots from the data % dataset % Author: T. Weise, USC %create smaller bins of data costSC = data(:,{'SCACScost' 'SCFSWcost' 'SCPAYcost' 'SCPROPcost'... 'SCPWRcost' 'SCTELcost'}); costMajorSystems = data(:,{'GScost' 'LVcost' 'MOcost' 'SCcostSC'}); %convert to $M costSC = replacedata(costSC,(double(costSC(:,:))/1e6),:); costMajorSystems = replacedata(costMajorSystems,... (double(costMajorSystems(:,:))/1e6),:); fixedHGA = data(data.SCTELfixedHGA==1,:); gimbHGA = data(data.SCTELfixedHGA==0,:); plotrows = 2; plotcols = 2; figure; subplot(plotrows,plotcols,1); plot(data.InstanceName,data.systemCost/1e6,'.'); title('Overall System Cost'); xlabel('Case Number'); ylabel('$M'); subplot(plotrows,plotcols,2); plot(data.InstanceName,costMajorSystems,'.'); legend(costMajorSystems.Properties.VarNames,'Orientation','horizontal',... 'Location','BestOutside'); title('Cost by Major System'); xlabel('Case Number'); ylabel('$M'); subplot(plotrows,plotcols,3); 155 plot(data.InstanceName,costSC,'.'); legend(costSC.Properties.VarNames,'Orientation','horizontal',... 'Location','BestOutside'); title('Subsystem Cost'); xlabel('Case Number'); ylabel('$M'); subplot(plotrows,plotcols,4); plot(data.InstanceName,data.SCcostSC/1e6,'.'); hold on; plot(data.InstanceName,data.SCcostSCSimple/1e6,'.r'); legend('Cost based on subsystem','Cost based on overall mass',... 'Orientation','horizontal',... 'Location','BestOutside'); title('Spacecraft Cost'); xlabel('Case Number'); ylabel('$M'); hold off; massSC = data(:,{'SCACSmass' 'SCCDHmass' 'SCPROPmass' 'SCPWRmass' ... 'SCTHERMmass' 'SCTELmass' 'SCscStructuralMass' 'SCPAYmass'}); figure; for i = 1:8 subplot(5,2,i); plot(data.InstanceName,massSC(:,i),'.'); title(massSC.Properties.VarNames(i)); ylabel('kg'); end; subplot(5,2,9); plot(data.InstanceName,data.SCscDryMass,'.'); title('Spacecraft Dry Mass'); ylabel('kg'); subplot(5,2,10); plot(data.InstanceName,data.SCscWetMass,'.'); title('Spacecraft Wet Mass'); ylabel('kg'); powerSC = data(:,{'SCACSpower' 'SCCDHpower' 'SCPROPpower' 'SCPWRpower' ... 'SCTHERMpower' 'SCTELpower' 'SCPAYpower'}); figure; for i = 1:7 subplot(4,2,i); plot(data.InstanceName,powerSC(:,i),'.'); title(powerSC.Properties.VarNames(i)); ylabel('W'); end subplot(4,2,8) plot(data.InstanceName,data.SCscPower,'.'); title('Total SC Power Load'); ylabel('W'); figure; subplot(2,2,1); plot(data.InstanceName,data.SCPWRsolarArrayPerf1AUBOL/1000,'.'); title('Solar array performance at 1 AU'); ylabel('kW'); 156 subplot(2,2,2); plot(data.InstanceName,data.SCPWRsolarArrayArea,'.'); title('Solar array area'); ylabel('m^2'); subplot(2,2,3); plot(data.InstanceName,data.SCTELantDiaSC,'.'); title('Spacecraft Antenna Diameter'); ylabel('m'); subplot(2,2,4); plot(data.InstanceName,data.SCTELdownlinkRate/1000,'.'); title('Telecom Downlink Rate'); ylabel('kbps'); figure; subplot(3,1,1); plot(data.SCPAYresolutionNadirX,data.SCPAYorbitaltitude/1000,'.') title('Orbit altitude as a function of resolution'); ylabel('km'); xlabel('m'); subplot(3,1,2); plot(data.SCPAYfovX,data.SCPAYapertureDiameter,'.'); title('Aperture diameter as a function of Field of View'); ylabel('m'); xlabel('deg'); subplot(3,1,3); plot(data.InstanceName,data.MOopsEncounterDuration,'.'); title('Encounter Duration'); ylabel('months'); xlabel('Case Number'); 157 9 Sample Diagrams in SysML Model Here is the overall system diagram showing the mission being made up of a Spacecraft, Ground System, and Launch vehicle. 158 This is a sample requirements diagram showing the verification path to meet the requirement. 159 This diagram shows the break down of the spacecraft into subsystems, along with spacecraft level parameters, and the details of the payload subsystem displayed. 160 This diagram demonstrates how the system is broken down into subsystems made up of components. In early phases, the components may not be defined, with the subsystem mass, power and data are estimated at that level, then as the definition is refined, the components are added and the subsystem model rolls up the mass, power, and data into one value for the subsystem. 161 Here is an example of a specific subsystem – the Attitude Control Subsystem. 162 Here is the payload subsystem, showing the details of the model elements already defined. The ‘parts’ section in the middle show two outside blocks (OrbitParameters and Constants) that are referenced by the payload, showing the objected orient nature of the modeling. 163 164 This block doesn’t represent a physical part of the spacecraft, just the algorithms and parameters required to compute the surface coverage. 165 While this block contains the orbital parameters, referenced by the previous coverage model. 166 The following diagrams represent the connections and algorithms between the component values used to compute things like the coverage, payload size, and mission duration. 167 168 169 170 171 172 173 10 References 1. Friedenthal, S., Moore, A., & Steiner, R. (2012) A practical guide to SysML: the systems modeling language. , . 2. INCOSE (2007) Systems Engineering Vision 2020, Version 2.03. , . 3. Wall, S. D. (2004) Model-based engineering design for space missions. 6, 3907-3915 Vol.6. 4. Graves, H. & West, M. (2012) Model-based Systems Engineering (MBSE) Initiative. , . 5. Spangelo, S. C., Cutler, J., Anderson, L., Fosse, E., Cheng, L., Yntema, R., Bajaj, M., Delp, C., Cole, B., Soremekum, G., & Kaslow, D. (2013) Model based systems engineering (MBSE) applied to Radio Aurora Explorer (RAX) CubeSat mission operational scenarios. , 1-18. 6. Bayer, T. J., Chung, S., Cole, B., Cooke, B., Dekens, F., Delp, C., Gontijo, I., Lewis, K., Moshir, M., Rasmussen, R., & Wagner, D. (2012) Model Based Systems Engineering on the Europa mission concept study. , 1-18. 7. (2014) OMG SysML. , . 8. Lopez, R. P., Soragavi, G., Deshmukh, M., & Ludtke, D. (2013) Knowledge Management tools integration within DLR's concurrent engineering facility. , 1-11. 9. Rao1, B. H., K.Padmaja2, & P.Gurulingam (2013) A Brief View of Model Based Systems Engineering Methodologies. International Journal of Engineering Trends and Technology 4, 3266-3270. 174 10. Bayer, T., Chung, S., Cole, B., Cooke, B., Dekens, F., Delp, C., Gontijo, I., & Wagner, D. (2013) Update on the Model Based Systems Engineering on the Europa Mission Concept Study. , 1-13. 11. () Modelica Association. , . 12. Otter, M. (2008) Modelica Overview. , . 13. Fritzon, P. (2012) The Modelica Language and Technology for Model-Based Development. , . 14. Fritzon, P. (2012) Introduction to Object-Oriented Modeling and Simulation with Modelica Using OpenModelica. , . 15. Pulecchi, T., Casella, F., & Lovera, M. (2010) Object-oriented modelling for spacecraft dynamics: Tools and applications. Simulation Modelling Practice and Theory 18, 63 - 86. 16. Pulecchi, T., Casella, F., & Lovera, M. (2006) A Modelica Library for Space Flight Dynamics. , . 17. Wertz, James R. & Larson, W. J. (1999) Space Mission Analysis and Design. , . 18. (2014) Juno|NASA. , . 19. Kusnierkiewicz, D. Y., Hersman, C. B., Guo, Y., Kubota, S., & McDevitt, J. (2005) A description of the Pluto-bound New Horizons spacecraft. Acta Astronautica 57, 135 - 144. 20. Wertz, James R. & Everett, D. F. P. J. J. (2011) Space Mission Engineering: The New SMAD. , . 21. Habib-Agahi, H., Mrozinski, J., & Fox, G. (2011) NASA instrument cost/schedule model Hamid Habib-Agahi. , 1-19. 175 22. (2009) NICM Schedule & Cost Rules of Thumb. , . 23. (2014) Deep Space Network. , . 24. Patel, M. R. (2005) Spacecraft Power Systems. , . 25. Kolbe, D. & Best, R. (1997) The \{ROSETTA\} mission. Acta Astronautica 41, 569 - 577. 26. Rayman, M. D., Fraschetti, T. C., Raymond, C. A., & Russell, C. T. (2006) Dawn: A mission in development for exploration of main belt asteroids Vesta and Ceres. Acta Astronautica 58, 605 - 616. 27. Wall, S. D. (1999) Reinventing the design process: Teams and Models. , . 28. Moeller, R. C., Borden, C., Spilker, T., Smythe, W., & Lock, R. (2011) Space missions trade space generation and assessment using the JPL Rapid Mission Architecture (RMA) team approach. , 1-11. 29. Sherwood, B. & McCleese, D. (2013) \{JPL\} Innovation Foundry. Acta Astronautica 89, 236 - 247. 30. Wessen, R., Adler, M., Leising, C., & Sherwood, B. (2009) Measuring the Maturity of Robotic Planetary Mission Concepts. , . 31. (2011) Perl Monks. , . 32. Russell, C. T. (2012) The Dawn Mission to Minor Planets 4 Vesta and 1 Ceres. , . 33. JPL () Dawn at Ceres Presskit. , . 34. Honeywell () Constellation Series Reaction Wheels. , . 35. Honeywell () HR 0610 Reaction Wheel. , . 176 36. Honeywell () MIMU Miniature Inertial Measurement Unit. , . 37. Aerojet () Monopropellant Data Sheets. , . 38. Sodern () SED26 CCD Star Tracker. , .
Abstract (if available)
Abstract
Spacecraft, their operations, are becoming more and more complex. Similarly, the practice of size and cost estimation early in the development cycle is becoming more challenging. This dissertation explores the feasibility of developing an integrated model based in Model Based System Engineering (MBSE) that combines the spacecraft design trades with mission scenario implications for deep space, robotic missions. These missions are typically more resource constrained than earth orbiting missions, which makes the tradeoffs more critical in the initial size estimation phase. The work ultimately resulted in the development of a Modelica based model to simultaneously solve equations relating spacecraft size, mass, performance and cost along with mission operations duration, complexity and staffing levels. This model, in association with some associated infrastructure to perform parametric studies, was used to estimate key space mission parameters, such as mass, data volume, mission duration, and cost for missions to several small bodies to demonstrate an application of the model.
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
Quantifying the effect of orbit altitude on mission cost for Earth observation satellites
PDF
Advanced nuclear technologies for deep space exploration
PDF
A declarative design approach to modeling traditional and non-traditional space systems
PDF
COSYSMO 3.0: an extended, unified cost estimating model for systems engineering
PDF
Mission design study of an RTG powered, ion engine equipped interstellar spacecraft
PDF
Systems engineering and mission design of a lunar South Pole rover mission: a novel approach to the multidisciplinary design problem within a spacecraft systems engineering paradigm
PDF
Relative-motion trajectory generation and maintenance for multi-spacecraft swarms
PDF
Characterization of space debris from collision events using ballistic coefficient estimation
PDF
Designing an optimal software intensive system acquisition: a game theoretic approach
PDF
Extending systems architecting for human considerations through model-based systems engineering
PDF
Optimal guidance trajectories for proximity maneuvering and close approach with a tumbling resident space object under high fidelity J₂ and quadratic drag perturbation model
PDF
Control of spacecraft with flexible structures using pulse-modulated thrusters
PDF
An analytical and experimental study of evolving 3D deformation fields using vision-based approaches
PDF
Cooperative localization of a compact spacecraft group using computer vision
PDF
Calibrating COCOMO® II for functional size metrics
PDF
Increased fidelity space weather data collection using a non-linear CubeSat network
PDF
Trajectory mission design and navigation for a space weather forecast
PDF
The development of an autonomous subsystem reconfiguration algorithm for the guidance, navigation, and control of aggregated multi-satellite systems
PDF
Experimental and numerical investigations of charging interactions of a dusty surface in space plasma
PDF
Autonomous interplanetary constellation design
Asset Metadata
Creator
Weise, Timothy M.
(author)
Core Title
Incorporation of mission scenarios in deep space spacecraft design trades
School
Viterbi School of Engineering
Degree
Doctor of Philosophy
Degree Program
Astronautical Engineering
Publication Date
04/27/2016
Defense Date
04/21/2016
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
MBSE,OAI-PMH Harvest,spacecraft cost estimation,spacecraft size estimation
Format
application/pdf
(imt)
Language
English
Contributor
Electronically uploaded by the author
(provenance)
Advisor
Kunc, Joseph (
committee chair
), Erwin, Daniel (
committee member
), Madni, Azad (
committee member
), Shiflett, Geoffrey (
committee member
)
Creator Email
tim.weise@icloud.com,tweise@usc.edu
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-c40-245574
Unique identifier
UC11277139
Identifier
etd-WeiseTimot-4387.pdf (filename),usctheses-c40-245574 (legacy record id)
Legacy Identifier
etd-WeiseTimot-4387.pdf
Dmrecord
245574
Document Type
Dissertation
Format
application/pdf (imt)
Rights
Weise, Timothy M.
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Access Conditions
The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...
Repository Name
University of Southern California Digital Library
Repository Location
USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA
Tags
MBSE
spacecraft cost estimation
spacecraft size estimation