Overheads from Parnas Presentation

1
Overheads from Parnas Presentation

• The next slides are transcribed versions of (most
  of) the transparencies in Parnas presentation.

2
Why is it important that the software can never
be trusted?

• We will make decisions as if it was not there.
• They will make decisions as if it might work.

3
A necessary condition for trustworthy engineering
products is validation by

• Mathematical analysis, or
• Exhaustive case analysis, or
• Prolonged, realistic, testing
• or a combination of the above

4
Why software is always the unreliable glue in
engineering systems

• The best mathematical tools require that a system
  be described by continuous functions
  
• Exhaustive case analysis can only be used when
  the number of states is small or the design
  exhibits a repetitive structure

5
Why do we have some usable software?

• Sometimes the requirements allow untrustworthy
  software
  
• There has been extensive use under actual
  conditions
  
• Operating conditions are controlled or
  predictable
  
• Backup manual system available when needed

6
What makes the SDI software much more difficult
than other projects?

• Lack of reliable information on target and decoy
  characteristics
  
• Distributed computing with unreliable nodes and
  unreliable channels
  
• Distributed computing with hard real-time
  deadlines
  
• Physical distribution of redundant real-time
  data
  
• Hardware failures will not be statistically
  independent

7
What makes the SDI software much more difficult
than other projects?

• Redundancy is unusually expensive
• Information essential for real-time scheduling
  will not be reliable
  
• Very limited opportunities for realistic testing
• No opportunities for repairing software during
  use
  
• Expected to be the largest real-time system ever
  attempted, frequent changes are anticipated

8
Software Espionage and Nuclear Blackmail

• Fact Software systems, because of their rigid
  predetermined behaviors are, easily defeated by
  people who understand the programs
  
• Fact Changes in large software systems must be
  made slowly and carefully with extensive review
  and testing

9
What about new Soft. Eng. techniques?

• Precise requirement documents
• Abstraction/information hiding
• Formal specifications
• The use of these techniques requires previous
  experience with similar systems
  
• Co-operating sequential processes requires
  detailed information for real-time scheduling
  
• Structured programming reduces but does not
  eliminate errors
  

10
What about Artificial Intelligence?

• AI-1 - Defined as solving hard problems.
• Study the problem, not the problem solver.
• No magic techniques just good solid program
  design.
  
• AI-2 - Heuristic or Rule Based Programming/Expert
  Systems
  
• Study the problem solver, not the problem
• Ad hoc, cut and dry programming
• Little basis for confidence

11
What about new programming languages?

• No magic
• They help if they are simple and well understood
• No breakthroughs
• The fault lies not in our tools but in ourselves
  and in the nature of our product.

12
What about automatic programming?

• Since 1948 a euphemism for programming in a new
  language?

13
What about program verification?

• The right problem but do we have a solution?
• Whats a big program?
• Wrong kind of program? How do you verify a model
  of the earths gravitational field?
  
• Implicit assumption of perfect arithmetic
• What about language semantics?

14
Is there a meaningful concept of tolerance for
software?

• The engineering notion of tolerance depends on
  an assumption of continuity.
  
• Statistical measures of program quality are
  limited in their application to situations where
  individual failures are not important.

15
Overheads from Seitz Presentation

• The next slides are transcribed versions of (most
  of) the transparencies in Seitz presentation.

16
From The Strategic Defense InitiativeWhite
House pamphlet dated Jan, 1985.

• SDIs purpose is to identify ways to exploit
  recent advances in ballistic missile defense
  technologies that have potential for
  strengthening our security and that of our
  Allies. The program is designed to answer a
  number of fundamental scientific and engineering
  questions that much be addressed before the
  promise of these new technologies can be fully
  assessed. The SDI program will provide to a
  future president and a future congress the
  technical knowledge necessary to support a
  decision in the early 1990s on whether to
  develop and deploy advanced defensive systems.

17
From 1985 Report to the Congress on the Stategic
Defense Initiative (Section III)

• The goal of the SDI is to conduct a program of
  rigorous research focused on advanced defensive
  technologies.
  
• The SDI seeks, therefore, to exploit emerging
  technologies that may provide options for a
  broader-based deterrence by turning to a greater
  reliance on defensive systems

18
From 1985 Report to the Congress on the Stategic
Defense Initiative (Section III)

• It should be stressed that the SDI is a research
  program that seeks to provide the technical
  knowledge required to support a decision on
  whether to develop and later deploy these
  systems. All research efforts will be fully
  compliant with U.S. treaty obligations.

19

• Weapons
• Incapable of causing damage at Earths surface
• Range 1000 km.
• Partial deployment ineffective in boost phase
• Sensors
• Some located in high orbits
• Can be passive
• Useful in early deployments
• Battle Management System
• Computers and communication

20
Coordination

• Lowest Level - stereo and sensor fusion
• Middle Levels - target discrimination, attack and
  coordination
  
• High Levels - assignment of priorities of target
  in midcourse in order to prevent particular areas
  from being overwhelmed in terminal defense, or to
  prevent any single area to accept too high a
  concentration for terminal defense
• Top Level - command and control decisions

21
Conclusions of the Panel

• The feasibility of the battle management
  software and our ability to test, simulate, and
  modify the system are very sensitive to the
  choice of system architecture. In particular, the
  feasibility of the BMS software is much more
  sensitive to the system architecture than it is
  to the choice of software engineering technique

22
Conclusions of the Panel

• Software technology is developing against what
  appears today to be relatively inflexible limits
  in the complexity of systems. The treadeoffs
  necessary to make the software tractable are in
  the system architecture

23
Conclusions of the Panel

• We must prefer an unconventional system
  architecture whose programming is within the
  anticipated limits of software engineering over
  reliance on radical software development
  approaches and the risk that we could not develop
  reliable software at any cost

24
Conclusions of the Panel

• One promising class of system architecture for a
  strategic defense system are those that are less
  dependent on tight coordination because of
  the ability to infer the performance of
  full-scale deployment by evaluating the
  performance of small parts of the system.