1. 18 December 2015Joe 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

2. 18 December 2015Joe 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

3. 18 December 2015Joe 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

4. 18 December 2015Joe 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)

5. 18 December 2015Joe 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

6. 18 December 2015Joe Hoffert, Aniruddha Gokhale, Doug Schmidt Use Case: The OMG Data Distribution Service (DDS) Application Logical Data Store read 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

7. 18 December 2015Joe 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

8. 18 December 2015Joe Hoffert, Aniruddha Gokhale, Doug Schmidt DDS QoS Policies Interactions of QoS Policies have implications for: Consistency/Validity e.g., Deadline period < TimeBasedFilter minimum separation (for a DataReader) Compatibility/Connectivity e.g., best-effort communication offered (by DataWriter), reliable communication requested (by DataReader) DataWriter Durability- Volatile Durability- Transient Reliability- Best Effort Reliability- 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

9. 18 December 2015Joe 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)

10. 18 December 2015Joe 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

11. 18 December 2015Joe 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

12. 18 December 2015Joe 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

13. 18 December 2015Joe 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 DataWriter 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

14. 18 December 2015Joe Hoffert, Aniruddha Gokhale, Doug Schmidt DBE Interpreter Model the Desired QoS Policies via DQML Invoke the DBE Interpreter Generates One QoS Settings File for Each DBE DataReader and DataWriter to Use DBE QoS Settings DataReader DataWriter Have DBE Launch DataReaders and DataWriters with Generated QoS Settings Files No Manual Intervention

15. 18 December 2015Joe 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

16. 18 December 2015Joe 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 patterns 1 –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)

17. 18 December 2015Joe Hoffert, Aniruddha Gokhale, Doug Schmidt Backup Slides

18. 18 December 2015Joe Hoffert, Aniruddha Gokhale, Doug Schmidt DDS Domains & Domain Participants 1 2 3 1 2 3 1 1 DomainParticipant Node Domain 1 Domain 2 Domain 3 Node The Domain is the basic construct used to bind individual applications together for communication Like a VPN

19. 18 December 2015Joe Hoffert, Aniruddha Gokhale, Doug Schmidt DCPS Entities DCPS 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 Data Reader Data Writer Data Reader Data Writer Subscriber Publisher Subscriber Data Domain Domain Participant