The EE400D Robot Company

• Functional Organization
• Project Teams
• Matrix

• Engineers working on the project work within the company’s existing functional organization.
• Coordination is maintained through existing company management structure.
• EE400D, a classroom of future electrical engineers, is not a real company and has no existing company management structure. Our functional organization will therefore reflect the common functional elements of our projects. This was a key consideration in the selection of our candidate set of projects.

• The company (instructor) assigns engineers to a project team which remains intact over the life of the project (the semester)
• This structure is simple, cohesive, and most important the one which you are most familiar.
• Unfortunately this structure has many disadvantages.
  • No training. You are assumed to be technically proficient in your area of responsibility on day 1.
  • No sharing of technology expertise or resources.
  • Difficult post-project transition. A real problem in a company with thousands of engineers.
• For these reasons, the Matrix organization is the typical structure you will find in large organizations like NASA’s Jet Propulsion Laboratory.

• Our class is organized as a matrix type organization as defined in the following two articles. Note that the x and y axis of our matrix is reversed from the generic matrix organization cited in these articles.
  • Matrix Management
  • Chap 3 Organization Structure

• The Matrix is a Hybrid organization where projects are overlaid on the company functional structure. For our class our functional organization is based on the common components of our robots.
• Notice that our functional organization forms the vertical axis of the matrix.
• In a matrix organization you report to both a project and a line manager.

• From the perspective of the company matrix, the Functional Organization is the vertical axis and describes the division’s sections, and groups that make up the company.
• Using NASA’s Jet Propulsion Laboratory as an example each node (circle) is a group of engineers who report to a group supervisor. These group supervisors in turn report to a section manager, who are at the end of each horizontal line in the matrix. Also seen in the matrix, each section manager reports to a division manager who in turn reports to the president. This is the Line Management of the company.

NASA System Engineering Handbook Section 6.1.2.1 “Work Breakdown Structure” and Section 4.3.2.1
“Product Breakdown Structure.” Also, review page 312 Figure G-1 where a PBS Example is provided.

This document describes how The Robot Company is structured technically known as the Company Work Breakdown Structure (WBS). From your perspective, the WBS describes your responsibilities within the company. In that spirit, I have worded the sections in the form of Job Descriptions and named the document accordingly.

During the first phase of the project, your manager will create a project WBS, based on this one but adapted to your specific robot. Later in the semester, you will hear the term Product Breakdown Structure (PBS). The PBS describes the parts (functional blocks) of the robot. The PBS is the responsibility of the System Engineer.

To make sense out of the following material, please refer to the Company Matrix Organization Chart presented earlier and the Figure 1 Company Work Breakdown Structure. To learn more, read Section 6.1.2.1 “Work Breakdown Structure” and Section 4.3.2.1 “Product Breakdown Structure” in the NASA System Engineering Handbook.  On page 312 Figure G-1 a PBS Example is provided.

Figure 1 Company Work Breakdown Structure

If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble … Therefore: Make sure the organization is compatible with the product architecture – Conway’s law

Task Summary:

• Define mission objectives
• Set cost and schedule goals based on inputs for the project manager and Electrical Engineering Department chair.
• Validate project design

The president is responsible for the management of all Robot Company projects. Coordinate working from the customer’s mission objectives to develop the program requirements for each project. Will allocate limited financial resource between projects.

The QA Engineer working with the project and division managers, will insure that project plans, documentation, presentations, and blog posts are consistent with those generated by working engineers and reflects well on the CSULB COE and EE department.

Define projects level 1 requirements, hold project meetings, manage and keep tasks on schedule. Working with your team to make your robot a success. Success will be defined by meeting cost, schedule, and performance requirements.

Present training material to the division members in the form of hands-on lectures and assess learning with assignments and/or exams. Manage cross-links between projects and find and manage resources within your division.

System Design, Integration and Test

Mission and Application Customization

Interface Design and Resource Tracking

MCU Subsystem and Control Firmware

Sensors, Actuators, and Power

PCB Design

3D Models and Simulation

Support Equipment

Manufacture Parts and Assemblies

Design

1. Who is responsible for designing the cabling layout?
2. You want to build a pan and tilt platform. Who is responsible for the specification of the servos?
3. You want to build a pan and tilt platform. Who is responsible for the design of the brackets to hold the servos?
4. Who is responsible for calculating the torque specification for the servo?
5. Who is responsible for simulating the pan and tilt platform to insure it will meet FOV requirements.
6. Provide one or more examples of a ConOps failure?

Testing

7. Who is responsible for designing robot verification tests?
8. Which division(s) are involved in testing the robot?

Printed Circuit Board

9. Which division(s) are involved in the design, fabrication, and testing of the PCB?
10. What part does the System Design engineer play in the design of the PCB?
11. Who designs the circuit schematic?
12. Who board layout of the Printed Circuit Board (PCB)
13. Who is responsible for assembling the PCB?
14. Who is responsible for testing the PCB?

Software

14. Which division(s) are in involved in software development?
15. Your project has decided to develop an iPhone powered spider robot. Who is responsible for customize the Arxterra application to control the spider robot?
16. Who is responsible for implementing commands?
17. Who is responsible for sending telemetry data packets to the Bluetooth module?
18. Who is responsible for writing the firmware to translate sensor inputs into data bytes?
19. In which computer can you find the MCU communication firmware?

Other

20. Who is responsible for drafting the product breakdown structure (PBS)?
21. Your project has decided to use a CNC machine to fabricate a part for your robot. Who should you look to for help?
22. Who is ultimately responsible for assigning your grade?
23. If you were going to fly a payload on the Space Shuttle, NASA Johnson Spaceflight Center (JSC) reassured you that all surface in the payload bay would be visually clean. Is this a quantitative requirement?
24. How often should system resources be updated?

• Your cover letter along with your resume will help me in assigning company responsibilities. Other direct input for assigning work is welcome.
• One page limit.
• How to write your Cover Letter and Resume
  • Resume Format – Write your cover letter in paragraph form as shown in the second figure here. Please do not provide a “functional” cover letter (first example shown).
  • Your Cover Letter should tell a story!
  • Here are some tips on what Beckman Coulter (Biomedical Engineering) and Google are looking for in your Cover Letter and Resume.
  • Finally, some sample EE400D Cover Letter.
• How to Send Me Your Cover Letter and Resume:
  • Your cover letter and resume should be in a single PDF document. The name of the document should be your name Joe Smith.pdf.
  • Place your Cover Letter with Resume in Beachboard Dropbox.

In your job application cover letter please answer the following questions.

1. Before you begin be sure you have read our company Job Descriptions. Read our company’s Blog Posts to learn more about each project.
2. What Position(s) are you applying for? Start your cover letter with a short sentence that allows our recruiting department to send your cover letter and resume to the correct engineering department(s) for review and consideration.
3. Introductory Paragraph(s):

• Next, introduce yourself by starting with the reason (e.g. motivation, goals) you chose electrical engineering.[1]
• Describe some significant engineering experience[2] and any access[3] you may have to resources which match the background requirements on the job posting.
• When describing your engineering experience, include any projects you have built.

4. EE400D Unique Career Path

• How many units are you taking this semester, including 400D? Do you have a job/internship and if yes, how many hours per week do you work?
• What career track would you like to be placed on? – Line (People) Management, Project Management, Technical Excellence
• If you had a choice, what project would you like to be assigned?
• Although the following material is optional, you may want to include it in order to help us place you within the company.
  1. What technical/project skills would you like to learn?
  2. What fellow students would you like to work with? Optional

[1] If you are not sure where to start see Appendix A     Why Do Students Choose Engineering?

[2] If you do not have any work experience you may include relevant classes.

[3] For example, talent or machines you have access to on campus (e.g., mechanical engineering machine shop, on campus projects, organization like the IEEE, SWE, etc.), at work or home.

Cover Letter Rubric

1. Create a resume that specifically applies your coursework and/or experience toward the position you are applying for at our company.
2. Personalize your resume to the company with a few introductory sentences. Think of your cover letter crystallized into two or three sentences. The company should come away with the idea that this is your dream job and they would be crazy not to hire you.
3. One page limit.
4. Please see Chapter 3 of Finkelstein on ‘Technical Definitions’ and Chapter 18
5. For help, try Resume Builder templates

1. Source: Stiquito An Inexpensive Robot by James M. Conrad, North Carolina State University
   • Career counselor suggested, based on correct (or incorrect) perceptions of the field.
   • A teacher suggested, because the student was good at math and science. (Note: teachers also discourage based on this and perception).
   • Second hand knowledge, like from a neighbor, relative, friend, books, newspapers, magazines.
   • Direct exposure with the field through work, workshops, class assignments.

   Students rarely have direct exposure to engineering.

The following document paraphrases and quotes material originally contained in the NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Section 4.0 System Design (page 31)

System engineering design is a highly iterative and recursive processes, resulting in a validated set of requirements and a validated design solution that satisfies a set of customer expectations.

1. Customer[1] Expectations (Program/Project Objectives and Mission Profile) and Constraints (Stakeholders, Institutional, Professional, etc.).
2. High Level Functional Requirements[2] (Level 1 Program/Project)
3. Functional and Logical decompositions (Project WBS)
4. Trade Studies and Iterative Design Loop
   1. Form Creative Design Solution (System PBS)
   2. Define Level 2 System and Subsystem Performance Requirements
   3. Make Hardware and/or Software Model(s) and Perform Experiments
   4. Organize and Analyze Data
   5. Does Functional & Performance Analysis show design will meet Functional Design and concept of operations (ConOps) Requirements?
   6. If additional detail need, Repeat Process
5. Select a preferred design
   1. Does the system work[3] (functional and performance)?
   2. Is the system achievable within cost and schedule and other constraints?
   3. If the answer is no, reenter design loop (Step 4), reorganize project (Step 3), or adjust Customer’s Expectations and Constraints (Step 1) and start again.
6. Preparing presentations (PDR and CDR)
7. Communicate Results (PDR and CDR)
8. Reports, plans, and specifications. (Project Planning)
9. Implement, Verify, and Validate the design. (Project Implementation)

After Mission Authorization (i.e. funding), the process Starts with a study team collecting and clarifying the Customer’s Expectations, including the program objectives, constraints, design drivers, mission profile[2], and criteria for defining mission success.

From the customer’s expectations high-level requirements are defined. These high-level requirements drive an iterative design loop where (1) creative “strawman” architecture/designs, (2) the concept of operations (ConOps), and (3) derived system and subsystem requirements are developed.

This process will require iterations and design decisions to achieve consistency (design loop blocks 1 – 3). Once consistency is achieved, analyses allows the project team to validate the design against the customer’s expectations. A simplified validation asks the questions:

• Does the system work (functional and performance)?
• Is the system achievable within cost and schedule constraints? [3]

The output of this step will typically result in modification of the customer’s expectations and the process starts again. This process continues until the system—architecture, mission profile, and requirements and stakeholder expectations achieve consistency.

The number of iterations must be sufficient to allow analytical verification of the design to the requirements.

The design process is hierarchical and recursive by nature with the same process applied to the next level down in the program – one person’s subsystem is another person’s project.

System Design Keys

• Successfully understanding and translation of the customer’s expectations into clear unambiguous quantitative, verifiable, and realizable program requirements
• Complete and thorough requirements traceability (including requirement flow-down)
• Document all decisions made during the development of the original design concept[4].
• Visualization of the product in use (ConOps) looking for missed level 1 requirements. Rapid Prototyping also helps us discover missing level 1 requirements (ex. ShopVac).
• Design validation is a continuing recursive and iterative process occurring over the entire life cycle of the product

Remember, validation occurs over the life of the product (from concept to retirement).

Design faults discovered before the operational phase of the project.

• On the prosthetic arm project, conOps showed that we had failed to conceptualize the soldier in McDonalds. Specifically, in appearance and the potential noise generated by the system. In both cases, unwanted attention of fellow customers would have been be placed on the soldier.
• On the solar panel project, conOps showed that we had failed to conceptualize operation of the rover remotely, in the desert or ultimately on Mars. Once discovered telemetry requirements were added to the project.

Design faults discovered during the operational phase of the project.

• After successful verification of the Pick and Place machine we tried to put it in a cabinet. Clearly, we did not conceptualize this step in the life-cycle of the product. All future projects now include this customer requirement.
• … it emerged that the design of Type 45 destroyers have faulty engines unable to operate continuously in warm waters. “The UK’s enduring presence in the Gulf should have made it a key requirement for the engines. The fact that it was not was an inexcusable failing and one which must not be repeated,” the MPs’ report said. Source: BBC “Royal Navy ‘woefully low’ on warships”

Customer Expectations (Project Objectives and Mission Profile)

Sponsor presents Program and/or Mission Objectives

• These are not requirements, but rather a statement of a problem to be solved. They may be qualitative in nature.

High Level Requirements (Level 1 Program/Project)

Reference: NASA Systems Engineering Handbook Section 4.2 Technical Requirements Definition Start (page 40) and Appendix C page A: 279

Figure 1. Requirement Levels

• Translate Program and/or Mission Objectives into Level 1 Program/Project Requirements.
• Work with and get the sponsors concurrence that these meet their Program and/or Mission Objectives.
• It is important to document all decisions made during these early phases of the project. Include links to source material and how decisions were made.
  • Were the equations used to calculate a requirement provided and are the answers correct?
  • Close attention to this process is the difference between the customer saying “you said” and your company paying to correct the problem within the agreed upon schedule, versus you telling the customer your new requirement is out-of-scope and your customer paying the increased cost with attendant schedule delay[1].

Form Creative Solutions

The word “creative” appears less than a half dozen times in the 360 page NASA Systems Engineering Handbook. I will therefore rely on outside sources.

Logical decompositions (Level 2 Systems)

The following document paraphrases and quotes material originally contained in the NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Section 4.3 Logical Decomposition (page 49)

“Logical Decomposition is the process for creating the detailed functional requirements that enable NASA programs and projects to meet the stakeholder expectations. This process identifies the “what” that must be achieved by the system at each level to enable a successful project. Logical decomposition utilizes functional analysis to create a system architecture and to decompose top-level (or parent) requirements and allocate them down to the lowest desired levels of the project.”

Design solutions – Experiments and Modeling (Level 2 Subsystems)

TBD

[1] For more on this subject see Week 3 “Requirements” document on page 10.

Source: NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1, Section 5.3 Product Verification

While the approaches taken to verify and validate a design may be similar, the reason behind the tests are different. Verification tests confirm that Project Objectives for the design (ex. the robot) as defined by its level 1 and level 2 design requirements are met. Validation tests confirm that the design can accomplish its mission. For our robots this is defined by the Mission Profile.

Like the design process, verification and validation are hierarchical by nature with the same process applied to the next level down in the program – one person’s subsystem is another person’s project.

Source: NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1, Appendix D: Requirements Verification Matrix

When developing requirements, it is important to identify an approach for verifying the requirements. The requirement verification matrix defines how all design requirements are verified. The matrix should identify each requirement by a unique identifier and be definitive as to the source. The example shown provides the minimum information that should be included in the verification matrix.

Table D‑1 Simplified Requirements Verification Matrix

1. Unique identifier for each System X requirement. The identifier should indicate the document the System X requirement is contained within. If more than 1 include a key (P = PDR, C = CDR)
2. Paragraph number of the System X requirement.
3. Summary Text (within reason) of the System X requirement, i.e., the “shall.”
4. Success criteria for the System X requirement.
5. Verification method for the System X requirement (analysis, inspection, demonstration, or test). If not verified in ECS-316 then indicate facility or laboratory used to perform the verification and validation (home, ECS-315).
6. Indicate documents that contain the objective evidence that requirement was satisfied
7. Simple PASS/FAIL

Source: NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1, Appendix E: Creating the Validation Plan (Including Validation Requirements Matrix)

When developing a design, it is important to identify a validation approach for demonstrating that the system (robot) can accomplish its intended mission. Validation testing is typically defined and conducted by the customer.

To simplify the course, a single validation grade will be assigned at the end of the mission.

High-Level Program/Project Requirements and Expectations: These would be the top-level requirements and expectations (e.g., needs, wants, desires, capabilities, constraints, and external interfaces) for the product(s) to be developed. (Section 4.1.1.3)

ConOps: Concept of Operations – This describes how the system will be operated during the life-cycle phases to meet stakeholder expectations. It describes the system characteristics from an operational perspective and helps facilitate an understanding of the system goals. (Section 4.1.1.3)

SE: Systems Engineering is the art and science of developing an operable system capable of meeting requirements within often opposed constraints. Systems engineering is a holistic, integrative discipline, wherein the contributions of structural engineers, electrical engineers, mechanism designers, power engineers, human factors engineers, and many more disciplines are evaluated and balanced, one against another, to produce a coherent whole that is not dominated by the perspective of a single discipline. (Section 2.0 Fundamentals of System Engineering)

1. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Appendix C: How to Write a Good Requirement, Use of Correct Terms
2. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Appendix C: How to Write a Good Requirement, Requirements Validation Checklist, Clarity
3. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Section 4.2 Technical Requirements Definition Start (page 40)
4. Department of Chemical Engineering, University of Michigan, Ann Arbor, Chapter 5 “Problem Definition Techniques”

1. Customer[1] Expectations (Project Objectives and Mission Profile)
2. High Level Requirements (Level 1 Program/Project)
3. Functional and Logical decompositions (Project WBS)[2]
4. Trade Studies and Iterative Design Loop
   1. Form Creative Design Solution (System PBS)
   2. Define Level 2 System and Subsystem Requirements
   3. Make Hardware and/or Software Model(s) and Perform Experiments
   4. Organize and Analyze Data
   5. Does Functional & Performance Analysis show design will meet Functional Design and concept of operations (ConOps) Requirements?
   6. If additional detail need, Repeat Process
5. Select a preferred design
   1. Does the system work[3] (performance)?
   2. Is the system achievable within cost and schedule constraints?
   3. If the answer is no, adjust Customer’s Expectations (Step 1) and start again.
6. Communicate Results (PDR and CDR)
7. Preparing presentations (PDR and CDR)
8. Reports, plans, and specifications. (Project Planning)
9. Implement the design. (Project Implementation)

• As you explore the problem by translating into requirements, a step which includes design trade-off studies, simulation, modeling, experiments, and rapid prototyping; you may also want to first apply the Duncker Diagram.
• Case Study – Duncker Diagram
• Problem: People are being injured and dying in traffic accidents.
• Achieve Desired State: Decrease the number of traffic accidents
  • Path 1: Driver education
  • Solution 1a: Roll out a “Drive Safely” campaign
  • Path 2: Traffic enforcement
  • Solution 2a: Hire more policemen
  • Path 3: Autonomous Vehicles
• Ok not to Achieve Desired State: Do NOT decrease the number of traffic accidents
  • Path 1: Design a safer vehicle
  • Solution 1: Air Bags
  • Solution 2: Impact crumple zones
• • Path 2: Design safer roadways
  • Solution 1 – 7: Roadway Engineering Design Strategies To Make Roads Safer For Drivers

The Situation:   Toasty O’s was one of the hottest selling cereals when it first came on the market. However, after several months, sales dropped. The consumer survey department was able to identify that customer dissatisfaction, as expressed in terms of taste, was related to the age of the cereal.  Consequently, management determined that they must streamline the production process to get the cereal on the store shelves faster, thus ensuring a fresher product.  Engineering had quite a time with this problem – there wasn’t much slack time that could be removed from the process to accomplish the goal.

Of the steps required to get the product on the shelves (manufacturing, packaging, storage, and shipping) manufacturing and packaging were the fastest so plans for building plants closer to the major markets were considered as was trying to add more trucks to get the cereal to market faster.

Sales of Toasty O’s are dropping. Consumer surveys have indicated dissatisfaction with a stale taste.

Perceived Mission Objective (The Problem):

“Streamline the production process to get the cereal on the store shelves faster, thus ensuring a fresher product.”

Second Perceived Objective:

Get the Cereal to Market Faster

Original Mission Statement

Get cereal to market faster.

The real problem was that the cereal was not staying fresh long enough, not that it wasn’t getting to market fast enough.

New Mission Statement

Make Toasty O’s boxes tighter and determine appropriate additive to slow down the spoiling reaction.

Once you have Identifying the real problem and gathered needed Information it is time to search for “original” creative solutions.

• Here are several techniques to help you and your team produce original creative ideas.
• Ideas may come from creativity, a subconscious effort, or innovation, a conscious effort.
• The objective is to break the set patterns of thought that everyone develops (i.e., team’s thinking tends to fall into ruts).

• Brainstorming versus Brainwriting
  • All ideas are encouraged.
  • Write down as many ideas as possible
  • After a break, combine and improve ideas.
  • Delay judgment and evaluation of ideas until end…
• Comments that Reduce Brainstorming to Braindrizzling

Methodology

1. List the major attributes or properties of a product, object, or idea – The fish bones
2. For each attribute, Brainstorm how each of the attributes could be changed.

Example

How can we improve the design of a cell phone?

Edward de Bono developed the lateral thinking techniques of random stimulation and using other people’s views to generate ideas during brainstorming. Lateral thinking provides new ways to come at a problem and get “unstuck.” We will look at two:

1. Forced Relationship Technique
2. Different Point of View

Methodology

1. Take a fixed thing, such as the product or some idea related to the product
2. Force it to take on the attributes of another unrelated thing.
3. Brainstorm

Pro-Tip: Try this Random Noun Generator

Example – Weed Cutter

The weed cutter will be the forced object. Suppose we randomly choose an automobile wheel as the other element. Some of the ideas that may occur based upon the automobile wheel are:

A weed cutter that rolls.
A round weed cutter.
A rubber weed cutter.
A weed cutter that has spokes.
A weed cutter that has brakes.

People sometimes stretch their minds by adopting different points of view.

• Imagine yourself in the future ; “What are the characteristics of an ideal solution?” even if not technically feasible today.
• Imagine a similar problem located on a strange planet or in free fall.
• Try to identify with the stone that is to be crushed, or the fruit that is going to be peeled.
• Pretend that common materials or components are not available or that certain exceptional ones are.
• Try to project how nature would do it.
• The methods are endless.

Lodged by Robert Frost

The rain to the wind said,
‘You push and I’ll pelt.’
They so smote the garden bed
That the flowers actually knelt,
And lay lodged–though not dead.
I know how the flowers felt.

Here are a few more specific actions and attitudes that can be employed to overcome obstacles to creative thinking:

1. Avoid placing unnecessary constraints on the problem being solved.
2. Search for different ways to view the problem, avoiding preconceived beliefs and stereotypical thinking.
3. Recognize that there are non-engineering solutions to many problems. Consider approaches that other disciplines might use.
4. Look for relationships that are remote and solutions that are unusual and nontraditional.
5. Most creative thought involves putting experiences and thoughts into new patterns and arrangements.
6. Divide complex problems into manageable parts and concentrate on solving one part at a time.
7. Allow time for incubation, after periods of intensive concentration – sleep on it
8. Be open to a variety of problem-solving strategies.

1. Introduction to Engineering Design and problem Solving, The Summer Institute for Engineering and Technology Education, University of Arkansas 1995.
2. University of Arkansas – A Collection of Engineering Design Problems [2009 Edition] This document also introduces “The Design Loop”
3. Teehan+Lax-Brainstorming-Checklist
4. University of Michigan – Strategies for Creative Problem Solving
   • Download and install first module – Brainstorming
   • University Of Michigan Chapter 4 – The First Four Steps
   • University Of Michigan Chapter 5 – Problem Definition Techniques
   • University Of Michigan Chapter 6 – Breaking Down the Barriers to Generating Ideas
   • University Of Michigan Chapter 7 – Generating Solutions (a lot of branches from this material)
     • Open-Ended Problem Solving Algorithm
   • University Of Michigan Chapter 8 – Deciding the Course of Action
   • University Of Michigan Chapter 9 – Implementing the Solutions

Types of Requirements

1. NASA System Engineering Handbook NASA-SP-2007-6105-Rev-1, Section 4.2.2.1 Types of Requirements
2. AcqNotes Requirements Development – Requirement Types

Functional requirements

Functional requirements define what functions need to be performed to accomplish the objectives. For example “The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch and yaw axes.” This statement describes a high-level function that the TVC must perform. The technical team needs to transform this statement into a set of design-to functional and performance requirements. [1]

Performance requirements

Performance requirements define how well the system needs to perform the functions. Here are the performance requirements associated with the functional requirements example. [2]

• The TVC shall gimbal the engine a maximum of 9 degrees, ± 0.1 degree.
• The TVC shall gimbal the engine at a maximum rate of 5 degrees/second ± 0.3 degrees/second.
• The TVC shall provide a force of 40,000 pounds, ± 500 pounds.
• The TVC shall have a frequency response of 20 Hz, ± 0.1 Hz.

Be careful not to make performance requirements too restrictive. For example, for a system that must be able to run on rechargeable batteries, if the performance requirements specify that the time to recharge should be less than 3 hours when a 12-hour recharge time would be sufficient, potential design solutions are eliminated. In the same sense, if the performance requirements specify that a weight must be within ±0.5 kg, when ±2.5 kg is sufficient, metrology cost will increase without adding value to the product.

Derived Requirements

Requirements that are implied but not explicitly stated or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Requirements arising from constraints, consideration of issues implied but not explicitly stated in higher-level requirements, factors introduced by the selected architecture, and the design. [3] For example, a requirement for long range or high speed may result in a design requirement for low weight. [4]

Allocated Requirements

A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items. By definition, these are interface requirements and may include mass properties, structural/mechanical, fluid, electrical (power), electronic (signal), software and data, environment (ex. dimensions, center-of-mass, field-of-view, stiffness), electromagnetic effects (electromagnetic compatibility, electromagnetic interference), to name a few. [5]

Specifications and Design Requirements

The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals. [6] All applicable standards must be referenced or included in the product specifications.

A specification provides sufficient depth, guidance, and constraints to build/purchase the design.

Technical Requirements

Endnote

In this section, I will look at how these requirement types fit within the temporal and hierarchical structure (Figure 1) of a NASA flight project.

Once the customer (e.g., NASA HQ) receives “Mission Authority” (funding), mission objectives and requirements are finalized and given to the implementing organization (e.g., JPL). Along with mission definition, the implementing organization is presented with programmatic constrains, including cost, schedule, and if applicable mission classification.

The implementing organization then translates these mission performance requirements and constants into project/system functional requirements. To these functional requirements, the implementing organization adds institutional constraints, assumption, environmental, and other design requirements and guidelines to a depth sufficient to write project/system performance requirements.

These project/system performance requirements are then further decomposed and allocated among the elements and subsystems. This decomposition and allocation process continues until a complete set of design-to requirements is achieved. At each level of decomposition (system, subsystem, component, etc.), the total set of derived requirements must be validated against the stakeholder expectations or higher level parent requirements before proceeding to the next level of decomposition.

Figure 1. Requirement Flowdown

1. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Appendix C: How to Write a Good Requirement, Use of Correct Terms
2. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Appendix C: How to Write a Good Requirement, Requirements Validation Checklist, Clarity
3. NASA Systems Engineering Handbook NASA-SP-2007-6105-Rev-1 Section 4.2 Technical Requirements Definition Start (page 40)
4. Department of Chemical Engineering, University of Michigan, Ann Arbor, Chapter 5 “Problem Definition Techniques

1. Customer[1] Expectations (Project Objectives and Mission Profile)
2. High Level Requirements (Level 1 Program/Project)
3. Functional and Logical decompositions (Project WBS)[2]
4. Trade Studies and Iterative Design Loop
   1. Form Creative Design Solution (System PBS)
   2. Define Level 2 System and Subsystem Requirements
   3. Make Hardware and/or Software Model(s) and Perform Experiments
   4. Organize and Analyze Data
   5. Does Functional & Performance Analysis show design will meet Functional Design and concept of operations (ConOps) Requirements?
   6. If additional detail need, Repeat Process
5. Select a preferred design
   1. Does the system work[3] (performance)?
   2. Is the system achievable within cost and schedule constraints?
   3. If the answer is no, adjust Customer’s Expectations (Step 1) and start again.
6. Communicate Results (PDR and CDR)
7. Preparing presentations (PDR and CDR)
8. Reports, plans, and specifications. (Project Planning)
9. Implement the design. (Project Implementation)

• After Mission Authorization (i.e. funding), the process Starts with a study team collecting and clarifying the Customer’s Expectations (The Problem Statement), including the program objectives, constraints, design drivers, mission profile[1], and criteria for defining mission success.
  • Include information on what you are to solve, and consider why you need to solve this problem. The Duncker Diagram may help answer this question.

[1] I will use the term Mission Profile in place of Operational Objectives

• The statement of the Customer’s Expectations may be modified as objectives are translated into requirements and the nature of the real problem is better understood.
• After each iteration, make sure you are proceeding to solve the real problem as opposed to the perceived problem.

From the customer’s expectations high-level requirements are defined.

These high-level requirements drive an iterative design loop where creative “strawman” architecture/designs and derived system and subsystem requirements are developed.

This process will require iterations (inside loops) and design decisions to achieve consistency. Once consistency is achieved, analyses allows the project team to validate the design against the customer’s expectations. A simplified validation asks the questions:

• Does the system work[1] (performance)?
• Is the system achievable within cost and schedule constraints?
• The output of this step will typically result in modification of the customer’s expectations and the process starts again (outside loop).
• This process continues until the system—architecture, mission profile (ConOps), and requirements and stakeholder expectations achieve consistency.
• The number of iterations must be sufficient to allow analytical verification of the design to the requirements.
• The design process is hierarchical and recursive by nature with the same process applied to the next level down in the program – one person’s subsystem is another person’s project.

[1] This includes determining if the system is safe and reliable.

Reference:   NASA Systems Engineering Handbook Section 4.2 Technical Requirements Definition Start (page 40) and Appendix C page A: 279

1. Understand and translate of customer’s expectations into clear unambiguous quantitative, verifiable, and realizable level 1 program requirements
2. Complete and thorough requirements traceability (including requirement flow-down and verification that the requirement is at the correct level).
3. Does the requirement move the design process forward and are any requirements missing (your strawman design will help you discover these requirements)?
4. Document all decisions made during the development of the original design concept[1]. (Including links to source material) and how they were made (Are equations used to calculate a requirement provided and are answers correct)
5. Is language in the form of a requirement?
6. Avoid multiple requirements within a paragraph. (i.e., breakup statements that contain multiple requirements)

Understand and translate of customer’s expectations into clear unambiguous quantitative, verifiable, and realizable level 1 program requirements

• “We choose to go to the moon in this decade” (time 0:19 to 0:23) is both a goal and at the same time an excellent set of top-level programmatic requirement encompassing cost, schedule, and performance.
• “This administration …declares unconditional war on poverty in America” may be a noble goal, but does not lead to a good set of top-level requirements.

Complete and thorough requirements traceability (including requirement flow-down and verification that the requirement is at the correct level).

• Program requirements translate, are linked to, the customer objectives, while project requirements may reflect an institutional requirement (like safety or flight restrictions).
• At this point in the project, our focus is on translating the customers and institutional requirements into Program/Project requirements.
• Program/Project requirements typically do not imply a design solution.

Does the requirement move the design process forward and are any requirements missing (these are the hardest to discover and the most expensive in cost and schedule to correct)?

• The lowest level requirement is normally stated in the form of a specification. In the diagram below, in the bottom row – left hand corner a specification is created without a link to a higher level requirement(s). This is the simplest way of discovering any missing requirements. Alternatively, if no such higher requirement exists, the product is over designed.
• In middle row – right side of the diagram below we have an example of a requirement that does not lead to a specification and therefore does not move the design process forward. Alternatively, it could be argued that the product is under designed by not meeting all its design requirements.

Document all decisions made during the development of the original design concept[2].

• Include links to source material and how decisions were made
  • Are the equations used to calculate a requirement provided and are answers correct?
• Close attention to this process is the difference between the customer saying “you said” and your company paying to correct the problem within the agreed upon schedule, versus you telling the customer your new requirement is out-of-scope and your customer paying the increased cost with attendant schedule delay.

Is language in the form of a requirement?[3]

• Use of Correct Terms. The correct word usage can make all the difference between success and failure.

1. Shall = requirement. All the rules defined in this presentation apply!
2. Will = facts or declaration of purpose. Typically verified simply by inspection. The robot will be painted red.
3. Should = goal. Time permitting we will accomplish this goal. You can think of these as bonus points.

• Are the requirements clear and unambiguous?
  • Are all aspects of the requirement understandable and not subject to misinterpretation?
  • Is the requirement free from indefinite pronouns (this, these) and ambiguous terms (e.g., “as appropriate,” “etc.,” “and/or,” “but not limited to”)?

• Are the requirements concise and simple?

Avoid multiple requirements within a paragraph[1].

• Do the requirements express only one thought per requirement statement, a standalone statement as opposed to multiple requirements in a single statement, or a paragraph that contains both requirements and rationale?
• Does the requirement statement have one subject and one predicate?

• Spring 2016 A-TeChToP Research Project

The most exhaustive research project ever done. Unfortunately, in many cases poorly translated to a corrected set of requirements.

• Tesla

The Tesla Final Project Document is here.  Does level 1 Project Requirements meet the criteria previously defined? Do level 2 System/Subsystem flow down from the level above.

• Pathfinder

The Preliminary Pathfinder Project Document is located here. How will these requirements be verified?

The System Engineering Method

Mission Authority > Start

1. Customer[1] Expectations (Project Objectives and Mission Profile)
2. High Level Requirements (Level 1 Program/Project)
3. Functional and Logical decompositions (Project WBS)[2]
4. Trade Studies and Iterative Design Loop
   1. Form Creative Design Solution (System PBS)
   2. Define Level 2 System and Subsystem Requirements
   3. Make Hardware and/or Software Model(s) and Perform Experiments
   4. Organize and Analyze Data
   5. Does Functional & Performance Analysis show design will meet Functional Design and concept of operations (ConOps) Requirements?
   6. If additional detail need, Repeat Process
5. Select a preferred design
   1. Does the system work[3] (performance)?
   2. Is the system achievable within cost and schedule constraints?
   3. If the answer is no, adjust Customer’s Expectations (Step 1) and start again.
6. Communicate Results (PDR and CDR)
7. Preparing presentations (PDR and CDR)
8. Reports, plans, and specifications. (Project Planning)
9. Implement the design. (Project Implementation)

For EE400D we have consolidate the typical 5 requirement levels: Program, Project, System (included Allocated), Subsystem, and Design, into only two: Program/Project and System/Subsystem. For this course therefore you can differentiate between the two levels by asking yourself the following question. Does the requirement imply a solution, if it does it is at level 2, otherwise it is level 1. One exception is if the customer specifies a design solution as part of their project expectations, in which case it is a level 1 requirement.

High-level requirements are decomposed into functional and performance requirements and allocated across the system. These are then further decomposed and allocated among the elements and subsystems. This decomposition and allocation process continues until a complete set of design-to requirements is achieved. At each level of decomposition (system, subsystem, component, etc.), the total set of derived requirements must be validated against the stakeholder expectations or higher level parent requirements before proceeding to the next level of decomposition.

The traceability of requirements to the lowest level ensures that each requirement is necessary to meet the stakeholder expectations. Requirements that are not allocated to lower levels or are not implemented at a lower level result in a design that does not meet objectives and is, therefore, not valid (under-design). Conversely, lower level requirements that are not traceable to higher level requirements result in an over-design that is not justified. This hierarchical flow down is illustrated in Figure 1.0.

Figure 1.0 The flowdown of requirements

As illustrated in Figure 1.0 constraints may come from the customer “Programmatic” or the implementing organization “institutional.”

When writing level 2 requirements start with the Harware System Block Diagram[1] and Software Block Diagram. Then come up with requirements needed to design each block. By definition, these are level 2 and are needed to build the system.

Figure 1. Tesla’s electromagnetic windshield wiper system. (Credit: US Patent Office)

In the “Requirements and Dunker Diagram” lecture, examples of Level 1 Program/Project by Tesla and Pathfinder were highlighted. In the following example we will take a look at Level 2 System/Subsystem Requirements.

Hexapod (L2 Subsystem Requirements)

• The Hexapod Project Document is named Executive Summary Project – November 1, 2013. The Executive Document provides a short summary paragraph and then links to all critical documentation within the blog. This is a nicely written document, and provides a good case study on derived requirements (flow down) and allocated requirements.

Battery

• The Hexapod requirements are located in 3 documents. Let’s focus on selecting specifications for the battery, which is a function of…
  • Mission duration (Time = Distance/Speed)
  • Average current
  • Maximum current
• A number of ancillary factors including, power supply efficiency and depth of discharge also come into play. 

Hexapod Mission Duration (Distance / Speed)

Mission Duration is derived from knowing the robot’s actual speed and course layout.

1. Speed

“The Hexapod will be able to match the speed of the rover currently being designed by the 400D Rover team…The speed of the rover will be defined at a later time.” – Project Requirements, October 29, 2013

“To match the speed of the rover, a calculation and verification testing will be performed so that Hexapod will have a walking speed of 8 inches in 1 second.” – Mission Objective, April 22, 2014

2. Distance Quiescent

“The Hexapod will be designed to operate safely during a demonstration in class and a complete running of the course laid out for the Hexapod at the traffic terrain (see Figure 1).” – Project Requirements, October 29, 2013

 “Figure 2. Route of the hexapod and spider bot going to travel.”
– Mission Objective, April 22, 2014

3. Mission Duration

• Ultimately, the mission duration was not specified in the October 29, 2013 System Requirements, or the April 22, 2014 Mission Objective documents. It does appear in the April 23, 2014 Current Draw blog post, listed as 5 minutes. This was the last Hexapod blog post.

Hexapod Average Current

Current is an allocated requirement, which includes a current breakdown by component. How could the TBDs have been filled in? Without knowing mission duration and current requirements, battery sizing becomes problematic – Resource Report October 31, 2013.

 “The Hexapod will have power supplied from a portable source, such as a battery, so that it can be controlled remotely and without any other equipment.” – System Requirements, October 29, 2013

• Is this an L2 system requirement? As with most robots a power budget is critical and the responsibility of the system engineer. 

Hexapod Battery Specification

“The battery chosen for the build will need to provide power for 18 servos and the control board. It will need to be rechargeable and be within budget. The weight of the battery must not excess 1/5 the weight of the full Hexapod. The battery must have better run time to provide full electricity for at least 20 minute operation. It must also provide enough current for all servos. The suitable range of current is from 2700mA to 3600mA (150mAh to 200mAh per servo). The battery should have a high discharge rate order to deliver the large amount of power at once. For safety requirement, the maximum safe continuous discharge rate must be greater than the maximum current drawn from the servos and electronics boards”

Battery Choices – November 1, 2013

• With textual content missing the battery study does not draw any conclusions from the tests and leaves the reader wondering why the tests were even conducted.
• Notice mission duration of 20 minutes has been selected. How was this time derived?

Hexapod versus UFO Abducted Battery Specification

Compare the Battery specification of Hexapod versus battery specification for UFO Abducted.

Hexapod Servo Specification

Subsystem Requirements

Are these requirements? To see how it turned out check out their fun video:

Standards provide technical requirements across a program to avoid incompatibilities, lower cost, establish materials and process specifications, test methods, and interface specifications, to name a few. Standards are applied across the projects life-cycle, including design, fabrication, verification, validation, acceptance, operations, and maintenance.

Standards are generated from many sources, leading to confusion, contradiction, and a need for prioritization. Here is one way standards may be prioritized.

1. Standards mandated by law (e.g., environmental standards)
2. National or international voluntary consensus standards recognized by industry,
3. Government standards
4. Customer and Institutional policy directives, and technical standards.

As an example, the selection of a computer-aided design CAD package may depend on on its ability to meet specific standards, such as model accuracy, dimensioning and tolerancing, the ability to create different geometries, and the capability to produce annotations describing how to build and inspect the part.

[This section is an abridged version of the NASA System Engineering Handbook, Sections 4.2.2.5 Technical Standards and 7.3.4 Design Standards.]

The System Engineering Method

Mission Authority > Start

1. Customer[1] Expectations (Project Objectives and Mission Profile)
2. High Level Requirements (Level 1 Program/Project)
3. Functional and Logical decompositions (Project WBS)[2]
4. Trade Studies and Iterative Design Loop
   1. Form Creative Design Solution (System PBS)
   2. Define Level 2 System and Subsystem Requirements
   3. Make Hardware and/or Software Model(s) and Perform Experiments
   4. Organize and Analyze Data
   5. Does Functional & Performance Analysis show design will meet Functional Design and concept of operations (ConOps) Requirements?
   6. If additional detail need, Repeat Process
5. Select a preferred design
   1. Does the system work[3] (performance)?
   2. Is the system achievable within cost and schedule constraints?
   3. If the answer is no, adjust Customer’s Expectations (Step 1) and start again.
6. Communicate Results (PDR and CDR)
7. Preparing presentations (PDR and CDR)
8. Reports, plans, and specifications. (Project Planning)
9. Implement the design. (Project Implementation)

Design evolves through analysis and synthesis.

• Webster’s definition of design: to conceive and plan out in the mind; to build, create, fashion, execute, or construct according to a plan
• analysis: to divide a complex whole into its parts or elements; separating or distinguishing the component parts of something (as a substance, a process, a situation) so as to discover its true nature or inner relationship
• synthesis: the composition or combination of parts or elements so as to form a whole

• Design is an iterative process where the engineer must analyze the design (i.e., break apart, deconstruct), identify areas of greatest uncertainty, study (rapid prototype) possible solutions, and along the way eliminate poor or unsuitable solutions.

• Once the parts of a design are understood, the design can be synthesized (i.e., put back together, reconstructed) and the design studied as a whole (i.e., at the system level).
• Designs are evaluated based on the mission objectives and requirements.

• There are many techniques an engineer might use to determine if an idea has promise.
  • Draw a preliminary sketch of the design
  • Make a back of the envelope calculation
  • Conduct a trade-off study
  • Model the System

• To facilitate the design process, engineers often rely on models.
• A model simplifies a system or process so that it may be better studied, understood, and used in a design.
• There are three common models used in engineering:
  • Mathematical
  • Computer Simulation
  • Physical Models
    • Full-scale Prototypes
    • Scale Models

• Mathematical models usually consist of one or more equations that describe a physical system.
• Many physical systems can be described by mathematical models. Such models can be based on scientific theories or laws that have stood the test of time, or they may be based on empirical data from experiments or observations.
• In order to construct these mathematical models, simplifying assumptions are often made (e.g., the model system as an nth order constant coefficient linear differential equation).
• Mathematical models are usually employed for simple systems. The difficulty in deriving the equations for complex systems outweighs their usefulness.

• Computer simulation models allow engineers to examine complex systems.
• These models typically incorporate many empirically1 based mathematical models as part of the total simulation model.
• From these empirically based models a computer program is written.
• This computer model is then subjected to many different simulated operating conditions.
• Simulation programs used in EE400D include Solidworks, LTSpice, MATLAB

• Physical models have long been used by engineers to understand complex systems. They probably represent the oldest method of structural design.
• Physical models have the advantage in that they allow an engineer to study a device, structure, or system with little or no prior knowledge of its behavior or need to make simplifying assumptions.
• Full scale models are sometimes built, but most often they have been scaled down anywhere from 1:4 to 1:48.
• Examples of studies made with physical models include:
  • Dispersion of pollutants throughout a lake.
  • Behavior of waves within a harbor.
  • Underwater performance of submarines of different shapes.
  • Performance of aircraft by using wind tunnels to simulate various flight conditions

• Many designers use full-scale prototypes to test the operation of the design.
  • The prototype then helps the designer identify any weak areas of the design and hopefully how to improve upon them.
  • No idea should be discarded solely on the basis of one prototype or one test. Many great designs have been discarded prematurely and many working prototypes have failed to give acceptable products.

Chop Suey (Hexapod)

Indirect evaluation can be used as well, to evaluate a design. Scale models can be used to test aircraft design at a fraction of the cost of building a prototype.

• Computer simulations and mathematical models may not be accurate enough to allow understanding of all the complexities of component interference or turbulence, but they still may be used to approximate the design of the first scale model for wind tunnel testing.

• Introduction to Engineering Design and Problem Solving
• Theories of Architectural Synthesis
  • http://www2.uiah.fi/projects/metodi/13l.htm
• Jack Polymath
  • http://jackpolymath.com/about/meaning
• robotic spider charecter design
  • http://www.coroflot.com/seterwu/robotic-spider-charecter-design
• A Personal Guideline for Gauging with Machine Vision: My Three Pixel Rule
  • http://www.microscan.com/en-us/Community/Blogs/11-16-10/A-Personal-Guideline-for-Gauging-with-Machine-Vision-My-Three-Pixel-Rule.aspx
• Part 1: Choosing a Proper Dynamic System Model by Using Physical Modeling (System Identification Toolkit)
  • http://zone.ni.com/reference/en-XX/help/372458D-01/lvsysidconcepts/sigs_phys_model/

Your final CDR grade will be a weighted average of the following elements.

• Project
  • Presentation Grade (content)
  • Project Readiness (includes items in the previous section, demo(s), etc.)
• Individual
  • Presentation Grade (content as defined in the outline)
  • Presentation Grade (style)
  • Tasks Completed (Appendix A and/or Blog Posts)

For additional tips on your CDR review, I would recommend reviewing the PDR PowerPoint presentation.