An Architectural Style Perspective on Dynamic Robotic Architectures - - PowerPoint PPT Presentation

an architectural style perspective on dynamic robotic
SMART_READER_LITE
LIVE PREVIEW

An Architectural Style Perspective on Dynamic Robotic Architectures - - PowerPoint PPT Presentation

An Architectural Style Perspective on Dynamic Robotic Architectures John Georgas Institute for Software Research University of California, Irvine SDIR07 4/14/07 Outline Motivation A Look at the Past RAS Architectural Style


slide-1
SLIDE 1

An Architectural Style Perspective on Dynamic Robotic Architectures

John Georgas

Institute for Software Research University of California, Irvine

SDIR’07 – 4/14/07

slide-2
SLIDE 2

Outline

Motivation A Look at the Past RAS Architectural Style Conclusions and Future Work

slide-3
SLIDE 3

Motivation

Self

  • Adaptive Software

Architecture-based

Explicit architectural model consistent with implementation

Dynamic Architectures

Runtime modification based on model changes

Model changes transitioned to implementation

Policy-based adaptation

Defining the when and how of adaptation Independent of and decoupled from the functionality

Malleable and non-concrete for adaptability

Software Architecture Styles

Styles promote qualities (modularity, evolvability, reuse)

slide-4
SLIDE 4

Motivation (2)

Robot control systems as an application domain

Need for dynamic change Naturally appropriate to self

  • a

daptive systems

Questions:

Do robotic architectures lend themselves toward

architecture-based techniques?

What can be learned from the successes and failures

  • f these architectures?
slide-5
SLIDE 5

Quick Look at Success and Failure

A look into robotic architectures

…where the architecture was at the forefront …with secondary research literature

…which captured “do’s” and “don’t’s”

Three architectures

Subsumption Three-Layer Reactive Concentric

slide-6
SLIDE 6

Subsumption

The good…

Built using independent, asynchronously

communicating modules

Behavior determined by topology

The bad…

Override mode of communication Disconnect between conceptual architecture

layers and actual implementation

slide-7
SLIDE 7

Three-Layer (3L)

The good...

Layers practically realized Communication through input not override

Enables more complex modes of component

interactions The bad…

Much of the behavior determined by special-

purpose scripts

Architecturally invisible and inaccessible

slide-8
SLIDE 8

Reactive Concentric (RC)

The good…

Component- and event-based system

construction

Input-based communication rather than

  • verride

The bad…

Conceptual layering lost in the implementation Architecturally invisible special-purpose

scripts

slide-9
SLIDE 9

Combining Insights

Lessons learned from robotic architectures

From both the successes and failures

Experience with software architectures

and styles (REST, C2)

Layered and event-based systems

Challenge: Integrate lessons learned with

domain-specific insights into a generic architectural style for robotic systems.

slide-10
SLIDE 10

RAS Architectural Style

In the abstract…

Deliberative Layer Reactive Layer Skill Layer Sequencing Layer

Deliberative Connector Sequencing Connector Reactive Connector

Action Requests Requests Robot Notifications Notifications

slide-11
SLIDE 11

Deliberative Layer Reactive Layer Skill Layer Sequencing Layer

Deliberative Connector Sequencing Connector Reactive Connector

Action Requests Requests Robot Notifications Notifications

Style Characteristics

  • Component-Based

Each layer composed of independent components Each component captures a specific behavior No special-purpose scripts; topology determines behavior

  • Explicitly Layered

Focused functionality layers, explicitly consistent with implementation Layering differentiated on functionality, timeliness, state, and interaction modes

  • Explicit Connectors

Independent connecting elements solely responsible for communication

  • Event-based Communication

Components communicate through event emission and receipt, with no service

assumptions

Typed events with transactional support

  • Directional Event Flow

Message type determines allowable communication and limits event scope Promotes layering conventions

  • Dynamic Architecture

Features specifically designed to support dynamism Supported by infrastructure enabling architecture-based runtime adaptation

slide-12
SLIDE 12

Consequences

Style characteristics support qualities “by design”

Modularity and strong decoupling

Component- and event-based

Incrementality and reuse

Even at the level of layers

High visibility and service access points

Connector-centric compositions

Features intended to support runtime dynamism

Supported through infrastructure

The price you pay…

Potential message loss and non-guaranteed services

In the nature of event-based systems

Potential scalability concerns

Mitigating factors: directional conventions, limited event scope

slide-13
SLIDE 13

ArchWall Robocode Example

slide-14
SLIDE 14

ArchWall Robocode Example

slide-15
SLIDE 15

ArchWall Robocode Example

slide-16
SLIDE 16

Early Experience

Use of the RAS style:

…enabled runtime evolution and adaptation …resulted in a modular and decoupled system

High level of reuse between configurations Behavioral changes focused on specific components and

their place in the architecture

…promoted a high level of architectural visibility

Changes centered and easily visible in the topology

slide-17
SLIDE 17

Conclusions and the Future

Current robotic architectures do not support architecture

  • based runtime adaptation well

An architectural approach supported by an appropriate

style can:

…enable dynamic adaptation while promoting

Modularity, incrementality, reuse, visibility

…address architectural drawbacks of current robotic

architectures with regards to adaptation

Continued development and refinement of RAS

  • style

architectures

More rigorous evaluation and performance metric gathering of

style’s overhead

Application to larger robotic system examples

slide-18
SLIDE 18

Extra Slides

slide-19
SLIDE 19

Definitions

Software Architecture

An explicit and deployable model of the system expressed in

terms of its constituent executable units and their interconnections, which remains consistent through the system’s lifetime.

Self

  • Adaptive Software

Self-adaptive software monitors, evaluates, and modifies its own

behavior according to a collection of adaptation policies.

Adaptation Policies

Adaptation policies establish specifics of system modifications

required in response to a set of conditions which indicate the need for change

slide-20
SLIDE 20

Policy-Based Adaptation