1. 1 Pattern-Oriented Composition and Synthesis of Middleware Services for NEST DISSECT-ing the Fairing Simulation Akos Ledeczi – Ken Frampton Vanderbilt University

2. 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. 3 Subcontractors and Collaborators Subcontractors –None Collaborators –Boeing –UCB

4. Demonstration Summary Services provided to Boeing Challenge Problem Relationship to Project Evaluation Criteria  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 Pattern-Oriented Composition and Synthesis of Middleware Services for NEST DISSECT-ing the Fairing Simulation Ledeczi Vanderbilt The middleware layer is modeled, composed and synthesized for two simulation setups using different control strategies  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 Boeing Simulation Engine DISSECT Geographic Ctrl Sim MWS Mode-Based Control Geographic Control MWS Mode-Based Ctrl Sim

5. Impact New Ideas Schedule  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. Pattern-Oriented Composition and Synthesis of Middleware Services for NEST Lédeczi, ISIS Q 1 2 Prototype pattern composition tool 2003 3 Optimization techniques 4 Demonstration 1 2 Integrated synthesis/composition tool 3 4 Network loading and dynamic reconfiguration 2004 2005 1 Final demonstration  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. MW Service Lib a2a2 x4x4 b1b1 m2m2 Application I/O Automata Platform A Middleware Application I/O Automata Platform A Middleware Application I/O Automata Platform A CCSL Composition Analysis and Optimization Synthesis Summary of Results (as of Q1 FY03):  PSL based on Asynchronous IO Automata theory provides a solid compositional foundation for NEST middleware representation  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 DISSECT

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

7. 7 Demonstration Roadmap 1.DISSECT models of mode-based control simulator middleware 2.Synthesis of middleware 3.Showing mode-based simulator skipped 4.DISSECT models of geographic control simulator middleware 5.Synthesis of middleware 6.Geographic Simulator Demonstration 7.Comparison of Control Strategies 8.Conclusions

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

9. 9 Fairing Simulator Middleware Models

10. 10 // 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); }; 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) }; // Types.idl - DISSECT generated IDL file // Friday, January 24, 2003 - 13:57 typedef long NodeId; typedef float Publication; typedef sequence PublicationSequence; typedef sequence NodeIdSequence;

11. 11 Publish/Subscribe Log 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 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

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

13. 13 Comparison of Local and Distributed Control on the Boeing Fairing

14. 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. 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. 16 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) Plant Compensator Disturbance Performance Control Sensor Compensators are locally, but not globally, optimal

17. 17 Grouping Examples 9 th Mode Group Reach 2 Geographic Group

18. 18 Performance Comparison Distributed Local No Control

19. 19 Distributed Control Performance 8090100110120130140150160170180 10 -3 Frequency, Hz Control Effort norm = 0.080 Open Loop norm = 0.035 Closed Loop norm = 0.028 Distributed No Control

20. 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. 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. 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. 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. 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.