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 SDIR’07 – 4/14/07

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

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)

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 of these architectures?

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

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

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

Reactive Concentric (RC) � The good… � Component- and event-based system construction � Input-based communication rather than override � The bad… � Conceptual layering lost in the implementation � Architecturally invisible special-purpose scripts

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.

RAS Architectural Style � In the abstract… Action Requests Deliberative Layer Requests Deliberative Connector Sequencing Layer Sequencing Connector Reactive Layer Notifications Robot Notifications Reactive Connector Skill Layer

Action Requests Deliberative Layer Requests Deliberative Connector Style Characteristics Sequencing Layer Sequencing Connector Reactive Layer Notifications Reactive Connector Robot Notifications Skill Layer 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

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

ArchWall Robocode Example

ArchWall Robocode Example

ArchWall Robocode Example

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

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

Extra Slides

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

Policy-Based Adaptation