Course Introduction

1
Course Introduction
2
Background

• Highlights (which hopefully will give useful
  insights to course topics)
• Much of career has been backwards!
• Started with reverse engineering included basic
  science and now am technical support to
  acquisition programs.

3
Background

• Analyzed Soviet missile telemetry to determine
  guidance law of ICBMs.
• Goal - assess accuracy.
• Telemetry from their test program.
• RF signal containing sampled engineering
  parameters.
• They made many launches.
• Would there be so many today? Why/ why not?

4
Background

• Test director for AAR-34 improvement program
• F-111 tail mounted IR detector of aircraft and
  AAMs.
• Numerous false alarms rendered it useless in
  Vietnam.
• Contractor/PO needed to test improvements.
• Safety issues (reason not done right originally).
• Once safety resolved, 20 sensors piggy-backed.
• Fired 120 missiles (Would that happen today?).

5
Missile protection on F-111
Infrared sensor
6
In Viet Nam
Jungle with ponds
Sun- glint
Sun Glint
To the F111 warning sensor, it looked like an
enemy missile or aircraft!
7
Dispense chaff and flares!
8
What to do?

• Improvement programa sensor redesign
• Improvements need to be tested
• Took improved sensor to White Sands Missile Range
  (WSMR) New Mexico for testing

9
WSMR
What else was tested here?
10
Fired 120 missiles at the sensor

• Falcons, Sidewinders including

11
10 Soviet Atolls
In 1958 a Sidewinder was fired from a Taiwanese
F-86 Sabre aircraft. It lodged without exploding
in a Chinese MiG-17. It was transferred to the
Soviets who made the Atoll based on it.
12
WSMR
Over 20 sensors piggy-backed on these missile
firings test! Over 100 people at the test site.
13
A day in my life

• Fly to WSMR test control station
• Helicopter to test site
• Fly back to control station
• Supervise test
• Return to home base
• Look at data, and get reports of results
• Extreme excitement and satisfaction!

14
Background

• SGEMP experimenter.
• Basic research.
• Info for spacecraft design using vacuum tank and
  idealized models of spacecraft shapes.
• Note sometimes only the govt can afford to get
  the needed engineering info, market dependent.
• Unless security issues, info is freely available.
• AFOTEC operations analyst.
• Operational test planning.
• From the very beginning!

15
Background

• Director of GPS user equipment test program.
• Gathered data for the Air Force to use in its
  Milestone 2 (B) decision.
• Instrument approaches, bombing, surveying etc.
• Doubters chair.
• Circular error probable (CEP).

16
In the 1970s

• GPS did not exist
• Military navigation done with
• Compass
• Map
• Star sighting with a sextant
• Time of signal to go to a known place and back
• Both accuracy and not being detected were big
  issues

17
Could GPS be the answer?

• Satellites send signals containing the
  satellites position.
• A receiver receiving three or more satellites
  signals can calculate its own position without
  being detected.
• The questions were
• Would it work?
• How to find out?
• The answer was
• A test program!

18
The test setup

• A few satellites were launched, and a few pretend
  satellites were installed, on the ground, at Yuma
  Proving Ground, Arizona.
• Whenever the satellites passed overhead, a test
  could be conducted.
• The idea was to see if a variety of possible
  users would find GPS useful.

19
Some of the GPS users
20
2000-pound dumb bomb
21
Used GPS to position the airplanefor bomb drop
22
Repeatedly impacted in a small area
Doubters chair
23
You know the rest of the story

• This is GPS now.

Based on this test program, the Pentagon decided
to build the GPS.
24
Background

• System engineer for equipment for a spacecrafts
  handling and testing.
• So big only the shuttle could launch it.
• Extreme reliability.
• Needed testing in space environment.
• Think about the difference in the test
  requirements compared to GPS users equipment.

25
Background

• IT manager for special program.
• Involved from the beginning.
• Major contributor to specification.
• If you cant readily imagine a verification
  technique its not a good specification!
• System Integration lab is a crummy place to find
  interface issues caused by poor communication
  during the design process. Sources of poor com?
• However, the fully assembled, ultimate system, is
  a much worse place!!

26
Background

• Contracting Officers Representative (COR) for
  special program.
• Good system engineers are very hard to find.
• Engineers revert to their roots.
• Therefore perhaps best if roots are SE?
• Even with the best of intentions there is never
  enough time for testing.
• Design issues eat into test time and the delivery
  date doesnt change.
• Decision? Bad (or untried) system vs. late
  system!
• Integrated test and product teams work well.

27
Overview and Chapter 1

• Goal is to appreciate and understand the
  different perspectives!

28
Overview and Chapter 1

• IT are integral and essential aspects of systems
  engineering. As such a foundational understanding
  of SE is essential to the understanding of the
  subject.
• We are going to survey the process of systems
  engineering, however
• Always thinking about the effect on IT and TE
• Bottom line These so-called tail-end functions
  arent really - thinking, planning and
  occasionally executing are from the beginning.

29
Overview
Integration vs. Interoperability

• Notion of integration and interoperability
  getting blurred.
• Integration implies within a system.
• Interoperability implies between systems.
• With systems of systems becoming more common the
  difference in the words shrinks.
• Interoperability is a user driven requirement.
• Especially in the defense and banking industries.

30
Overview

• What does it mean to integrate.
• Data and data storage have a shared
  understanding.
• Control single string of control.
• Presentation to the user - seamless and feels
  like its designed by one person.

31
Overview

• Integration
• Property of a relationship i.e. 2 or more
  entities.
• Done well - a users perspective.
• Done easily - an engineers perspective.

32
Overview

• Interoperability
• Much more than data and data exchange.
• More will be required shortly after completion.
• When a component evolves the interoperability of
  the whole must be maintained.
• Cant the same be said within a system?
• If so whats the difference in the two words?
• Interoperability cooperation integration

33
Chapter 1

• Design Integration
• The process that results in a design that
  appropriately includes the suitability
  (ilities) factors and assures that the various
  components of a system will work together
  synergistically and cooperatively.
• IT
• A process of assembly of hardware and/or software
  components to create a system. The checking of
  the results (during the build-up) and fixing of
  problems is included.

34
Chapter 1

• Test
• A form of verification that that gets data which
  can be used to demonstrate whether a certain
  parameter meets or could potentially meet its
  requirement.
• Evaluation
• The process of using data to determine whether a
  requirement has been met. May suggest areas to
  fix to bring the system into compliance.

35
Chapter 1

• What are systems?
• Why are they so complex?
• How do we handle complexity?
• What is a systems approach?
• What is a bottoms-up vs. top-down design approach?

36
Chapter 1

• What is driving the need for more and better
  SE? See Fig 1.4
• Market (Changing requirements, competition etc)
• Deliver now- fix it later
• Complexity (Systems full of what were formerly
  systems, world-wide suppliers and customers)
• How do we deal with complexity?
• Subsystems
• What process becomes harder with more complexity?
  IT

37
Fig. 1.4
38
Chapter 1

• What historically bad practices does SE attempt
  to change? Why? M.E.s? E.E.s?
• What is the most expensive time in a systems life
  cycle for making changes?
• Later is almost always significantly worse.
  Fig 1.5 and1.8.
• Look at Fig 1.7. What are the most often
  forgotten aspects of a system?

39
Fig 1.5
40
Fig. 1.8
41
Fig. 1.7
42
Chapter 1

• Look at Fig 1.2. Do you include these items when
  thinking of a system?
• System life cycle.
• From idea, to creation, to use, to disposal!
• All phases contain consideration for SE!
• Surprisingly all phases require IT consideration
  too!

43
Fig. 1.2
44
Chapter 1

• System engineering identifying qualities.
• Top down - viewing system as a whole.
• Life cycle view.
• Complete effort to identify system requirements
  up-front.
• Interdisciplinary team approach.

45
Chapter 1

• Note the three perspectives in Fig 1.18.
• Parallels from both sides of the V.
• Note Figure 1.19.
• Although says for software I believe its really
  a system diagram i.e. substitute design
  engineering in place of software engineering.
• Note how IT considerations apply to every block.

46
Fig.1.18
47
Fig. 1.19
48
Chapter 1

• DOD 5000 version of Fig 1.26.

49
Fig. 1.26
50
Chapter 1

• Evolutionary development DOD.

51
Chapter 1

• Why evolutionary development?
• Complexity
• Changing technology
• Improvements
• Obsolescence
• What are the implications to IT?
• Anticipation!

52
Chapter 1

• Should SE be the overall program management?
• SE management responsibilities.
• Communication with the customer.
• Develop the SEMP.
• Develop the TEMP.
• Plan/schedule design reviews.
• Conduct ongoing performance assessment and
  validation.

53
Chapter 1

• Why is system IT so important yet so underrated?
• How/why has increasing complexity increased the
  need for more/better SE especially in the form of
  IT competence?

54
Chapter 1

• What are some key enablers to successful IT?
• Good interface definitions.
• Good configuration management.
• Well written i.e. verifiable specifications.
• Enough time planned into program for adequate
  and early testing.

55
Chapter 1

• Lets look at some of the questions at the end of
  Chapter 1.

56
Projects

• Each study group will develop a system.
• System to be selected by the group from list
  (next slide) or approved by Bell.
• Im your customer.
• You will define all the steps and documents.
• Define and selectively develop program schedule,
  system, documents.
• Emphasis is on all integration aspects and
  appropriate testing along the way to customer
  acceptance
• Each group will develop an A Spec, SEMP and TEMP
• Each group will make a presentation (1 hour).
• Every member presents
• Each presentation is a portion of a major design
  or test review.

57
Instructions

• Develop mini(10 pages each) A Spec with
  section 4, SEMP, and Integration Test Plan or
  Master Test Plan
• Define subsystems and their performance
  requirements
• Include engineering organization with roles and
  responsibilities
• Use IPTs
• Summarize written documents for a Powerpoint
  classroom presentation of which everyone presents
  an approximately equal portion
• For the remaining information you need to know to
  do your project... ask Bell.
• If no answer in two days, make and document your
  assumptions then continue.

58
Systems for Projects

• Select one or suggest one to Bell for approval
• Automobile
• Airplane
• Distributed computing
• Train
• Spacecraft
• Health monitoring

59
Systems for Projects

• Automobile
• Seats 5 -220 lb, 65 adults.
• 0-60 mph in 6 sec.
• Accelerates as quickly as it stops.
• Has auto-steer and auto-trip capability
• New capability that uses GPS and obstruction
  sensing to navigate safely from place to place.
• 2 years to IOC.

60
Systems for Projects

• Airplane
• Must host surveillance equipment (provided by
  another vendor)
• Accommodates aircrew and 5 sensor operators
• Delivered with operator USI subsystems installed
• Must fly from unimproved airfields
• Used by all military services
• All weather flying
• 4 years to IOC, if modified
• 6 years to IOC, if new aircraft

61
Systems for Projects

• Distributed computing
• World -wide interconnected users
• Business data processing
• Scientific data analysis
• Includes all communication, computing and data
  storage.
• 2 years to IOC

62
Systems for Projects

• Passenger train
• Magnetically levitated
• 220 mph normal cruise
• Less than 80dB noise at 15 feet from train
• May use modified version of existing cars for
  passengers
• Include first 100 miles of track from DFW to
  Waco
• 3 years to IOC

63
Systems for Projects

• Spacecraft
• Mercury mapper
• Both IR and radar
• Directed subcontractors for the sensors
• 3 year on-station life
• Uses existing ground stations
• 3 years to launch from shuttle in orbit

64
Systems for Projects

• Health monitoring
• Used to monitor ambulatory patients from their
  homes.
• Realtime notification of physicians of out of
  tolerance parameters (50)
• Directed subcontractors for the sensors
• 5 years between mandatory service
• Automatic instructions to patient i.e. not just
  an alarm
• 2 years to competitors roll-out