1. A Platform-Independent Component Modeling Language for DRE Systems
Krishnakumar Balasubramanian, Jaiganesh Balasubramanian,
Jeff Parsons, Aniruddha Gokhale, Douglas C. Schmidt
Department of EECS,
Vanderbilt University
November 11, 2018

2. Motivating Application
Emergency Response System
Monitor terrain
Unmanned Aerial Vehicles (UAVs)
Capture images
Send images to control center
Key QoS parameters
Image Tx Latency
Network Bandwidth
Multiple mission modes
Image processing
Multiple Simultaneous QoS requirements

3. Component Middleware … … …
Components encapsulate application “business” logic
Components interact via ports
Provided interfaces, e.g.,facets
Required connection points, e.g., receptacles
Event sinks & sources
Attributes
Containers provide execution environment for components with common operating requirements
Components/containers can also
Communicate via a middleware bus and
Reuse common middleware services
Component-Integrated ACE ORB (CIAO)
Our CCM implementation based on The ACE ORB (TAO) …
Container …
Middleware Bus
Container …
Security
Replication
Notification
Persistence
Scheduling
A/V Streaming
Load Balancing

4. UAV System Components System Resource Manager Global QoS manager
Control Center Display
User interaction
Policy specification
Image Stream(s)
Sender/Receiver
Tx/Rx images
Local Resource Manager
Local QoS manager
Qoskets
QoS enforcer
QoS predictors
QoS helpers
Built using Component-Integrated ACE ORB (CIAO)
dist-systems.bbn.com/papers

5. CCM Deployment & Configuration Process
SW Deployer
Deployment
Infrastructure
Deployment Tools (generic)
Deployment Interfaces
Infrastructure Interfaces
Shipping SW
Creator2 A2 A1
Deployment
requirements
Implementations
Creator1
Interchange Formats
D & C
Profile
XMLSchema Generation
IDL Generation
OMG D & C Spec
(PIM & PSMs)

6. Building UAV system using CCM
Identify components & define interfaces
Define Component IDL
Define component interactions
Define connections between components using XML
Compose application
Define instantiations of components
Generate metadata
Deploy the application onto its run-time platform
Define a mapping between components & nodes
Refine the application to incorporate changes

7. Component-based UAV system Challenges (1/5)
Accidental complexities in interface definition
Differences between CORBA 2.x and CORBA 3.x (CCM)
New keywords in the language
Subtle differences in syntax and semantics of equivalent elements
CORBA 2.x interfaces
CORBA 3.x components
// CORBA 2.x
interface ImageProvider {};
interface ImageViewer {};
interface LRM
: ImageProvider,
ImageViewer {
// Operations on LRM };
// CORBA 3.x
component ImageProvider {};
component ImageViewer {};
component LRM
: ImageProvider,
ImageViewer {
// Operations on LRM };

8. Component-based UAV system Challenges (2/5)
Defining consistent component interactions
Textual IDL definition
Edit-Compile-Fix Cycle
No inter-connections
No whole system view
component MultiReceiver
: ImageProcessingQosket {
consumes ResourceAllocationEvt resourceEvt; consumes PolicyChangeEvt policyEevt; };
component SystemResourceManager { attribute double available_cpu; attribute double available_bw; attribute double needed_cpu; attribute double needed_bw; attribute UAV_List uavs_from_lrm; uses multiple LRMInterface my_lrms; provides SRMInterface srm_interface; publishes ResourceAllocationEvt resourceEvt; publishes PolicyChangeEvt policy_evt; };

9. Component-based UAV system Challenges (3/5)
Associating components with targets
Map software artifacts to physical system
Match component requirements with target capabilities
Performed in an ad-hoc fashion
By different people
At different periods in time

10. Component-based UAV system Challenges (4/5)
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance> <connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</connection>
</assemblyImpl>
Generating valid deployment descriptors
XML is non-intuitive
Error-prone to write manually
No way to propagate changes automatically
Redundant effort
Cascading effect

11. Component-based UAV system Challenges (5/5)
Automating propagation of changes
Typical in DRE systems evolution
Currently changes propagated in an ad-hoc fashion
Redundant effort
Cascading effect
Change to a single UAV stream
Needs to get propagated to all instances of the stream
1 stream per UAV
n streams in total (n>=50)
Difficult to estimate effect of changes

12. Model-Driven Development (MDD)-based Solution
Platform-Independent Component Modeling Language
Developed using GME
Core of Component Synthesis using Model-Integrated Computing (CoSMIC) toolchain
Capture elements & dependencies visually
Define “static semantics” using Object Constraint Language (OCL)
Define “dynamic semantics” via model interpreters
Generates domain specific meta-data
Goal: “Correct-by-construction”

13. Challenge 1 Resolved: Constraints for IDL
Visual component interface definition
Import/Export IDL
Define IDL rules as OCL constraints
Example:
An abstract Event can have no concrete parent; a concrete Event can have at most one.
let concrete_parents =
self.parts ("Inherits")->
select (x : gme::Model | x.oclAsType (Event).abstract = false) in
if (self.abstract = true)
then
concrete_parents->size = 0
else
concrete_parents->size < 2
endif

14. Challenge 2 Resolved: Visual composition
Semantically compatible component interaction definition
Enforce static constraints using OCL
Enforce dynamic constraints via a model interpreter

15. Challenge 3 Resolved: Deployment Planning
Target domain definition
Describe domain resources
Describe inter-connections
Mapping components
Components → Nodes
Requirements → Capabilities
Optimize communication path
Exploit locality → Collocate

16. Challenge 4 Resolved: Generate metadata
Define model interpreters
Generate descriptors using interpreters
Ensures validity
Syntactic
Semantic
Relieve DRE developers from learning yet another technology
Save time

17. Challenge 5 Resolved: Hierarchical Composition
4 streams x 11 components per stream x 3 connections per component
Too much to comprehend at once; n streams (n >= 100) => ???
Model single stream
Reuse stream multiple times
Increased comprehension
Automate propagation of changes

18. Related Work
CADENA
Integrated Environment to apply static analysis using model-checking
VEST
DSML developed in GME
Pre-defined component Libraries
Aspect checks
Prescriptive aspect library
ESML
Targets PRiSM (Boeing’s Bold-stroke component model)
Ptolemy II
Modeling, simulation, and design of concurrent systems
Allows defining systems based on Models of Computation
cadena.projects.cis.ksu.edu
ptolemy.eecs.berkeley.edu

19. Concluding Remarks PICML DSML based approach
Support for component-based development
Design-time
Specify component functionality
Component interactions
Assembly & Packaging of components
Deployment-time
Specification of target environment
Automatic Deployment plan generation
Available as open-source
CoSMIC
cosmic
CVS Repository
cvs.dre.vanderbilt.edu

20. Questions?

21. Deployment & Configuration
OMG Specification
Defines deployment of component-based applications
Meta-information is captured using XML descriptors
Defines a Platform Independent Model (PIM) in two dimensions
Data vs. management (run-time)
Software vs. target vs. execution
Different Stages
Development
Developer
Assembler
Packager
Target
Domain Administrator
Deployment
Repository Administrator
Planner
Executor

22. Example Meta-data generated by PICML
Component Interface Descriptor (.ccd)
Describes the interface, ports, properties of a single component
Implementation Artifact Descriptor (.iad)
Describes the implementation artifacts (e.g., DLLs, OS, etc.) of a single component
Component Package Descriptor (.cpd)
Describes multiple alternative implementations of a single component
Package Configuration Descriptor (.pcd)
Describes a specific configuration of a component package
Component Implementation Descriptor (.cid)
Describes a specific implementation of a component interface
Contains component inter-connection information
Component Deployment Plan (.cdp)
Plan which guides the actual deployment
Component Domain Descriptor (.cdd)
Describes the target domain of deployment
Component Packages (.cpk)
Aggregation of all of the above
<Deployment:ComponentImplementationDescription>
  <UUID>FB9D BC1D-EA9EAAB3ED2A</UUID>
  <implements href=“Sender.ccd" />
<monolithicImpl>
<primaryArtifact>
  <name>Sender_exec</name>
  <referencedArtifact href=“Sender_exec.iad" />
  </primaryArtifact>
  <name>Sender_stub</name>
  <referencedArtifact href=“Sender_stub.iad" />
  <name>Sender_svnt</name>
  <referencedArtifact href=“Sender_svnt.iad“ />
  </monolithicImpl>
</Deployment:ComponentImplementationDescription>

23. Motivation for Deployment & Configuration
Packaging & Deployment
Component Properties
Display
Database
Print
File
Component
Assembly
File Properties
Database Properties
Goals
Ease component reuse
Build complex applications by assembling existing components
Standardize deployment of applications into heterogeneous domains
Separation of concerns
Component development
Application assembly
Application deployment
Application configuration
Middleware configuration

24. Model-Driven Development (MDD)
Models as basic artifact in all stages of system development
Definition of Domain-Specific modeling languages (DSMLs)
Concrete Syntax, Abstract Syntax, Semantic Domain, Syntactic Mapping, Semantic Mapping
Meta-models, models, model-transformations, code generators

25. Generic Modeling Environment (GME)
Tool Developer (Metamodeler)
GME used to develop a domain-specific graphical modeling environment
Define syntax, static semantics, & visualization of the environment
Semantics implemented via interpreters
Application Developer (Modeler)
Uses a specific modeling environment (created by metamodeler w/GME) to build applications
The interpreter produces something useful from the models
e.g., code, simulations, configurations

26. Platform-independent Model (PIM) Dimensions
Modeling view-points
Conceptual, logical, & physical view-point
Platform-independent model
Conceptual & logical viewpoint of deployment & configuration
Defined in two-dimensions
PIM
Data Model
Run-time Model
Component Software
Meta-data to describe component based applications and their requirements
Interfaces to browse, store and retrieve such meta-data
Target
Meta-data to describe heterogeneous distributed systems & their capabilities
Interfaces to collect & retrieve such meta-data and commit resources
Execution
Meta-data to describe a specific deployment of an application into a distributed system
Prepare environment, Execute on target to Deployment plan, manage lifecycle

27. PIM Mapping to CCM Physical viewpoint
Mapping from PIM to platform specific model (PSM) for CCM
Set of transformations
T1  PIM to PSM for CCM
T2  PSM to
PSM for IDL
PSM for XML
Set of mapping rules
M1  PSM to IDL
M2  PSM to XML schema

28. Deployment And Configuration Engine (DAnCE)
Solution
Deployment & Configuration Engine (DAnCE)
First-cut implementation of deployment infrastructure
Partial implementation of the following interfaces:
RepositoryManager
NodeManager
NodeApplicationManager
DomainApplicationManager
NodeApplication
ExecutionManager
Processes XML meta-data generated by PICML
Synergy between CIAO, DAnCE and CoSMIC
CIAO
CoSMIC
DAnCE