Resolving QoS Policy Configuration Challenges for Publish/Subscribe Middleware Platforms AFRL JBI PI Meeting

Outline Motivating Example QoS Policy Configuration Challenges Evaluating Common Solutions DQML Overview

Motivating Example – Unmanned Aerial Vehicle (UAV) UAV Desirable Data Flows –Storage and dissemination of data for late arriving subscribers (e.g., other aircraft and satellites coming into range) –Reliable communication of critical data (e.g., sensor data to satellite to ground station) –Prioritization of data delivery for mission-critical or high value data (e.g., time-sensitive targets) –Ordered and/or grouped data dissemination to ensure ordering and appropriate level of granularity

QoS Policy Configuration Challenges (1 of 3) QoS Policy Compatibility –QoS policies for the communicating entities must be compatible between what’s requested and offered Best effort data transfer offered Reliable data transfer requested X Data will not be transferred –For example, if subscriber requests reliable data transfer the publisher can not offer best effort data transfer

QoS Policy Configuration Challenges (2 of 3) QoS Policy Consistency –QoS policies for any one entity must be consistent with each other Deadline’s period = 5 ms. Time based filter’s minimum separation = 10 ms. X QoS policies will not be set –For example, deadline period must be >= minimum separation for time based filter

QoS Policy Configuration Challenges (3 of 3) Accurate QoS Policy Configuration Transformation –Propagating QoS policy configuration through development stages –For example, transforming design of QoS configuration into application code

Evaluating Common Solutions Three Common Solutions to Challenges –Point-based solutions –Patterns-based solutions –Domain specific modeling language (DSML) based solutions Categorized by –Robust vs. non-robust solution documentation –Robust vs. non-robust solution implementation

Point-based Solutions Focused on particular solution/application –QoS policy configuration is developed Configuration is designed Cons –Non-robust solution documentation –Non-robust solution implementation –Application is compiled & run –Feedback is gathered & evaluated –Process is repeated as necessary Design Code TestEvaluate Pros –Low overhead Configuration is implemented

Patterns-based Solutions Enables codification of configuration expertise Cons –No help with solution implementation (i.e., non-robust) Pros –Reuse of expert configuration design knowledge (i.e., robust design) Continuous Data Pattern Application A Application BApplication C Documented use of QoS policies for –Dataflow management –Dataflow prioritization –Dataflow shaping

DSML-based Solutions Uses domain specific terminology and constructs Cons –Learning curve/training overhead Pros –Robust solution documentation (via metamodel constraints) –Robust solution implementation (via interpreters) Application A Application B Application C Metamodel QoS Config Application model QoS Config Metamodel created in metamodeling tool QoS Config

DDS QoS Modeling Language (DQML 1 of 2) Models relevant DDS entities Models DDS QoS polices Models relationships between entities and QoS policies

DDS QoS Modeling Language (DQML 2 of 2) Supports QoS compatibility and consistency constraint checking Generates implementation artifacts (currently for DDS Benchmarking Environment (DBE)) DBE Interpreter DBE QoS SettingsDataReaderQoS Settings DataWriter