Top Banner
Robust Self-configuring Embedded Systems http://www.ece.cmu.edu/roses Prof. Philip Koopman Bill Nace – Charles Shelton – Meredith Beveridge – Tridib Chakravarty – Chris Martin – Mike Bigrigg Institute for Complex Engineered Systems & Electrical Computer ENGINEERING RoSES
13

RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

Aug 25, 2020

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

Robust Self-configuringEmbedded Systemshttp://www.ece.cmu.edu/roses

Prof. Philip KoopmanBill Nace – Charles Shelton – Meredith Beveridge –

Tridib Chakravarty – Chris Martin – Mike Bigrigg

Institutefor ComplexEngineeredSystems

&Electrical ComputerENGINEERING

RoSES

Page 2: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

2

RoSES Objectivesu Context: distributed embedded systems

• Multiple “smart” sensors/actuators connected to embeddedreal-time network

u Research goal – automatic reconfiguration for:• Graceful degradation

• Graceful reintegration after repair

• Graceful acceptance of non-exact spares

• Graceful upgrade with new capabilities

S A

CPUS A

CPUS A

CPU

S ACPU

S ACPU

EmbeddedNetwork

Page 3: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

3

Product Family Architecturesu Fine grain distributed systems yield dense product lattices

# ComponentsInstalled

N

N+1

N+2

N+2

N-1

Product Family

StandardProduct A

StandardProduct D

StandardProduct B

StandardProduct C

= Product Variant= Add or Remove a Component

Page 4: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

4

Why Self-Configuration?__________________u Product Families + Automatic configuration

management creates a unifying capability• Product families can include degradation as well as intentional

price/performance tradeoff points

u Consider component failure as an example:• Component fails –

triggers reconfiguration for degraded operation• Component replaced –

reconfiguration to integrate repair part• New component added –

reconfiguration to upgrade system

u That’s a lot to attempt all at once…• Static configuration at first• On-the-fly configuration as an eventual goal

Page 5: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

5

A Simplistic Example…u Control of gasoline engine speed

• Complicated system controls fuel if valve is installed/operational

• But, baseline capability is retained in case of failure

Throttled Engine Controller

NETWORK

FUELVALVE

SPEEDCONTROLLER

SPEEDSENSOR

PID CONTROLALGORITHM

IGNITIONCONTROL

Hit-or-Miss Constant Speed Engine Controller

NETWORK

IGNITIONCONTROL

SPEEDSENSOR

BANG-BANGCONTROL

ALGORITHMDegrades to

Page 6: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

6

Different Sensors / Different Capabilitiesu Similarly, different actuators have different capabilities

• Mobile Object Adapters translate raw capability into desiredinterface

RELATIVESPEED

SENSOR

LOCALCOMPUTATION,ALGORITHMS,

DATA STORAGE

EXAMPLE SIMPLE SPEED SENSOR

RELATIVESPEED

INTERFACE(TOO FAST/TOO SLOW)

Mobile Object Adapter

Embedded Network

PROPORTIONALSPEED

SENSOR

EXAMPLE HIGH-END SPEED SENSOR withMULTIPLE INTERFACES

RPMINTERFACE

OVERSPEEDEMERGENCYINTERFACE

PERCENTMAXIMUM

INTERFACE

RELATIVESPEED

INTERFACE(TOO FAST/TOO SLOW)

LOCALCOMPUTATION,ALGORITHMS,

DATA STORAGE

Mobile Object Adapters

Embedded Network

Page 7: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

7

Generic RoSES System Architecture

Object Bus (Run-Time Infrastructure & Network)

BaselineSensor SWFunctionality

Dynamic Interfaceto Object Bus

SWAdapter forHigh Level

LogicalInterface

SWAdapter forHigh Level

LogicalInterface

BasicSensorDevice

SMART SENSORS

BaselineActuator SWFunctionality

Dynamic Interfaceto Object Bus

SWAdapter forHigh Level

LogicalInterface

Adapter Repository Co-Scheduling & Assigment Tool

SWAdapter forHigh Level

LogicalInterface

BasicActuatorDevice

SMART ACTUATORS

CUSTOMIZATION MANAGER

Page 8: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

8

Near-Term Research Challengesu Mapping functionality onto hardware

• Maximize utility of result given constrained resources

u Achieving real-time operation• Co-schedule CPU, Memory, Network usage to meet real-time

deadlines

u Achieving “plug & play” capabilities• e.g., What would it take to put CORBA on a CAN network?

• Avoid re-inventing CORBA if possible…

u Tractable demonstration• Generic automotive testbed

Page 9: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

9

Functionality To Hardware Mappingu Automatic allocation of HW & SW components

• Maximize utility of functions within hardware constraints

FUNCTIONALREQUIREMENTS

CPUs MEMORY NETWORK

SENSORS ACTUATORS

CONTROLALGORITHMS

&SOFTWARE

DynamicAdaptionRuntimeSystem

Page 10: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

10

Proposed Testbedu Navigation + active vehicle stability control

• Inertial sensors / dead reckoning subsystem– 3d inertial platform with acceleration and speed readouts

– Steering angle

– Wheel speed

• GPS-basednavigationsubsystem

– External source ofposition and speed

• Data collection subsystem– Stores and forwards data for failure diagnosis

• Gateway to wireless internet connection– Simulated using Wireless Andrew

• CANalyzer system to simulate rest of vehicle network– Provides messages for realistic operating environment

InertialNavigation

CAN Embedded Network

GPSNavigation

DataCollection

VehicleStabilityControl

PrecisionNavigationSynthesis

WirelessAndrew

CANalyzerTest Tool

Page 11: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

11

Experimentsu Applications

• Phase 1: Precision navigation– Gracefully degrading navigation based on sensor information– Combine inertial & GPS for result better than either alone

• Phase 2: Active vehicle stability control– Vehicle stability algorithms vary degree of control based on quality of sensor

information– Graceful degradation rather than brute force redundancy

u Year 1 goal – lab demo:• Demonstrate automatic reconfiguration when sensors/actuators/

computers fail for navigation application

u Later goals:• Demonstrate automatic reconfiguration in a test vehicle• Demonstrate upgrade of baseline component with

advanced/proprietary component• Demonstrate graceful failure and restoration after

repair in a test vehicle

Page 12: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

12

Possible Extensionsu Embedded system point of view

for system security• Vehicle / external firewall

• Protection against malicious or faultycomponents on networks

u Safe upgrade strategies• Even if new components have

software defects (?!)

Page 13: RoSES - Carnegie Mellon Universitykoopman/roses/roses_slides.pdf · 2007. 8. 28. · 2 RoSES Objectives u Context: distributed embedded systems • Multiple “smart” sensors/actuators

13

Peopleu Prof. Phil Koopman

• 10+ years industry experience embedded hardware & software

u Bill Nace• Ph.D. student: functionality-to-resource mapping

u Charles Shelton• Ph.D. student: software architecture

u Meredith Beveridge• M.S. student: testbed/baseline applications + Jini-on-CAN

u Chris Martin• M.S. student: simulation infrastructure (details TBD)

u Tridib Chakravarty• M.S. student: embedded protocol infrastructure

u Mike Bigrigg – staff member R o S E S