SSC19-WKII-08

Tailored systems engineering processes for low cost high risk missions.
Jared Clements and Tyler Murphy
ATA Aerospace
1851 Charlene Dr. Kirtland AFB, NM 87117

Lee Jasper
Space Dynamics Laboratory
1851 Charlene Dr. Kirtland AFB, NM 87117

Charlene Jacka
AFRL/RVEN
1851 Charlene Dr. Kirtland AFB, NM 87117

ABSTRACT
Given the low cost of most cubesat missions, a full implementation of the traditional space systems engineering
process to cubesat missions can be detrimental to programmatic success of the cubesat. At the other extreme, cubesat
missions often suffer predictable consequences from the omission of standard systems engineering processes such as
risk management, configuration management, and quality assurance. In this paper we discuss a scaled systems
engineering approach to cubesat missions implemented on a programmatically constrained mission. A discussion of
each of the standard systems engineering processes and options for tailoring the processes for a constraint-based
mission and how this varies from the typical top-down mission processes. The intent is to inform the decisions of
mission developers in determining what level of rigor is appropriate for each process in their unique circumstances
and mission needs. Examples of tailoring processes utilized with missions currently underway at the Air Force
Research Laboratory's Small Satellite Branch (AFRL/RVEN) are used to illustrate the application of the information
presented.

CONSTRAINT-DRIVEN DESIGN While Class D missions can be applicable to any size of

Small satellites are seeing significant utilization because space system, the reality is that small satellites generally
they are intended to be both lower cost and more rapidly do not meet the intent of Class D. The growing
deployed; these attributes allow for a much wider range prevalence of small satellites are also starting to violate
of people and organizations to build spacecraft. While the assumptions Class D was predicated on: that these
small satellite platforms are not nearly as capable as their are one-of-a-kind. Class D is a higher risk posture but
larger, more ‘traditional’ counterparts, they are has evolved (or always was) assuming a relatively high
facilitating large growth and investment. Since just 2015 probability of mission success. The small satellite
well over 600 CubeSats have flown [1, 2] and it is community, and the design principles therein, have
expected that much greater adoption of the small satellite evolved from the concept of pushing the boundary on
form factors will continue with investments on the order faster innovation. The small satellite community’s
of tens of billions of dollars [3, 4]. The schedule and cost innovation cycle was enabled by the community
savings appear, so far, to have justified the reduced adoption of the containerized 1U standard. This standard
capability imposed by this smaller form factor. has since been adapted to larger form factors but the
fundamental design trades were developed in a form
With the growing interest, and investment, in these factor that were amenable for wide spread adoption.
platforms there is a growing level of scrutiny being This standard has allowed the community to focus on
applied to the small satellite industry. Common space innovation in processes and platform capabilities
industry practices are being applied to small satellites atypical of larger scale missions.
that have been developed for larger one-of-a-kind space
assets [5, 6]. Essentially, many organizations are Further, these systems are greatly constrained and often
attempting to develop small satellites to Class D or (the are not capable of achieving something like Class D. The
ambiguous) sub-Class D level of system engineering and form factor imposes many physics-based limitations
mission assurance. (volume, mass, power), many technologies are relatively
low Technical Readiness Level (TRL), and the greater
space industry holds many misperceptions about these

Clements 1 33rd Annual AIAA/USU

Conference on Small Satellites
vehicles (e.g. 50% of all small satellites are dead on In order to be constraint-driven and reap the benefits of
arrival to orbit; the actual number is more like 17% [1, faster and cheaper, a mission’s scope must be well
2]). Because of the perception that these spacecraft are defined and limited [8] or the scope must be flexible to
cheaper and faster, their schedules and budgets are often reductions as constraints are realized. This idea can be
more static than the traditional “big space” paradigm. challenging and even abrasive to much of “big space”
This drives capability, system engineering processes, but it is familiar to many small satellite crafters [2].
and mission assurance. Assuming this step can be taken with mission
stakeholders, the next most important attribute to a
It is recognized within the small satellite community that constraint-driven mission is scaling the systems
high levels of system engineering and mission assurance engineering practices: the focus of this paper.
processes can reduce the innovative intention of small
satellites. Where possible, the idea that a small satellite It is a common refrain for those working on small
mission will “fit the box” instead of “building the box” satellites that certain practices are not conducted
has been utilized to help scope missions implemented in “because it’s a SmallSat”. This is, in of itself, not
a small satellite form factor, as shown in Figure 1. While sufficient or technically correct. Small satellites go
these ideas have been in the small satellite community through all of the same phases and steps as any space
for years, they have only recently been more directly vehicle however there are many practices and processes
discussed [7, 8, 9]. that are either done on a very small scale or not
applicable. The processes also tend to be iterative versus
Constraint-driven design is where schedule, cost, and serial, with smaller scale processes happening
existing limitations (both technical and policy) drive the throughout the mission lifecycle. Tailoring of these
mission scope and execution plan. This is, so far, how practices and processes to be constraint-driven is
most small satellite platforms have been designed and is discussed and recommendations are made based upon
in contrast to the “big space” requirements-driven experience from various AFRL programs and the
paradigm. Requirements-driven design prioritizes University NanoSatellite Program. Further, discussion of
mission scope over schedule, cost, or other limitations good practices for improving resilience/robustness of
that may drive larger development efforts. space vehicles, without necessarily increasing system
engineering or mission assurance burden, are discussed.

Figure 1: Constraint vs. Requirements driven missions [7]

VITALITY OF MISSION SCOPE result should be. Detailed (or deep) requirements are still
Unlike the wide and deep requirements of the traditional necessary but they are only created when they are
needed. It is important through this process to not over-
spacecraft development approach the requirements in a
define the solution space but rather the problem that
constraint driven model are kept at a high level and
needs to be solved.
focused on the specific capability that is required to be
demonstrated on orbit. The scope should cover the The key piece of information here that drives scope is the
overall definition of what the mission is supposed to
Minimum Viable Product which is tied directly to the
accomplish and a specific description of what the end

Clements 2 33rd Annual AIAA/USU

Conference on Small Satellites
capability that should be validated on-orbit. Each Table 1. Systems engineering processes
capability has at least one on orbit demonstration
associated with it for on-orbit validation purposes. Note Technical Management Technical Processes
that if there is not an on-obit test associated with the Processes
capability then the associated development is descoped
from the mission. This scoping effort drives many of the • Project Planning • Mission Analysis
systems engineering design trades that are determined • Project Assessment • User Requirements
through a mission lifecycle and fundamentally bound the and Control Definition
programmatic constraints of the mission.
• Decision • System Requirements
In constraint driven models the scope of a mission is Management Definition
controlled not fixed. It is expected that the scope will • Risk Management • Architecture
change throughout the mission lifecycle; this change is • Information Definition
documented throughout mission lifecycle at Management • Design Definition
programmatic reviews. It is critical that programmatic • Configuration • System Analysis
discipline is maintained to only add capabilities when Management • Implementation
they have made space by removing other capabilities • Quality Assurance • Integration
first. Scope creep, where mission stakeholders add • Measurement • Verification
desired capabilities outside the necessity of the • Transition
Minimum Viable Product, is a real danger to the success • Validation
of a mission. • Operation
• Maintenance
It is critical to document exactly how and when a • Disposal
mission’s objectives are to be achieved by showing the
major products, milestones, activities, and resources
required for the mission. In traditional management the TECHNICAL MANAGEMENT PROCESSES
scope, cost and schedule imply high quality attributes Accurate project planning is generally considered the
which is locked down at the start of the project, most difficult of the tasks that systems engineers are
conversely, in a constraint driven model the mission assigned. One often quoted rule of thumb is to multiply
should deliver the desired scope, in the time allowed, your most accurate cost and schedule estimate by pi
within the budget allocated, and to the quality aspired to. (3.14) to get a realistic estimate, or the constant e (2.72)
The systems engineering processes tailoring therefore is if you’re feeling optimistic. While there are always
a conversation between all stakeholders which is clearly unknowns that will trip up any program plan, there needs
defined at the beginning of a mission, so that mission to be a recognition that there are significant outside
expectations and programmatic constraints can be factors that drive this perception. One significant one is
realized as early as possible in the mission lifecycle. the inherent optimism that is required when making a
program plan under competitive circumstances. A
SYSTEMS ENGINEERING PROCESSES green-light schedule that assumes zero problems will
Though there are several definitions of the various always be unrealistic, especially under cost-plus
systems engineering processes in use today this paper contracting; Firm-fixed price contracting has a strong
will reference the IEEE 15288 definitions and process tendency to bring clear-eyed realism to cost and schedule
breakdown. Table 1 presents the processes that we will discussions, with those most familiar with the challenges
be discussing in this paper, broken down into Technical of the project able to inject their concerns into the
Management Processes and Technical Processes planning process. This, in turn, forces difficult
following the breakdown given in the DOD Best discussions significantly earlier in the program,
Practices for Using Systems Engineering Standards requiring more realistic cost-benefit trades to be made at
document [10]. Note that several of the processes called the user level, and helps temper unrealistic expectations
out in 15288 are considered out of scope for this paper, from mission sponsors. Cost overruns are still a
consisting of Acquisition, Supply, Life Cycle Model significant fact of life, but when constraints imposed on
Management, Infrastructure Management, Portfolio missions are rooted in reality and cancellation is more
Management, Human Resources Management, Quality than a threat, but a valid option for a program, cost and
Management, and Knowledge Management. Though schedule realism can become part of the organizational
critical to the success of an organization, this paper will culture.
be neglecting discussion of the larger processes and
focusing on the processes that are within the scope of a Generally, even the cheapest missions will still undergo
single project. the full review process that is inherent in the Project

Clements 3 33rd Annual AIAA/USU

Conference on Small Satellites
Assessment and Control process. Tailoring is applied to with appropriate explanation by the acting person. Flight
the individual review, with a certain level of informality hardware handling practices include ESD safety,
and relaxation of rigor to the requirements that are levied smocks, hairnets, gloves, and a class 10K clean
at each review. One critical piece that is shared between environment.
this and the Decision Management process is to push the
decision making power as far down the organization as Measurement processes are generally associated with
possible [7]. This has the effect of minimizing the need tool location and calibration tracking. Poor calibration
to bring the reviewers up to speed on the current state of practices can come back to damage a spacecraft in the
the mission and allows the review to focus on the current most inopportune times, giving little options to scale
issues that need addressing before moving forward. back calibration practices. In general, tools lost inside
Continuity of management (driven by short schedules) spacecraft hardware can be mission ending, but with
also helps this process drastically, maintaining spacecraft as small as these there are few opportunities
familiarity with the mission and knowledge of the to misplace tools.
previous decisions.
For many of these systems engineering processes there
Risk management is generally one area where process is is the recognition that while process can improve
tailored generally falls to an identification of the primary consistency, in can also reduce individual responsibility
risks at every review, with appropriate mitigation as it and ownership. Delegation of authority is critical to
relates to the mission success. For many missions, large improve ownership and responsibility such that
risk items that would be unacceptable for higher class relaxation of process can reduce cost and schedule
missions are routinely accepted, such as the use of without catastrophic results.
industrial quality electronics and unknown radiation
susceptibility (generally a community practice). TECHNICAL PROCESSES
Mitigating the lack of more structured risk management The technical processes in Table 1 generally follow a
is the smaller teams that are enforced by the low budgets mission flow, with the exception of the System Analysis
of these missions. The improved communication process, which is cross cutting throughout the mission.
amongst the small team allows the systems engineers to Figure 2 shows the connection between the processes
discover the risks inherent in specific courses of action. and the mission lifecycle for a satellite mission.
Also key is having the expertise available necessary to
understand new found risks and mitigations quickly. Concept development

The adoption of new toolsets such as Confluence or other The early stages of mission lifecycle are likely the least
wiki-based systems has enabled significantly lower well defined. The goals of the early stages of mission
friction information management processes than development is to identify a self consistent set of mission
predecessor file-based toolsets. Accompanying objectives, requirements, and architecture that are
delegation down the organization structure of approval feasible within cost and schedule constraints.
and review authority, as well as relaxation of some of the Sometimes this is straight forward, such as when a
related formalisms also simplifies and speeds customer approaches with a well scoped component test
information transfer through the wiki-based toolsets. idea. Usually there will be several iterations of concept
development, including cost and schedule estimates,
Configuration management and quality assurance are returning to the customer to discuss options and
often lumped together because of the overlap in both possibilities, before a committment is made.
objectives and processes. A significant relaxation that is
applied is the ability to work both tests and assembly Concept development generally consists of rapid
procedures without detailed procedures. When the test iterations on the systems budgets, such as
requirements and test flow has been discussed with the communications, power, pointing, navigation, etc.,
appropriate approvers the test can be run and evaluating changes to the mission and experiment
documented live, providing a significant speedup. CONOPS enabled by various options. Impacts to the
Integration with the wiki-based information requirement set and system architecture guide new
management system has also improved the ability to decisions. Key performance parameters drive decisions
capture critical information from the procedure. Some and guide the selection process.
relaxation of the standard two person rule has been
tolerated, mostly in relaxing the knowledge requirements
of the second person, where a tech or engineer with
unrelated expertise can review and sign off on an action

Clements 4 33rd Annual AIAA/USU

Conference on Small Satellites
 IEEE 15288 Systems Engineering Activities
Lifecycle Activities
SE Phases and System Interactions

1) Mission
Analysis • Mission Statement & Objectives
• CONOPS & Use Cases
2) User Reqmts • Constraints
Definition

• Requirements Analysis Feedback,

3) System Reqmts
Reality Check,
Definition 6) System Analysis
Iteration
 SRR – Decision Point

4) Architecture Systems Design Model Rev. 1

• Architecture & System Definition
Definition • CONOPS
• Constraints
 PDR – Decision Point Baseline • Requirements
Specifications • Architecture
• Design to Requirements • Performance Budgets
5) Design • Make / Buy • Cost
Definition • Software Architecture
• S/W & H/W Prototyping Availability &
Performance Evolution
 CDR – Decision Point

• Procurement Systems Design Model Rev. 2

• Fabrication Specs • CONOPS
• EM & FM • Constraints
7) Implementation Results • Requirements
• Flatsat / EM Integration • Architecture
• Functional Test Dev. ICDs • Performance Budgets
• Flight S/W & Ground S/W Dev.
• Cost

 IRR – Decision Point

Evolution
Operations Exercises, Rehearsals, and Dress Rehearsal

8) Integration • Flight Integration

• Electrical, Mechanical, & S/W ICDs
Systems Design Model Rev. 3
• CONOPS
• Functional/Performance Testing Reqmts • Constraints
Results • Requirements
 TRR – Decision Point • Architecture
9) Verification • Performance Budgets
• Environmental Testing Reqmts • Cost

 PSR – Decision Point

Mission Planning Toolset
• Launch Preparation & LBCT • On Orbit Handbook
10) Transition • Flight Rules
 MRR – Decision Point • Operations Procedures
Model • Experiment Plan
Validation • Space Vehicle Handbook
• Launch
• Performance Budgets
11) Validation Performance • Mission-Unique Planning
• L&EO Operations S/W
Predictions
12) Operation
• Nominal Operations Performance Predictions
13) Maintenance

• Program Final Reports

• Lessons Learned

14) Disposal • End of Life Disposal

Figure 2. Systems engineering processes and the mission lifecycle.

Clements 5 33rd Annual AIAA/USU

Conference on Small Satellites
The baseline for the system is implemented and mission logic may be able to fit in basic microcontrollers,
documented in a system design model which consists of significantly reducing the time and financial investment
the CONOPS, requirements and constraints with required for the software development.
functional, performance, and environmental testing
defined, architecture, and the performance and cost Certain judicial enhancements to the mission at this
budgets. Further detail is required in a risk assessment design stage can minimize cost and personnel
and mitigation plan. The generation of a self consistent commitments during both testing and operations. One
system design model is necessary to progress to PDR. requirement that is generally carried on AFRL/RVEN
missions is to be power positive in a tumble. This
This top level description of the concept development requirement enables the critical components to be
process most likely applies across all mission classes, the reduced to the power, TT&C, and connecting
key ideas that change with mission class is that process subsystems (usually command and data handling). The
is looking for a well scoped minimum viable product that elimination of the attitude determination and control
there is reasonable agreement is worthwhile to embark subsystem from the system safe mode allows for both
on for the cost and schedule resources available. This simplified operations (e.g. business hours only,
can be low risk, such as a widget testing mission, or high progressing to unattended operations), and a reduction in
risk, such as attempting to interface with a global satcom testing in the ADCS system, due to the knowledge that it
constellation that is not a critical subsystem.

Design definition System analysis

Between PDR and CDR the design is fleshed out through The system design model is the central analysis tool that
procuring or developing the subsystems and components supports the systems analysis portion of the systems
that meet the detailed requirements. One simplification engineering process. The model captures the mission
applied is a strong preference towards buy in make/buy and experiment CONOPS, the requirements flowdown,
decisions. Full design rigor is generally expected when product break down and work break down structure, and
the decision is to make the component in house. the ICDs.

One simplification to the review and approval process The interaction between the system design model and the
that can be adopted is a peer technical review, which is a system changes throughout the mission lifetime. Most
detailed, but often informal, assessment of the work of the design work on the mission occurs in the system
conducted on a component, subsystem, system, etc. The design model prior to PDR. Between PDR and CDR the
intent is to get a second set of eyes to better catch errors, model is updated to reflect component availability and
omissions of best practices, cross pollinate ideas, and to feasibility, cost benefit analyses, design trades, and
provide more cross-team communication. This review evolving schedule and cost constraints. The final
may come from a subject matter expert or similarly CONOPS scenarios, design, and expected performance
skilled engineer from another project. are captured at CDR.

In many cases it is quicker and cheaper to begin After CDR the model serves as the basis for defining test
prototyping early in this process, allowing the engineers campaigns and incorporating test results into
to evaluate design and component selection decisions performance predictions. The model informs flatsat,
while providing time to correct mistakes. The increasing hardware-in-the-loop and software-in-the-loop testing
complexity the various ICs available today increases the and provides the proper location to incorporate the
challenge of catching errors at the schematic level, often record as-built performance and calculate system
the only way to determine if a chip can perform the margins and capability. It also provides the ability to
required task is to prototype the circuit and work out the analyze the impact of a failed test and informs the
proper settings by hand. decision to modify the design, modify the test, or accept
it as is with a waiver.
Canonically, software development work prior to CDR
should be limited to architecture, prototyping, and In AI&T, the model helps specify the functional and
planning. However, most missions can attest to the environmental testing to ensure a test-as-you-fly
wisdom of an early start to the software development. In approach. As final testing wraps up the model is used to
this case, the use of non-EEE parts can significantly develop operations plans and a mission planning toolset
enhance the capability of the processing on the for use during early, nominal and contingency
spacecraft, and has enabled significant sophistication in operations.
the flight software of cubesat missions. At the same
time, if mission scope can be reduced sufficiently the

Clements 6 33rd Annual AIAA/USU

Conference on Small Satellites
Implementation alignments, and less on the integration of more robust
The functions of implementation are the procurement systems.
and fabrication of the various parts, components, and
The testing and verification of constraint-driven
subsystems. One particularly powerful simplification of
missions also varies significantly from the traditional
this process in the use of a flatsat, where non-flight
paradigm. While the same objectives of verifying that
boards and harnesses are electrically integrated in a
the system will survive launch and perform the mission
tabletop setting. This encourages rapid identification
objective still apply, the level to which this verification
and correction of flaws in design, ICD mismatches, and
is performed is where constrain-driven missions vary the
most non-mechanical issues. The flatsat allows for
most. For these missions, it has been found the that the
breaking connections and break-out box level
greatest return on investment comes from the following
verification of key measurements that are infeasible after
basic tests:
mechanical integration

The flatsat also allows for early functional test Functional Day-in-the-Life (DITL)
development, which provides time for iteration on the DITL testing, when properly designed, should accurately
functional test procedures and helps in catching design demonstrate the critical functionality of the spacecraft.
flaws, allowing for later flight hardware functional tests This usually focuses first on initial startup and system
to only focus on workmanship flaws. A heavy focus is checkout and then exercises the operational modes.
placed on test scripting. Some simple error detection and recovery testing may be
performed but it is not the intent of constraint-driven
The flatsat also provides an ideal platform for flight DITL to exercise all of the edge cases but to simply
software testing. The acceleration of flight software verify that the system performs as intended. This test
development on the flatsat is likely sufficient specifically includes the launch and early operations
justification for the apparent extra effort even without the sequence.
other advantages described here.
Power Characterization
Assembly, Integration, & Testing
As the power subsystem represents the lifeblood of the
The AI&T phase of any mission can make or break both spacecraft, significant efforts are expended to verify the
a mission’s schedule and budget. During this phase of full functionality of the subsystem. This includes
mission development, many of the investments or shot verification of the depth of discharge, recharge through
comings made in the earlier missing phases are realized. solar panels, autonomous recognition of safety limits on
the battery, proper inhibit functionality, load testing and
Traditional mission AI&T focuses heavily on the
switching, and proper telemetry production.
carefully developed integration procedures with multiple
levels of inspection and may even include the
Long Range Communications Verification
construction of an engineering unit to test these
procedures. These practices, while well suited for Small satellite systems present a unique opportunity to
Requirements-driven missions, significantly increase test a full end to end communications path of the satellite
both the cost and schedule for the mission. For that simply could not be performed with larger systems.
Constraint-driven missions, similar levels of mission Due to their size, the satellite can either be tested by free
assurance can be achieved through the application of air radiating with a significant distance between the test
some simple design practices and lean integration antenna and the satellite or even with an actual ground
processes specifically applied to mission critical station asset. It has been found that many issues can be
integration activities. discovered by performing a long range test that would
otherwise be missed when using either an antenna hat or
In general, small satellite missions are designed and built performing attenuated hardline tests.
by much smaller teams than their traditional
counterparts. This allows the design team to also act as Command and Execution Test
the AI&T team. Having these functions so closely
coupled allows the AI&T team to become experts with Full verification of the software functionality is required,
their system during the design and since they don’t though there is some flexibility on whether that is
handoff AI&T to a separate team, there is less need to performed on the flatsat, flight vehicle, or a simulator.
meticulously design integration procedures. With this This is an execution of each command in the Command
level of understanding of the design intent, procedures and Telemetry List (CTL). The depth to which all the
can focus on critical integration activities, such as optical various permutations of arguments for each command is
verified is allowed to fluctuate depending on the mission.

Clements 7 33rd Annual AIAA/USU

Conference on Small Satellites
Full Functional Test This operations method is achieved through the careful
Functional testing on the balance of the subsystems is design of the constraint-driven system to include two
allowed to stay at a high level, emulating the expected design principles. The first of these is a tumble proof
use cases that each component may see in operations. If COM link. By providing a communications link that can
failures are encountered further investigation is required. still close the link with the ground even in a tumble,
Often there are edge and corner cases that are not well operators can recover the vehicle from anomalies much
explored or tested, and these can be discovered on orbit. quicker as well as monitor the system state of health even
The expectation is that as long as the critical subsystems in if it currently is unable to recover from a current power
are well characterized these faults are recoverable and condition. Once the power system recovers, operators
can be dealt with during operations. can then proceed with bringing the system back online.

The second operations enabling principle is to utilize the

CG/MOI Testing and Polarity Checks DITL testing to develop mission operations scripting. By
These tests gather the required information to ensure that developing and utilizing this scripting during the testing
the ADCS system and algorithms are provided with the phase, these command sets can be “canned” and used for
most accurate information. The polarity checks also future operations. By designing in this way, operations
ensure that the sensors and actuators were installed planning can then be accomplished during a weekly
correctly. planning meeting rather than the more traditional daily
planning.
Other tests that may be performed, given the specific risk
tolerance posture of the mission, these include CONCLUSIONS
EMI/EMC testing, detailed ADCS testing, and payload The majority of space organizations have evolved to be
performance testing. requirements driven such that meeting mission goals,
and scope, take a level of precedence over cost and
Vibration Testing schedule due to the limited access to space. However, as
More traditional systems may test all components access to space continues to expand for small satellites,
independently prior to integration and modeling the and the need for rapid capability development increases,
integrated system prior to full vehicle vibration testing. schedule and cost are driving mission lifecycles. These
Constraint-driven missions can realize significant cost Constraint-Based missions require tailored systems
and schedule savings by only vibration testing the fully engineering practices that prioritize demonstrated
integrated system and limiting modal modeling to only capability with a lower performance over
extremely sensitive components. undemonstrated capability with higher performance. The
small satellite community should adopt a process that
Thermal Vacuum Testing verifies mission success allowing the mission validation
to occur on orbit allowing rapid demonstration of
Testing the system under both hot and cold vacuum
capability.
ensures that the system will perform as designed on orbit.
While the duration and number of cycles can vary from References
mission to mission, limiting the number of cycles can
significantly reduce the cost and schedule. 1. Swartwout M., “CubeSat Database,” Saint Louis
University, 2019.
MISSION OPERATIONS [Link]
e/cubesat-database
Traditional mission operations consist of several
operators sending command sets up to the spacecraft in 2. Swartwout, M., “CubeSat Mission Success: Are
a serial process. This method of controlling is well suited We Getting Better?,” Proceedings of the CubeSat
for the requirements-driven mission as it provides a man Developers’ Workshop, CalPoly, 23 April 2019.
in the loop to ensure that the spacecraft remains 3. “Global Prospects for the Small Satellite Market,
operational as much as possible. 2018-2022,” [Link], 27
March 2019.
For a constraint-driven mission this operations paradigm
must also be adjusted. Many of these missions have 4. “Global Small Satellite Market Insights, Forecast
much more constrained operations budgets that drive a to 2025,” The Market Reports, January 2019.
push to operate as “lights out” as possible. “Lights out” Report Code: 1237587.
operation is a method of operating a spacecraft with 5. “Design, Construction, and Testing Requirements
either very limited or actually zero controllers sitting in for one of a kind space equipment,” SPVT-2016-
the mission control center.

Clements 8 33rd Annual AIAA/USU

Conference on Small Satellites
 005, ORIGINAL ED., DOD-HDBK-343.
February 1986.
6. Johnson-Roth, G., “Mission Assurance Guidelines
for A-D Mission Risk Classes”, Aerospace
Corporation, TOR-2011(8591)-21, June 2011.
7. Jasper, L. E. Z. and L. Hunt and D. Voss and C.
Jacka, “Defining a New Mission Assurance
Philosophy for Small Satellites,” SmallSat
Conference, Logan, UT, Aug 4-9, 2018. Paper No.
SSC18-WKII-05
8. Tolmasoff, M. and R.S. Delos and C. Venturini,
“Improving Mission Success of CubeSats,”
Proceedings of the U.S. Space Program Mission
Assurance Improvement Workshop, The Boeing
Company, El Segundo, CA, June 2017.
9. Johnson, M. A. and P. Beauchamp and H. Schone
and C. Venturini and L. E. Z. Jasper and R.
Robertson and M. Moe and J. Leitner and F. Tan,
“The Small Satellite Reliability Initiative: A
Public-Private Effort Addressing SmallSat
Mission Confidence,” SmallSat Conference,
Logan, UT, Aug 4-9, 2018. Paper No. SSC18-IV-
01
10. “Best Practices for using Systems Engineering
Standards (ISO/IEC/IEEE 15288, IEEE 15288.1
and IEEE 15288.2) on Contracts for Department
of Defense Acquisition Programs,” Office of the
Deputy Assistant Secretary of Defense, April
2017, [Link]

Clements 9 33rd Annual AIAA/USU

Conference on Small Satellites