ESMD Course Material : Fundamentals of Lunar and Systems Engineering for Senior Project Teams, with Application to a Lunar Excavator

Contact: David Beale,

Chapter X
Lunar Engineering Handbook
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Additional Resources
Contact Info
About the Authors

A lunar excavator's mission is to dig lunar soil.

Figure 1  A lunar excavator's mission is to dig lunar soil

Chapter X: A Roadmap to Design an Excavator Based on Systems Engineering

The objective of this chapter is to present condensed and hyperlinked course material that chronologically steps through the systems engineering design process to design an excavator.  Following a link will lead to a more detailed explanation and/or additional materials.


  1. The Systems Engineering Method
    1. Classroom Discussion – How to Design an Excavator
  2. The Mission Objective
  3. Background Information and Science
    1. Background Information from Chapter 1
    2. Lunar Physics – Background Information from Chapter 5
    3. Thermal Analysis and Control
  4. Envision the Disciplines and Teams
    1. Management Structure
    2. Communications
  5. The Phases of the Life Cycle
    1. The Vee Chart
    2. The 11 Systems Engineering Functions and the SE Functions Triangle
  6. Appendix

The Systems Engineering Method

(The Systems Engineering Method is fully explained in Chapter 2. ) 

First a bit of systems terminology about elements and hierarchy ……

Our goal is to create a product.  The "system" and the "product" are the same thing.

Elements of a system are not just hardware but can also include software, and can even include people, facilities, policies, documents and databases.

A system can be broadly defined as an integrated set of elements that accomplish a defined objective.

A subsystem is a system in its own right, except it normally will not provide a useful function on its own, it must be integrated with other subsystems (or systems) to make a system. 

Components are elements that make up a subsystem or system. 

Parts are elements on the lowest level of the hierarchy, and are often COTS (Commercial-off-the-Shelf).  For example a resistor, link, bolt, etc. are parts.  Software could also be a "part".

Example of a system and its subsystems, components and parts: A dish antenna system on earth that receives a radio signal from a satellite, and that will automatically point the dish toward the satellite moving across the horizon.  A combination of elements consisting of a motor, position and velocity sensors, controller, software and wires to automatically position the dish toward a satellite is the motor control subsystem in the dish antenna system. The motor is a component in the motor control subsystem. The dish antenna system includes the following subsystems: 1) the motor control subsystem, 2) the dish is a part and along with the electronics make up the communication subsystem, 3) the structures subsystem, and 4) the electrical power subsystem.

The Engineering Design Process (EDP)

 Imagine you were asked to design a part, component or subsystem, for example a can opener, a mousetrap, a bicycle, an automotive suspension, etc.

Question: What process would you follow?

Answer: The Engineering Design Process (EDP) which contains the following steps in Figure 2:

  1. Project Definition – meet with stakeholders, define the mission objective(s), understand the problem.
  2. Requirements Definition and Engineering Specifications – carefully and thoughtfully develop requirements that will guide the design creation to follow.  Clearly document the requirements and receive stakeholder approval before proceeding.
  3. Conceptual Design – generate ideas, compare using trade studies, models, proof-of-concept prototypes, down select to focus on a meritorious concept in the next step.
  4. Product Design, Fabrication and Test – complete all detailed drawings, make or purchase parts and components, assemble and measure performance.  If performance requirements are met, begin manufacturing.
Project Definition Requirements Definition Conceptual Design Product Design Manufacturing

Figure 2 Steps of the Engineering Design Process

Now consider designing a system with many subsystems, which are made up of components and parts. It may require software and mechanical, electrical and electronic hardware. 

  • System examples: The Space Transport System (STS) in Figures 3, the Mars rover and satellites.  Not so complex systems are a camera, a programmable microwave, a refrigerator.  The chart of Figure 4 shows the "tiers" of a "product hierarchy" for the orbiter portion of the STS.  The STS contains the Orbiter, the External Tank and the 2 Solid Rocket Boosters as tier 1 (sub)systems.   Tier 2 is shown for the Orbiter only, and tier 3 for the Avionics (sub)system only.  Other (sub)systems at tier 2 might include the orbiter power system, robotic arm, communications, payload, landing gear, engines, piping, etc.   It is permissible to call a "subsystem" a "system", as is done in Figure 4.  Whether a subsystem is called a system or a subsystem is a choice made by a manager.  

 Buzz Lightyear standing in front of a space shuttle on the launch pad



 Figure 3: STS and Buzz Lightyear (


Figure 4. STS and some of its (sub)systems in a product hierarchy


Figure 5. Common Satellite Subsystems

Although quite different products, there are common types of subsystems in satellites, rockets and  rovers.  These common types of subsystems include in Figure 5:

  • C&DH = Command and Data Handling,

  • EPS=Electrical Power System,

  • ADC=Attitude Determination and Control,

  • Structures=Structures and Mechanisms,

  • COMM=Communications,

  • Thermal=Thermal Control,

  • Ground Station,

  • And Payload.

 Should we call the COMM a subsystem or system?  Again, either terminology is OK!  But to eliminate confusion the convention hereafter will be to call the final product the "system", and every other system below the top tier a "subsystem".

Classroom Discussions – How to Design an Excavator

First you receive a mission objective from your NASA sponsor.  A possible mission objective for the "teleoperated lunar excavator" is:

Create a lunar excavator prototype for studies on the earth that will connect to a standard NASA mobility platform plate (where there is 19" from ground to bottom of excavator-rover interfacing plate, see Appendix), which dumps the soil into an attached bin.  The excavator weighs less than 100 kg (not including the bin and mobility platform).  Target less than 150 W power and capable of digging 250 kg/hour of regolith, and can be controlled from an out-of-sight ground station.

 Classroom Discussion #1:  What subsystems might be needed for a teleoperated lunar excavator? 

Note that:

  • In order to create a system to meet the mission objective, design teams would eventually be formed, one team for each expected subsystem.

  • Specialty design teams will be applying the EDP to design their own subsystem.

  • The teams will also be applying "Concurrent Engineering", where multiple subsystems are being designed simultaneously by different teams, with strong collaboration across boundaries of subsystems and disciplines.  "The objective of concurrent engineering is to reduce the produce development cycle time through a better integration of activities and processes" - NASA Systems Engineering Handbook SP-601S.

Classroom Discussion #2: List all the tasks you think should be performed to make sure that separately designed subsystems, when integrated together, will create a system able to perform the mission?

 The instructor should allocate enough time for the class to discuss, and the professor lists the answers on the board.  Alternatively, the class may be broken up into teams of 5 students that work together for 15 minutes, and then each team lists their answers on the board.  After this exercise, students will hopefully have a good feel for what "Systems Engineering" is, without it having been defined yet!  

A partial answer is hidden in text format.  To reveal it, press:

So Now What is Systems Engineering (SE)?

Systems Engineering (SE) is the engineering process to create a system.  It is a structured process based on concurrent engineering and that incorporates the Engineering Design Process.  

One definition of SE is as follows (NASA Systems Engineering Handbook SP-601S):

"Systems Engineering (SE) is a disciplined approach for the definition, implementation, integration and operations of a system (product or service) with the emphasis on the satisfaction of stakeholder functional, physical and operational performance requirements in the intended use environments over its planned life cycle within cost and schedule constraints. Systems Engineering includes the engineering activities and technical management activities related to the above definition considering the interface relationships across all elements of the system, other systems or as a part of a larger system."

 This and other definitions of systems engineering are presented in Chapter 2.

The Vee Chart (Figure 9) was created to guide and simplify the application of the SE process through a series of Phases.  Within each phase of the Vee chart, you will sequentially consider application of the 11 Systems Engineering Functions (Figure 10).  

The Mission Objective

NASA is represented by Robert Mueller as the customer or stakeholder in the project, whose expectations will lead to statement of a mission objective.   The team should make sure that the mission objective is clearly stated, it could also include functional, physical and operational performance requirements for the environment and life (in the strictest sense, requirements are not usually a part of the mission objective as presented in Chapter 2, but we bend the rules a bit here). 

 Here are some examples of mission objectives:

 The Electro-Mechanical Excavator Prototype:

Create a lunar excavator prototype for studies on the earth that will interface to a NASA mobility platform (19" from ground to bottom of plate), dumps the soil into an attached bin, weighing less than 100 kg, not including the bin and mobility platform. Target less than 150 W power and capable of digging 250 kg/hour of regolith.

 The Autonomous Excavator Prototype:

Create a lunar excavator prototype for studies on the earth that will interface to a NASA mobility platform (19" from ground to bottom of plate), dumps the soil into an attached bin, weighing less than 100 kg, not including the bin and mobility platform.  Target less than 150 W power and capable of digging 250 kg/hour of regolith, and functions autonomously.

The Wireless Excavator Prototype:

Create a lunar excavator prototype for studies on the earth that will interface to a NASA mobility platform (19" from ground to bottom of plate), dumps the soil into an attached bin, weighing less than 100 kg, not including the bin and mobility platform.  Target less than 150 W power and capable of digging 250 kg/hour of regolith, and can be controlled from an out-of-sight ground station.

On the moon the excavator will be digging lunar soil called "regolith". The regolith will be needed for a lunar base - for making oxygen, for base construction, etc.  The "mobility platform" is a wheeled or tracked vehicle with a motor that will move and locate the excavator.  The completed student excavator is attached to a NASA mobility platform via an interfacing plate (see Appendix).  You can see a prototype mobility platform at .  Other mission objectives may require you to build your own vehicle to drive the excavator.

 Implicit in the creation of a "lunar excavator prototype" that will be tested on the earth is that the team has enough forethought to realize that the design, and specifically materials and components, must reflect the special concerns and limitations that the lunar environment imposes.  For instance, a gasoline powered engine in a prototype may not be a good choice since this type of actuator requires air for combustion and hence cannot be used on the moon.  Chapter 5 Chapter5.htm#TheLunarEnvironment was written to provide the designer with the necessary background on the lunar environment.   Also, a chapter entitled Component Design and Selection Chapter6.htm#ComponentandMaterialSelection provides useful information for helping you select components that have been designed for the space environment.  Just as the Cube Satellite program ( allows student teams to build satellites that will operate in space, in the foreseeable future student teams may be making excavators that they will design, build and operate from a campus ground station controlling an excavator on the moon.

 So, in the future, student teams could build the Lunar-Ready Excavator with the following mission objective:

Create a lunar excavator that dumps the soil into an attached bin, weighs less than 100 kg, uses less than 150 W power, is capable of digging 250 kg/hr of regolith, fits within a cargo space of 1 m3, with operational lifetime of 5 years, and can be controlled from a ground station, run either autonomously or from ground station commands.

Be prepared to perform test your prototype.   If necessary you can create your own soil bin using sand or other commercially-available material available at a garden center, or consider going to a beach if one is nearby.  Dry concrete mix is more representative of the soil properties of regolith than sand and may be the most representative choice of any easily acquired material.  In the future expect that locations, such as NASA centers, will have bins loaded with regolith simulant such as JSC-1a for testing.   

Background Information and Science

Before going onto the next phase of the design you will need to learn about the moon.  Students and practicing engineers will find a hostile environment that requires careful material selection, analysis and design so that equipment will be able to operate successfully.   

Background Information from Chapter 1 


·         The moon is quite different than the earth as a future sight for habitation.  Check out the comparison of the earth and moon.

·         What is an excavator?  An excavator for the earth will look much different than for the moon.   As you learn more about the needs of a lunar excavator and the lunar environment, you may not feel these excavator designs are the best choice for lunar regolith excavation.

·         The history of the lunar missions can be seen at  This is a really neat site.  Click on any of the vehicles (orbiters or landers) to learn more about that mission.   Look at the LCROSS and LRO missions scheduled for late in 2008, which are intended to look for water in the lunar craters.  When NASA next sends humans to the moon, it will be flying the Ares launch vehicle (the rocket) attached to the Crew Exploration Vehicle (CEV) named Orion. 

·         The lunar rover or "moon buggy" operated on the surface of the moon which astronauts drove almost 7 km from the lander.  A lot can be learned from successful space systems of the past and applied to future designs.  Chapter 6 goes into the details of the design of the lunar rover .

·         Much of the future lunar base will be constructed by robots like "robonaut" and "centaur".  The future rover may look like the "chariot"

·         A lunar base architecture (base layout) at the lunar equator is shown in Chapter 1.  Location 1 is a pit where regolith has been excavated, and brought by a hauler (2) to a processing plant (3) where oxygen is extracted from the regolith.  Other parts of the base include a nuclear reactor (4), habitat and airlocks (5), radio tower (6), dish antenna (7), radiators (8) and (9), fuel cells (10) and Ga-As photovoltaic solar cell arrays (11).

·         A base at a pole can take advantage of continuous light on the top of mountains for continuous solar power, and cold craters which may contain hydrogen as possibly water ice. 

·         To further that direction the NASA’s Exploration Systems Mission Directorate (ESMD) is dedicated to creating a "constellation of new capabilities, supporting technologies and foundational research that enables sustained and affordable human and robotic exploration". 

·         ITAR is the International Traffic in Arms Regulations (ITAR).  It is a law and punishable with fines and imprisonment if violated.  Its purpose is to control the export and import of defense-related articles and services, which often includes work on NASA projects.  Designs, test data, software codes, etc. should not be shared with non-US citizens.  Or, if you have access to such data you are not allowed to share it with non-US citizens. 

Lunar Physics – Background Information from Chapter 5 

Lunar Gravity and Lunar Vacuum

Gravitation acceleration on the moon’s surface is 1.622 m/sec2, or about 1/6 that of earth.  Without an atmosphere the surface of the moon has almost no pressure that an atmosphere would create, and is classified as a "hard vacuum".    

Lunar Day and Night 

The lunar day and night each last about 14 earth days, except for the poles.  For ½ the year at the poles, the sun is barely above the horizon.  For the other half, the sun is barely below the horizon.

Figure 6 Because of the moon’s small spin angle variation, the sun’s elevation varies between +/- 1°32’ above and below the horizon near the lunar poles. High mountains on the shadow side in the figure can be perpetually sunlit, and craters on the sun side in the figure can be perpetually dark.


Radiation striking the moon includes electromagnetic wave radiation that is classified and characterized by a wave and its frequency, and includes visible light.   A second form of radiation is energized particulate radiation.   Radiation not only affects temperature.  The more energetic radiation of either form can ionize material, degrading performance and reducing useful life.   Humans, organic materials (including plastics and composites) and electronic equipment are particularly susceptible and will need to be protected.  The sources of the radiation include Solar Wind, Solar Cosmic Rays from Solar Particle Events (SPE), and Galactic Cosmic Rays (GCR).  

Surface Temperature



Daytime High

Nighttime Low









Mean Surface







Equator (0° Latitude)





















Dark Polar Crater







 The above table is the temperature of the surface of the regolith.  Notice the highest high temperature  (at the equator) and the lowest low (in a dark polar crater).  During the day the temperature of exposed equipment could be quite different from the surface temperature.   An excavator's temperature on the shaded side will be significantly lower than on the sunny side.  Design issues include thermal stresses and thermal distortions, brittle failure, and the possibility of temperatures outside the useful range for electronics and batteries.  The chapter on thermal control was written to help deal with temperature issues. 


Micrometeoroids are meteoroids (naturally occurring solid bodies traveling through space) that are less than 1mm diameter, and based on their average density their mass will be less than .01 g.   The hit the moon at high velocity and could damage equipment if large enough.


Neil Armstrong, as he stepped onto the moon, stated:

"the surface is fine and powdery.  I can pick it up loosely with my toes.  It does adhere in fine layers like powdered charcoal to the sole and sides of my boots.  I only go in a small fraction of an inch.  Maybe an eighth of an inch, but I can see the footprints on my boots and the treads in the sandy particles"

  • Lunar regolith refers to all the fragmented rock material that covers the moon.  Lunar soil is technically regolith excluding rocks larger than 1 cm in size.   Lunar dust is technically defined as having particle sizes less the 20 μm with a bulk density of 1.5 g/cm3.
  • The thickness of regolith layer is estimated to be 4-5 meters thick in mare regions (lunar planes) and 10-15 m in older highland regions (plains of higher elevation than the mare). 
  • The first few centimeters to tens of centimeters is a well-mixed or "gardened" zone, created by the churning of repeated micrometeoroid strikes. 
  • Lunar soils are far more abrasive than earth soils; they are akin to broken glass.
  • The average mass percentage of major constituent elements in lunar regolith in the lunar highlands is 45% oxygen, 21% silicon, 13% aluminum, 10% calcium, 5.5% magnesium, 6% iron with less than 1% titanium, sodium and sulfur.   These elements are chemically bound in the minerals that make up the regolith and will require processing to extract. 
  • Lunar regolith is electrostatic (causing it to adhere to suits and equipment) and has low thermal and electrical conductivity (i.e. it is a good insulator).
  • The geotechnical (density, porosity) and engineering properties (cohesion, friction angle, bearing capacity) are important measures that determine lunar soil strength.  For construction of roads and habitats based on regolith, high strength is necessary.  Lunar soil strength properties are important factors when evaluating and comparing excavation methods.    

NASA has developed simulants that mimic lunar soil, such as JSC-1.  Prototype excavators will eventually need to be tested on a lunar simulant. 

Lunar Resources

 Here is a list of resources available and potential uses for a lunar base.  All these resources are in-situ, except for recyclable resources.  Using resources from the moon to sustain a lunar base is called In-Situ Resource Utilization (ISRU)

 Resource: Regolith (lunar soil) 

·         A source for oxygen for life support and fuel oxidizer

·         Water-ice and/or hydrogen if present, from the dark polar craters

·         Construction materials, such as

o   Concrete, by combining sulfur or epoxy cement with regolith aggregate

o   melted then cast into blocks

o   sintered into blocks, sintered roadways

o   fiberglass, fiber mats

o   cast glass, ceramics

o   metals for conducting wire, machinery, structural members, rope

·         Building material for habitats, garages, berms, landing pads, roadways.

·         Protection from radiation and as a thermal insulator.

·         Raw material for solar cell and solar concentrators

·         For extraction of trace elements, such as C and N

·         Helium 3 for fusion power


Resources: Solar Radiation

·         Solar energy from solar cells and solar collectors

·         Temperature difference from shadow to sunlight for closed-cycle heat engine (e.g. Stirling engine)


Resource: Vacuum Atmosphere

·         A platform for scientific studies (e.g. astronomy, vacuum experiments and vacuum manufacturing)


Resource: Low Gravity

·         Material processing


Resources from Recycling of Earth-delivered Materials

·         Reuse and scavenging of propellants

·         Recycling of trash for polymers, methane, propellant, hydrogen extraction

·         Reuse of rocket canisters for habitats

Thermal Analysis and Control

As previously mentioned the lunar thermal environment is quite austere and the environmental temperatures are usually extremely cold or hot.  Since temperature effects can be detrimental on lunar systems, methods of thermal analysis and control eventually become a necessary part of the design effort.   Extreme temperatures result from the lack of any atmosphere while exposed to either direct sunlight or no sun at all.  Therefore, the only heat transfer methods available on the lunar surface are either radiation, or conduction with the lunar soil.  In addition for most locations on the lunar surface (excluding the poles) the lunar day and night both last around fourteen earth days.   There are three areas of interests in defining the lunar thermal environment: the length of lunar nights, the direct and reflected solar flux, lunar soil temperatures, and associated lunar surface IR energy. Once the lunar environment is clearly defined and all environmental loads computed, then a thermal analysis can be performed to find the expected worst case hot and cold environments.   The methodology of this type of an analysis is demonstrated in a case study found in Chapter 7.     

Envision the Disciplines and Teams (follow this link to the team structure for a cube satellite project)

After receiving the mission objective, envision the subsystems needed to accomplish the mission.  The design of each subsystem is a task performed by applying the Engineering Design Process (EDP), and students of particular disciplines are best suited for certain subsystems.  For instance, on the cube satellite of Chapter 3, Structures and Mechanisms, Attitude Determination and Control, and Thermal Control could be performed by teams of mechanical and/or aerospace engineering students.   The Payload (a UV sensor) Subsystem was a team of electrical engineers and physicists.  Command and Data Handling were computer and electrical engineers.  Communications, Electrical Power System and Ground Station were performed by teams of electrical engineers.

Management Structure

Figure 7 Management Structure

A possible management structure with teams is described below and based on Figure 7:

 Program Manager – This is your instructor with the usual teaching and grading duties.  As program manager he/she is familiar with NASA goals, and will make sure the team has correctly interpreted the mission objective.   He/she will make sure you will be or will have been taught the necessary material and have all the needed resources to complete this project.  Your instructor can answer most of your questions, or point you to other resources.   Important resources are listed in the references at the end of each chapter, at the "Additional Resources" tab, and also in the chapters themselves.  Lastly, remember that this is a student project, and the design and all related activities are you and your team’s responsibility. 

Project Manager - Concentrates on managing the overall project.  This includes scheduling, assuring mission objectives are met, decision making and responsibility for overall success of the project, and meeting regularly with the instructor.  His/her tools are the Work Breakdown Structure, Gantt Chart (for scheduling of reviews and tasks) and cost budget.

Systems Engineer – Guides the engineering of the project, with responsibility for all systems engineering functions.  His/her role is analytical, advisory and planning.  The systems engineer is part of management and works closely with the project manager and meets regularly with the instructor.   Some of his/her tools are the trade studies, requirements documentation, interfacing documentation and risk analysis.  The systems engineer will lead a systems engineering team to perform systems engineering tasks.  

Subsystem Lead Engineers – Concentrates on managing the technical aspects of the design of their particular subsystem, and working with the systems engineering on systems engineering tasks. 

Subsystem Team Members (Design Engineers) – Work on design of their particular subsystem within the systems engineering framework of requirements and interfaces. 


During the design formulation phases, the Systems Engineer will lead the effort as described below.   The Systems Engineer will conduct meetings where all teams, representing the required diversity of technical disciplines, are present and contributing.  It is important for student teams to "buy into" the Systems Engineering approach.   The Systems Engineer must keep the subsystem teams focused on designing to meet requirements and satisfy the mission objective.  Since the Systems Engineer is ultimately responsible for the successful integration of many subsystem products into a single system, the Systems Engineer is the "glue" that makes the whole thing work.   As a word of advice, do no choose your systems engineer or project manager until you have gotten to know the potential candidates.   Please see Chapter 2 by following this link to qualities of an effective systems engineer.

The Phases of the Life Cycle

The flow of the Systems Engineering process through the entire project life is called the Systems Engineering Life-Cycle.  The life-cycle is divided into phases that are described in the table below.  At the end of each phase a decision is made whether to proceed to the next phase or not; this decision is made during or after a review meeting with stakeholders.  Each succeeding phase of the life-cycle advances the development and maturation of the system design - from initial concepts, to operational system - and beyond to disposal.   Two tools – the Vee-Chart and the 11 Systems Engineering Functions – are needed to apply the systems engineering process. 


Phase Title


End of Phase Review

Pre-Phase A

Concept Studies

Produce a broad spectrum of ideas and concepts, establish mission objectives

Mission Concept Review (MCR)

Phase A

Concept and Technology Development

From multiple approaches develop a single system concept for the mission, with system requirements and architecture. Perform trade studies and identify needed technologies.

System Definition Review (SDR)

Phase B

Preliminary Design and Technology Completion

Establish a preliminary design, with subsystem requirements, interfaces, and with technology issues resolved.

Preliminary Design Review (PDR)

Phase C

Final Design and Fabrication

Complete the design and drawings, purchase or manufacture parts and components, code software.

Critical Design Review (CDR)

Phase D

System Assembly, Integration, Test and Launch

Assemble subsystems, integrate subsystems to create systems, test to verify and validate performance, deploy the system.

Readiness Review (RR)

Phase E/F

Operation and Sustainment/Closout

Operate System, decommissioning, disposal

Decommissioning Review

Figure 8. Phases of the Systems Engineering Life-Cycle

The Vee Chart

The Vee Chart from Chapter 2 and repeated in Figure 9 is a tool to help students remember and apply the life-cycle process.  The phases are on the legs of the Vee Chart, beginning at the top of the left leg.  The phases on the left leg (Pre-Phase A through Phase C) are the formulation phases, and are the decomposition and definition sequence. In the formulation phases the Systems Engineering process begins with the mission objective with stakeholder expectations in Pre-Phase A, from which the detailed requirements are "decomposed" - first creating them at the systems level, followed by the subsystem and component level.  Simultaneously and iteratively the architectures and designs are "defined"- again beginning first at the systems level and proceeding through the subsystems onto the components.  The end result of the formulation phases is a complete system architectural design that will satisfy requirements for the system, the subsystems and the components.     That is, the system is decomposed and defined from the systems level to the component level as the design process progresses down the left side of the Vee.  The architectural design is handed off to design engineers who detail design their subsystems to meet the architectural design's requirements.   Advancing upward on the right leg is the integration and verification sequence contained in Phase D.  Proceeding up the right leg the system is built from procured or fabricated parts and component, assembled into subsystems which are integrated across interfaces to create a completed functioning system.   Verification is testing to prove or demonstrate that components, subsystems and systems performs as per requirements. 

 Notice that some phases have been split to separate tasks within certain phases, e.g. D(1) through D(4) on the right leg of the Vee Chart.  Notice also that boxes on the same horizontal level are at the same level in the system.  For example, Phase B and Phase D(2) both operate on the subsystems level.  Phase B is concerned with detailing subsystem level architectures, requirements and proposing a verification tests for the subsystems - whereas Phase D(2) is concerned with physically building the subsystems and verifying using Phase B subsystem verification requirements.

 The Vee chart is divided by a horizontal line that reveals the responsibility boundary between the systems engineering tasks and the tasks typically performed by the design engineering teams applying the Design Process.  This boundary illustrates that systems engineering rarely ventures into the level of component design, and only ventures to the subsystem design peripherally, with responsibility for interfaces and requirements.   Lastly, the systems engineering duties may not all be handled solely by the Systems Engineer; the Systems Engineer may assign Systems Engineering tasks to others.  

 Vee Chart

Figure 9  The project life-cycle as a VEE chart  (R/A/C are the Requirements, Architectural Design and ConOps steps of Figure 10, SAITL is System Assembly, Integration, Test and Launch).

The 11 Systems Engineering Functions and the SE Functions Triangle

So what are the tasks that should be considered in each phase?  The tasks are the 11 Systems Engineering  Functions.  The 11 Systems Engineering Functions are shown in Figure 10 and include the five functions associated with the triangle, as well as six other SE functions.  The functions are a set of actions for each phase.  The mission objectives initiate the process.  The three major functions at the corner of the triangle – Derived Requirements, Architectural Design and Concept of Operations (ConOps) – are significant functions.  The double arrows of the triangle connects the functions performed during the student team "brainstorming" sessions during each of the formulation phases, and are guided by the systems engineer.  The double arrows also show the iterative nature of the process and the interdependence of the ConOps, requirements and architectural design.   The completed Derived Requirements, Architectural Design and Concept of Operations define a new system for that particular phase of the process.  Before a phase can be completed the student team must also consider the "Other SE Functions" (6 through 11); the consideration can be a brief one if the function does not warrant a significant effort.   Each function is explained below.

11 SE Functions

Figure 10  The Systems Engineering Functions, including the iterated functions shown on a triangle (NASA, 2002)

Function 1:  Mission Objectives are statement(s) that clearly document the goal(s) and constraint(s) of the mission.   Constraints are pre-imposed limitations on the project.  The mission objective follows from the stakeholders and their expectations.  Examples_of_Mission_Objectives

Function 2: Derived Requirements, or simply denoted as requirements, are succinct statements that state what must be accomplished, how well it is to be accomplished, and under any constraints or limitations. There are many kinds of requirements, including functional, performance, verification and interface requirements.  Requirements are level dependent; they are system (top level), subsystem, or component (bottom level) requirements.  Requirements are often expressed as "shall" statements. 

Examples of requirements:

Chapter 2 Examples: Chap2_Example_Requirements

Pre-Phase A Chap3_Pre-PhaseA_Example_Requirements,

Phase A Chap3_PhaseA_Example_Requirements

Phase B Chap3_PhaseB_Example_Requirements


Function 3:  Architectural Design Development  :  An architectural design (or just an architecture) is a “description of the elements, their interfaces, their logical and physical layout and the analysis of the design to determine expected performance”.  It is not a detailed design - that is performed by the subsystem design teams and is not a SE function.  It begins as a hierarchy of major subsystems on a block diagram (e.g., an organizational chart in PowerPoint) in Pre-Phase A with only one or two tiers, becoming more detailed by adding more tiers as progress advances through the phases.  


Examples of Architectural Designs:


Chapter 2 Examples: Chap2_A&D_Examples

Pre-Phase A Chap3_PrePhaseA_A&D_Example,

Phase A Chap3_PhaseA_A&D_Example

Phase B PhaseB A&D Example

A Product Breakdown Structure (PBS) is a detailed hierarchy of all the elements that make-up the system.  Examples are presented in Chapter 4:  Chap4_PBS

Function 4: Concept of Operations (ConOps) is a description of how the system will operate to meet stakeholder expectations. 

Examples of ConOps:

Chapter 2 ConOps Example

Pre-Phase A Chap3_PrePhaseA_ConOps,

Phase A Chap3_PhaseA_ConOps

Phase B Chap3_PhaseB_ConOps 


In Phase A multiple architectural designs must be reduced to a single selected architecture before progressing to Phase B.   A trade study is a tool that can be used to compare alternative designs in order to choose the best of the alternatives.  A trade study can either be a formal process (with numerical measure of effectives with a ranking system based on selection criteria) or informal using logical arguments.  The concepts are compared and evaluated and the best selected to put forward.  The trade space of a trade study is the set of all feasible alternatives.  For example, Chapter 2 presents the problem of designing a mousetrap that does not kill the mouse, and there are many alternatives; there might be one or two closing doors, 3 bait options (none, replaceable, user supplied) and 4 actuation concepts (spring, electric sensor, hydraulic, mouse powered).  These alone give a trade space of 24 possible concepts to impartially evaluate in a trade study.  For an excavator, trade studies could be performed to choose a power system (e.g. solar cells, batteries, a combination of solar cells and batteries, unspent rocket fuel, fuel cells, nuclear power, etc.), specific battery type, microcontroller type and features, etc.)

Examples and further explanation of trade studies are found at:

Chap4 Trade Studies, including steps to follow in a trade study, with examples of a car purchase and a microcontroller selection.

Chap3_microcontroller_trade_study (repeated in Chapter 4).


Function 5:  Validate and Verify is another SE function that is ongoing during requirements, architectural design and ConOps formulation in order to guarantee they will lead to a plausible design, and are consistent.   In most cases this will be achieved by logical argument.  Secondly, validate and verify guide the physical testing in Phase D; to do this the student team should create requirements in Phase B to be able to perform Requirements Verification, System Verification and System Validation in Phase D testing.

Requirements Verification is proving that each requirement is satisfied.  

System Verification is assuring that the system is built right. 

System Validation is assuring that the right system is built for the intended environment. 


Function 6: Interfaces and ICD (Interface Control Document)  Interfaces are mechanical, electrical, thermal and operational boundaries that are between elements of a system. The interfaces appear as the architectural design progresses, by the addition of more and more detail to the subsystems and components.  The ICD specifies the mechanical, thermal, electrical, power, command, data, and other interfaces.  For examples, see:

Pre-Phase A Interfaces_PrePhaseA,

Phase A Interfaces_PhaseA

Phase B  Interfaces_PhaseB_listed

A number of examples from Chapter 4

Function 7:   Mission Environment must be communicated, because it does affect the design, and it could include vibration, shock, static loads, acoustics, thermal, radiation, single event effects (SEE) and internal charging, orbital debris, magnetic, and radio frequency (RF) exposure.   Chapter 5 described the lunar environment.

Function 8: Technical Resource Budget Tracking identifies and tracks resource budgets, which can include mass, volume, power, battery, fuel, memory, process usage, data rate, telemetry, commands, data storage, RF links, contamination, alignment, total dose radiation, SEE, surface and internal charging, meteoroid hits, ACS pointing and disturbance and RF exposure. 

Example of a Power Budget: Chapter4_Power_Budget_Example

Example of a Mass Budget: Chapter_4_Mass_Budget_Example

Example of a Data and Link Budget: Chapter_4_Data_Link_Budget_Example

Function 9:   Risk Management identifies the risks to safety, performance and the program (cost overruns and schedule delays).  Performance and safety risk may be a design consideration, calling for a design change or improvement.  There are analytical tools to assess risk if a more detailed study is needed, such as FMA and FMEA for risk identification and mitigation. The steps of Failure Mode Analysis (FMA) are 1) Seek and identify the risks, 2) Determine their severity and effect of the risk based on coding as shown in the Figure 11, and 3) Develop methods to mitigate the risk.  Codes of the severity of a risk range from 1 (non-critical failure) to 4 (entire mission failure).    Mitigation can be achieved by providing redundant components, fault tolerant components, and error detection methods. 

 Examples of Failure Mode Analysis: Chapter_4_Failure_Mode_Analysis_(COMM_CD&H)Chapter_3_Failure_Mode_Analysis_EPS_System

Figure 11  Four failure classifications and their failure code

Function 10:  Configuration Management and Documentation is a system for documentation control, access, approval and dissemination. The teams should have an accessible drive on the university computer network to place documents or something equivalent.  Documentation starts in the project formulation phases, and documents are updated at the end of each review.  Although the systems engineer is listed as responsible, the systems engineer can delegate tasks.  For the Mission Objective, Derived Requirements, Concept of Operations, Verification and Validation, Mission Environment there are no specific tools other than a list created and updated by the systems engineer.  Other documents include parts lists, drawings, schematics and software.  Eventually documents reach a "baseline", thereafter changes to the document will require an approval of the project manager.   These changes are called "revisions", and each revision should be numbered and dated, with an explanation for the purpose of the revision.

Function 11: System Milestone Reviews and Reports are presented to the stakeholders.  The reviews can occur at the end of each phase, and may include:

·         Pre-Phase A - Mission Concept Review (MCR)

·         Phase A - System Definition Review (SDR)

·         Phase B - Preliminary Design Review (PDR)

·         Phase C - Critical Design Review (CDR)

·         Phase D – Operational Readiness Review (ORR)

Reviews can be combined so that there are fewer.  Each Review should include a Power Point Presentation, plus a Report.  The format of Figure 12 includes sections on Project Management, Systems Engineering and reporting from each Subsystem Design team.  Within the Systems Engineering section, the report should address each SE function.  The project management section should present task assignments on a Gantt Chart and management structure.  

Examples from Chapter 2:  Gantt Chart 

Chapter 4 Examples: Chapter4.htm#GanttChart.

Project Report

Figure 12.  Review Report and Presentation Outline

Function 12:  System Engineering Management Plan (SEMP) should follow the format of the hyperlink.  "An important part of Systems Engineering is planning the systems engineering activities, what is done, who does them, how it is to be done, and when the activities are expected to be complete. The purpose of the Systems Engineering Management Plan is to document the results of the planning process." (NASA, 2002).  This is not one of the 11 SE functions, and should be considered optional.




2‑1 A Sand-filled Wooden Trough for Testing

2‑2 KSC Rover Interfacing Plate