Aerospace Systems Engineer


Review and Coordination

Review process-

What does it mean to review a document? Are these formal document reviews of a baselined product or more casual peer level courtesy reviews? The first could benefit from a structured and formal DR type process (at the expense of time), the later can, and should be, more casual.

Does the author want a “rubber stamp” of approval, or a critical review and comments, or a redlined re-write? And with what level of formality?

What is the mechanism for providing “review” comments? Should functional areas (i.e., conops, test, etc.) coordinate input to make sure they are internally consistent?

If one is forwarded a product to review do you provide your review to the author, or the person who forwarded you the product?

A PDR Outline

The objectives of PDR are to demonstrate through presentation and support material that the program understands its requirements and has developed a preliminary design that fulfills the requirements.
Typical PDR Entrance Criteria

The following items are complete (to PDR level of development) and typically provided as read material. Read package may also contain analysis material, trade studies, etc. (i.e., Technical Memos)

            System Specification

            Segment Specification
            Element Specification(s)
            Interface Requirements Specifications IRS(s)
            Software Requirements Specifications SRS(s)
            System verification matrix and verification plan
            System Integration & Test Plan
            System Engineering Design Document (SEDD)

System/Sub-System Architecture

            Block Diagrams
            Interface Diagrams
            Operations Concept Document (OCD)

System Behavior (Threads & Use Cases)

            System Design/Cost Analysis
            SFR Action Items

Completed Mitigation Plan

Typical PDR Presentation Outline


*      Program Overview
*      Program Processes
*      Security/P2
*      Program Staffing
*      Schedule
*      Entrance Criteria

System Introduction

*      System Architecture
*      Functions
*      OPSCON (Behavior) – L0 Thread
*      Thread Mapping
            Critical Use Cases
            Segment Behavior Allocation
*      Timeline Allocations
*      TPMs
*      Risk

Design Description Element

Expectations --

System Architecture
The segment should present the key design areas of their system; Functional, Hardware and Software. Each area should be presented graphically as an architectural diagram. Each will be expanded upon during the Functional, Hardware and Software segments of the PDR presentation. Sub-Segment Architecture Diagram Hardware Implementation & Deployment Diagram Software Implementation & Deployment Diagram

Context Diagram
The segment should present a context diagram illustrating where their segment functionally, physically and logically (SW) fits within the larger system.

Interface Diagram
The segment should present an interface diagram illustrating the physical and logical interfaces with entities outside the segment.

Functional Architecture
The segment should demonstrate they understand the functions required of their system. The segment should present the allocations of functions to HW and SW elements of the design.

Key Function(s) Design
The segment should demonstrate they understand the driving requirements of their segment that support the overall program.

The segment should demonstrate the flow down and understanding of system level requirements to Segment and Element.

The segment should demonstrate they understand the necessary behavior of their segment in support of program requirements and in conjunction with other segments.

The segment should demonstrate they understand and are managing identified areas of design and development risk.

Systems Analysis and Studies
The segment should demonstrate they have performed, with adequate rigor, the analysis of their preliminary design. The segment should present design trades and supporting material for design decisions.

Design Margins
The segment should present design analysis demonstrating design closure and indicating design margin, where applicable.

Development Assurance
*      Requirements Verification Plans & Status
*      Integration & Test
*      Software Engineering
*      Specialty Engineering
*      Reliability/Availability Allocations
*      Maintainability
*      Logistics

It's just a toaster

The "stuff" we work on is big and complex, but the principles are simple and basic. To keep the thinking simple, think of "the system" as a toaster. The same basic SE principles hold true for a toaster as any highly complex system, but we can conceptualize the application to the development of a toaster without getting lost in "interesting" technical problems.

Basic Questions
What are we doing?
What is the objective of the program?
This should be very simply and straightforwardly stated. What Designing
Complex Systems with Models and Objects calls "the essential elements of
design". Typically less than 10.

Who is the Customer?

Who is the System operator?
Who is the System's User (the user of the system's product)?
What is the System?
  • Physical & Logical Architecture
  • Key (driving) requirements "the essential elements of design".
  • Key Use Cases
               Operate (and Maintenance)

  • What is the administrative structure of the program?
  • Should align with physical logical architecture
  • What is the Period of Performance?
  • What are the deliverables?
  • What is the schedule for deliverables?
Spec tree
  • Should align with physical logical architecture and administrative structure
  • Should include Specs (including SRS), conops documents, and ICDs

Processes & Procedures
Documented in a Systems Engineering Management Plan (SEMP)
A SEMP is important from a communication with the team perspective but even more so for being forced, by generating the SEMP, to think about and coordinate within the management team, an implementable process understood and supported by the management team. Process is essential, but fight unnecessary bureaucracy.

SEMP Content (not exhaustive)

  • Program phases and schedule (defines actions and products)
  • Products (with descriptions, include cmd media and/or DID references)
  • Technical Review process (with entrance and exit criteria)
  • CM/DM process
  • Change process
  • Tools & Techniques
  • Systems Engineer F&Rs
  • Functions: Analysis, Design, Review, Audit, Approve
  • Responsibilities:

Systems Engineering emphasis varies over the lifetime of the program