Nomenclature α = function of Technology Readiness Level (TRL) β = complexity of each connection between pairs of components γ = 1/n Π i = expected profit for missions of type i A = Design Structural Matrix C AIT = assembly, integration, and test cost C D = development cost of each satlet variant C NR = non-recurring development costs C PMSE = aggregate system level PMSE estimate C i R = recurring costs (manufacturing costs, operations costs, and launch costs) C 1 = complexity due to number and flight readiness of components C 2 = complexity due to pair-wise component interactions Distribution Statement A: Approved for Public Release, Distribution Unlimited.2 C 3 = complexity due to topology of system architecture and complexity of integration E(A) = graph energy of the DSM m = number of interfaces m i = number of specific missions of type i resulting from market projection n = number of components Ps i = probability of success of architecture in providing capabilities for mission type i R i = nominal maximum revenue from mission type i AFS = Aurora Flight Sciences AIT = assembly, integration and test CER = cost-estimating relationship DSM = Design Structural Matrix IMCE = Integrated Model-Centric Engineering JPL = Jet Propulsion Laboratory PMSE = Project Management and Systems Engineering PODS = Payload Orbital Delivery System Satlet = cellularized satellite building blocks SSCM = Small Satellite Cost Model SysML = Systems Modeling Language TDRS = Tracking and Data Relay Satellites TRL = Technology Readiness LevelThis paper describes a model-based architectural design and analysis approach developed to support the initial design of cellularized spacecraft architectures, such as the DARPA Phoenix program. As one of its technical pillars, the Phoenix program is aiming to construct new "aggregate satellites" on-orbit by combining cellularized building blocks referred to as "satlets." A critical question that needs to be addressed is "should there be a single satlet type that provides all the required satellite functionality, or should there be multiple specialized types"? Our initial approach includes capture of satlet design and aggregated satellite design trade spaces using the Systems Modeling Language (SysML), specification of requirements as parametric constraints on the set of acceptable solutions, automated search of this trade space and generation of paretooptimal satlet architectures that satisfy mission requirements while maximizing a specified value metric. The initial results of our analysis suggest that a cellularized architecture should include sets of more specialized satlets: a central satlet type that includes components for computation and data processing, centralized attitude sensing and ground communication, a satlet type that provides actuation in the form of either reaction wheels or thrusters, a payload satlet type to provide any specialized functionality for a particular mission (e.g., an RF transceiver), and finally, "connector" satlet types that provide structural, mechanical and power inte...

No abstract

No abstract

One of the most challenging yet poorly defined aspects of engineering a complex aerospace system is behavior engineering, including definition, specification, design, implementation, and verification and validation of the system's behaviors. This is especially true for behaviors of highly autonomous and intelligent systems. Behavior engineering is more of an art than a science. As a process it is generally ad-hoc, poorly specified, and inconsistently applied from one project to the next. It uses largely informal representations, and results in system behavior being documented in a wide variety of disparate documents. To address this problem, JPL has undertaken a pilot project to apply its institutional capabilities in Model-Based Systems Engineering to the challenge of specifying complex spacecraft system behavior. This paper describes the results of the work in progress on this project. In particular, we discuss our approach to modeling spacecraft behavior including 1) requirements and design flowdown from system-level to subsystem-level, 2) patterns for behavior decomposition, 3) allocation of behaviors to physical elements in the system, and 4) patterns for capturing V&V activities associated with behavioral requirements. We provide examples of interesting behavior specification patterns, and discuss findings from the pilot project.