Akos Ledeczi – Ken Frampton Vanderbilt University

1. Pattern-Oriented Composition and Synthesis of Middleware Services for NESTDISSECT-ingthe Fairing Simulation Akos Ledeczi – Ken Frampton Vanderbilt University

2. Administrative • Project Title: Pattern-Oriented Composition and Synthesis of Middleware Services for NEST • PM: Vijay Raghavan • PI: Ákos Lédeczi • PI phone # : (615) 343-8307 • PI email: akos@isis.vanderbilt.edu • Institution: Institute for Software Integrated Systems Vanderbilt University • Contract #: 733615-01-C-1903 • AO number: L538 • Award start date: 6/2001 • Award end date: 5/2005 • Agent name & organization: Al Scarpelli, AFRL/IFTA

3. Subcontractors and Collaborators • Subcontractors • None • Collaborators • Boeing • UCB

4. Ledeczi Vanderbilt MWS MWS MWS MWS MWS MWS Pattern-Oriented Composition and Synthesis ofMiddleware Services for NESTDISSECT-ing the Fairing Simulation Demonstration Summary Relationship to Project • Our project is not focused on specific middleware services, rather the composition and synthesis technology. For both control strategies we’ve selected the set of appropriate mw services including group communication, discovery etc. We’ve created new services including publish/subscribe and neighborhood. We’ve used DISSECT to compose and synthesize these. • Our demo is a subset of the final CP. The actual technology and tools that we have developed are prototypes of the final system that will support all CPs Geographic Control Geographic Ctrl Sim Boeing Simulation Engine DISSECT Mode-Based Control Mode-Based Ctrl Sim The middleware layer is modeled, composed and synthesized for two simulation setups using different control strategies Services provided to Boeing Challenge Problem Evaluation Criteria • DISSECT: The tool supports modeling, composition and automatic synthesis of the middleware layer utilizing RT-CORBA. It is directly applicable to the Boeing fairing simulation platform. • New services: • NeighborhoodComm • Physical Location • Publish/Subscribe • Number of different target platforms supported • Number of different middleware services modeled, composed and synthesized • Application performance: time and frequency domain vibration attenuation • Middleware development time

5. Lédeczi, ISIS MW Service Lib New Ideas a2 Application Application Application m2 x4 b1 CCSL Middleware Middleware I/O Automata I/O Automata I/O Automata Platform A Platform A Platform A Impact Schedule Pattern-Oriented Composition and Synthesis of Middleware Servicesfor NEST Composition DISSECT • Using the Pattern Specification Language (PSL), NEST middleware services are formally captured as design patterns. • Requirements, applicability and resource constraints are also formally captured. • Library of middleware services specified in PSL is defined. • Composable Coordination Service Layer (CCSL): desired design patterns are composed and the application-specific middleware satisfying all constraints is automatically synthesized. • Support for optimization and dynamic reconfiguration. Analysis and Optimization Summary of Results (as of Q1 FY03): PSL based on Asynchronous IO Automata theory provides a solid compositional foundation for NEST middleware representation Synthesis Formal representation of services enable the analysis, verification and system-level optimization of the middleware layer (CCSL) Experiments and proof-of-concept prototypes proved that efficient middleware code can be generated from service models for multiple NEST platforms • A design pattern specification language allows capturing and documenting common and reusable middleware services for DoD systems. • Composable Coordination Service Layer (CCSL) ensures that only necessary services are included in the middleware providing a thin layer that can run efficiently on the resource limited nodes. • Rapid and cost-effective composition of application-specific middleware layer(s). • Approach supports upgrades and reconfiguration performed dynamically enabling uninterrupted operation of DoD systems. Q 1 2003 2 Prototype pattern composition tool 3 Optimization techniques 4 Demonstration 1 2004 2 Integrated synthesis/composition tool 3 4 Network loading and dynamic reconfiguration 2005 1 Final demonstration

6. Geographic Control Geographic Control Simulator Boeing Simulation Engine Distributed Services Composition and Synthesis Technology DISSECT PhysLoc Service GroupComm Service Neighborhood Service Discovery Service Pub/Sub Service SimCtrl Service Mode-Based Control Mode-Based Control Simulator Demonstration Overview

7. Demonstration Roadmap • DISSECT models of mode-based control simulator middleware • Synthesis of middleware • Showing mode-based simulator skipped • DISSECT models of geographic control simulator middleware • Synthesis of middleware • Geographic Simulator Demonstration • Comparison of Control Strategies • Conclusions

8. Geographic Controller Geographic Controller Geographic Controller Geographic Controller send send readAll readAll send send readAll readAll Neighborhood Communication Neighborhood Communication Neighborhood Communication Neighborhood Communication neighbors neighbors PhysLoc PhysLoc PhysLoc PhysLoc neighbors neighbors subscribe subscribe publish publish publish publish subscribe subscribe Publisher Publisher Publisher Publisher subscribe subscribe getData getData Subscriber Subscriber Subscriber Subscriber update update subscribe subscribe update update unsubscribe unsubscribe getData getData unsubscribe unsubscribe Neighbors New Middleware Services forGeographic Control Node N

9. Fairing Simulator Middleware Models

10. Generated IDL files // Publisher.idl - DISSECT generated IDL file // Friday, January 24, 2003 - 13:57 #include "Types.idl" interface Publisher { void getId(out Types::NodeId nodeid); void subscribe(in string subscriber) void unsubscribe(in string subscriber) oneway void publish(in Types::Publication value) }; // Subscriber.idl - DISSECT generated IDL file // Friday, January 24, 2003 - 13:57 #include "Types.idl" interface Subscriber { void getPublications(out Types::PublicationSequence values); // subscriber interaction void subscribe(in Types::NodeIdSequence publishers); oneway void update(in Types::NodeId publisherId, in Types::Publication value); void getId(out Types::NodeId nodeid); }; // Types.idl - DISSECT generated IDL file // Friday, January 24, 2003 - 13:57 typedef long NodeId; typedef float Publication; typedef sequence<Publication> PublicationSequence; typedef sequence<NodeId> NodeIdSequence;

11. Publish/Subscribe Log Node17.log --- Publisher publishes to node 11 : 0.000001 575 entered LowLevelController::UpdateControl cycle: 578 setSensorData value is: 0.000009 --- Subscribed to nodes: 11 12 13 14 15 16 17 24 --- Actual data : -8.3244e-006 0 0 0 0 0 -5.77626e-006 1.02831e-005 Executing Control Code node input 17.000000, first ctrl param -2.599428e+000 Sending actuator command 0.000011, sens 0.000009, y.out2 -0.041287, mode 0 setSensorData value is: 0.000009 --- Publisher publishes to node 12 : 0.000008 577 --- Subscriber has recevied update from node 11 : -0.000055 576 Node11.log: --- Actual data : 0 0 7.4397e-005 0 0 0 0 0 4.38564e-006 1.02071e-005 -3.0545e-005 Executing Control Code node input 11.000000, first ctrl param -3.465484e-001 Sending actuator command 0.000314, sens 0.000009, y.out2 -0.038137, mode 0 --- Publisher publishes to node 17 : -0.000055 576 --- Subscriber has recevied update from node 17 : 0.000001 575 setSensorData value is: 0.000041 entered LowLevelController::UpdateControl cycle: 579

12. Simulator Output Geographic control, 25 nodes, reach = 2

13. Comparisonof Local and Distributed Controlon the Boeing Fairing

14. Objectives • Compare the default Boeing simulator control approach to a distributed control approach • Default control law applies dynamic compensation to local sensor signal only • Distributed control law applies static compensation to many sensor signals

15. Control based on Group Management Middleware • Assuming that groups can be defined and managed • How well can specific modes be targeted? • What type of grouping yields the best performance? • Each node receives sensor signals from all group members to produce local control signal • Grouping based on structural modes or geographic neighbors

16. Performance Disturbance Plant Control Sensor Compensator Distributed, Two-Port Control Design • Objective is to minimize Disturbance to Performance path with sensor/control closed loop • Geographic groups average are REACH=2 (13 members) • Compensators are locally, but not globally, optimal

17. 1 Ring 7 1 Position Ring 7 17 1 Position Grouping Examples 9th Mode Group Reach 2 Geographic Group

18. Distributed Local No Control Performance Comparison

19. Control Effort norm = 0.080 Open Loop norm = 0.035 Closed Loop norm = 0.028 Distributed -3 No Control 10 80 90 100 110 120 130 140 150 160 170 180 Frequency, Hz Distributed Control Performance

20. Control Comparison Conclusion • Comparison is not perfect • Unknown control effort comparison • Effects of network on distributed control are unknown (although previous simulations indicate that these effects are minimal) • Performance of the two approaches are similar • The two approaches challenge middleware in very different ways

21. Context • Relationship to Challenge Problem: • DISSECT and its built-in synthesizer for RT-CORBA-based middleware is directly applicable toward the challenge problem • Relationship to NEST and your project: • Boeing simulator is another target platform for the technology we are developing in NEST • DISSECT is a generic tool for middleware development for NEST • DISSECT supports: • UCB Motes / TinyOS • Boeing platform / RT-Corba • Siesta / Asynchronous IO Automaton-based middleware engine

22. Evaluation Criteria • Number of different target platforms supported:  3 (Boeing/RT-CORBA, UCB motes/TinyOS, Siesta/Asynch IO Automata) • Number of middleware services modeled, composed and synthesized:  6 (Publish, Subscribe, PhysLoc, NeighborhoodComm, Discovery, Group Communication) • Application performance: time and frequency domain vibration attenuation:  Performance of the two approaches are similar • Middleware development time:  N/A

23. Demonstration Issues • Low-level node to node communication with reach = 2 (i.e. ~12 neighbors for every node) overloaded Windows. Either <=25 nodes or reach = 1 or two machines had to be used. • RT-CORBA imposes relatively large infrastructural overhead that may be prohibitive for most “classical” NEST platforms

24. Demonstration Lessons Learned • DISSECT language was developed before considering RT-CORBA as a target platform. Yet the modeling language is powerful enough to capture all necessary concepts for the new platform without modification • Models are rich enough that would enable generation of custom marshalling code for severely resource constrained targets where the overhead of CORBA is prohibitive • DISSECT provides nice support for componentization, complex components can be easily refactored into smaller units.