Systems Engineering and Architecture Richard M. Murray Control and - - PowerPoint PPT Presentation

▶
systems engineering and architecture
SMART_READER_LITE
LIVE PREVIEW

Systems Engineering and Architecture Richard M. Murray Control and - - PowerPoint PPT Presentation

Feb 03, 2024 212 likes •412 views

Systems Engineering and Architecture Richard M. Murray Control and Dynamical Systems California Institute of Technology Design Principles in Biological Systems 21 April 2008 Product Systems Engineering Systems engineering methodology

slide-1
SLIDE 1

Systems Engineering and Architecture

Richard M. Murray Control and Dynamical Systems California Institute of Technology Design Principles in Biological Systems 21 April 2008

slide-2
SLIDE 2

Richard M. Murray, Caltech CDS Banbury, May 2007

Product Systems Engineering

Systems engineering methodology

  • requirements capture and analysis
  • systems architecture and design
  • functional analysis
  • interface design and specification
  • communications protocol design & specs
  • simulation and modeling
  • verification and validation
  • fault modeling

2

Boeing 737: first flight, April 1967 PDP-8: debuted 1965

slide-3
SLIDE 3

Richard M. Murray, Caltech CDS Banbury, May 2007

Systems of Systems Engineering

Little centralized control over the design

  • Individual systems build for specific purpose
  • No global requirements document + evolution

Example: air operations center (think ATC)

  • Multiple aircraft, designed over the last 50

years (with lots of variations in capabilities)

  • Ground control stations + imagery analysis

design to run independent of AOC

  • All running on COTS computers, networks

3

Layer 1 Layer 1 Layer 2 Layer 3 Layer 4

Inter-layer interfaces

slide-4
SLIDE 4

Richard M. Murray, Caltech CDS Banbury, May 2007

The Role of Architecture

How do we define architecture?

  • IEEE: “The fundamental organization of a system embodied in its components, their

relationships to each other, and to the environment, and the principles guiding its design and evolution.”

  • Doyle (following Gerhart and Kirschner): “The constraints that deconstrain”
  • Partha (following from building architecture): Integration of structure and function

Some useful concepts

  • Functional decomposition: how do we break down a

system into functionally independent modules

  • Interfaces and standards: how to we specify consistent

interfaces that let us integrate functional modules

  • Protocols: how do we build layered abstractions that

allow designers to ignore the details above and below

4

Protocols Interfaces

slide-5
SLIDE 5

Richard M. Murray, Caltech CDS Banbury, May 2007

Design Example: “Alice”

DARPA Grand Challenge

  • 150 miles of autonomous desert driving
  • Key challenge: uncertainty route/env
  • Diversity: 198 teams → 120 → 43 → 23

Alice

  • 50 Caltech undergraduates, 1 year
  • 5 cameras: 2 stereo pairs, roadfinding
  • 5 LADARs: long, med*2, short, bumper
  • 2 GPS units + 1 IMU (LN 200)

Computing

  • 6 Dell PowerEdge Servers (P4, 3GHz)
  • 1 IBM Quad Core AMD64 (fast!)
  • 1 Gb/s switched ethernet

Software

  • 15 programs with ~100 exec threads
  • 100,000+ lines of executable code

Short range stereo Long range stereo LADAR (4) Alice

5

slide-6
SLIDE 6

Richard M. Murray, Caltech CDS Banbury, May 2007

Evolution of Alice’s Architecture

Bob’s architecture: arbiter based

  • Key idea: independent sensors “vote” for

direction that vehicle should drive

  • Key feature: once interface protocol for a

“voter” is established, can work on many sensor processing approaches in parallel

  • Limitation: very limited ability to “reason”

about environment; no contingency plans

  • Complexity: 20k (est) lines of C++ code

Alice’s architecture: cost map + planning

  • Higher level reasoning about environment

based on cost map

  • Key features:
  • Fuse elevation maps to allow parallel

development of sensor pathways

  • Supervisor controller for contingencies
  • Limitation: much more complex software
  • Complexity: 100k lines of code; some reuse
  • Built on top of lots of existing code + COTS

6

Road Sensors Terrain Follower Path State Estimator Planner Path Supervisory Control Map Elevation Map Cost Vehicle Vehicle Actuation Finding

slide-7
SLIDE 7

Richard M. Murray, Caltech CDS Banbury, May 2007

2007 DARPA Grand Challenge (Urban Challenge)

Autonomous Urban Driving

  • 60 mile course, less than 6 hours
  • City streets, obeying traffic rules
  • Follow cars, maintain safe distance
  • Pull around stopped, moving vehicles
  • Stop and go through intersections
  • Navigate in parking lots (w/ other cars)
  • U turns, traffic merges, replanning
  • Prizes: $2M, $1M, $500K

!"#$%&'"()&"*$+%)&,-"." /012$3-%*"3-"%)&"40,53-6" 7$%"89$-&":;<"0,&" =)&>52$3-%*""""""""""""""""""""""""""

!" !#

!"#$%&'()* +$,-./0&1)(2 3,$44.5& 6.,578

" $ ! !! # % & ' ( !) * ! " * & % # $ ( !) !! !* !" ' !&

9$%*)./( 1$/8 :)/8 '()*&'.0/ '80;8/(&<&:)/8&=> 6?85-*)./(&=>

+,-./012345

! !

?:@A @

7

slide-8
SLIDE 8

Richard M. Murray, Caltech CDS Team Caltech, Apr 07

How did we come up with this?

  • Step 1: requirements analysis - what does Alice need to

be able to do? Based on specs given by DARPA

  • Step 2: functional decomposition - what are the basic

elements required to function? Designer choice

  • Step 3: scenario generation and iteration - can it do what

we want? Some simulation; mainly paper-based

  • Step 4: interface specs (50% inherited ⇒ software reuse)

DGC07 System Architecture (Gen 3)

8

Feature Classificat’n Elevation Mapping Obstacle Detect/Track LADAR (6) Stereo/Road Finding Gimbaled Sensor World Map Obstacle Map Vehicles Path Planner Path Follower Actuation Interface Traffic Planner Mission Planner Vehicle State Estimator Vehicle

Sensing Navigation Systems

Process Manager Health Manager Logging/ Visualization Simulation

Properties

  • Highly modular
  • Rapidly adaptable
  • Constantly viable
  • Robust ???

Linux, TCP/IP, ...

slide-9
SLIDE 9

Richard M. Murray, Caltech CDS DGC Contract Kickoff, 6 Oct 06

Architecture, July 2007

9

Computing - 24 cores

  • 10 Core 2 Duo processors (cPCI)
  • 1 IBM Quad Core AMD64
  • 2 Intel P4 (legacy)

Sensing

  • 8 LADAR, 8 cameras, 2 RADAR
  • 2 pan/tilt units (roof + bumper)
  • Applanix INS (dGPS, IMU, DMI)
slide-10
SLIDE 10

Richard M. Murray, Caltech CDS Team Caltech, Apr 07

Sensing Bowtie

MapElement serves as constraint that deconstrains

  • Fix the structure of the elements in the world map
  • Left end: sensors → perceptors → MapElements
  • Right end: MapElements → environment descriptions → planners

Engineering principle: allow parallel development (people and time) + flexibility

  • Fixing the map element structure allows 15 people to work simultaneously
  • We can evolve/adapt our design over time, as we get closer to the race

10

Feature Classificat’n Elevation Mapping Obstacle Detect/Track LADAR (6) Stereo/Road Finding Gimbaled Sensor World Map Obstacle Map Vehicles

MapElement

slide-11
SLIDE 11

Richard M. Murray, Caltech CDS Team Caltech, Jan 08

Feeder → Perceptors → Mapper

11

slide-12
SLIDE 12

Richard M. Murray, Caltech CDS Team Caltech, Apr 07

Protocol stack based architecture

  • Planners uses directives/responses to communicate
  • Each layer is isolated from the ones above and below
  • Have 4 different path planners under development, two

different traffic planners. Rewriting the controllers as we speak (literally) Engineering principle: protocols isolate interactions

  • Define each layer to have a specific purpose; don’t rely
  • n knowledge of lower level details
  • Important to pass information back and forth through

the layers; a fairly in an actuator just generate a change in the path (and perhaps the mission)

  • Higher layers (not shown) monitor health and can

act as “hormones” (affecting multiple subsystems)

Planning Hourglass

12

Path Planner Path Follower Actuation Interface Traffic Planner Mission Planner Vehicle

slide-13
SLIDE 13

Richard M. Murray, Caltech CDS NCS, 30 Nov 07

Canonical Software Architecture

Directive/response framework

  • Each component communicates with its neighbors through directives and status
  • Separate taking directives from other components (in their terms) from a given

component's core function and directives (in its own terms)

  • Build on JPL “State Analysis”

(Rasmussen et al) Modularity

  • Interfaces are defined indepen-

dently from the module structure, such that when one module gets rebuilt,the modules that it talks to can remain the same

  • Each component is divided into

three parts

  • Arbitration: accept/reject
  • Control: execute
  • Tactics: success/fail

13

slide-14
SLIDE 14

Richard M. Murray, Caltech CDS Team Caltech, Jan 08

Testing at El Toro

Approximate 300 miles of testing over 2 months

  • Longest run without intervention: 11 miles
  • Top average speed: ~10 mph

14

slide-15
SLIDE 15

Richard M. Murray, Caltech CDS Team Caltech, Jan 08

2007 National Qualifying Event

15

Merging test

  • 10-12 cars circling past inters’n
  • Count “perfect runs” in 30 min

Results

  • First run: tight corners caused Alice

to stop in intersection

  • Second run: bugs introduced while

trying to improve performance; caused multiple “aggressive” events

slide-16
SLIDE 16

Richard M. Murray, Caltech CDS Team Caltech, Jan 08

2007 National Qualifying Event

Results

  • First run - safety buffers

too large => slow progress

  • Second run - completed

course in 22 minutes; minor errors

  • 1 of ~8 vehicles completed

16

Driving test

  • 2 mile run - roads, parking

lots, obstacles on road

slide-17
SLIDE 17

Richard M. Murray, Caltech CDS Alice, November 2007

Richard’s Observations (JPL, Feb 08)

Things that worked

  • Basic architecture was sound; capable of completing the race
  • Sensing subsystem performed well (some spurious/misclassified obstacles)
  • Rail planner was very versatile: could handle on-road/off-road, forward-reverse, etc
  • Canonical software architecture worked better than previous supervisory control
  • Alice was good at not getting stuck and not running into things

Things that didn’t work

  • Original planning approach (OTG) was too slow; late switch to rail planner
  • Canonical software architecture implementation slowed us down
  • Traffic logic was complex; difficult to debug and modify; didn’t get stressed until late in

the cycle

  • Planned project schedule was too aggressive (but probably required to qualify)

17

slide-18
SLIDE 18

Richard M. Murray, Caltech CDS Caltech, September 2007 18

Credits (2007)

Technical Contributers (79): Daniel Alvarez, Mohamed Aly, Jessica Austin, Brandt Belson, Philipp Boettcher, Julia Braman, Joel Burdick, William David Carrillo, Vanessa Carson, Arthur Chang, Edward Chen, Steve Chien, Jay Conrod, Iain Cranston, Lars Cremean, Josh Doubleday, Tom Duong, Stefano di Cairano, Noel duToit, Luke Durrant, Josh Feingold, Matthew Feldman, Tony and Sandie Fender, Nicholas Fette, Ken Fisher, Melvin Flores, Brent Goldman, Scott Goodfriend, Sven Gowal, Steven Gray, Rob Grogan, Jerry He, Phillip Ho, Andrew Howard , Mitch Ingham, Nikhil Jain, Michael Kaye, Aditya Khosla, Ryan Lim, Magnus Linderoth, Laura Lindzey, Christian Looman, Ghyrn Loveness, Jeremy Ma, Justin McAllister, Joe McDonnell, Richard Murray, Russell Newman, Noele Norris, Josh Oreman, Kenny Oslund, Robbie Paolini, Jimmy Paulos, Celia Peina, Humberto Pereira, Rich Petras, Sam Pfister, Christopher Rasmussen, Bob Rasumussen, Dominic Rizzo, Miles Robinson, Henrik Sandberg, Chris Schantz, Kristian Soltesz, Chess Stetson, Sashko Stubailo, Tamas Szalay, Klimka Szwaykowska, Daniel Talancon, Daniele Tamino, Pete Trautman, David Trotz, Glenn Wagner, Yi Wang, David Waylonis, Nok Wongpiromsarn, Albert Wu, Francisco Zabala, Johnny Zhang Major Sponsors: DARPA, Caltech, IST, Big Dog Ventures, Mohr-Davidow