A New Kind of Language for Complex Engineering Systems€¦ · Engineering Systems: Case Study:...

E. Crawley and B. Koo © MIT1 2004-4-23

A New Kind of Language for ComplexEngineering Systems:

Case Study: NASA’s Apollo Program

Benjamin KooEdward F. Crawley

Engineering Systems DivisionDepartment of Aeronautical and Astronautical Engineering

NKS 2004


Architecting in Engineering Systems

• One Grand Challenge in Engineering Systems:– Assessing Very Large Scale engineering decisions early enough with

meaningful model resolutions and abstraction levels

– Architects face numerous options based on possible combinations andpermutations with insufficient computational power

• Need to integrate multiple domains of knowledge at meaningful levels ofabstraction and resolution– By applying the Principle of Computational Equivalence to translate between

domain models

– Using a generalized version of Wolfram Automata: Object-Process Network(OPN)

• Applying NKS to NASA’s Apollo Mission:– Wolfram’s automata (a simple language) can be mapped onto multiple

abstraction levels based on the Principle of ComputationalEquivalence

– NASA’s Apollo mission is revisited to to show that NKS can helpassess critical decisions at multiple technical levels


Architecting as Language Manipulation

• The Principle of Computational Equivalence states thatall physical processes can be mapped onto equivalent“languages”– Computer scientists often define various kinds of “machines” as

“languages” or “automata”

• All domain-specific models must be built on a commonset of linguistic primitives in order to ensure consistency– Choice of vocabulary embodied in OBJECTS with their

respective range of admissible states define the variability in asystem

– Grammatical rules are PROCESSES that capture therelationships between objects (as conditional probabilityfunctions) can reduce system complexity

– Vocabulary arranged by Grammatical Rules creates aNETWORK


Language: the medium of interactions

• Interactions between subsystems requires translationbetween domain-specific languages

• System architects must share a global language ortranslate between local/domain-specific languages

• All domain-specific models must be built on a commonset of linguistic primitives in order to ensureconsistency and composability

Operational System

Bi-directional Influencing

Development System

OperationalAssessing Development

Assessing

Program-LevelSystem

Language(s) of Technologists

Language(s) of Operators

Language(s) of Decision Makers


Languages based on “SimplePrograms”

• Wolfram Automata– A series of interactive machines that follow one rule

to perform Turing computable tasks

• Languages based on a “simple kernel”– Mathematica

• Multi-Paradigm Programming Language

• Meta-Language that subsumes multipleprogramming paradigms

– Modelica

• A visual object-oriented language for physicalsystems based on Mathematica’s runtime engine


Variability in Cell-State Permutation

• Order sensitive: color permutation at initial row

• The vertical dimension is time

• A common vocabulary and one rule family

Discrete Space

Time

p(t=0) q(t=0) r(t=0)

Wolfram Rule

q(t=1)

€

rule30 : p⊗ (q∨ r)rule90 : p⊗ rrule110 : ((¬p)∧q∧ r)⊗ q⊗ r

Wolfram rules are highly composable

<cells, neighboring relations, initial condition, rule number>

• Cellular Automata is a visual programming language


Simple Programs in ConditionalProbability Tables

• Wolfram Rules can also be encoded in Conditional Probability Tables

Where:N: rule number (0..255)p: left cellq: middle cellr: right cell

€

N ∈ {0,1,2...}c = p × 4 + q × 2 + r

Pr(black,N) =mod(N −mod(N,2C )2C

,2)

One generalized function for all 256rules… (one alternative to NKSp.648)

€

Pr(black | p,q,r,N = 30) =0,{pqr}∈1,{pqr}∈

Pr(white) =1−Pr(black){ , , , }

{ , , , }


Variability in Cell-State Combination

• When time is ignored, acombinatorial problem can beformulated as a graph ofconditional probability tables, a.k.a.Bayesian Belief Networks(BBNs)

• BBNs can be thought of asprobabilistic automata

• Exact BBN solution is known to beNP-hard, not suitable for largegraphs or dynamic problems


OPN is a Simple Meta-language

• OPN allows non-technical users to construct domain-specific languages– Domain-specific Vocabulary (Objects)

• Local knowledge confines the space of combinatorialpossibility by carefully choosing the inclusion of variables andtheir admissible value ranges

– Domain-specific Grammar (Processes)

• Local knowledge eliminates unnecessary permutation andcombinatorial possibilities

– Domain-specific language (Network)

• Humans and machines can incrementally edit the networkstructure or the conditional probability table based on localcontext and runtime experience

v1Object

v2

Process

yesObject1

no Process trueObject2

false


Cellular Automata in Object-ProcessNetwork

• Object-Process Network (OPN) is an extension fromDori’s (2002) Object-Process Methodology (OPM)– A general purpose system description language (UML replacer)

• Cells as Objects– Each object can have two or more states

• Rules as Functions (Processes)– Each rule is specified by a unique instance of Conditional

Probability Table/Function


OPN subsumes 4 languages

Concepts

Languages

Operand

Operator

RuntimeEngine

ApplicationDomains

Temporal Scale

SemanticMetaphors

Relationship

System Dynamics

ColouredPetri-Net

ProbabilisticNetwork

CellularAutomata

Object-ProcessNetwork

v1Object

v2

Process

System Description/Simulation

Natural SciencePattern Generation

Rule number,Cell Layout

State

Conditional Probability Tables

Reasoning aboutState-SpaceCombination

€

pTransition

Place

Place + Coloured tokens

P1 T1 P2

Pre-condition

Post-condition

Discrete EventModeling

Stock

flow

Embedded in arrows

Physical System Modeling/Decision Support

SynchronousRule Firing

NumericalIntegrationEngine

EventSchedulingEngine

BeliefPropagationAlgorithms

S-ExpressionInterpreter

Synchronized Time Steps

InfinitesimalTime Steps

Approximation ofmultiple scales

AsynchronousTime Steps

Time-independentMemory-less

Interactive Systems

Dynamics ofAnalog Signals

SymbolicKnowledge

Dynamics ofMessages

CausalStructures

Direction of Dependency


Can one language help reason-through abinary decision in the Apollo Program?

• A highly public architectural decision– Tremendous impact on downstream developmental activities

• How did the decision makers reason through thedecision with incrementally available knowledge?

Earth Orbit Rendezvous (EOR) Lunar Orbit Rendezvous (LOR)

docking

launching

or ?


Apollo Funding Breakdown

0

500,000

1,000,000

1,500,000

2,000,000

2,500,000

3,000,000

3,500,000

1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973

Year

tho

usa

nd

s o

f d

ollars

Impact of LOR Architectural Decision

LOR decision reached: June 7th, 1962 $160M, 0.82% of total budget $19.4B


Science in the LOR vs. EOR Decision:Sequence and Combination Matters

• How to enumerate all possible itineraries?– Space of trajectories must include sequence info.

• How to assess variable interactions over multipleknowledge domains?– Space of technical options includes a large

combination of possibilities

• How to inform stakeholders about decisions withcomprehensive contextual data?– The interactions between the two kinds of

computational complexity, sequence andcombination, must be coherently organized in aunified representational scheme, namely a language


Manual representation andenumeration of trajectory options?

Planetary Arrival - 2 Craft - Joined Initially, JoinedFinally

Super-orbital Orbital Entry De-orbit Direct Descent

Planetary Arrival - 1 craft

• Consider the trip as four planetary encounters (Earth depart, moon arrive, etc)• Each encounter has numerous permutations of objects and processes

Super-orbital

Orbital Entry

Orbit to Landing

Direct Descent

Super-orbital Orbital Entry Orbit to Landing Direct Descent

Super-orbital

Orbital Entry

Orbit to Landing

Direct Descent

Planetary Arrival - 2 Craft - Joined Initially, SeparatedFinally

Super-orbital Orbital Entry Orbit to Landing Direct Descent


How to represent and enumeratetrajectory options systematically?

• Use a finite state automaton to generate all possiblemission architectures– Repeatable Motion Primitives (“Trim” conditions)

• Constant in control setting, configuration– Finite-Time Motion Primitives (“Maneuvers”)

• Finite time transition between two Repeatable Motions

Orbit Attaining

Transiting

Orbit Entering

Orbit Departing

“TrimTrajectory”

Surface

Orbit

Frazzoli 2001

De-OrbitingDirect Ascent

Direct Decent

Orbiting

A “language” for describing all possible single craft itineraries


Generator of Mission ArchitecturesManeuvering “Trim” conditionssteady state steady state“Trim” conditions


Demo


Summary

• Large Scale Engineering Decisions need a New Kind ofLanguage– As systems become more complex, a simpler yet unifying

language is needed to deal with the two essential sources ofcomputational complexity (permutation and combination)

– Existing computable languages can be simplified or emulatedusing a unifying meta-language, Object-Process Network

• Object-Process Network is a user-friendly meta-language that allows a wide range of users to createintuitive, domain-specific, yet efficient languages– Languages derived from OPN can be composed into a unified

computational model to assess the interactive effects ofsubsystems across many levels of abstraction and modelresolutions


Acknowledgements

• Dr. Robert Seamans for his generous time and oral history that shedlight on Apollo’s landmark decisions

• Dr. Raymond Leopold for his insights into the design of IridiumSatellite systems and how simple rule tables can be used toconstruct very complex interactive systems

• Mr. Russ Wertenberg from NASA for his insights into the socio-techno dynamics in Space Programs

• Thanks to Christopher Fry at http://www.clearmethods.com for hisimplementation of the OPN runtime engine using the WaterProgramming Language

• Mr. Qiu Yilin for his original concepts in evolvable software systems

• Prof. Paul Carlile for his contribution in using boundary objects as acommon currency for socio-technical system interactions

• Dr. Geilson Loureiro, Karen Marais, A-P Hurd for their respectiveintellectual contribution and technical reviews of this presentation.

A New Kind of Language for Complex Engineering Systems€¦ · Engineering Systems: Case Study:...

Documents

Transcript of A New Kind of Language for Complex Engineering Systems€¦ · Engineering Systems: Case Study:...