Capstone Design Class

Student Handbook

Klipsch School of Electrical and Computer Engineering

September 2006

-i-

Table of Contents

List of Figures.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -iii-

List of Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -iv-

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-

2 Design Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1-

3 Design Evolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -2-3.1 Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -2-3.2 Subsystems.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -3-3.3 Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -5-

4 Documentation.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -7-4.1 Documentation Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -8-4.2 Mission Vision Statement, Mission Requirements, and Success Criteria

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -9-4.3 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -10-

4.3.1 Mission Requirements and Success Criteria. . . . . . . . . . . . . . . -12-4.3.2 Performance/Environmental Requirements. . . . . . . . . . . . . . . . -13-4.3.3 Subsystem Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . -13-4.3.4 Requirements Matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -14-

4.4 Work Breakdown Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -15-4.5 Operations Concept Document.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -16-4.6 Design Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -16-

4.6.1 Requirements Coverage.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -16-4.6.2 Design Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -17-

4.6.2.1 Functional Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . -17-4.6.2.2 Signal Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -19-4.6.2.3 Dependencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . -20-

4.6.2.3.1 Required Support from Other Entities. . . . -21-4.6.2.3.2 Support Provided to Other Entities. . . . . . . -21-

4.6.3 Supporting Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -21-4.6.4 Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -22-4.6.5 Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -22-4.6.6 Form Factor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -24-4.6.7 Integration with the Testbed. . . . . . . . . . . . . . . . . . . . . . . . . . . . -24-

4.7 Parts List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -24-4.8 Materials List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -25-

-ii-

4.9 Drawings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -25-4.9.1 Mechanical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -26-4.9.2 Electrical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -26-

4.10 Assembly Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -26-4.10.1 Unit Assembly Procedure. . . . . . . . . . . . . . . . . . . . . . . . -26-4.10.2 Integrated Assembly Procedure. . . . . . . . . . . . . . . . . . . -31-

4.11 Test Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -32-4.12 Assembly Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -35-4.13 Test Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -35-4.14 Integration Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -36-4.15 Integration Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -36-4.16 Integrated Test Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -36-4.17 Integrated Test Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -36-4.18 Certificates of Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -36-4.19 Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -39-4.20 Budget.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -39-4.21 Risk Assessment.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -41-

5 Design Reviews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -41-5.1 System Concept Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -41-5.2 Preliminary Design Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -42-5.3 Subsystem Design Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -44-5.4 Critical Design Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -45-5.5 Final Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -46-

6 Class Expectations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -48-

Appendix A – Documentation Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -49-

-iii-

List of Figures

No. Title Page

1 Example of a system diagram based on the design of a small satellite 3

2 Example of the space segment in the overall system decomposed intothe electrical subsystem components

5

3 Power subsystem decomposed into individual functional units. Theonly signal flow is the power signal (no control or data signals). Thecontrol and data signals would be included in the final, completedesign drawing.

6

4 Design process from initial concept to final product 7

5 Requirements flow in the system from the mission definition throughindividual subsystems.

8

6 Functional flow diagram for the example satellite system 18

7 The electrical subsystem functional diagram for the example satellitesystem

18

8 The functions found in the power section of the electrical subsystemfor the example satellite

19

9 Functions and interfaces in the power control unit of the power portionof the electrical subsystem in the satellite example

19

10 Example wiring harness interfaces 23

11 Testbed for the nanosatellite components. 24

12 An example of a mechanical drawing from Solid Works and thefabricated unit for the example satellite project

27

13 Electrical schematic diagram for the charging control and associatedcircuitry used in the power module of the example satellite system

28

14 Printed circuit board for the power unit having the schematic diagramshown in Figure 11

28

15 Example schedule entered as a spreadsheet. This is a portion of theoverall schedule showing the WBS identifier, the task names, andtarget dates. The " �" implies a specific date while the " �==== �" isa task range of dates.

40

-iv-

List of Tables

No. Title Page

1 Example Requirements Flow 14

2 The Work Breakdown Structure (WBS) for the Example SatelliteProject

15

3 Assembly identification method 30

4 Assembly setup documentation 30

5 Detailed assembly procedure 31

6 Test identification method 33

7 Test setup method 33

8 Test procedure method 34

9 Example of an assembly log 37

10 Example of a test log 38

-1-

1 Introduction

This design guide is to provide the overall approach to designing a system as part ofthe Klipsch School of Electrical and Computer Engineering capstone design program. This process is based on methods typically found in the aerospace industry. However,the principles are general enough to ground the student in any system involving a highdegree of accountability in the design process. This technique also permits fulldocumentation of the project so that (a) others can learn how the design wasaccomplished, (b) what components were chosen, and (c) how the design was finallyverified. In this process, we will assume the existence of a “customer” who hassupplied a set of performance and functional requirements that the design is to meet forfinal acceptance. The purpose of the documentation, design reviews, and testing is toensure and verify that we have a design that will meet the requirements. We will alsoneed to manage the process to keep it on track, as much as possible, for meetingbudget and schedule.

2 Design Process

All of the details of the design process are, probably, too much to attempt in a singledocument. For more details, the student should refer to textbooks such as Design forElectrical and Computer Engineers by J. E. Salt and R. Rothery (John Wiley & Sons,2002) or Engineering Design by R. J. Eggert (Pearson Prentice Hall, 2005). In thisclass, we will look at the basics of the process but we will never become experts fromthis one exposure. What are the basics that we will consider? First, the design will bean open-ended process. By that, we mean that the design does not necessarily haveone solution and the design team may need to consider several equally-good solutions. Secondly, the design process will be iterative. By that, we mean that the design willmature as new information is learned, as solutions are evaluated, and as the design istested. Thirdly, we must convince ourselves, and others, that the design reallyaccomplishes something – that is, the design meets the requirements. We will do thatby documentation and testing. Finally, we must realize that the design might not beperfect (see, for example, H. Pertroski’s Small Things Considered: Why There Is NoPerfect Design (Knopf, 2003)). That means that there may be competing constraints orlimitations that will cause compromises in the design. The goal is to work with theconstraints to make a design that is optimal, or at least fits, within the constraints butmay not always be “perfect.” Design compromise is the typical situation in the “realworld.”

This handbook is to give the student the means to demonstrate that the design iscorrect (meets the requirements) and that the finished product operates correctly (wehave tested it). The project will be documented to capture the details of the design andtest stages. We emphasize this because most student designs work “on paper.” However, it is only when objects are constructed and used that any design flawsbecome apparent. The documentation also allows students, who may extend the

-2-

design in subsequent classes, to understand your thinking and learn from your efforts.

3 Design Evolution

The design project needs to be broken into small segments to allow us to manage thedesign efficiently. This is similar to the structured programming method found insoftware design. Here, we start at the top and work our way down to refine the designgradually. Then in the building and integration, we start at the lowest level and work ourway up to make the entire system. This process is really not linear but will typicallyinvolve several iterations to “get it right.”

One way to make the design evolve quicker is to develop a system design testbed. This is a place where components can be tried out with other components to learn theirworking characteristics in the system as a whole, test interfaces, and gain operatingexperience as the design evolves. These testbeds come with different names such as“flatsat” in the satellite design world or “hot bench” in the aerospace industry.

After the system is designed, it will need two further items to complement the design: amethod of assembly and a test regimen. The assembly method makes sure that theparts go together properly and the testing is to make sure that things “work asdesigned” every step of the way.

Throughout this document, we will use several examples from a satellite design project.This example project represents a large, interdisciplinary design project requiringseveral distinct teams. This example shows the full range of what might beencountered in a class design project. However, not all components will be found in alldesign projects.

3.1 Systems

The system is the overall project item that we are attempting to design. This includesnot only the hardware and software components made by the designers but theinteractions with the world around the system. From a hardware and software point ofview, the system is the integration of the ensemble of the components into the workingentity. When this integration is done and verified, we have completed the design. However, for most people, we cannot design the entire project at this level. To keep theproject manageable, we will decompose the overall project into more smaller, well-defined segments for detailed design work. The design team is then composed of“experts” to tackle the smaller work units based upon their area of expertise(electronics, communications, mechanical structures, controls, science instrumentation,computer programming, etc.). Because the project has now been divided into smallersegments, we now need to make sure that the segments will compose a compatiblewhole when put back together. This forms the basis for needing detailed

-3-

documentation and detailed testing.

An example of a system diagram is shown in Figure 1 where we look at the design of asatellite to perform a science mission from an earth orbit. This system has two majorcomponents: the space segment (the part orbiting the earth) and the ground segment(the part that tracks the satellite and communicates with the satellite from the ground). Each segment will have its own set of subsystems that will need to be designed andmanaged. The system has a science mission so it will collect science data thatbecomes an external “input” signal (independent and outside the system) from outsidethe system. The solar energy used to power the satellite is another example of anexternal input. The ground segment communicates with the space segment viacommand and telemetry data messages. This ground segment interacts with the user(consumer) of the data and the satellite controller who provides control “data” to run thesystem.

How do we know what all this system is supposed to accomplish? The customer willhave a project “mission statement” that outlines the vision for the project and anassociated set of project requirements for the system to describe the functions to beaccomplished.

3.2 Subsystems

Each of the segments can be decomposed into specific subsystems to accomplish thefunctions the project segment needs to fulfill. Subsystems are the major components ofthe design to actually accomplish the “mission statement” and the associated missionrequirements. Each of the mission requirements can be mapped to one or moresubsystems for actual realization in the design by the design teams. The highest levelof subsystem differentiation is between the following divisions:

Figure 1 – Example of a system diagram based on the design of a small satellite

-4-

1. Electrical Subsystems,2. Mechanical Subsystems,3. Software Subsystems.

Each segment of the system in Figure 1 can be broken down into an electrical,mechanical, and a software subsystem. This does not mean an absence of overlapbetween the subsystems. For example, the mechanical subsystems may haveembedded software inside a component. However, these are the major ways to look atthe partitioning of the design. We will use this partitioning to assign requirements todesign segments for realization and we will also use the partitioning to design the WorkBreakdown Structure to be discussed later.

Next, we need to decompose each of the major areas into functional parts. The partsmay be a single component, a collection of components realizing a function, or a majorentity. The main thing is that the decomposition tries to isolate the function(s) to beperformed in the subsystem. For example, electrical subsystems may include thefollowing entities:

1. Power Supply2. Communications3. Computing4. Sensors and actuators

An example of these subsystems for the space segment portion of the satellite projectis illustrated in Figure 2. Here we show the major functional blocks and the signalspassing between these functions.

The mechanical subsystems may include the following entities:

1. The bus (structure holding all of the components)2. Separation mechanisms3. Attachment mechanisms4. Motors

The software subsystems may include the following entities:

1. Scheduling of events or processes2. Control of equipment3. File management4. Sensor data analysis

The exact mix of subsystems will, naturally, depend upon the nature of the system andthe functions to be performed.

-5-

3.3 Units

The Units are the refinement of the subsystems into individual functional entities thatperform the necessary tasks to perform the specific requirements. For example, thePower subsystem might be broken into the following units:

1. Solar cells2. Batteries for energy storage3. Power conversion (DC-to-DC converters)4. A charging-control circuit5. Protection diodes6. Fuses.

These individual units would then be broken down in the design process to theindividual components to make the Unit work as required to make the system functionas needed. These components will be individual items that can be purchased ormanufactured locally. As an example, the decomposition of the power system intoindividual units is illustrated in Figure 3. Each box is a specific design of functionalcomponents to accomplish a defined task. Similarly, the other subsystems can bedecomposed into their constituent units.

Figure 2 – Example of the space segment in the overall system decomposed into the electricalsubsystem components.

-6-

Figure 3 – Power subsystem decomposed into individual functional units. The only signal flowis the power signal (no control or data signals). The control and data signals would be includedin the final, complete design drawing.

-7-

4 Documentation

The project documentation in the class will be extensive. However, the purpose of this documentation set is twofold:first, to make sure that all of the design process elementsare considered and second, to acquaint the student with theway documentation is done in industry, especially forgovernment work. The process used in this design classforces the student design teams to look at open-endedproblems and to consider new topics such as testing,assembly, and safety. Each document listed below shouldbe treated as a separate entity; that is, do not try to placethem all into a single document covering all of the areas. The actual document for each area does not need to be anylonger than that required to supply the necessaryinformation. Often, the required information can bedeveloped in one or two pages.

The documentation mirrors the design process given inFigure 4. The top level is the development of the systemrequirements with the customer. The requirements will thenbe assigned to system components. These systemcomponents will then be further refined into the functionalunits. Each unit will require a document to describe it as willthe overall system interfaces and testing. The individualunits, subsystems, and, finally, the entire system, need tobe integrated and tested. Each document captures thedesign process at each stage shown in Figure 4. Properdocumentation will not prevent design mistakes. However,it will allow the design team to find them more easily andallow the membership of the design team to change overtime and still not lose vital information for completing theproject.

The project documentation will flow as illustrated in Figure 5. The customer needs willbe encapsulated in a “vision statement,” mission/project requirements, and successcriteria. From these basic statements, the design team will derive the specific projectrequirements and assign them to the segment, subsystem, and unit design elements.

Figure 4 – Design processfrom initial concept to finalproduct

-8-

4.1 Documentation Template

The Documentation Template for the project provides a uniform look and style that givethe project a “professional” look. It also helps the student know where to start whendeveloping the individual documents. A Documentation Template for the examplesatellite project is given in Appendix A which can be adapted for use in this class. When developing the documents describing the system, the first part of the templatethrough the end of Section 1 is common for all documents that are developed. Theonly individual editing that needs to be done to these parts is for the title page andSections 1.4 and 1.6 to define the specific document needs. The title page has placesto insert the project name, the name of the document, e.g., Requirements Document,and the document author(s). Section 1.4 is a description of the contents of theindividual document. Section 1.6 is the list of relevant references for the document. Sections 2 though 5 are for the user to fill out, as appropriate, for the design document. Only Section 2 is required if the document can contain all of the necessary informationin this one section. Use the other sections if they will improve the logical flow. Thesections below will contain suggestions for the contents of several standard documents. The class instructor will work with the design teams to specify the specificdocumentation for the class.

Figure 5 – Requirements flow in the system from themission definition through individual subsystems.

-9-

4.2 Mission Vision Statement, Mission Requirements, and Success Criteria

The first step in the design process is to realize that the final system is supposed to dosomething. That something may also need to operate with constraints such as size,power, operational environment, and cost. The something will also have performancecharacteristics that the customer wants to see met. These concepts are captured in theMission Vision Statement, the Mission Requirements, and the Mission Success Criteria. The characteristics of a good mission vision statement are

1. It is a clear statement of the objectives of the project2. Does not concern itself with justification 3. Does not include requirement statements.

The Mission Statement is to answer the “vision” questions about the project. It shouldbe a “pithy” statement of approximately one paragraph in length and be like a projectabstract. This vision statement can be further refined into a set of project objectives tofurther refine the vision statement. Using our nanosatellite project as an example, aproposed mission statements for the overall project is as follows:

The primary purposes of the NMSUSat2 mission are to demonstratetwo-axis control of the satellite when in LEO orbit and to demonstrate theability to use the robotic arm to inspect the surface of the satellitestructure and estimate inertia properties.

The Mission/Project Requirements are exact specifications of the mission vision thatany proposed design must meet. Different design teams could realize the systemdesign in different ways; however, the mission requirements would be the same for alldesign teams. The mission requirements are statements of measurable ordemonstrable criteria that the customer will use to state that the project is donecorrectly and really complete. The criteria should not use vague qualifiers such as“quickly” or “easy to read.” Rather, a measurement should be supplied; “quickly”/ inless than 2 seconds or “easy to read” / at least 12 point Arial font, yellow letters on ablue background, non-blinking. In these cases, the mission requirements can beobjectively determined.

How do you find the requirements? Usually, the design team will need to interview thecustomer to find out the customer’s needs for the overall project. The followingquestions example interview questions and are intended to elicit information from thecustomer to develop the system requirements and system success criteria.

1. Describe the operational functional environment for the total system.2. How many different existing systems do you know of?3. What are the good points in the existing systems?4. What are the deficiencies in the current systems?

-10-

5. What are the problems the existing systems create?6. What would your ideal system do?7. What potential problems might your ideal system create?8. Who is the eventual user of the system?9. How many systems will need to be active at a single time?10. What are the cost/performance trade-offs?11. What is the maximum unit cost permissible?12. What is the working environment that the system must operate in?13. What are the constraints that the system must meet?14. What are the system data requirements (min and max)?15. What are the system size and weight limits?16. What is the minimum set of performance requirements that you consider

acceptable for a successful design?

The success criteria are quantifiable mission statements that are specifications thecustomer will use to buy off on a successful project design. Again, using thenanosatellite design, examples of mission success criteria might include the followingstatements:

• Within two weeks of being placed on orbit, the satellite shallachieve a nadir-pointing attitude to within ±10° as evidenced bymeasurements.

• After achieving nadir pointing, the satellite shall maintain nadirpointing to within ±10° for at least 90% of the remaining usefulmission time, as evidenced by measurements.

Obviously, the mission requirements and the success criteria do not contain all that theproject needs to do. These statements need to be mapped into the components thatwill actually accomplish the program. The detailed requirements specifications willperform that task.

4.3 Requirements

The second step in the design process is to turn these overall mission requirementstatements, interview results, and success criteria into specific, testable statements thatdescribe what is needed to accomplish the mission and meet the criteria. Commonly,the requirements may be incomplete at the start of the project because the customer isnot really sure if the success criteria are really what is needed in the design or themission may change due to financial or market drivers. As the design and testingprocess proceeds, the requirements may also change as the design team and thecustomer learn more and uncover unexpected performance characteristics (both goodand bad). In both cases, the design team and the customer need to agree on thechanges before the design can be completed. In the nanosatellite example, the overallsystem was broken into two segments: the space segment and the ground segment.

-11-

The requirements will need to follow both segments and allocate requirements andfunctions to each segment.

Generally, the system requirements can be broken down into three general areas:

1. Customer Requirements – functions and features that must be present to fulfillthe customer’s needs

2. Derived Requirements – functions and features that must be present to make theCustomer Requirements practical

3. Performance Specifications – levels of performance to make the system work asdesigned and be safe.

We will look at each of these types of requirements in the following paragraphs. Eachrequirement must be testable in some manner. That is, a measurement or analysismust be possible to show that the requirement is fulfilled in the final design. When therequirements are fully developed, we should be able to map each requirement to one ormore system elements that realize the design requirement. One word of caution here:the requirements should state functions to be performed or specifications to be met andnot the design that should be used to realize the function. For example, Figure 3 listsan energy storage element in the power module. The requirements should only statethe need for energy storage with, perhaps, the duration that the power is to be supplied. The requirement should not be written as “provide five D-sized NiCd batteries.” This isa specific realization of the design and not a functional requirement. The energystorage element may be realized in several ways and the designer is to pick the “best”one to fulfill the requirement to supply energy for the specified duration. This designmight just be five D-sized NiCd batteries, however, that should fall out of the designprocess and not the requirements.

A second word of caution: do not have more requirements than the minimum necessaryto specify the functions and performance really required to define the system. Therequirements should not be so plentiful and in such detail that they become a designitself. The designer also needs to avoid “mission creep” where the customer keepsexpanding the requirements suite or “just add a new feature because you can” type ofthinking.

The output from the process to develop the requirements is the System RequirementsSpecification Document (or simply the Requirements Document). This document will bea collection of quantifiable statements of the design requirements starting with theMission Statement and the Success Criteria. Additionally, the Requirements Documentwill contain a listing of the criteria for evaluating the finished design (acceptancecriteria).

Following the standard Section 1, the Requirements Specification Document wouldhave the following sections:

-12-

1. Section 2 – Mission Statement, Mission Requirements and Mission SuccessCriteria

2. Section 3 – Performance/Environmental Requirements3. Section 4 – Subsystem Requirements

The requirements in each area can be organized into a table with the followingcolumns:

1. Requirement Type2. Requirement Number3. Requirement Text4. Source of the Requirement

The requirement type and requirement number can be identified with a code such as“XXX###” where XXX is “M” for mission requirements, “PER” for performancerequirements or “ENV” for environmental requirements and the ### is a sequentialnumber. For analysis and design purposes, these requirements should be grouped sothat similar requirements are next to each other. The requirement text is a simple,testable statement. The subsystem requirements show which element in the overalldesign will be responsible for fulfilling the requirement. The source tells where therequirement originates. Mission requirements may originate in a proposal or businessplan. Performance and environmental requirements may originate in an industrystandard or government code that the project must meet by law. Subsystemrequirements will form a tree that is traceable back to mission or performance/environmental requirements. The goal is to have requirements that eventually specifyall of the needs and there should be no requirement without an identifiable source.

4.3.1 Mission Requirements and Success Criteria

The Mission Requirements and Success Criteria are the functions and constraints thatthe customer considers being “must haves” in the final design to fulfill the MissionStatement. These requirements need to be expressed as quantifiable statements ofperformance or function so that the requirement can be verified. If a requirement cannotbe verified, then it is not a requirement! Besides the basic requirement statements, thedesign team also needs to establish the acceptance criteria for the finished product foreach requirement. The requirements specifications may be too tightly drawn so thatthey go beyond the customer’s needs to the detriment of the design. If this happens,the design team or the customer may add specifications that go beyond needs intoother areas that are not required to meet the user’s needs.

In the requirements development process, it is often hard to distinguish betweencustomer needs and wants. Needs are performance specifications that the customercannot live without. Wants are really “nice to haves” or “do it if it can be done withinprice and performance envelopes.” Wants can drive a design into the realm of the

-13-

unrealizable. Therefore, leave the “wants” from the list of requirements.

After the requirements are developed, the set of requirements needs to be reviewed toensure that the requirements are not mutually exclusive or have another form ofcontradiction. These contradictions should never happen but they often do, especiallywhen the system is in a faulty operating mode or if new technology developments arerequired to meet customer needs. The design team also needs to review therequirements to ensure requirements do not violate external constraints (cost, legal,etc.). Generally, the customer needs to agree to the output of these reviews.

4.3.2 Performance/Environmental Requirements

Beyond the Mission and Success requirements, the Requirements Document willcontain performance and environmental requirements that will influence the design. The project may include constraints due to environmental conditions, form factors, etc.as determined by the customer’s needs or legal requirements. Performance andenvironmental criteria might include the following parameters:

1. Maximum power, or voltage, or current to be consumed,2. Maximum weight,3. Maximum size,4. Specific materials to be used or not used,5. Safety factors and margins,6. Maximum permitted interference with other entities,7. Compatibility with other entities,8. Industry or legal codes to be met,9. Maximum number of permitted transmission errors per unit data transmission,10. Minimum number of samples per second that need to be taken and the

resolution per sample.

Performance criteria may also specify parameters related to the system’s userinterface. These can be specifications related to color, text size, visible area fordisplays, etc.

4.3.3 Subsystem Requirements

The previous two sets of requirements next get mapped into the subsystems that willactually make the project happen. When the process starts, the mapping will be at ahigh level: structures, software, electrical, etc. Each of these will the be refined to showmore detail but never to the level of specifying a design. For example, a project mayrequire 24-hour on-time for the one-year project lifetime, even when not connected tothe power grid. The requirements should specify just that. They should not specify thatsolar cells and rechargeable batteries are needed since they are design decisions.

-14-

Table 1 – Example Requirements Flow

Mission-Level Requirements

ID Requirement Source

M.2 The satellite shall provide controllable robotic arms for surfaceinspection

proposal

Robotic Arm Requirements

RA.1 The robotic arms shall be able to be commanded to a specifiedposition at a specific rate

M.2

RA.2 The robotic arms shall have imaging support for surfaceinspection

M.2

Communications Requirements

CO.1 The satellite communications system shall support SpaceTelecommand services

RA.1

CO.2 The satellite communications system shall support SpaceTelemetry services

RA.2

After all, a designer may decide to propose a small nuclear reactor to fulfill thisrequirement! Table 1 shows an example flow of mission and subsystem requirements. Here we see that requirement M.2 is a mission criterial rooted in the proposal. Thisflows down to the need for a robotic arm component RA.1 and RA.2. These tworequirements have M.2 as their source. To make the robotic arm work, the team hasidentified a need for a communications system. We could have guessed that theproject would need a communications system but here we have identified the need for itto fulfill the basic mission needs and not just because we think it is a good idea to haveone. This type of analysis is then conducted for all of the mission and performance/environmental requirements to identify what types of subsystems are required and whatthe requirements on each subsystem are to fulfill the mission.

4.3.4 Requirements Matrix

A typical systems engineering tracking is to use a requirements tracking matrix called a“Requirements Matrix” or a “Requirements Traceability Verification Matrix.” This matrixwill show all of the project and subsystem requirements using the form given in Table 1.

-15-

Table 2 – The Work Breakdown Structure (WBS) for the example satellite project

4.4 Work Breakdown Structure

The Work Breakdown Structure (WBS) is a way of showing the relationship betweenthe parts of the system. It does this through a systematic numbering system to trackthe individual jobs needed to construct the system completely. It comes from thephilosophy of “divide and conquer” applied to all of the system components. The WBSelements are frequently used to organize the project schedule as well. A WBS for aproject might look like the one in Table 2. The WBS is broken into the expectedsections for the electrical, mechanical, and software subsystems. The WBS typicallyalso has sections for “Systems Engineering” to cover system-level items likerequirements. A WBS will also contain a section to cover the integration and testactivities, which are often very detailed for complicated systems. Additionally, a sectionfor managing the project is included in the WBS since management tasks are importanttoo. Generating such a list in a spreadsheet program, like EXCEL, is easy. Typical

-16-

project planning software like Project also has this capability as part of the projectscheduling and management functions.

4.5 Operations Concept Document

Associated with the requirements document is a parallel, and equally importantdocument, called the Operations Concept Document. This operations conceptdocument tells the designer how the system is intended to be used in typicaloperations. This would typically include the following points:

1. How to turn the system on and off,2. How to calibrate the system for proper operation, how often the calibration would

need to be redone, how to tell if the system is still in calibration, etc.,3. How to change batteries, how would the user know when to change the

batteries, etc.,4. How the system would typically be used, including different operational modes,5. Safe operating practices; unsafe operating practices.

This may give the designer insights that the pure requirements specifications will notprovide.

4.6 Design Guide

The Design Guide is the “bible” for your design. Its purpose is to guide thedevelopment of the actual device by explaining how it works and how it relates to anyother devices in the overall system. Using the standard numbering scheme, thefollowing sections should be included, at a minimum, in the Design Guide after thestandard Section 1:

1. Section 2 – Requirements Coverage2. Section 3 – Design Description3. Section 4 – Supporting Analysis4. Section 5 – Operations5. Section 6 – Interfaces6. Section 7 – Form Factor7. Section 8 – Integration with the Testbed.

The following paragraphs describe sections these sections in more detail.

4.6.1 Requirements Coverage

The Design Guide needs to tell the reader what subset of the overall requirements that

-17-

the design addresses. This can be done as a simple table that lists the requirementsfrom the Requirements Document and then the design features that realize therequirement. When the total design is finished, every requirement will need to betraceable to a design element. Conversely, the design should not contain elements thatdo not relate to the requirements. Extra design elements only make the project moredifficult to verify that it is working properly – no matter how good the extra elementsseem to be at the time.

4.6.2 Design Description

The Design Overview is to give the reader a high-level view into the design. It shouldbe concentrating more on the functions to be performed and the interrelationships withthe other parts of the design than with the detailed components. These are coveredlater in other sections of the document.

4.6.2.1 Functional Flow

The functional flow shows how the design is broken down into functional sections fromthe system level down to the unit level. Naturally, for the Design Overview, the onlyparts of the functional flow needed are the overall system, the major subsystem group,the individual subsystem, and the individual unit. This will give a context for how thefunction of this particular design element relates to the overall system, in general, andits peer entities, in particular. This also helps to provide a cross check that nothingmajor is being forgotten.

For the satellite system example given here, the following figures illustrate thefunctional flow concept. Figure 6 is the system functional flow for the example. Itcontains all of the major system elements and their functional relationships. Figure 7 isthe satellite electrical subsystem functional flow. This is one part of Figure 5 with moredetails. Figure 8 is the power electronics functional flow broken down to the majorfunctions that will lead to a design. Finally, Figure 9 is the Power Unit functional flowdecomposed to the individual design elements. While this may seem like a largenumber of diagrams, there is a good deal of re-use in them in the design documentationso it is not wasted effort. All Design Guides in the overall system would contain Figure6. This diagram shows the major subsystems and the types of interactions betweenthem. Notice that there is not any identification of actual hardware modules. Rather, atthis level we are concerned with the functional parts and the signals between them. AllDesign Guides dealing with the satellite’s electrical subsystems would have Figure 7. Notice that this is a refinement of just one part of Figure 6. There is a bit more detail toprovide a better context for the electrical system. All Design Guides dealing with thesatellite power would have Figure 8. Notice that this has begun to break the function“supply electrical power” into functional units that can be designed in more detail. Theonly Design Guides that would have unique diagrams are those dealing with the

-18-

Figure 6 – Functional flow diagram for the example satellite system.

Figure 7 – The electrical subsystem functional diagram for the example satellite system.

-19-

individual units of the power electronics. This can be seen in Figure 9 where we havebroken down the Power Unit into individual design elements to make the whole. Also,notice that no hardware devices have yet to be explicitly identified. However, from thedetails in Figure 8, we can proceed to a detailed design with specific componentsidentified.

This commonality and gradual refinement shown in Figures 6 through 9 helps to makesure that the individual design groups can see how their part relates to the whole. Thenext level of the design will be documented in the detailed Parts List and Drawingsdocuments.

4.6.2.2 Signal Flow

We hope that the student will notice that Figures 6 through 9 contain signals andfunctions. The signals are used to communicate between the different functions. Designs have two general signal types included in the diagrams:

Figure 8 – The functions found in the power section of the electrical subsystem for the examplesatellite.

Figure 9 – Functions and interfaces in the power control unit of the power portion of theelectrical subsystem in the satellite example.

-20-

1. Data and Control Signals2. Power Signals.

Next, we look at each of these.

Data and Control Signals. The data and control signals will be information signalsbetween entities in the design. These signals may be either analog signals or digitalsignals. The Design Guide needs to record

1. The signal name – a mnemonic name to describe the signal2. The signal source – where does it originate3. The signal destination – where does it end4. The signal type – analog or digital5. Signal ranges – both normal and, if possible, out-of-normal ranges or

minimum/maximum ranges; if digital, how many bits are used to establish thesignal.

The data can be placed into a table with each item in the above list forming a column inthe table.

Power Signals. The power signals will be the voltage and/or current flow betweenentities in the design. The Design Guide needs to record

1. The signal name – a mnemonic name to describe the signal2. The signal source – where does it originate3. The signal destination – where does it end4. The signal type – DC or AC5. The voltage ranges – both normal and, if possible, out-of-normal ranges or

minimum/maximum ranges6. The current ranges – both normal and, if possible, out-of-normal ranges or

minimum/maximum ranges.

As we suggested before, the data can be placed into a table with each item in theabove list forming a column in the table.

4.6.2.3 Dependencies

Each unit does not exist in isolation from the rest of the system. Generally, it will haveelectrical and mechanical relationships with other units. These relationships involvesupport that the unit needs from other entities plus support the unit gives to otherentities.

-21-

4.6.2.3.1 Required Support from Other Entities

Each design has the potential of requiring support or resources from other entities ofthe overall system design. These dependencies must be documented and tracked tomake sure that the system integrates properly. There needs to be a discussion in theDesign Overview of the assumed support that will be available to the unit or subsystemfrom other entities in the design. This support needs to cover the following items:

1. Electrical Support – what power, control, and data signals are assumed to besupplied by other entities. Include signal names, values, etc. that will enable thisDesign Guide with other Design Guides to ensure that everything matches.

2. Mechanical Support – what types of attachments, material support, etc. isexpected to be available to the unit to operate properly.

3. Functional – what operations or processes being run elsewhere in the systemdirectly affect the unit or subsystem covered in this Design Guide by providingdata inputs or signals for this unit/subsystem?

This information complements the other side of the design. It describes the supportthat this module provides to the rest of the system. This is covered next.

4.6.2.3.2 Support Provided to Other Entities

Each design has the potential of providing support or resources to other entities of theoverall system design. Just as we saw above, these dependencies must bedocumented and tracked to make sure that the system integrates properly. Thereneeds to be a discussion in the Design Overview of the types of support that will beavailable to other units or subsystems in the design from this module. This supportneeds to cover the following items:

1. Electrical Support – what power, control, and data signals will be supplied toother entities. Include signal names, values, etc. that will enable this DesignGuide with other Design Guides to ensure that everything matches.

2. Mechanical Support – what types of attachments, material support, etc. will beavailable to other units.

3. Functional – what are the operations or processes being run in this unit thatdirectly affect other units or subsystems?

4.6.3 Supporting Analysis

Nearly every design has some associated analysis to go with it to justify the designdecisions. Typical analysis tasks include, but are not limited to, the followingconsiderations:

-22-

1. Voltage and current draw to justify wire sizing2. Voltage and current draw to justify power source sizing3. The characteristics of components to show they meet performance requirements4. Mechanical characteristics to support the operation of the device5. Electrical and mechanical safety factor analysis6. Margins in the design between what is required and what the design can attain.

The analysis should show the necessary equations and data, based on theperformance requirements, necessary to show that the design will work as it should. The analysis should show a degraded performance assessment, if possible. Forexample, consider a string of solar cells where one cell fails for some reason. What willbe the available current and voltage coming from this solar cell string if a failure occurs? How will the failure of this cell in this solar cell string affect to overall performance of theentire solar array? Will the degraded solar array affect the current and voltage marginsfor the power system? Will it inconvenience the project, degrade the performance ofthe project, or make the project totally unusable?

4.6.4 Operations

How will the device operate? How does it get initialized or reset? How does it normallyoperate? Is there any type of built-in fault detection and correction? The designers willneed to explain both the normal and abnormal ways the device is supposed to operatein this section of the documentation. This should mesh with the Operations ConceptDocument.

4.6.5 Interfaces

What are the electrical and mechanical interfaces between this device and the rest ofthe system? Frequently, the interface will have both a mechanical component and anelectrical component. For electrical interfaces, this includes such information as

1. Power inputs (connectors, polarity indicators, voltage and current ratings, etc.)2. Signal inputs and outputs (connectors, polarity indicators, voltage and current

ratings, etc.)3. Indicator lights (both their colors and assigned meanings)

For mechanical interfaces, this includes such information as

1. Bolt sizes and threading2. Brackets for mounting3. Interface connector housings

From these lists, a cross check can be made with the peer documents to ensure that

-23-

the electrical and mechanical interfaces match.

The interface point will typically be named in a unique manner so that it can be properlydrawn and traced. For example, an electrical harness will be used to connect twosubsystems within the project. This harness will be described by

1. The harness name; for example Harness A,2. The name of the interface connector to subsystem1, and3. The name of the interface connector to subsystem2.

This is illustrated in Figure 10. Here, this is Harness I in the system. The connectorlabeled IM1 is the Harness I connector to connect to the subsystem designated M and itis the first subsystem M connector. The connector labeled IR1 is the Harness Iconnector to the subsystem designated R and it is the first subsystem R connector. On subsystem M, the connector IM1 plugs into the connector XM1 where the “X”indicates that it is an external connection. Likewise, on subsystem R, the connector IR1attaches to connector XR1. The harness specification will then include, at a minimum,

1. The type of connector, e.g. DB9 female, on both the harness side and thesubsystem side,

2. The wiring assignment for each pin in the connector,3. The color and gauge of wire for each strand,4. The way of mechanically attaching the harness connector to the subsystem

connector, and5. The part number of the harness.

Figure 10 – Example wiring harness interfaces.

-24-

4.6.6 Form Factor

What are the size, shape, orientation and interface for this device in the rest of thesystem? If one side is to be oriented in a particular manner, how is that marked andshown on the device? Any other special electrical or mechanical information notcovered elsewhere should be noted here.

4.6.7 Integration with the Testbed

The design testbed is a good tool for testing the integration and operations of thecomponents. An example is shown in Figure 11. In this case, we have the components

for the small satellite project. Each major components/subsystem is enclosed in analuminum box with cables like those to be used in the final assembly between eachbox. AS new components are completed, they are integrated with the overall system. Software can also be developed in this environment rather than using the completed,final hardware for the software development.

4.7 Parts List

The Parts List is exactly what it sounds like: a listing of all of the parts that need to be

Figure 11 – Testbed for the nanosatellite components.

-25-

assembled to make the unit. At the unit level, this is the list of components such aswire, resistors, nuts, bolts, brackets, boxes, connectors, etc. identified as individualpieces. Normally, we do not include the parts on prefabricated devices like a printedcircuit board unless we fabricate the board as part of the project.

Units are assembled into subsystems or systems. Each unit, which is assembled into ahigher-level device, needs to have a serial number that is both unique and trackable. This is true for assemblies made as part of the project and assemblies purchased fromexternal vendors.

At higher levels, the Parts List will include individual components at that level plus anylower-level assemblies made as part of the project or purchased externally.

The content part of the Parts List document (Section 2 in the documentation template)can be arranged as a table with the following columns:

1. Part Number2. Part Description3. Vendor4. Vendor Identifier (model number or the like)5. Quantity Used

Note: if the part is something made by the design team, then the vendor is “NMSU” andthe design team will need to generate a serial number for the part.

4.8 Materials List

Because many designs have safety and environmental concerns, we often need toknow what materials are used in each unit. Normally, the manufacturer will need to beconsulted to obtain this information. If the materials’ content of the unit cannot befound, the unit may need to be encapsulated to prevent out gassing or other potentiallydangerous interactions between the unit and the user or the user’s environment. TheMaterials List document can be entered as a table for Section 2 with the followingcolumns:

1. Part number (same as in the Parts List)2. Part Description3. Part manufacturer4. Part materials (include mass or volume amounts if possible).

4.9 Drawings

Drawings are used to describe the unit being produced visually. The drawings will

-26-

include both the mechanical aspects and the electrical aspects of the design.

4.9.1 Mechanical

The mechanical drawings are the output of a standard drawing package such as SolidWorks or AutoCAD. A picture of the completed mechanical element is also a good ideato illustrate how the drawing translates to “real life.” For the example of our smallsatellite, the mechanical drawing for a side panel is given in Figure 12 to show a typicalmechanical drawing and the fabricated part.

4.9.2 Electrical

The electrical drawings are the output of a standard drawing package such as MultiSimor similar schematic capture programs. A picture of the completed electrical element isalso a good idea to illustrate how the drawing translates to “real life.” For the exampleof our small satellite, the electrical drawing for charging control and associated circuitryfor the power module in the example satellite system is given in Figure 13 to show atypical electrical schematic drawing. Figure 14 illustrates the circuit boardcorresponding to this electrical schematic diagram.

4.10 Assembly Procedure

The units and subsystems will individually need to be assembled and tested. Then theentire set of parts integrated into the full system. The process is typically broken into aUnit Assembly and an Integrated Assembly stage. We will discuss these below.

4.10.1 Unit Assembly Procedure

The Unit Assembly describes how to assemble the parts to make the individual units. This is similar to designing the assembly procedure for a kit. For critical parts or oneswith a complicated procedure, the use of a formal assembly procedure may be requiredin the design. The Unit Assembly Procedure has three subsections for Section 2 of theDocumentation Template that follows the standard Section 1:

-27-

Figure 12 – An example of a mechanical drawing from Solid Works and the fabricated unit forthe example satellite project.

-28-

Figure 13 – Electrical schematic diagram for the charging control and associated circuitry usedin the power module of the example satellite system.

Figure 14 – Printed circuit board for the power unit having the schematic diagram shown inFigure 13.

-29-

1. 2.1 – Assembly Purpose – a verbal description of the assembly being formed2. 2.2 – Assembly Environment – what is needed to make the assembly: clean

environment, tools, soldering irons, test equipment, etc.3. 2.3 – Assembly Procedure – a step-by-step guide for correctly fabricating the

assembly.

The assembly is best done in a repeatable manner. To do this, develop a stepwiseprocedure that can be repeated and documented that it was followed. We do this inthree steps:

1. 2.3.1 – Assembly identification – what parts are being put together2. 2.3.2 – Assembly setup – how to prepare the parts for assembly3. 2.3.3 – Assembly procedure – stepwise procedure

Each of these steps requires both a “test engineer” and a “witness.” The “witness”should be someone who is knowledgeable and can spot problems and act as a checkthat the procedures were really run. In practice, this witness performs the function of aQuality Assurance (QA) engineer. In the capstone class, we will QA the work of ourclassmates rather than having a separate engineering staff.

An example of the assembly identification information is given in Table 3. This table ismade by using a word processor but the table can also be realized using aspreadsheet.

An example of the assembly setup documentation is given in Table 4. Notice that itincludes, as needed, not only the equipment but required setup and calibrationprocedures to be made before the assembly is attempted.

The detailed assembly procedure is illustrated in Table 5. Whenever possible, haveintermediate results that can be checked for correct operation. Also, when makingmeasurements, try to include acceptable ranges or expected values for themeasurements. It is also a good idea to insert pictures of the hardware assembly orspecific components into the procedure at places where it would make the processclearer for someone not familiar with the hardware.

-30-

Table 3 – Assembly identification method.

Check

when

complete

Detailed Procedure Description Engineer

& Date

Witness

& Date

G 1. Enter Identification for Test __________________________

a: Engineer #1 __________________________________

b: Engineer #2 __________________________________

c: Witness #1 __________________________________

d: Witness #2 __________________________________

G 2. Purpose of Test

GACCPT G FAB/ASSY G I&T

G 3. Project Name: University Nanosat 2 - 3 Corner Sat

G 4. Assembly Date (s):________________________

G 5. Part number: ____________________________

G 6. Part Name: Flight Radio Control Board

G 7. Serial Number or ID ___________________________

G 8. Hardware Type

G FLT G FLT QUAL GNonFLT G ETU

Table 4 – Assembly setup documentation.

Check

when

complete

Detailed Procedure Description Engineer

& Date

Witness

& Date

G 1. Properly clean all parts with a cotton swab using isopropyl alcohol.

G 2. Have a PC with Hypertem running. Hyperterm is set for 9600 baud,

8-N-1, XON/XOFF protocol.

G 3. Heat grounded-tip soldering iron. Have cleaning pad properly wet

with distilled water.

G 4. Glove and ground all assembly personnel.

-31-

Table 5 – Detailed assembly procedure.

Check

when

complete

Detailed Procedure Description Engineer

& Date

Witness

& Date

G 1. Insert Basic Stamp into the board in the correct orientation. U3 on the

circuit board should be facing you and at the top left-hand side, notch in

the Basic Stamp pointing towards the power connections to the left of the

Stamp

G 2. Solder all Stamp connections to the board

G 3. Insert first TOSW-230 RF switch into the board in the correct

orientation. U1 and NMSU Radio Control board designation are on the

top side of the control board. Insert TOSW-230 from the bottom side

with the pins sticking out the top side. Pin 1 of the chip is to be inserted

in the pin 1 hole on the circuit board.

G 4. Solder first TOSW-230 RF switch connections to the board

G 5. Insert second TOSW-230 RF switch into the board in the correct

orientation. U2 and NMSU Radio Control board designation are on the

top side of the control board. Insert TOSW-230 from the bottom side

with the pins sticking out the top side. Pin 1 of the chip is to be inserted

in the pin 1 hole on the circuit board.

G 6. Solder second TOSW-230 RF switch connections to the board

G 7. Insert first SMA RF connector into the board in the correct

orientation. Inserted through the top (NMSU Radio Control Board

identifier) and pins stick out the bottom.

G 8. Solder first SMA RF connector to the board

G 9. Insert second SMA RF connector into the board in the correct

orientation. Inserted through the top (NMSU Radio Control Board

identifier) and pins stick out the bottom.

4.10.2 Integrated Assembly Procedure

The Integrated Assembly Procedure uses the same format as does the Unit AssemblyProcedure. Really, we are just assembling smaller units into larger units. The samedocumentation format can be used with appropriate changes for the higher level ofintegration in the system. Again, this may really only be needed when making a criticalassembly or when required by the customer. This document may not be required formore simple projects.

-32-

4.11 Test Procedure

Testing is useful to both troubleshoot designs and to validate that the design works as itshould. The Test Procedure has three subsections for Section 2:

1. 2.1 – Test Purpose – a verbal description of the goals of the test set being run2. 2.2 – Test Points – where in the unit the tests will be made. For electronics, this

will be signal test points. For software, this will be debug or log file output. Formechanical systems, this will be where sensors or other items will be typically beattached.

3. 2.3 – Test Procedure – how to conduct the test and what test instruments arerequired to make the measurements.

The testing is best done in a repeatable manner. To do this, develop a stepwiseprocedure that can be repeated and documented that it was followed. We do this inthree steps:

1. 2.3.1 – Test identification2. 2.3.2 – Test setup3. 2.3.3 – Test procedure

Each of these steps requires both a “test engineer” and a “witness.” The “witness”should be someone who is knowledgeable and can spot problems and act as a checkthat the procedures were really run.

An example of the test identification information is given in Table 6. As with theassembly procedure, the test procedure can be developed in a word processor.

An example of the test setup documentation is given in Table 7. Notice that it includesnot only the equipment but required setup and calibration procedures to be madebefore the test is run.

The detailed test procedure is illustrated in Table 8. Notice that the end of the table hasa checkbox for the tester to indicate if the test were successful.

-33-

Table 6 – Test identification method.

Check

when

complete

Detailed Procedure Description Engineer

& Date

Witness

& Date

G 1. Enter Identification for Test __________________________

a: Engineer #1 __________________________________

b: Engineer #2 __________________________________

c: W itness #1 __________________________________

d: W itness #2 __________________________________

G 2. Purpose of Test

GACCPT G FAB/ASSY G I&T

G 3. Project Name: University Nanosat 2 - 3 Corner Sat

G 4. Test Date (s):________________________

G 5. Part number: ____________________________

G 6. Part Name: Flight Radio Control Board

G 7. Serial Number or ID ___________________________

G 8. Hardware Type

G FLT G FLT QUAL GNonFLT G ETU

Table 7 – Test setup method.

Check

when

complete

Detailed Procedure Description Engineer

& Date

Witness

& Date

G 1. Gather the following test devices

a: 0 - 500 MHz spectrum analyzer; quantity 1

b: 0 - 500 MHz FM signal generators; quantity 3

c: multi-power supply units; quantity 2

d: 1-GHz digital oscilloscope; quantity 1

G 2. Set one FM signal generator with

• 5-kHz deviation FM

• 145 MHz output frequency

• -25 dBm amplitude

• 1-kHz internal tone frequency

G 3. Verify frequency and modulation with spectrum analyzer

G 4. Set second FM signal generator with

• 5-kHz deviation FM

• 450 MHz output frequency

• -25 dBm amplitude

• 1-kHz internal tone frequency

Check

when

complete

Detailed Procedure Description Engineer

& Date

Witness

& Date

-34-

G 5. Verify frequency and modulation with spectrum analyzer

G 6. Set third FM signal generator with

• 5-kHz deviation FM

• 10 kHz output frequency

• -25 dBm amplitude

• 1-kHz internal tone frequency

G 7. Verify frequency and modulation with spectrum analyzer

Table 8 – Test procedure method.

Check

when

complete

Detailed Procedure Description Engineer

& Date

Witnes

s

& Date

I. Primary Radio Switch Test

G 1. Connect power supply ground to circuit board ground

G 2. Connect Channel 1 of oscilloscope to R1SW

G 3. Apply +5V DC to BSPW R and PPW R

G 4. Verify that a negative pulse occurs on Channel 1. This shows

that the radio is switched ON (change of state), if it was in an OFF

state.

G 5. Apply +3.4V DC to PSR1

G 6. After four (4) seconds that there is no pulse on Channel 1

... skipping many intermediate steps for space ...

V. Primary and Secondary Radios Transmit Test

G 1. Connect the 145 MHz signal to Channel 1 of oscilloscope.

Using a tee, connect to R1VHF on control board

G 2. Connect the 450 MHz signal to Channel 2 of oscilloscope.

Using a tee, connect to R2UHF on control board.

G 3. Connect 100 kHz signal to R1UHF and R2VHF. This is to

check that there is no cross talk and/or interference from the

radios close proximity to each other.

Note: The three very different input frequencies are only for

ease in verifying the switching process and are not

necessarily the operational frequencies.

Check

when

complete

Detailed Procedure Description Engineer

& Date

Witnes

s

& Date

-35-

G 4. Connect the VHF output to Channel 3 of oscilloscope and the

UHF output to Channel 4 of the oscilloscope.

G 5. Apply +5V DC (TTL level "1") power to control board at

BSPW R, PPW R, BKPW R. Apply +3.4V DC to PSR1 and PSR2

G 6. Verify that signal on Channel 3 (VHF) of the oscilloscope is the

same frequency as on Channel 1 and Channel 4 (UHF) is the

same frequency as on Channel 2.

G Accept or reject unit:

G Accept G Reject

Whenever possible, have intermediate results that can be checked for correctoperation. Also, when making measurements, try to include acceptable ranges orexpected values for the measurements.

4.12 Assembly Log

The Assembly Log documents when the assembly took place, who performed it, whowitnessed it, and tracks the identity numbers for the parts used in the assembly. TheAssembly Log is the documentation log shown in Table 9 backed with the AssemblyProcedure steps. There is space on the Assembly Log to make notes of problems oranomalies encountered during the assembly process. This is important fortroubleshooting the finished product if any problems occur. Note: if multiple units arebeing assembled with the same assembly procedure, each has a unique Assembly Logbacked with the Assembly Procedure.

4.13 Test Log

Similar to the Assembly Log, the Test Log documents when the testing took place, whoperformed it, who witnessed it, and tracks the identity numbers for the parts used in theunit under test. The Test Log is the documentation log shown in Table 10 backed withthe Test Procedure steps. There is space on the Test Log to make notes of problemsor anomalies encountered during the assembly process. This is important fortroubleshooting the finished product if any problems occur. Note: if multiple units arebeing tested with the same test procedure, each has a unique Test Log backed with theTest Procedure.

-36-

4.14 Integration Procedure

The Integration Procedure is really an Assembly Procedure for one or more units orsubsystems leading all the way up to the final Integration Procedure for finishing thesystem. The format to be used is the same as that for an Assembly Procedure but nowwe are operating at a higher level of integration.

4.15 Integration Log

Accompanying the Integration Procedure is an Integration Log. As you may suspect,the Integration Log would follow the same format as the Assembly Log with theappropriate changes made for this level of integration of the system.

4.16 Integrated Test Procedure

Integrated units or subsystems need to have an accompanying test procedure. Just asin the Unit Test Procedure, there will be an Integrated Test Procedure. Use the UnitProcedure with the appropriate changes for an Integrated Test Procedure.

4.17 Integrated Test LogAccompanying the Integrated Test Procedure is an Integrated Test Log. The IntegratedTest Log follows the same format as the Test Log with the appropriate changes madefor this level of integration of the system.

4.18 Certificates of Compliance

When hardware is purchased from an external vendor, how does the designer knowthat the equipment meets the published specifications for the equipment and the itemreally is the part named in the purchase request? The reputable vendors will supply thepurchaser with a Certificate of Compliance (CFC) to document that the vendor certifiesthat the part really is the one named and that the part meets the publishedspecifications. The design process requires that a file be established to collect andhold the CFC’s for the design validation.

-37-

Table 9 – Example of an assembly log

-38-

Table 10 – Example of a test log

-39-

4.19 Schedule

Every project needs a schedule to track if the project will be completed on time or if it isgetting stuck at a certain stage. The schedule can be very detailed and use a tool suchas Microsoft Project to track it. Alternatively, a simple time line can be used. Identifyingcritical points where schedule slips may occur is helpful. For example, a critical partmay have an 8-week lead time in purchasing. This lead time needs to be captured inthe schedule because it may severely delay design completion. Again, suppose that aspecial, week-long finishing treatment is required for the assembled unit. This will affectsubsequent testing and integration, so this finishing time must be captured in theschedule. Remember: in real life, things will always take longer to complete than oneexpects. Having some pad time in the schedule is not a bad idea as long as the projectis completed by its due date. Do not forget to factor in “down time” cause by holidays orbreaks in the semester schedule.

An example schedule is shown in Figure 14. Here, we identify the tasks by name andWBS number. A task having a specific date, for example a design review, is indicatedby a single diamond symbol such as “�.” Tasks that occur over a range of dates arebracketed by triangles such as “�====�.” The top of the spreadsheet show dates ona two-week basis. Other time bases can be used, as appropriate, to show more or lessdetail.

4.20 Budget

Every design is usually constrained by a real budget. The instructor may give thedesign team a maximum “not-to-exceed” value for your design. The total cost of theitems in your design cannot exceed this amount without prior approval. It may also driveyour choices on parts selection and vendor selection.

-40-

Figure 15 – Example schedule entered as a spreadsheet. This is a portion of the overall schedule showing the WBS identifier, the tasknames, and target dates. The “�” implies a specific date while the “�====�” is a task range of dates.

-41-

4.21 Risk Assessment

Each design has some risk that it will not be completed on time or not work as desired. This is especially true when the performance requirements push what is possible underthe state of the art. The Risk Assessment is the designer’s honest assessment ofwhether or not the final design will meet all functional and performance specifications. The risk will be assessed at “high,” “medium,” or “low.” Each can be interpreted asfollows:

1. High risk – performance or functions may not be met unless all conditions workperfectly.

2. Medium Risk – there is a sufficient margin in the design such that performance orfunctions should all be met

3. Low Risk – it has been shown by testing that the design meets performance orfunctional specification.

Generally, at the initial design phases, most subsystems should be rated at high risk ormedium risk unless that subsystem is an available, proven unit. As the designprogresses, the risk should lower to the medium and low-risk categories. At the finalreview, the risks should all be low, except those items intentionally identified as high-riskitems at the start of the design process.

5 Design Reviews

There are several design reviews to ensure that the process is on track to completion. The design reviews used in this process are

1. System Concept Review2. Preliminary Design Review3. Subsystem Design Review4. Critical Design Review5. Final Review

The individual reviews are described in more detail below along with the items to bepresented at each review level.

5.1 System Concept Review

The System Concept Review (SCR) is intended to see if a workable design is possible. At this stage, all of the major subsystems will be identified. A preliminary draft of thefollowing items should be presented:

1. The Mission Vision, Objectives, Requirements, and Success Criteria Document

-42-

2. Material for each section of 4.6.2 Design Overview 3. The initial draft of the Operations Concept Document4. The initial Risk Assessment for each subsystem5. The development of the Management Plan including sections for (a)

Development Prioritization, (b) Schedule and (c) Budgets. The budgets includebreakdowns for (1) component costing and (2) personnel.

The SCR presentation should, at a minimum, cover the following topics:

1. Title slide with project name, date, and graphic/logo.2. Mission/project overview slides to cover

a. Mission/project vision statementb. Mission/project Objectivesc. Mission/project Requirementsd. Mission/project Success Criteriae. Mission/project Timeline and/or Operational Phases

3. Subsystem slides to cover the design, includinga. Overall system block diagram identifying system segments, overall inputs

and outputs, and any signals between the segments.b. For each segment, a listing of the expected subsystems and a block

diagram showing the relationship between the subsystems and the overallI/O and signals.

c. For each subsystem in each segmenti. Specific requirements and a trace to the Mission Requirements

and/or Success Criteriaii. Block diagram showing expected inputs and outputsiii. Operations description of functions, timing, constraints

d. Preliminary WBS chart4. Prioritization Plan5. Schedule6. Budget, including

a. Personnel requirements for each segment/subsystemb. Costing requirements for each segment/subsystem.

5.2 Preliminary Design Review

The Preliminary Design Review (PDR) is the first major review of the actual design withas many components identified as possible. The materials for the design review includethe following items:

1. Revised Mission/program Vision, Objectives Requirements, and Success Criteria2. Revised Operations Document3. System Design Overview for each segment

a. Requirements for Segment/Subsystem/Units

-43-

b. Requirements Matrix for entire system/programc. Block Diagrams for Functional Flowd. Block Diagrams for Signal Flowe. Baseline draft to the 4.6.2 of the Design Description for each unit and the

first draft of the other sections of the Design Guide

The PDR presentation should, at a minimum, cover the following topics for each designarea:

1. Title slide with project name, date, and graphic/logo.2. Updated mission/project overview slides to cover

a. Mission/project vision statementb. Mission/project Objectivesc. Mission/project Requirementsd. Mission/project Success Criteriae. Mission/project Timeline and/or Operational Phases

3. Subsystem slides to cover the design, includinga. Updated overall system block diagram identifying system segments,

overall inputs and outputs, and any signals between the segments.b. For each segment, an updated listing of the expected subsystems and a

block diagram showing the relationship between the subsystems and theoverall I/O and signals.

c. For each subsystem in each segmenti. Updated detailed specific requirements and a trace to the Mission

Requirements and/or Success Criteriaii. Updated block diagram showing expected inputs and outputsiii. Updated operations description of functions, timing, constraintsiv. Design overview listing components, input/output signals, mass and

electrical properties, specific constraints, materialsv. Subsystem Red/Yellow/Green risk assessmentvi. Unit design diagrams: block diagrams and schematics (mechanical

and electrical)vii. Design budgets for

(1) Performance (mass, power, functional, etc.)(2) Schedule(3) Cost

4. Overall Program Risk Assessmenta. Detailed Red/Yellow/Green by subsystemb. Summarize major cost and schedule risk drivers and mitigation strategies

5. Test and Integration Programa. For each subsystem, describe the tests to be performed by

i. Unitii. Functionaliii. Validation/safety/thermal

b. Describe the expected integration flow

-44-

c. Describe the expected test flowd. Plans for constructing the Project Testbed

6. Development, Test, and Integration Schedule for the Program7. Program Management

a. Team Members and & Organizational Chartb. Risk identification and mitigation strategiesc. Revised WBSd. Revised Requirements Matrixe. Revised Program Schedule down to the Unit level.

5.3 Subsystem Design Review

The Subsystem Design Review (SDR) is intended to make sure that eachunit/subsystem of the overall system is on track to being completed. The materials forthe review include the following items:

1. Revised Mission/program Vision, Objectives Requirements, and Success Criteria2. Revised Operations Document Updates to the Design Guide3. Updated Risk Assessment for each major subsystem4. Preliminary drafts of the Test Plans5. Preliminary drafts of the Assembly Procedures6. Preliminary drafts of the Parts List7. Preliminary drafts of the Materials List8. Preliminary drafts of the electrical and mechanical Drawings9. Assessment of Schedule and Budget status.

The SDR presentation should, at a minimum, cover the following topics for each designarea:

1. Title slide with project name, date, and graphic/logo.2. Updated mission/project overview slides to cover

a. Mission/project vision statementb. Mission/project Objectivesc. Mission/project Requirementsd. Mission/project Success Criteria

3. Subsystem slides to cover the design, includinga. Updated overall system block diagram identifying system segments,

overall inputs and outputs, and any signals between the segments.b. For each segment, an updated listing of the expected subsystems and a

block diagram showing the relationship between the subsystems and theoverall I/O and signals.

c. For each subsystem in each segmenti. Updated detailed specific requirements and a trace to the Mission

Requirements and/or Success Criteria

-45-

ii. Updated block diagram showing expected inputs and outputsiii. Updated operations description of functions, timing, constraintsiv. Updated design overview listing components, input/output signals,

mass and electrical properties, specific constraints, materialsv. Updated subsystem Red/Yellow/Green risk assessmentvi. Updated Unit design diagrams: block diagrams and schematics

(mechanical and electrical)vii. Updated design budgets for

(1) Performance (mass, power, functional, etc.)(2) Schedule(3) Cost

4. Updated overall Program Risk Assessmenta. Detailed Red/Yellow/Green by subsystemb. Summarize major cost and schedule risk drivers and mitigation strategies

5.4 Critical Design Review

The Critical Design Review (CDR) is to ensure that the entire design is ready for a finalbuild. At this point, all of the major design decisions should be finalized and the risks tocompletion should be nearly all “low.” The team should know how the design will cometogether for the final build. The materials for the review include the following items:

1. Near-final version of the Design Guide2. Near-final Risk Assessment3. Near-final version of the Drawings4. Near-final version of the Parts List5. Near-final version of the Materials List6. Near-final version of the Assembly Procedure7. Near-final version of the Test Procedures8. Assessment of Schedule and Budget status.

The CDR presentation should, at a minimum, cover the following topics for each designarea:

1. Title slide with project name, date, and graphic/logo.2. Updated mission/project overview slides to cover

a. Mission/project vision statementb. Mission/project Objectivesc. Mission/project Requirementsd. Mission/project Success Criteriae. Mission/project Timeline and/or Operational Phases

3. Subsystem slides to cover the design, includinga. Near-final overall system block diagram identifying system segments,

overall inputs and outputs, and any signals between the segments.

-46-

b. For each segment, a near-final listing of the expected subsystems and ablock diagram showing the relationship between the subsystems and theoverall I/O and signals.

c. For each subsystem in each segmenti. Near-final detailed specific requirements and a trace to the Mission

Requirements and/or Success Criteriaii. Near-final block diagram showing expected inputs and outputsiii. Near-final operations description of functions, timing, constraintsiv. Design overview listing components, input/output signals, mass and

electrical properties, specific constraints, materialsv. Subsystem Red/Yellow/Green risk assessmentvi. Unit design diagrams: block diagrams and schematics (mechanical

and electrical)vii. Design budgets for

(1) Performance (mass, power, functional, etc.)(2) Schedule(3) Cost

4. Overall Program Risk Assessmenta. Detailed Red/Yellow/Green by subsystemb. Summarize major cost and schedule risk drivers and remaining mitigation

strategies5. Test and Integration Program

a. For each subsystem, describe the tests to be performed byi. Unitii. Functionaliii. Validation/safety/thermal

b. Describe the integration flowc. Describe the test flowd. Demonstrate a Basic, Working Testbed (all important features and

subsystems present)6. Updated Development, Test, and Integration Schedule for the Program7. Program Management

a. Team Members and & Organizational Chartb. Updated risk identification and mitigation strategiesc. Near-final WBSd. Near-final Requirements Matrixe. Near-final Program Schedule down to the Unit level.

5.5 Final Review

This Final Review is to “buy off” that the design really works as required, theperformance requirements have been met, and that the final version of the design isready. The materials for the review include the following items:

-47-

1. The working system for display2. Assembly Logs3. Integration Logs4. Test Logs5. Final Budget accounting6. Final version of the Design Guide7. Final Risk Assessment8. Final version of the Drawings9. Final version of the Parts List10. Final version of the Materials List11. Final version of the Assembly Procedure12. Final version of the Test Procedures.

The Final Review presentation should, at a minimum, cover the following topics for eachdesign area:

1. Title slide with project name, date, and graphic/logo.2. Final mission/project overview slides to cover

a. Mission/project vision statementb. Mission/project Objectivesc. Mission/project Requirementsd. Mission/project Success Criteriae. Mission/project Timeline and/or Operational Phases

3. Subsystem slides to cover the design, includinga. Final overall system block diagram identifying system segments, overall

inputs and outputs, and any signals between the segments.b. For each segment, a final listing of the subsystems and a block diagram

showing the relationship between the subsystems and the overall I/O andsignals.

c. For each subsystem in each segmenti. Final specific requirements and a trace to the Mission

Requirements and/or Success Criteriaii. Final block diagram showing expected inputs and outputsiii. Final operations description of functions, timing, constraintsiv. Design overview listing components, input/output signals, mass and

electrical properties, specific constraints, materialsv. Subsystem Red/Yellow/Green risk assessmentvi. Unit design diagrams: block diagrams and schematics (mechanical

and electrical)vii. Design budgets for

(1) Performance (mass, power, functional, etc.)(2) Schedule(3) Cost

4. Overall Program Risk Assessmenta. Detailed Red/Yellow/Green by subsystem

-48-

b. Summarize how successfully the major cost and schedule risk drivers andmitigation strategies worked

5. Test and Integration Programa. For each subsystem, describe the results of the tests that were performed

byi. Unitii. Functionaliii. Validation/safety/thermal

b. Describe the integration flowc. Describe the test flow

6. Development, Test, and Integration Schedule for the Program7. Program Management

a. Team Members and & Organizational Chartb. Risk identification and mitigation strategiesc. Revised WBSd. Revised Requirements Matrixe. Revised Program Schedule down to the Unit level.

8. Final working project should be demonstrated.

6 Class Expectations

In this class, the student is expected to “do everything.” That is, the student team isexpected to produce

1. The actual design item for which the team is responsible2. The supporting documentation3. The test of the item to show that it works as designed.

The rough schedule for deliverables will be

1.Semester 1:a.System Concept Review – 1/3 through the semesterb.Preliminary Design Review – 2/3 through the semester

2.Semester 2:a.Subsystem Design Review – First Weekb.Critical Design Review – Mid-termc.Final Review – Finals Week

-49-

Appendix A – Documentation Template

This documentation template appearing on the following pages was developed for asatellite design project. It can be adapted to be the documentation template for otherprojects as well.