An Intelligent Spacecraft Configuration Tool for ...

An Intelligent Spacecraft Configuration Tool for Mission Architecture Space Exploration Spandan. J. Das1 and Daniel Selva2 Cornell University, Ithaca, NY, 14850 and Alessandro Golkar3 Skolkovo Institute of Science and Technology, Moscow,143026, Russian Federation

This paper presents an intelligent agent called ISCA that finds a reasonable configuration for a spacecraft given its mass and volume budgets. ISCA is integrated in a multi-agent mission architecture framework used for early mission concept studies, and must therefore trade fidelity against computational expense. ISCA uses a rule-based system to exhaustively search over combinations of launch vehicles and configurations generated using different stacking heuristics and rules of thumb. The least expensive combination is selected and used to estimate launch cost. The information is also fed back to several subsystem design modules such as attitude control to account for updated inertial properties, which leads to the need for iteration. Despite this being work in progress, the validation shown in this paper shows the promise of the rule-based approach to obtain good enough configurations in a fraction of a second. The integration of ISCA with a catalog-based CubeSat design tool shows how ISCA is also capable of producing realistic configurations if COTS or legacy components are used.

Nomenclature A = ADCS = CAD = COTS = E = H = I = IMU = ISCA = JESS = LHS = m = RHS = S/C = UV = VLSI = VNIR =

cylinder cross-sectional area Attitude Determination and Control Subsystem Computer-Aided Design Commercial-Off-The-Shelf Young’s modulus of the material cylinder height moment of inertia Inertial Measurement Unit Intelligent Spacecraft Configuration Agent Java Expert System Shell Left-Hand Side spacecraft launch mass Right-Hand Side Spacecraft UltraViolet Very Large Scale Integration Visible and Near Infrared

1

Meng Student, Mechanical and Aerospace Engineering, 405 Rhodes Hall, AIAA Student Member. Assistant Professor, Mechanical and Aerospace Engineering, 212 Upson Hall, AIAA Member. 3 Assistant Professor, Space Center, 3 Nobel Street Office 447, AIAA Senior Member. 1 2

American Institute of Aeronautics and Astronautics

I. Introduction The configuration of a spacecraft (i.e. the physical arrangement of the main spacecraft subsystem and components) must be considered early in the mission design process, as it can be an important driver of mission lifecycle cost. In particular, launch vehicle selection, which can amount to an important fraction of lifecycle cost, depends not only on the spacecraft launch mass and performance of the launch vehicle for the desired orbit, but also on its configuration, as the spacecraft must fit inside the launch vehicle’s fairing volume. This is especially important in multi-vehicle architectures, where a single launch may carry more than one vehicle. Furthermore, the design of certain subsystems, such as the attitude determination and control subsystem, depends on the inertial properties of the spacecraft and thus on its configuration. The optimization of satellite configurations belongs to the broader category of three-dimensional layout problems of engineering systems. While layout problems have been extensively studied in two dimensions for Verylarge-scale integration (VLSI) of integrated circuits1, the problem of 3-D component allocation in physical layouts has received less attention2. In current professional practice, designers allocate components manually, and use CAD models to verify that their work satisfies the requirements that are set by other subsystem specialists working on the project. The task becomes increasingly complex as the number of design interactions increase in the system, which is the case of complex, multidisciplinary engineering systems such as spacecraft, automobile systems, and other types of complex mechanical artifacts. The ability to support designers in these fields with an automated 3-D component allocation approach becomes critical in light of the need of reducing development time and ensure timely product delivery, while ensuring the effectiveness of the delivered solution in terms of performance, cost, manufacturability, and other requirements. Computational component allocation is a fundamental step towards model-based systems engineering3, and to the so-called computational design synthesis4. Cagan et al. provide a comprehensive survey on the state of the art of computational approaches to 3-D layout problems, that while dated back to 2002, still provides an excellent description of the main challenges entailed by the problem5. Cagan frames 3-D layout problems as design optimization problems, and notes that the difficulty in their solution stems out of three factors: “(1) the modeling of the design objectives and constraints; (2) the efficient calculation of the objectives and constraints; and (3) the identification of appropriate optimization search strategies”5. Typical layout problem formulations model components as 3-D cuboids, and seek to identify their optimal location and orientation in space. Objectives being sought to optimize include performance, cost, and design ilities 6 such as manufacturability, and component accessibility. Common issues that arise in these problems are components interference and clearance 5. As an optimization problem, 3-D layout problem are NP-hard7, and thus heuristic algorithms are often used for their solution. Cagan provides an extensive review of the effectiveness of heuristic approaches to 3-D layout problems including the use of the genetic algorithm, simulated annealing, hybrid approaches, and extended pattern search approaches5. Specific literature on satellite components layout optimization is surprisingly sparse, though it is considered as an important problem to be solved8–10. Wertz provides several heuristics driving satellite configurations11. Configurations are driven by payload requirements (including mission requirements and interference constraints between active and passive instruments), attitude determination and control requirements, power generation (solar array) requirements, telecommunications, harness minimization, and so forth. All these factors interact with each other, and it is thus difficult, if not impossible, to prescribe a ‘one-size-fits-all’ solution to the satellite configuration optimization problem. An example of satellite configurations influenced by the instrument interference problem is the Envisat satellite platform12. Satellite configurations primarily driven by attitude determination and control requirements are spinstabilized13 and dual spin14 satellite configurations. Solar arrays for on-board power generation can be arranged using different configurations depending on the amount of solar power to be generated and the attitude control method used on the spacecraft. These include body mounted, hinged, and deployable (single axis or multiple axes) array configurations11. With exceptions of special cases such as satellites driven by scientific requirements (e.g. the ‘diamond-shaped’ configuration of the GOCE spacecraft15, specifically tailored for gravimetry measurements), satellite configurations usually follow certain canonical geometries that are the result of decades of design experience made by industry and space agencies worldwide. A satellite configuration that is typically encountered in projects include a central thrust tube configuration, where a central thrust cone is used to carry the axial loads of the spacecraft incurred during launch, to ensure efficient load transmission to a central payload adapter attached to the launch vehicle upper stage, and provide convenient allocation to oxidizer and propellant tanks, when prescribed by mission requirements. This configuration is typical of large geostationary platforms 16, but is oftentimes employed in 2 American Institute of Aeronautics and Astronautics

small satellite platforms as well such as in the case of the SMART-1 European satellite17. Components are typically allocated on horizontal panels, in addition to nadir, zenith, and lateral panels forming the envelope of the spacecraft. Vertical shear panels (full panels or more typically in more mass-efficient shear web configurations) may be employed to provide additional mechanical interfaces for components. Smaller satellites may not make use of a central thrust tube but still may make use of all other components described above. A configuration that is more and more often encountered in practice is the linear component stacking in modules, usually met in the design of small CubeSat systems18 (1U and 3U systems being the most commonly seen in practice, with the 6U standard slowly emerging in recent mission proposals). Most spacecraft are a mix of two types of components: reused or bought from suppliers, and fabricated in house or built to order. When existing components, either commercial-off-the-shelf (COTS) or legacy components, are selected to design the different subsystems, information about mass and dimensions is known with relative certainty. On the other hand, when a component is fabricated in house or made to order, there is a larger uncertainty on the mass and dimensions of the final component, which makes the work of configuration engineers hard. For example, many CubeSats make extensive use of COTS, whereas large aerospace organizations may choose to develop some of the key components in house in order to gain in mass, performance or cost. Typically, as the mission design process advances, uncertainty on component mass and dimensions is reduced and the configuration is refined. At the architecture level, there is still much uncertainty in component selection, which adds an additional layer of complexity to the spacecraft configuration task, being it a NP-hard problem by itself. In fact, most early spacecraft design algorithms use parametric models that estimate the mass of the subsystem as a function of payload and orbit requirements, without necessarily providing much information on specific components, their dimensions, allocation, and orientation. Furthermore, even if detailed information was available, configuration models based on topology optimization algorithms19 could not be used anyway due to their prohibitive computational cost. Hence, what is needed at the architecture-level is a tool that: a) provides enough fidelity to design the spacecraft and to predict with high accuracy what are the most cost-efficient launch strategy is for the mission (i.e. type of launch vehicle and number of launches); b) is fast enough to enable exhaustive exploration of the architecture space (i.e., runs in fractions of a second). This paper presents ISCA, an Intelligent Spacecraft Configuration Agent with a trade-off between fidelity and computational expense that is adequate for architecture studies. The tool is integrated in the spacecraft design and cost estimation module of an existing multi-agent mission development framework that is used to explore very large spaces of Earth observing mission architectures (hundreds to millions)20. The inputs to ISCA are mass and power budgets for different spacecraft subsystems estimated by the existing spacecraft design algorithm. The output of ISCA is a spacecraft configuration, defined by the positions and dimensions of the main spacecraft components. Component orientation is not considered in the problem formulation, in view of the sought balanced tradeoff between model fidelity and computational viability. This information is then fed back to specific subsystem design modules and used to select the launch vehicle. The dimensions of the main components are computed by making a number of assumptions about the number and types of components of each subsystem, and transforming mass and volume into dimensions. Then, the positions of the components are determined by solving an optimization problem where the overall objective is the total lifecycle cost (which incorporates number of launches and cost of individual launches). The tool tackles this problem using a rulebased system to express expert knowledge and constraints about the placing of components (e.g. specific payloads must be on specific sides of the spacecraft, heavy components go towards the center and towards the base) and a greedy algorithm to find a good configuration quickly (since the tool must run inline). Furthermore, the tool generates text files from each configuration that can be opened from a CAD tool to automatically create CAD models of the spacecraft inside the launch vehicle. This was accomplished using a Solidworks API designed using Visual Basic. The remainder of the paper reviews the multi-agent architecture development framework and the existing spacecraft design algorithm (Section II), describes the ISCA agent in more detail (Section III), the validation effort (Section IV), and its integration with a CubeSat design tool (Section V). The main contributions and limitations of the model are discussed in Section VI together with future work.

3 American Institute of Aeronautics and Astronautics

II. Multi-agent Mission Architecture Development Framework A. Multi-agent framework The ISCA agent was designed to be integrated in a multi-agent mission development framework developed by Selva et al. 21–23. A multi-agent system is a computer program in which multiple autonomous simple programs (agents) collaborate to solve a complex problem 24. Typically used to model and simulate economic or natural complex systems, multi-agent systems have also been used for engineering design for over a decade 25,26. Their flexibility, scalability, and ability to simulate mixed human-computer teams are often cited as major advantages. Several architectures have been proposed for multi-agent systems. The architecture development facility is based on the MadKit platform 27, in which agents enroll in groups and communities to perform different types of tasks asynchronously and communicate through exchange of messages. In the architecture development facility, agents are used to create or modify mission architectures, evaluate their performance, estimate their cost, explain the results of an architecture, critique an architecture, and others. ISCA is concerned with the cost estimation agents, and more precisely with the spacecraft design agents. Doing a metaphor with a human design team, ISCA would be the configuration engineer working for the mission project manager. B. Spacecraft design algorithm and cost estimation The existing spacecraft configuration and cost estimation agent is described succinctly in this section. Additional information can be found in 20 and 28. The overall flow of the algorithm and its integration within the cost model are illustrated in Figure 1.

Figure 1: Existing spacecraft design algorithm and cost agent

The fundamental idea is that it must be iterative in order to account for couplings between subsystem designs. For example, if an omnidirectional communications antenna is replaced by a more massive parabolic antenna, the increase in mass at a point distant from the center of mass may require a larger set of reaction wheels, which may consume more power, which may require larger solar panels and batteries, all of which can affect the structures subsystem. Hence, the algorithm keeps iterating over the modules in charge of designing the different subsystems until the changes in mass from the last iteration are small enough. 4 American Institute of Aeronautics and Astronautics

More precisely, the algorithm takes the payload requirements (mass, power, data rate and dimensions) and orbit characteristics as inputs and starts by computing an initial rough guess of the mass and dimensions of the spacecraft. In particular, it is assumed that the spacecraft mass equals four times the payload mass, and that the spacecraft is a cube of average density 64 𝑘𝑔/𝑚3 . Then, it enters the subsystem design loop, in which subsystem design agents take turns in modifying the design of their subsystem. Each agent uses equations and rules to size the main components of the subsystem. The electrical power subsystem design agent computes the area and mass of solar panels needed to provide enough end of life power to the payload and other subsystems, as outlined in 29. A basic delta-V budget is computed that accounts for injection, orbit maintenance, attitude control, and deorbiting needs over the mission lifetime. The ADCS subsystem design takes in the attitude control and slewing requirements, and deduces a specific number and type of components (e.g., 4 reaction wheels, 4 sun sensors, 1 3axis magnetic torquer and 2 magnetometers for a 0.01 deg control requirement, or a purely magnetic configuration for a >1deg control requirement). The worst case between the maximum disturbance torque and the slewing torque is used to size the actuators. Momentum dumping is also considered. The mass of the sensors is obtained from a parametric relationship from the accuracy requirement. The approach followed is adapted from 30. The propulsion system design agent computes the propellant mass needed by all thrusters and apogee kick motors in the spacecraft and then estimates the dry mass of the engines assuming a 94-6 propellant to structure mass ratio 31. The avionics, thermal and structure subsystems are sized assuming fixed subsystem-to-spacecraft mass ratios. Once all the subsystem design agents have acted in a given iteration, the spacecraft mass and dimensions are recalculated. The inertial properties assume that the spacecraft consists of a cube with solar arrays on each of two sides. The convergence criterion is based on a simple threshold on the change in total satellite dry mass from the last iteration. The spacecraft mass and dimensions are fed to the launch vehicle selection, which chooses the least costly option from a list of available launch vehicles. A launch vehicle is valid if it satisfies three constraints, namely: a) the performance of the launch vehicle at the desired orbit must be greater than the satellite launch mass with some margin; b) the height of the launch vehicle payload volume inside the fairing must be greater than the largest dimension of the spacecraft with some margin; c) the diameter of the launch vehicle payload volume inside the fairing must be greater than the second largest dimension of the spacecraft. In the case of a constellation of spacecraft, multiple satellites per launch vehicle are allowed, and the minimum number of launches for each launch vehicle is computed based on the same constraints, and assuming linear stacking of spacecraft with some margin. Finally, once the spacecraft has been designed and a launch vehicle selected, the lifecycle cost model estimates the mission lifecycle cost, which includes payload, bus, launch and operations cost and distinguishes between nonrecurring and recurring costs. Learning factors are also considered in the case of multiple identical spacecraft 32.

III. ISCA: Intelligent Spacecraft Configuration Agent A. ISCA Architecture ISCA is a rule-based agent written using the JESS rules engine 33,34. Rule-based systems have about 50 years of history and are a very mature artificial intelligence technology used in a variety of industries (e.g., medical, banking, marketing, engineering) for a wide range of tasks including assessment, diagnosis, tutoring, and design among others. The foundational work on rule-based systems by Newell and Simon 35, Buchannan et al 36, Feigenbaum et al 37 intended to mimic the way a human expert reasons by encoding chunks of expert knowledge in the form of IFTHEN logical rules and using those rules to solve complex problems such as diagnosing a bacterial infection, or inferring the material of a surface from spectral information. While the use of rule-based systems to build a generalpurpose AI was quickly abandoned due to the rigidity of the rule construct, rules engines are still widely used today and are one of the main tools of any knowledge engineer. A diagram explaining the fundamentals of how a rulebased system works is shown in Figure 2.

5 American Institute of Aeronautics and Astronautics

Figure 2: Flow diagram of a basic rule-based system

The main parts are: a rule database, a fact database called the working memory, and an inference algorithm, typically the Rete algorithm 38. Each rule consists of a left-hand side (LHS, the if part of the rule containing the conditions in the form of a set of facts that must be present in the working memory), and a right-hand side (RHS, the then part of the statement containing the actions executed if the conditions are all met, which typically involve adding, removing or modifying facts in the working memory). The Rete algorithm consists of three steps that are executed iteratively: 1) pattern matching, in which activation records are created for each set of facts that matches the LHS of a rule; 2) conflict resolution, in which a single activation record is selected for execution; 3) the execution of the actions in the RHS of the rule of the selected activation record which deletes the activation record from the agenda. These three steps are repeated until there are no more activation records in the agenda. In the case of ISCA, the facts contain input information about the mass and dimensions of the spacecraft components, and output information about the spacecraft configuration. The rules contain the knowledge needed to determine a configuration based on information in the input facts. B. Computing the spacecraft configuration The configuration of the spacecraft plays an important role in the design of the spacecraft, as discussed previously in the Introduction. The spacecraft configuration is also an important factor in the launch vehicle selection tool. To ensure that the satellite fits inside the fairing volume of the launch vehicle, the shape and dimensions of the satellite must be known with sufficient accuracy. The shape and dimensions of the satellite will be different for different configurations. Typical formulations for finding the optimal configuration to minimize mass subject to structural and other constraints require in general discretizing 2D or 3D space into discrete elements and then solve an assignment problem of components to elements. However, due to the computational complexity of the problem, it is often intractable in real time by exact algorithms such as branch and bound or cutting planes. Hence, heuristics or rules of thumb based on expert knowledge are sometimes used to determine good locations for specific components. These heuristics, in combination with hill-climbing using local search operators such as swapping the positions of two components, can be used to find “good” configurations very quickly. Note that meta-heuristic algorithms operating over combinatorial (binary matrices or permutations) could also be effective, but are too slow to be used inside a spacecraft design algorithm that is intended to run in a fraction of a second 39. Examples of heuristics used in this version of ISCA are as follows:  Place heaviest components closer to the bottom of the spacecraft. This facilitates meeting the structural constraints during launch (particularly axial loads).  Place heaviest components closer to the center of mass of the spacecraft. This reduces moments of inertia, which can reduce the burden on the ADCS.  Place connected components close to each other. This is desirable from the integration, assembly and testing perspective, as components that are related and work together are close together, facilitating troubleshooting.  Minimize harness (power and data), which translates directly into mass savings. 6 American Institute of Aeronautics and Astronautics

   

Ensure a minimum distance between active and passive instruments to avoid mutual interference during operations. Place reaction wheels in a pyramidal configuration to ensure minimal mass, redundant torque authority on all inertial axes. Minimize the number of horizontal and shear panels employed in the configuration while satisfying component allocation requirements. Employ simple solar cell allocations first (e.g. body mounted), and scale up to increasingly complex allocations (in increasing order of complexity: hinged, single-axis array, multiple-axis array) as dictated by generation power requirement needs.

ISCA considers two different configurations for a spacecraft: 1) linear stacking of components in layers (mostly suitable for CubeSat and very small satellite platforms,) and 2) stacking around a central thrust cylinder. For each spacecraft and launch vehicle, both configurations are computed and the one resulting in lower cost is selected. It is important to note that the optimal configuration of a spacecraft may depend on the launch vehicle. Launch vehicle selection exhibits strong design influences on the spacecraft configuration, and viceversa. For instance in multiple deployment launches, the satellite structure may need to be reinforced and result, strictly speaking, in a mass-suboptimal structure of the individual spacecraft. However, the result may be desirable from a mission-level point of view, as minimizing the number of launches required to satisfy mission requirements significantly reduces launch costs. This system-level considerations introduced in ISCA brought an important modification in the overall flow of the spacecraft design and cost estimation model of the rule-based model proposed by Selva et al 21–23. By including ISCA in the spacecraft design loop, the selection of the launch vehicle, the spacecraft design, and cost estimation modules are no longer decoupled. Hence, the loop is now done at the cost estimation level, in order to ensure that the least costly architecture, accounting for spacecraft configuration, is chosen. This is shown in Figure 3.

Figure 3: Updated Spacecraft Design Algorithm

Note that in addition to the extra computational cost due to the configuration agent by itself, the new flow diagram of the cost estimation module is N times more expensive as the previous one, where N is the number of 7 American Institute of Aeronautics and Astronautics

launch vehicles in the database. This is due to the fact that a spacecraft design algorithm is run for every launch vehicle in the database, since the spacecraft design may be affected by the choice of launch vehicle. As mentioned above, the spacecraft configuration depends on the stacking heuristic used. In this paper, two stacking heuristics are considered – linear stacking heuristic, and central thrust cylinder stacking heuristic. Both heuristics are subject to a number of assumptions and hard constraints, namely:  Components are declared as either interior or exterior. Interior components such as batteries are placed inside the spacecraft volume, whereas exterior components such as antennas and radiators are placed on one of the outside spacecraft faces.  All the instruments shall be placed on the nadir face of the satellite unless specified.  The radiators are placed on the anti-sun face of the spacecraft.  The solar panels are assumed to be in the launch configuration, i.e. stowed.  Propellant tanks (if required) are assumed to be placed inside the central thrust cylinder, if present. The various configurations generated (position and dimension of all components) can be visualized using a Solidworks macro written in Visual Basic. While generating the macro, the components are approximated as simple geometric bodies such as cuboids, cylinders or cones. This macro was used to generate the figures in this section. 1. Linear stacking heuristic In the linear stacking heuristic, all the internal components are arranged into layers, and the layers are stacked linearly on top of each other. It is assumed that the bottommost layer corresponds to the nadir face, where most payloads will be placed. The heuristic then arranges the different components into layers such that all the components belonging to a particular subsystem go on the same layer. As an example, the reaction wheels, Inertial Measurement (IMU) and the magnetometer are arranged into the ADCS layer. The layers are then stacked linearly on top of each other, with the position of the layer in the vertical arrangement resulting as a tradeoff between the mass of that layer and attitude control requirements. For structural purposes, the heaviest layer would always placed just above the payload layer, and the lightest layer would always be placed on the zenith face. However, this needs to be traded off against the need of providing a balanced moment of inertia across the platform, and a position of the center of gravity as close as possible to the geometrical center of the configuration. Furthermore, all this must be balanced with requirements from other subsystems. With the interior structure of the spacecraft is defined, the exterior components are now placed. The solar arrays are placed on the sides of the zenith; in the case of deployable arrays, these are arranged in their folded configuration. Other components such as sun sensors are also placed on the outside. Figure 4 shows a spacecraft configuration generated using the linear stacking algorithm. The payload in the spacecraft is a UV/visible/near infrared spectrometer, which has dimensions of 0.5m x 0.4m x 0.3m and a mass of 46kg. The linear stacking heuristic is mostly used in nanosatellites such as CubeSats, where axial loads at launch are relatively small.

Figure 4: Spacecraft in linear stacking configuration. The Payload is on the bottommost layer (nadir face). The Avionics, Power, ADCS subsystems are stacked in linearly on successive layers.

8 American Institute of Aeronautics and Astronautics

2. Central thrust cylinder stacking heuristic In the central thrust cylinder stacking heuristic, all the internal components are mounted around a central tube. The central tube is the main load bearing member and ensures that all the critical interior components do not undergo failure by yielding due to the excessive forces encountered during launch. As is the case with most Earth observing missions, the instruments will be placed on the nadir face in the central tube stacking heuristic as well. The central tube extends above the instrument layer and it has diametrically opposite shear panels on which the components can be mounted. The number of shear panels is determined by the number of interior components that need to be mounted. The default number of shear panels is two, and if the number of interior components exceeds a threshold, the number of panels is increased in even numbers, accordingly. This ensures that the configuration is symmetric and has a center of mass closer to the geometric center. The radius of the central tube is approximated as a ratio of the payload adapter, and the height of the tube is the equal to the maximum of the shear panel heights. The thickness of the tube is designed to ensure that the first longitudinal and lateral frequencies of the cylinder given by Equations (1.1) and (1.2) are higher than the launcher’s ones: 𝐴𝐸 𝑚𝐻

(1.1)

𝐸𝐼 𝑚𝐻3

(1.2)

𝑓𝑙𝑜𝑛𝑔 = 0.259 √ 𝑓𝑙𝑎𝑡 = 0.560 √

where 𝐴 is the cross sectional area of the cylinder, 𝐼 is the moment of inertia, 𝐻 is the height of the cylinder, 𝐸 is the Young’s Modulus of the material and 𝑚 is the mass of the whole satellite. Figure 5 shows the spacecraft configuration generated using the central tube stacking heuristic. The payload in this configuration is the same spectrometer that was previously considered.

Figure 5: Spacecraft in central thrust tube configuration. The payload is on the bottommost layer. The internal components are mounted on the appendages of the central tube. The solar panels are mounted in launch configuration.

C. Single-spacecraft launch configuration In addition to determining the shape and dimensions of the spacecraft, it is important to assess whether or not the spacecraft fits in a launch vehicle. This is accomplished by the launch vehicle selection tool. The decision is based on three criteria:

9 American Institute of Aeronautics and Astronautics

  

The performance of the launch vehicle shall be greater than the total mass of the satellite stack, with some margin. The height of the launch vehicle shall be greater than the height of the satellite stack, with some margin. The cross sectional area of the launch vehicle shall be greater than the cross sectional area of the satellite stack, with some margin.

A launch adapter is also added to the overall launch mass of the spacecraft when the launch vehicle is chosen. The adapter for a single spacecraft configuration is assumed to be a truncated cone with a cylindrical base, and its mass is fixed for a given launch vehicle. The configuration of a spacecraft inside a launch vehicle can also be visualized using CAD. Indeed, another Solidworks Macro generates a CAD Model of the spacecraft inside the launch vehicle. Figure 6 shows the spacecraft in launch configuration inside the launch vehicle. The payloads in the spacecraft the same as in the Terra spacecraft. The combination of central thrust cylinder configuration and the Atlas launch vehicle was found to minimize the lifecycle cost of the mission for this payload.

Figure 6: Simulated spacecraft carrying Terra payloads inside the Atlas launch vehicle. The launch vehicle has been made transparent to aid visualization.

D. Multiple-spacecraft launch configuration The single-spacecraft launch configuration assumes a single launch vehicle per spacecraft. However, current trends in Earth observing satellite missions favor constellations of satellites rather than single-spacecraft missions, especially with irruption of constellations of nanosatellites such as CYGNSS 40. In these cases, one can launch multiple satellites of the constellation in a single launch vehicle to reduce launch costs. For example, the heuristic of one launch per orbital plane is quite popular as it facilitates constellation deployment without the need for large propulsion systems capable of changing the orbital plane. Therefore, it becomes imperative to make the launch vehicle selection tool general enough to deal with multiple satellites inside a single launch vehicle in order to capture these realistic cost savings. The tradeoff is thus selecting between having a large number of launches of a smaller rocket, or a smaller number of launches of a bigger rocket. The optimum of this problem depends on the 10 American Institute of Aeronautics and Astronautics

packaging factors that can be achieved for each launch vehicle, which depend not only on the launch vehicle characteristics, but also on the exact mass and volume of each spacecraft. The number of satellites that can be stacked inside the launch vehicle without interference is governed by the same three constraints mentioned above. The most constraining one is used to determine the number of spacecraft that can be launched per launch vehicle, which yields the number of launches. Then, launch cost is simply given by the number of launches times the cost of a single launch. It is assumed that as many launch vehicles as required to launch the constellation are available. 1. Dual-launch configuration When the number of satellites inside the launch vehicle is two (i.e. a dual-launch configuration, like the one used in the Ariane 5 rocket), the satellites are assumed to be on top of each other, with an adapter in between. The bottom satellite uses the standard truncated cone launch adapter. A conical structure with a truncated cone lid covers the bottom satellite in its entirety (e.g. Ariane 5’s SYLDA structure 41). Then, a smaller truncated cone launch adapter for the upper satellite is placed on top of the bottom satellite cover, and the upper satellite sits on top of this adapter. Figure 7 shows a dual-launch configuration inside the Taurus Launch Vehicle. On the left figure, the conical launch adapter which supports the upper spacecraft conceals the lower spacecraft. The spacecraft under consideration carries a UV/VNIR spectrometer, and has a central-tube internal configuration. On the right figure, the launch adapter has been made transparent to reveal the lower spacecraft as well as the lower launch adapter.

Figure 7: Dual-launch configuration inside the Taurus Launch Vehicle. The launch vehicle has been made transparent to aid visualization. On the left figure, the conical launch adapter of the upper satellite conceals the lower satellite. On the right figure, the conical launch adapter has been made transparent to reveal the lower spacecraft.

2. Multiple (N>2) spacecraft launch configuration When the number of satellites inside the launch vehicle is greater than two, the satellites are arranged into layers of up to 4 spacecraft arranged equidistant from each other. Additional layers are then stacked on top of the bottom layer in a linear fashion. The number of layers is determined by the number of spacecraft to be placed inside the launch vehicle. Figure 8 shows 16 spacecraft inside the Ariane-5-ESCA- Launch Vehicle. The spacecraft have been arranged into 4 layers, with each layer containing 4 spacecraft. This arrangement is not the only one conceivable for multiple launch configurations; future work will address additional configurations for different spacecraft platform sizes. Note that the selection of a launch configuration has direct feedback impact on satellite configuration 11 American Institute of Aeronautics and Astronautics

decisions and resulting layout, which motivated the change in the flow of the spacecraft design algorithm illustrated in Figure 3.

Figure 8: Multiple launch configuration with 16 satellites inside the Ariane-5-ESCA Launch Vehicle. The Launch Vehicle has been made transparent to aid visualization. The 16 satellites have been divided into 4 vertical layers of 4 satellites each. The satellites in each layer are placed diametrically opposite each other to ensure symmetry. The central tube acts as the interface between each satellites and the launch vehicle.

IV. Validation of ISCA Validation is a critical step of any tool used in mission conceptual design. Ideally, we would like to test our tool on a set of payloads and orbits, obtain the corresponding spacecraft mass, configuration, and launch vehicle selected and compare to the actual values of those parameters. This is however very challenging due to the difficulty in finding an adequate dataset that can be used as “truth” to compare results against. Furthermore, obtaining a highly accurate configuration of a spacecraft is not a goal of this tool; rather, we intend to predict with reasonably high accuracy the mass of the spacecraft and the cheapest launch vehicle available. Finally, it is also challenging to define how “different” two configurations are, other than by looking at them. Hence, our validation strategy so far has been limited to comparing predicted against actual launch vehicles for a number of Earth observing spacecraft. We used past missions from the NASA Earth Observing System program for the validation, and a database of launchers available at the time including the Taurus-XL, Delta-7320, Delta-7420, Delta-7920, and Atlas-5. Since our launch vehicle database contains launch vehicles that were not available or considered for some missions, only a subset of the database was used in some cases. For example, the Russian Soyuz rocket was not available for any NASA earth observation satellite missions, and was therefore not considered. The results of the launch vehicle selection validation are presented in Table 1. Table 1 : Results from the launch vehicle selection validation. Closest LV is the launch vehicle in the database that is most similar to the actual launch vehicle used by the mission. Class distance is the difference between the ranks of the true class and the predicted class (e.g., Taurus-XL=1, Delta-7320=2, Delta-7420=3,…).

Mission

Payload

Closest LV

Predicted ISCA

ACRIMSAT AQUA

ACRIM AIRS AMSR-E

Taurus Delta-7920

Taurus-XL Atlas-5

12 American Institute of Aeronautics and Astronautics

Class Distance 0 1

AURA ICESAT JASON-1 ORBVIEWSEAWIFS QUIKSCAT SORCE TERRA LANDSAT-7

AMSU-A CERESC HSB MODIS HIRDLS MLS OMI TES GLAS ALT-SSALT TMR GGI DORIS SEAWIFS SEAWINDS SOLSTICE ASTER CERES CERES-B MISR MODIS-B MOPITT ETM+

Delta-7920

Atlas-5

1

Delta-7320

Delta-7320

0

Delta-7920

Delta-7320

1

Taurus-XL

Taurus-XL

0

Delta-7420 Taurus-XL

Taurus-XL Taurus-XL

2 0

Atlas-5

Atlas-5

0

Delta-7920

Delta-7420

1

The results show that the launch vehicle selection performs relatively well in most cases. In the few cases where there is a classification error, the class distance is usually 1. Class distance is defined as the difference in cost rank between predicted and true launch vehicle class (e.g. the class distance between Delta-7320 and Delta-7420 is 1 because there is no other option with a cost in between, and the difference between the Delta-7320 and the Atlas-5 is 3, because the Delta-7420 and Delta-7920 are available options with costs in between the Delta-7320 and Atlas-5. Some errors are explained by a large error in the estimation of the spacecraft mass. However, it is noted that most errors occur due to misprediction of the satellite dimensions in the case of multi-instrument satellites, which suggests that the heuristic that all instruments are on the nadir face may not always be appropriate. It is important to acknowledge that this validation work is still in progress, and that more effort needs to be devoted to validation activities in general. In particular, visually comparing the generated configurations with the actual ones, as opposed to just looking at the launch vehicle selection outcome, would be very informative. In addition to the launch vehicle validation, the spacecraft dry mass returned by the design tool was compared to the actual dry mass of the satellite. The results of this validation are shown in Figure 9. The relatively high Pearson correlation coefficient (R^2=0.968) suggests that the model is working correctly, with a mean standard error of 10%. Note however the small number of points in the dataset.

Figure 9: Validation of the calculation of dry mass

13 American Institute of Aeronautics and Astronautics

V. Integration of ISCA with CubeSat catalog design tool So far, we have discussed the integration of ISCA in a traditional top-down spacecraft design algorithm in which parametric models are used to size many or most of the components. This results in relatively low fidelity configuration in which components are approximated as simple geometrical shapes such as boxes or cylinders. However, in cases where most components are either COTS or reused from previous missions, the exact shape and dimensions of the component are known with certainty, and this information can be used to generate higherfidelity configurations. Of particular interest is the case of CubeSats, since most CubeSat missions make extensive use of COTS. Furthermore, CAD models of actual CubeSat components can be found online on the websites of some vendors. Hence, ISCA was modified to allow the incorporation of actual components with their CAD files. In order to test this capability, ISCA was integrated with a catalog-based CubeSat design tool recently developed by Jacobs and Selva 42. This CubeSat design tool has a database of components, and is capable of finding the cheapest combination of components that is capable of meeting a set of requirements including payload and orbit characteristics, pointing requirements, spatial resolution, accuracy, data throughput, reliability and others 42. When integrated in this tool, ISCA is capable of computing a reasonable configuration for a given Cubesat, and creating a CAD model of the CubeSat using the actual CAD models of the components. A linear stacking heuristic is used, since it is commonly used for Cubesats. A solidworks macro finally generates a CAD assembly file of the components inside the cubesat, with the CAD models obtained from the prepopulated database. An example of CubeSat configuration obtained with the tool is shown in Figure 10.

Figure 10: CAD Model of a CubeSat design returned by ISCA. The assembly file is built by the insertion of the CAD models of the individual components from a prepopulated database. The CubeSat in the above figure comprises of a Camera as a Payload, an ADCS, a motherboard, and a UHF dipole antenna in a 3U skeleton. Solar panels, batteries and radiators are not shown.

VI. Conclusion A. Summary This paper has presented ISCA, a rule-based agent that uses expert knowledge to sketch spacecraft configurations quickly. ISCA is integrated into a multi-agent mission design and design space exploration tool, and can be thought of as playing the role of the configuration engineer in a concurrent design session. The knowledge in ISCA is in the form of rules of thumb with different priorities that suggest good placements for different types of components. Given the information about mass and dimensions of the components, these rules of thumb can be applied to place the components in a reasonable configuration. 14 American Institute of Aeronautics and Astronautics

In its current version, ISCA tries two different types of configuration for each spacecraft: linear stacking (most adequate for small spacecraft) and central thrust cylinder (for larger spacecraft). Both configurations are computed for each spacecraft and the one resulting in a lower cost according to the cost model is selected. Since the outputs of ISCA (i.e., the configuration) affect the design of the spacecraft (e.g. ADCS) and the selection of the launch vehicle, the flow of the mission design tool was changed to take this coupling into account. A Visual Basic macro was used to visualize the output of ISCA graphically in a CAD environment. A CAD model showing a simplified spacecraft configuration is automatically created in the order of seconds at the user request, if he or she wants to get a more clear idea of the configuration of the spacecraft automatically created by the tool. This feature facilitates human-computer interaction in a way that is conducive to trust. The application of ISCA to a number of examples was shown, together with some preliminary results of the validation effort currently on-going. While ISCA is still work in progress, results show its promise to produce good enough configurations in time scales compatible with design space exploration tasks (i.e., fraction of a second). Of particular interest is the integration of ISCA with a catalog-based CubeSat design tool, since it shows that ISCA is also capable of producing realistic configurations when fed with CAD models of actual components as opposed to just rough mass and dimensions information. B. Limitations and future work ISCA and the multi-agent mission architecture development framework are still work in progress and much can be done to improve it. Some of the stronger limitations and items of future work are outlined below.  Configuration types: The current version of ISCA only has two types of configuration: linear stacking and central-truss tube. However, many spacecraft have configurations that differ widely from these ones (e.g. Snapdragon configuration for synthetic aperture radar missions). Adding some of these alternative configuration types may greatly increase the utility of the tool.  Heuristics: The current version of ISCA has a reduced set of relatively simple heuristics that ignore important aspects such as placing of wiring or electromagnetic interference. These more sophisticated heuristics should be incorporated into ISCA.  Optimization: The current version of ISCA does not use any optimization algorithm to find a good configuration. It relies on prioritized heuristics instead. Adding a linear programming solver or a simple hill-climbing algorithm using local search techniques could help reduce the mass and cost of the spacecraft through a better configuration.  Interactive version: The current version of ISCA is fully automatic because it is used as part of a cost model that needs to run in a fraction of a second. However, it does provide an off-line visualization tool to help the user see the results of the configuration. Giving the user the ability to modify the configuration manually could increase the utility of the tool and lead to much better configurations.  Validation: The validation efforts currently ongoing must continue. The spacecraft design algorithm (through its dry mass), the launch vehicle selection and the cost estimation module must all be tested on a larger set of missions with a broader range of configurations.  Multiple launch configurations: future work will address additional configurations of multiple launch for varying spacecraft platform sizes and will address in more detail the feedback interactions between launch and spacecraft configuration.

References 1

Kleinhans, J. M., Sigl, G., Johannes, F. M., and Antreich, K. J., “GORDIAN: VLSI placement by quadratic programming and slicing optimization,” Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, vol. 10, 1991, pp. 356–365.

2

Comput, S. J., “On three-dimensional packing*,” vol. 19, 1990, pp. 847–867.

3

Estefan, J. A. J., Survey of Model-Based Systems Engineering (MBSE) Methodologies, 2007.

15 American Institute of Aeronautics and Astronautics

4

Cagan, J., Campbell, M. I., Finger, S., and Tomiyama, T., “A framework for computational design synthesis: model and applications,” Journal of Computing and Information Science in Engineering, vol. 5, 2005, pp. 171–181.

5

Cagan, J., Shimada, K., and Yin, S., “A survey of computational approaches to three-dimensional layout problems,” Computer-Aided Design, vol. 34, 2002, pp. 597–611.

6

Crawley, E., Cameron, B., and Selva, D., Systems Architecture: Strategy and Product Development for Complex Systems, Prentice Hall, 2015.

7

De Bont, F. M. J., Aarts, E. H. L., Meehan, P., and OBrien, C. G., “Placement of shapeable blocks,” Philips Journal of Research, vol. 43, 1988, pp. 1–22.

8

Fakoor, M., and Taghinezhad, M., “Layout and configuration design for a satellite with variable mass using hybrid optimization method,” Proceedings of the Institution of Mechanical Engineers, Part G: Journal of Aerospace Engineering, 2015, p. 0954410015591834.

9

Sun, Z.-G., and Teng, H.-F., “Optimal layout design of a satellite module,” Engineering Optimization, vol. 35, 2003, pp. 513–529.

10

Zhang, B., Teng, H.-F., and Shi, Y.-J., “Layout optimization of satellite module using soft computing techniques,” Applied Soft Computing, vol. 8, 2008, pp. 507–521.

11

Wertz, J., Everett, D., and Puschell, J., Space Mission Engineering: The New SMAD, Hawthorne CA: Microcosm Press, 2011.

12

Selva, D., and Crawley, E., “Integrated assessment of packaging architectures in Earth observing programs,” Aerospace Conference, 2010 IEEE, Big Sky: IEEE, 2010, pp. 3–12.

13

Lawrence, G., “Spin Stabilized Satellites,” Small Satellite Conference, 1987.

14

Bainum, P. M., Fuechsel, P. G., and Mackison, D. L., “Motion and stability of a dual-spin satellite with nutation damping,” Journal of Spacecraft and Rockets, vol. 7, 1970, pp. 690–696.

15

Drinkwater, M. R., Floberghagen, R., Haagmans, R., Muzi, D., and Popescu, A., “GOCE: ESA’s first earth explorer core mission,” Space Science Reviews, 2003, pp. 419–432.

16

Evans, B. G., Satellite communication systems, Iet, 1999.

17

Foing, B. H., Racca, G. D., Marini, A., Heather, D. J., Koschny, D., Grande, M., Huovelin, J., Keller, H. U., Nathues, A., and Josset, J. L., “SMART-1 mission to the moon: Technology and science goals,” Advances in Space Research, vol. 31, 2003, pp. 2323–2333.

18

Nugent, R., Munakata, R., Chin, A., Coelho, R., and Puig-Suari, J., “The cubesat: The picosatellite standard for research and education,” AIAA SPACE 2006 Conference & Exposition, San Jose, CA: 2006.

19

Rozvany, G. I. N., “A critical review of established methods of structural topology optimization,” Structural and Multidisciplinary Optimization, vol. 37, 2009, pp. 217–237.

20

Selva, D., Cameron, B. G., and Crawley, E. F., “Rule-based System Architecting of Earth Observing Systems: The Earth Science Decadal Survey,” Journal of Spacecraft and Rockets, 2014. 16 American Institute of Aeronautics and Astronautics

21

Selva, D., “Rule-based system architecting of Earth observation satellite systems,” PhD dissertation, Massachusetts Institute of Technology, ProQuest/UMI, 2012.

22

Hitomi, N., and Selva, D., “Experiments with Human Integration in Asynchronous and Sequential Multi-Agent Frameworks for Architecture Optimization,” Procedia Computer Science, 2015.

23

Selva, D., “Knowledge-intensive global optimization of Earth observing system architectures: a climate-centric case study,” SPIE Remote Sensing, International Society for Optics and Photonics, 2014, p. 92411S– 92411S.

24

Ferber, J., Multi-agent systems - an introduction to distributed artificial intelligence, Addison-Wesley, 1999.

25

Campbell, M., Cagan, J., and Kotovsky, K., “A-design: An agent-based approach to conceptual design in a dynamic environment,” Research in Engineering Design, vol. 11, 1999, pp. 172–192.

26

Egan, P., Cagan, J., Schunn, C., and LeDuc, P., “Synergistic human-agent methods for deriving effective search strategies: the case of nanoscale design,” Research in Engineering Design, vol. 26, 2015, pp. 145–169.

27

Gutknecht, O., and Ferber, J., “The MadKit Agent Platform Architecture,” Infrastructure for Agents, MultiAgent Systems, and Scalable Multi-Agent Systems SE - 5, T. Wagner and O. Rana, eds., Springer Berlin Heidelberg, 2001, pp. 48–55.

28

Sanchez, M., Selva, D., Cameron, B., Crawley, E., Seas, A., and Seery, B., “Exploring the Architectural Trade Space of NASA’s Space Communication and Navigation Program,” Aerospace Conference, 2013 IEEE, Big Sky: IEEE, 2013.

29

Bokulic, R. S., DeBoy, C. C., Enger, S. W., Schneider, J. P., and McDermott, J. K., “Spacecraft Subsystems IV — Communications and Power,” Space Mission Engineering: The new SMAD, Hawthorne, CA: Microcosm, 2011.

30

Starin, S. R., and Eterno, J., “Spacecraft Subsystems II- Control Systems,” Space Mission Engineering: The new SMAD, 2011, pp. 565–600.

31

Leyva, I. A., “Spacecraft Subsystems I - Propulsion,” Space Mission Engineering: The new SMAD, 2011, pp. 527–564.

32

Apgar, H., “Cost Estimating,” Space Mission Engineering: The new SMAD, J.R. Wertz, D.F. Everett, and J.J. Puschell, eds., Hawthorne, CA: Microcosm, 2011.

33

Friedman-Hill, E., JESS in Action, Manning, 2003.

34

Friedman-Hill, E. J., Jess, The Java Expert System Shell, Livermore, CA: 2000.

35

Newell, A., and Simon, H. A., Human Problem Solving, Englewood Cliffs, NJ: Prentice Hall, 1972.

36

Buchanan, B. G., and Shortliffe, E. H., Rule-based Expert Systems: the MYCIN experiments of the Stanford Heuristic Programming Project, Addison-Wesley, 1984.

37

Feigenbaum, E. A., Buchanan, B. G., and Lederberg, J., “On generality and problem solving: a case study using the DENDRAL program,” Machine Intelligence 6, B. Meltzer and D. Michie, eds., Edinburgh, Scotland: 1971, pp. 165–190. 17 American Institute of Aeronautics and Astronautics

38

Forgy, C. C. L., “Rete: A fast algorithm for the many pattern/many object pattern match problem,” Artificial intelligence, vol. 19, Sep. 1982, pp. 17–37.

39

Hopper, E., and Turton, B. C. H., “Empirical investigation of meta-heuristic and heuristic algorithms for a 2D packing problem,” European Journal of Operational Research, vol. 128, 2001, pp. 34–57.

40

Ruf, C. S., Gleason, S., Jelenak, Z., Katzberg, S., Ridley, A., Rose, R., Scherrer, J., and Zavorotny, V., “The CYGNSS nanosatellite constellation hurricane mission,” International Geoscience and Remote Sensing Symposium (IGARSS), 2012, pp. 214–216.

41

Breton, J., and Maroquene, F., “The Ariane family of launchers,” Spacecraft Structures, Materials and Mechanical Engineering, 1996, p. 3.

42

Jacobs, M., and Selva, D., “A CubeSat Catalog Design Tool for a Multi-Agent Architecture Development Framework,” Aerospace Conference, 2015 IEEE, 2015.

18 American Institute of Aeronautics and Astronautics