April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
Enabling Trustworthy Systems with the DDS Quality of Service
Modeling Language
Joe Hoffert, Aniruddha Gokhale, Doug Schmidt{joseph.w.hoffert,a.gokhale,d.schmidt}@vanderbilt.edu
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
Outline• Trustworthy Systems via Model Driven
Engineering (MDE)• Use Case: Data Distribution Service (DDS)• DDS QoS Modeling Language (DQML)• DQML Metamodel Overview• DQML Application: DDS Benchmark
Environment (DBE)• DBE Interpreter• DQML Demonstration• Future Work
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
Trustworthy Systems (1/2)
• Security Technology– Software Security
• Software design– specification languages, methods, and tools
supporting security by design• Static code verification via:
– security-friendly APIs– disciplined styles of programming– automated tools for lightweight static checking
– Trusted Platforms• Understanding composition• Evaluating security and vulnerability• Examining minimal configurations
(hardware & software) that provide trusted platforms
• Systems Science– Model-Based Integration of Secure Systems
• model-based design• model transformation technology • Quality of Service (QoS)-enabled component
middleware
TRUST Goals for Enterprise Publish/Subscribe DRE Systems
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
• Manage inherent complexity– Scope models to area/level of concern– Compose larger scope using modeling
artifacts (e.g., application infrastructure/framework, higher level tools)
– Understand composition via separation of concerns
– Simplify vulnerability, provability analysis
Trustworthy Systems (2/2)
• Reduce accidental complexity– Increase confidence, reuse via MDE
tools– Close security loopholes via misused
tools, software, and configurations
Facilitation of TRUST Goals via Model Driven Engineering (MDE)
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
• Coupling of business logic, infrastructure, QoS configuration (i.e., all crafted in handwritten code)
• Intermixing of concerns/areas of focus• Lack of composition understanding• “Provability” via testing• Potential loopholes in untested code paths• Unintended functionality (i.e., design !=
implementation)
Non-Trustworthy Systems
Vulnerability, Lack of Confidence/Provability
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
Use Case: The OMG Data Distribution Service (DDS)
Application
Application
Application
Application
ApplicationLogical Data Store
read
read
read
write
write
write write
Provides flexibility, power and modular structure by decoupling:
• Location – anonymous pub/sub
• Redundancy – any number of readers & writers
• Time – asynchronous, time-independent data distribution
• Platform – same as CORBA middleware
Architecturally Broken into:• Data Centric Publish/Subscribe (DCPS)
- Lower layer APIs to exchange topic data based on QoS policies
• Data Local Reconstruction Layer (DLRL)- Upper layer APIs that make topic data appear
local
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
QoS Policies Supported by DDS• DCPS entities (e.g., topics, data readers/writers) configurable via QoS policies
• QoS tailored to data distribution in tactical information systems
• Request/offered compatibility checked by DDS at Runtime
• Consistency checked by DDS at Runtime
– DEADLINE
• Establishes contract regarding rate at which periodic data is refreshed
– LATENCY_BUDGET
• Establishes guidelines for acceptable end-to-end delays
– TIME_BASED_FILTER
• Mediates exchanges between slow consumers & fast producers
– RESOURCE_LIMITS
• Controls resources utilized by service
– RELIABILITY (BEST_EFFORT, RELIABLE)
• Enables use of real-time transports for data
– HISTORY (KEEP_LAST, KEEP_ALL)
• Controls which (of multiple) data values are delivered
– DURABILITY (VOLATILE, TRANSIENT, PERSISTENT)
• Determines if data outlives time when they are written
– … and 15 more …
• Implications for Trustworthiness
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DDS QoS PoliciesInteractions of QoS Policies have implications for:
• Consistency/Validitye.g., Deadline period < TimeBasedFilter minimum separation (for a DataReader)
• Compatibility/Connectivitye.g., best-effort communication offered (by DataWriter), reliable communication requested (by DataReader)
DataWriter
Durability-Volatile
Durability-Transient
Reliability- Best EffortReliability-
Reliable
Deadline-10ms
Deadline-20ms
Liveliness-Manual By Topic
Liveliness-Automatic
Topic
Will Settings Be Consistent?Or Will QoS Settings Need Updating?
Timebased-15ms
DataWriter
DataReader
Will Data Flow?Or Will QoS Settings Need Updating?
DataReader
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DDS Trustworthiness Needs (1/2)• Compatibility and Consistency of QoS Settings
– Data needs to flow as intended• Close software loopholes that might be maliciously exploited
– Fixing at code time untenable• Implies long turn-around times• Code, compile, run, check status, iterate• Introduces accidental complexity
• DDS QoS Modeling Language (DQML) models QoS configurations and allows checking at design/modeling time– Supports quick and easy fixes by “sharing” QoS policies– Supports correct-by-construction configurations
– Fixing at run-time untenable• Updating QoS settings on the fly• Introduces inherent complexity• Unacceptable for certain systems (e.g., RT,
mission critical, provable properties)
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DDS Trustworthiness Needs (2/2)
• QoS configurations generated automatically– Eliminate accidental complexities
• Close configuration loopholes for malicious exploitation
– Decouple configurations from implementations• Refinement of configuration separate from
refinement of code
• DQML generates QoS settings files for DDS Applications– Creates consistent configurations– Promotes separation of concerns
• Configuration changes orthogonal to business logic changes
– Increases confidence
QoS Settings
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DDS Application Development• Business logic/application code mixed with QoS
configuration code– Accidental complexity– Obfuscation of configuration concerns
• DQML decouples QoS configuration from business logic– Facilitates configuration
analysis– Reduces accidental
complexity
DataWriter QoS configuration & datawriter creation
QoS configuration & publisher creation
QoS Configuration Business logic
=Higher confidence DDS application
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DQML Design Decisions
No Abortive Errors• User can ignore constraint errors• Useful for developing pieces of a
distributed application• Initially focused on flexibility
QoS Associations vs. Containment
• Entities and QoS Policies associated via connections rather than containment
• Provides flexibility, reusability• Eases resolution of constraint
violations
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DQML Application: DDS Benchmark Environment (DBE)
• Part of Real-Time DDS Examination & Evaluation Project (RT-DEEP)
• http://www.dre.vanderbilt.edu/DDS
DataReader
DataReader
DataReader
DataWriter
DataWriter DataWriter
DataWriter
QoSQoS
QoS
QoSQoS
QoS
QoS
DataReader
QoS
• Developed by DRE Group at ISIS
• DBE runs Perl scripts to deploy DataReaders and DataWriters onto nodes
• Passes QoS settings files (generated by hand)
• Requirement for testing and evaluating non-trivial QoS configurations
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DBE Interpreter
Model the DesiredQoS Policies via DQML
Compicon.icoInvoke the DBEInterpreter
Generates One QoS Settings File for Each DBEDataReader and DataWriter to Use
DBE
QoS Settings
QoS Settings
DataReader
DataWriter
Have DBE Launch DataReadersand DataWriters with Generated
QoS Settings Files
No Manual Intervention
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DQML Demonstration
• Create DDS entities, QoS policies, and connections
• Run constraint checking
• consistency check
• compatibility check
• fix at design time
• Invoke DBE Interpreter
• automatically generate QoS settings files
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
Future Work
• Incorporate into Larger Scale Tool Chains– e.g., Deployment and
Configuration Engine (DAnCE) in CoSMIC Tool Chain
• Incorporate with TRUST Trustworthy Systems– Combine QoS polices and patterns to provide higher level
services• Build on DDS patterns1
– Continuous data, state data, alarm/event data, hot-swap and failover, controlled data access, filtered by data content
1 Gordon Hunt, OMG Workshop Presentation, 10-13 July, 2006
• Fault-tolerance service (e.g., using ownership/ownership strength, durability policies, multiple readers and writers, hot-swap and failover pattern)
• Security service (e.g., using time based filter, liveliness policies, controlled data access pattern)
• Real-time data service (e.g., using deadline, transport priority, latency budget policies, continuous data pattern)
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
Backup Slides
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DDS Domains & Domain Participants
1
2
31
2
3
1
1
DomainParticipant
Node
Domain 1
Domain 2 Domain 3
Node
NodeNodeNode
Node
• The Domain is the basic construct used to bind individual applications together for communication
• Like a VPN
April 21, 2023 Joe Hoffert, Aniruddha Gokhale, Doug Schmidt
DCPS EntitiesDCPS Entities include
– Topics
• Typed data
– Publishers
• Contain DataWriters
– Subscribers
• Contain DataReaders
– DomainParticipants
• Entry points
• Data can be accessed in two ways
– Wait-based (synchronous calls)
– Listener-based (asynchronous callbacks)
• Sophisticated support for filtering
– e.g., Topic, Content-FilteredTopic, or MultiTopic
• Configurable via (many) QoS policies
Topic Topic Topic
Data Reader
Data Writer
Data Writer
Data Reader
Data Reader
Data Writer
Subscriber PublisherPublisher Subscriber
Data Domain
Domain Participant
Top Related