SDI: A Violation of Professional Responsibility

A presentation by: Rong Gu Cincy Francis Amitkumar Dhameja CS575 - Software Design

SDI: A Violation of Professional Responsibility

Contents: 1.

SDI – An Overview 2.

Parnas & SDI 3.

4.

5.

6.

The Role of Computers The Decision to Act Some Critical Issues Broader Questions 7.

8.

9.

Parnas’ Advice Questions Our Opinion CS575 - Software Design

SDI - An Overview

Strategic Defense Initiative:

 A U.S. government program responsible for research and development of a space-based system to defend the nation from attack by strategic ballistic missiles  Popularly referred to as “Star Wars”  Announced by President Ronald Reagan in a speech in March of 1983 CS575 - Software Design

SDI - An Overview

Strategic Defense Initiative:

 Administered by the Strategic Defense Initiative Organization (renamed Ballistic Missile Defense Organization, 1993)  Under Department of Defense, assisted by NASA CS575 - Software Design

SDI - An Overview

SDI Aims:

 To develop a network of satellites carrying sensors, weapons and computers  To detect ICBMs and intercept them in mid-air  To free us from the fear of nuclear weapons, and make nuclear strategic missiles impotent and obsolete CS575 - Software Design

SDI - An Overview

“Some say it will bring war to the heavens. But its purpose is to deter war in the heavens and on earth. Now some say the research would be expensive. Perhaps, but it could save millions of lives, indeed, humanity itself.” - President Ronald Reagan CS575 - Software Design

SDI – A Software Classification

Four Classes of Usage 1.

2.

Man-rated:

Software so important and critical that lives may depend on it. Examples: SDI, ATC, Medical device software

Enterprise-rated:

Software critical to the uninterrupted operation of an enterprise. Examples: ATMs, Web-commerce software.

CS575 - Software Design

SDI – A Software Classification

Four Classes of Usage 3.

4.

Good-enough:

user software Business software not critical but maybe used frequently. Examples: Personal productivity applications, much client & single

Don’t-care:

Non-critical, business or personal entertainment software. Examples: Games, seldom used utilities CS575 - Software Design

Parnas & SDI

Parnas’ Involvement in SDI :

 Approached by the SDIO in May of 1985  $1000/day SDIO Panel on Computing in Support of Battle Management  Resigned 2 months later CS575 - Software Design

Parnas & SDI

Professional Responsibility:

A professional  Is responsible for his own actions and cannot rely on any external authority to make his decisions for him  Cannot ignore ethical and moral issues  Must make sure that he is solving the real problem, not simply providing short-term satisfaction to his supervisor  Shouldn’t hesitate to “blow the whistle” CS575 - Software Design

Parnas & SDI

Parnas’ Early Doubts:

 Whether any such system could meet the requirements   Possible conflict of interests Whether such a system would be trustworthy  Would it be useful to build a system we did not trust CS575 - Software Design

Parnas & SDI

Why trustworthiness is essential:

If the system is not trustworthy  US will not abandon deterrence and nuclear missiles  Seeing both a “shield” and missiles, USSR would feel impelled to improve its offensive forces  US not trusting its defense, would join in, in the arms race  Result – a more dangerous world, instead of a safer one CS575 - Software Design

The Role of Computers

Computers must:

 Process and analyze vast amounts of data produced by the sensors  Detect missile firings, determine source, compute trajectories  Discriminate between warheads and decoys  Aim and fire the weapons

Software is the glue that holds the system together, if software is not trustworthy, the system isn’t either!

CS575 - Software Design

The Role of Computers

Limits of Software Technology:

 Lack of validation methods mean we cannot expect a real program to work properly the first time it’s used  Tests/simulations fail to uncover all serious problems  Reliability & trustworthiness – only through extensive use.

CS575 - Software Design

Why Software for SDI is Difficult

 Based on assumptions about target and decoy characteristics controlled by attacker  Espionage could render it worthless, so could overloading  Dependence on communicating computers in satellites makes it vulnerable CS575 - Software Design

Why Software for SDI is Difficult

 A satellite will require data from other satellites to assist in tracking, discrimination & countering noise  Realistic testing of hardware & software through “practice” nuclear wars impossible  MUST WORK THE FIRST TIME CS575 - Software Design

The Decision to Act

Some reasons Parnas got in support of SDI:

 Research money would advance the state of computer science!

 The money was going to be spent anyway and Parnas should help to see it well spent!

 There could be 100,000 errors in the software and it would still work properly!

CS575 - Software Design

The Decision to Act

Some reasons Parnas got in support of SDI:

 There was no fundamental law of computer science that said the problem could not be solved!

 Parnas – and other SDI critics – are demanding perfection!

CS575 - Software Design

The Decision to Act

Parnas Resigns…

 Found no scientist who disagreed with his conclusions  Every reply argued with statements other than those Parnas had published  “Taking money allocated for a shield against nuclear missiles, while knowing that such a shield was impossible, seemed like fraud to me” – Parnas CS575 - Software Design

Some Critical Issues

The “90%” Distraction

 3 layers, each 90% effective – overall leakage is less than 1% as effectiveness multiplies

Parnas reveals

  Assumes performance of each layer is independent of others  90% figure picked for illustration Percentage???

CS575 - Software Design

Some Critical Issues

The “Loose Coordination” Distraction (Eastport Group, Dec. 1985)

 Phase I architectures – excessively tight coordination between “battle stations”  Software difficulties could be overcome with loose coordination  New Phase I studies be started CS575 - Software Design

Critical Issues

The “Loose Coordination” Distraction Parnas Argues

 Loose coordination???

 Loose coordination – reduced communication between stations  Later sections discuss need for extensive communication – Inconsistency CS575 - Software Design

Critical Issues

Eastport Group’s Unstated Assumptions

 Battle stations do not need data from other satellites to perform their functions 

False!!!

 Data from other satellites is essential for accurate tracking and discrimination between warheads & decoys CS575 - Software Design

Critical Issues

Eastport Group’s Unstated Assumptions

 An simple battle station is a small software project that will not run into software difficulties described before 

False!!!

 Each battle station is unlikely to work, impossible to test, impossible to trust CS575 - Software Design

Critical Issues

Eastport Group’s Unstated Assumptions

 The only interaction between the stations is by explicit communication 

False!!!

 Communication through weapons, sensors and through shared targets. Weapons, destruction of targets creates noise.

CS575 - Software Design

Critical Issues

Eastport Group’s Unstated Assumptions

 A collection of communicating systems differs in fundamental ways from a single system 

False!!!

 A collection of communication programs is mathematically equivalent to a single program. In practice, distribution makes the problem harder, not easier CS575 - Software Design

Some Critical Issues

1985 CPSR-MIT Debate:

David Parnas, Joseph Weinazenbaum (Against SDI) v.s.

Charles Seitz, Danny Cohen (In favor of SDI) CS575 - Software Design

Some Critical Issues

Parnas’ arguments:

 Specifications cannot be known in advance   Realistic testing is essentially impossible Hard real-time deadlines do not allow repair during use  No foreseeable advance in software tech changes this  Therefore – It is not possible to construct SDI software that you could trust to work CS575 - Software Design

Some Critical Issues

Steitz’s arguments:

 The current objective of SDI is to conduct the vigorous research necessary to build a defense system  Such a system can be written using conventional software techniques coupled with radical hardware architecture  This will greatly aid in the testing, simulation and modification of SDI CS575 - Software Design

Some Data on SDI

TOP 10 SDI contractors 1983-1986:($Thousand) 800,000 700,000 600,000 500,000 400,000 300,000 200,000 100,000 0 720,961 612,698 375,433 Lockheed* General Motors DOE Lawrence Livermore Nat'l Lab* 373,697 Boeing 373,117 TRW 360,300 Company 338,224 327,542 285,588 260,797 EG&G* McDonnell Douglas MIT Lincoln Lab DOE Los Alamos Nat'l Lab* General Electric

Source

: Council on Economic Priorities 1987 CS575 - Software Design

Some Data on SDI

Distribution of requested SDI funding in major research areas in FY1985:($ Million) Survivability, lethality & key support technology Systems concepts & battle 8% Management HQ, SDI 1% management 7% Kinetic energy weapons 19% Surveillance, acquisition, tracking & kill assessment 40% Directed energy weapons 25% Total: $ 1357.299

Source:

Waller

et al.

1986: 15 CS575 - Software Design

Broader Questions



Is SDIO sponsored work of good quality?

 Phase I studies – Eastport vs. SDIO contractors/evaluators  Big promises, low quality  Bypasses scientific review processes, no real scientific contribution CS575 - Software Design

Broader Questions



Do those who take SDIO funds really disagree with Parnas?

 Remember the reasons Parnas got in support of SDI?



The blind led by those with their eyes shut

 Often people indulge in unprofessional behavior just to not displease the customer CS575 - Software Design

Broader Questions



The role of academic institutions

 Institutional pressures in favor of accepting research funds from any source  A researcher judged on his ability to attract funds  DoD is a major administrator of research funds – consequently many institutions are working on SDIO CS575 - Software Design

Broader Questions



Should we pursue SDI for other reasons?

Parnas says  “Good research stands on its own merits; poor research must masquerade as something else”  “Over funded research is like heroin, it leads to addiction, weakens the mind, and leads to prostitution” – Prof. Janusz Makowski CS575 - Software Design

Parnas’ Advices

Determine participation in defense projects by:

  Prioritizing legitimate defense interests of the country  Considering effectiveness of project Emphasizing individual responsibility CS575 - Software Design

Our Opinion

Is SDI really impossible???

  As our technologies evolve the system becomes more realistic Present systems show some signs of success  Reliability/trustworthiness can be achieved through testing  Testing can be done via computer simulations (e.g. Nuclear Tests are no longer necessary)  Changes in hardware (Sensors, weapon delivery systems, etc.) can compensate for no advances in Software technology  Better algorithms should be developed to counter noise, detect decoys, etc.

 “SDI is the way to go” – Amit, Cincy, Rong CS575 - Software Design

Questions

CS575 - Software Design