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

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

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) http://www.dre.vanderbilt.edu/CIAO … Container … Middleware Bus Container … Security Replication Notification Persistence Scheduling A/V Streaming Load Balancing

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

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)

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

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 };

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; };

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

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

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

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”

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

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

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

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

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

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 www.cs.virginia.edu/~stankovic/vest.html www.isis.vanderbilt.edu/projects/mobies ptolemy.eecs.berkeley.edu

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 www.dre.vanderbilt.edu/ cosmic CVS Repository cvs.dre.vanderbilt.edu

Questions?

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

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>FB9D7161-1765-4784-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>

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

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

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 http://www.isis.vanderbilt.edu/Projects/gme/default.htm

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

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

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