Soleil: A Component Framework for RTSJ


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Soleil: A Component Framework for RTSJ

  1. 1. SOLEIL : An Integrated Approach for Designing and Developing Component-based Real-time Java Systems <br />AlešPlšek<br />INRIA Lille, team ADAM<br />Université de Lille, France<br />Supervisors: Prof.LionelSeinturier<br />Dr.PhilippeMerle<br />14.9.2009<br />Lille, France<br />
  2. 2. Introduction<br />Context<br />Domains<br /><ul><li>Component-based Software Engineering (CBSE)
  3. 3. Real-time Java Programming (RTSJ)</li></ul>Our Approach<br /><ul><li>Solution through Software Engineering Methods
  4. 4. High-Level Abstractions</li></ul>Thesis Statement. An effective development process of RTSJ-compliant systems must consider RTSJ concerns at early stages of the system design and must provide their high level abstractions as the only way to avoid tedious and error-prone process when implementing them.<br />2<br />
  5. 5. Introduction<br />Outline<br />Introduction<br />State of the Art<br />Proposal<br />Validation<br />Conclusion<br />3<br />
  6. 6. Introduction<br />Outline<br />Introduction<br />State of the Art<br />Proposal<br />Validation<br />Conclusion<br />4<br />
  7. 7. Why Real-Time?<br />Introduction<br />Real-time Programming<br />A little interest in Real-time from the mainstream software engineering community<br />Deadlines, interruption handling, too low-level…<br />Real-Time Systems Trends<br />Large-scale, heterogeneous systems<br />Dynamically highly adaptable systems<br />Systems composed from hard-, soft-, <br /> and non-real-time units<br />Many software engineering techniques can be applied in the real-time domain<br />Component oriented programming, Generative Programming, Model Driven Engineering, Formal Verification, etc.<br />5<br />
  8. 8. Successful Stories<br />Introduction<br />Shipboard computing<br />US navy Zumwalt-class Destroyer<br />5mio lines of Java code<br />Red Hat Linux, RT GC the key part<br /> Avionics<br />787 Dreamliner saves 900kgs<br /> of weight<br />A380 saves a half of the processing units<br /> Financial Information Systems<br />100 milliseconds deadlines<br />Thomson Reuters Market Data System (powered by SUN RTS Java)<br />6<br />
  9. 9. Why Java?<br />Introduction<br />Java<br />Easy to use, familiar<br />Popular programming language<br />Libraries<br />Portable across platforms<br />But – non-predictable<br />RTSJ – Real-time Specification for Java<br />Making Java predictable<br />Thread and Memory model<br />7<br />
  10. 10. RTSJ Illustration Example<br />Introduction<br />SweetFactory<br />A helloworld RTSJ example developed by IBM [GHMS07]<br />Output statistics control, reporting anomalies and wrong values<br />Real-time and non-real-time concerns coexist in the system<br />RTSJ Implementation<br />How to express RTSJ?<br />RTSJ concerns mixed with system architecture<br />8<br />
  11. 11. Introduction<br />RTSJ Thread Model <br />2 New Types of Threads<br /><ul><li>Realtime threads
  12. 12. NoheapRealtime threads
  13. 13. Cannot be preempted by Garbage Collector
  14. 14. No heap memory access</li></ul>9<br />Thread Management Issues<br /><ul><li>Priorities setting and management
  15. 15. Bootstrapping threads
  16. 16. Cross-ThreadCommunication</li></li></ul><li>Introduction<br />RTSJ Memory Model<br />Memory Management<br /><ul><li>Immortal Memory
  17. 17. Objects are collected when the application terminates (live forever…)
  18. 18. Memory Scope
  19. 19. Size is fixed and pre-declared
  20. 20. Lifetime of objects in the Scope</li></ul>10<br />Memory Management Issues<br /><ul><li>Cross-Scope communication
  21. 21. Communication Rules
  22. 22. RTSJ patterns</li></li></ul><li>Introduction<br />Lessons Learned from Real-Time Java<br />Advantages<br />1/9/90 Real-time Rule<br />Standard Java advantages<br />hard-, soft-, and non-real-time cooperation<br />Complexities<br /><ul><li>Error-prone process
  23. 23. Non-intuitive rules and restrictions
  24. 24. Functional code tangled by the RTSJ code
  25. 25. Introducing a new programming style</li></ul>11<br />
  26. 26. Remedy?<br />Component-based Software Engineering (CBSE)<br /><ul><li>Higher levels of abstraction
  27. 27. Separation of Concerns
  28. 28. Runtime Infrastructure
  29. 29. Component Container
  30. 30. Generative programming
  31. 31. Container Implementation automatically generated
  32. 32. Adaptation Support</li></ul>Component Framework for Real-time Java <br /><ul><li>To shield developers from the RTSJ complexities</li></ul>Introduction<br />12<br />
  33. 33. State of the Art<br />Outline<br />Introduction<br />State of the Art<br />Proposal<br />Validation<br />Conclusion<br />13<br />
  34. 34. State of the Art<br />Component Frameworks for Real-time Systems<br /><ul><li>AADL[FLV06], AdaCCM[PMPL08] , SOFA HI [MWP+08]</li></ul>Component Frameworks for Real-time Java Systems<br /><ul><li>Compadres [HGCK07], Etienne et al. [ECB06], Golden Gate [DBC+04] </li></ul>State of the Art<br />14<br />
  35. 35. Component Frameworks for Real-time Systems<br />State of the Art<br />Separation of Real-time and Functional Concerns<br />AADL [FLV06], AdaCCM [PMPL08]<br />Development Methodology<br />AADL [FLV06], AdaCCM [PMPL08]<br />Component-Oriented Containers<br />SOFA HI [MWP+08]<br />Active/Passive Components<br />Fractal [BCL+06]<br />Formalization Support<br />Fractal in Alloy [MS08]<br />Towards a specific programming language<br />AdaCCM [PMPL08]<br />Matured component models employed<br />15<br />
  36. 36. Component Frameworks for RTSJ<br />State of the Art<br />CBSE Criterions<br />Weak Component Models<br />Only event-oriented<br />Compadres [HGCK07], Golden Gate [DBC+04] <br />Matured Model<br />Etienne et al. [ECB06]<br />Inspired by Fractal<br />Development Methodology<br />Compadres [HGCK07]<br />Features not supported<br />Component-Oriented Containers<br />Formalization of the model<br />16<br />
  37. 37. Component Frameworks for RTSJ<br />State of the Art<br />RTSJ criterions<br />Memory model<br />“one memory area per component”<br />No other granularity or flexibility<br />Compadres [HGCK07]<br />No support for heap memory<br />Etienne et al. [ECB06]<br />Thread model<br />Active/Passive components<br />Etienne et al. [ECB06]<br />No abstractions of RTSJ complexities provided<br />Development process not facilitated<br />RTSJ concepts not separated, this hinders reuse of components<br />No support for cross-memory and cross-thread communication<br />17<br />
  38. 38. Proposal<br />Outline<br />Introduction<br />State of the Art<br />Proposal<br />Validation<br />Conclusion<br />18<br />
  39. 39. Our Goal<br />Our Philosophy<br />RTSJ considerably influences the architecture of the system, therefore has to be considered earlier than during the implementation<br />Ultimate Goal: Component Framework for RTSJ<br />Isolate RTSJ–related properties in clearly identified entities<br />Manipulate RTSJ-concerns during the development lifecycle<br />Separation of Concerns<br />State of the Art<br />19<br />
  40. 40. Proposal<br />SOLEIL Design Framework<br />HULOTTE Implementation Framework<br />SOLEILMetamodel<br />Contributions – Big Picture<br />Domain Component<br />RTSJ abstractions<br />20<br /><ul><li>Domain Component Implementation
  41. 41. Runtime Infrastructure Generation
  42. 42. Methodology
  43. 43. Metamodel Formalization
  44. 44. Validation Support</li></li></ul><li>Proposal<br />Outline<br />Introduction<br />State of the Art<br />Proposal<br />SOLEILMetamodel<br />SOLEIL Design Framework<br />HULOTTE Implementation Framework<br />Validation<br />Conclusion<br />21<br />
  45. 45. SOLEILMetamodel<br />Proposal<br />22<br />Metamodel<br /><ul><li>Fractal Component Model inspired
  46. 46. Hierarchical model
  47. 47. Component sharing</li></ul>New concepts:<br /><ul><li>Functional Component
  48. 48. Active and Passive Components
  49. 49. Implement functional services
  50. 50. Domain Component
  51. 51. Represents non-functional services</li></li></ul><li>RTSJ-specificDomain Components<br />Proposal<br />RTSJ Domain Components<br /><ul><li>For each domain, rules and restriction of its application are defined, in compliance with RTSJ</li></ul>Advantages<br /><ul><li>Real-Time concerns at the architectural level as components
  52. 52. Abstracting the complexities of real-time development
  53. 53. Evaluate RTSJ compatibility earlier than “after the implementation”</li></ul>23<br />
  54. 54. Domain Components in SOLEIL<br />Proposal<br />Memory Domains<br />Composition & Communication constraints <br /><ul><li>to reason about the conformance to RTSJ</li></ul>Thread Domains<br />24<br /><ul><li>Different assemblies of real-time components
  55. 55. Adapting systems for different real-time conditions.</li></li></ul><li>Proposal<br />Outline<br />Introduction<br />State of the Art<br />Proposal<br /> RTSJ-specific Metamodel<br />SOLEIL Design Framework<br />HULOTTE Implementation Framework<br />Validation<br />Conclusion<br />25<br />
  56. 56. SOLEIL Framework<br />Proposal<br /><ul><li>Design Methodology
  57. 57. Methodology how to gradually construct and merge design components with functional architecture
  58. 58. Defining and distinguishing between real-time and non-real-time parts of the system
  59. 59. Designing RTSJ concerns independently from the rest of the system</li></ul>26<br />
  60. 60. Proposal<br />Metamodel Formalization<br />Motivation<br /><ul><li>Exact definition of the component model and its composition rules
  61. 61. Alloy specification language</li></ul>abstractsigComponent {<br /> interface: setInterface<br />superComponent : setComposite<br />}<br />sigComposite in Component {<br />subComponents : setComponent<br />}<br />sigPrimitive inComponent { }<br />sig FunctionalComponent { }<br />fact {<br />all f : FunctionalComponent|<br /> f in Primitive <br />or<br /> f in Composite<br />and <br />not f in (Primitive and Composite)<br />}<br />27<br />
  62. 62. Proposal<br />fact EveryCompHasMemory {<br /> all f : Component |<br />one m: MemoryArea|<br /> f inm.^subComponent<br />}<br />Architecture Validation Process<br />Composition Rules Validation<br />Consistence with RTSJ<br />RTSJ communication Patterns<br />Formalized in the model<br />The process facilitates<br />Incremental design<br />Reasoning about the system before starting with implementation<br />Using the Formalized Metamodel<br />28<br />
  63. 63. Proposal<br />Outline<br />Introduction<br />State of the Art<br />Proposal<br /> RTSJ-specific Metamodel<br />SOLEIL Design Framework<br />HULOTTE Implementation Framework<br />Validation<br />Conclusion<br />29<br />
  64. 64. HULOTTE Implementation Framework<br />Proposal<br />Motivation<br />Keep components also at the implementation layer<br />Distinguish functional and domain components <br />Implementation of Domain Components <br />Component-Oriented Containers<br />Hidden Intercepting and control mechanisms to manage RT concerns<br />Component Refinement<br />30<br />
  65. 65. HULOTTEMetamodel<br />Proposal<br />Metamodel Specifics<br />Application and Container Level<br />Fractal Component model concepts<br />Container level<br />Implements Domain Components<br />Container architectures<br />Component Refinement Process<br />31<br />Application Level<br />Container <br />Level<br />Container Level<br />Application Level<br />Container Level<br />
  66. 66. Component Refinement Example<br />Proposal<br />32<br />Application Level<br />Container Level<br />
  67. 67. Component Refinement Example cont.<br />Proposal<br />33<br />Application Level<br />Container Level<br />
  68. 68. HULOTTEToolchain<br />Proposal<br />34<br />Key features:<br /><ul><li>Step-wise refinement process
  69. 69. Hulotte internal is implemented using CBSE
  70. 70. Fully extensible / provides a plugin-oriented architecture</li></ul>Internal structure & compilation flow:<br /><ul><li>Front-end: Process a description of a functional architecture stored in ADL
  71. 71. Mid-end: Step-by-step architecture refinement
  72. 72. Back-end: Container Implementation Generation</li></li></ul><li>Proposal<br />Generation of Container Implementations<br />Reducing overhead of the framework<br />A tradeoff between flexibility and performance<br />3 levels of optimization<br />Soleil<br />Full componentization of Execution<br /> Infrastructure<br />Merge All<br />Membrane and functional component merged<br />No reconfiguration at the membrane level<br />Ultra Merge<br />The application merged into one class<br />Static infrastructure, No reconfiguration<br />35<br />
  73. 73. Validation<br />Outline<br />Introduction<br />State of the Art<br />Proposal<br /> RTSJ-specific Metamodel<br />SOLEIL Design Framework<br />HULOTTE Implementation Framework<br />Validation<br />Conclusion<br />36<br />
  74. 74. Validation<br />Validation<br />Case studies<br /><ul><li>3 Case Studies
  75. 75. SweetFactory
  76. 76. Real-time Collision Detector
  77. 77. Ambient and Distributed Programming in Hulotte
  78. 78. Goals
  79. 79. Performance Evaluation
  80. 80. Software Engineering Perspectives
  81. 81. Extendability Towards Different Domains</li></ul>37<br />
  82. 82. SweetFactory<br />Validation<br />SweetFactory[GHMS07]<br />Case Study Goal <br /><ul><li>Componentize in SOLEIL
  83. 83. Performance Overhead
  84. 84. Comparing different Implementations
  85. 85. OO - IBM’s object-oriented
  86. 86. SOLEIL - SOLEIL implemented and optimized implementations</li></ul>38<br />
  87. 87. Validation<br />Performance Benchmarks<br />Measuring overhead of the framework<br />Different levels of optimization<br />Memory Footprint<br />Memory Footprint<br />5%<br />Execution Time Distribution<br />39<br />
  88. 88. Validation<br />Real-time Collision Detector<br />Real-Time Collision Detector<br />Algorithm computing collision courses of aircraft in real-time<br />A software engineering challenge<br />A well-known Real-time Java benchmark [PFHV04, ABG+08]<br />Goals of the Case Study<br />Evaluation on a large real-life application<br />Comparison with the state-of-the-art approaches<br />Componentization of the Application<br />40<br />
  89. 89. Validation<br />Realtime Collision Detector<br />RCD Architecture<br />Results<br />RTSJ concerns separated from the functional logic of the system<br />Simplified design and development<br />No trade-offs caused by RTSJ<br />Separation of concerns<br />41<br />Refined Architecture<br />
  90. 90. Validation<br />Ambient and Distributed Programming<br />Goals <br />Evaluate SOLEIL&HULOTTE in a more general perspective<br />Face challenges from different domains<br />Targeted Domains<br />Distributed Programming<br />To provide a transparent implementation of a distributed system<br />Ambient Programming<br />To provide implementation of ambient services<br />42<br />
  91. 91. Validation<br />Distributed Programming<br />A new domain component <br />DistributedNode<br />Execution infrastructure<br />Distribution support implemented <br />Transparent implementation for the functional components<br />Using RTZenmiddleware [RZP+05]<br />RTZen Stubs/skeletons <br />43<br />
  92. 92. Outline<br />Introduction<br />State of the Art<br />Proposal<br /> RTSJ-specific Metamodel<br />SOLEIL framework<br />HULOTTE framework<br />Validation<br />Conclusion and Perspectives<br />44<br />
  93. 93. Contributions<br />Conclusion<br /><ul><li>SOLEIL Design Framework[2,4]</li></ul>a matured component model - Fractal, in the world of real-time programming<br />Domain Components and RTSJ abstractions<br />Explicit separation of functional and real-time concerns<br />RTJS formalization<br />Development Methodology<br /><ul><li>HULOTTE Implementation Framework [1]
  94. 94. Domain component implementation
  95. 95. Component-Refinement Process
  96. 96. Automatic instantiation of runtime infrastructures
  97. 97. Evaluation [2,5,6,7]
  98. 98. Various case studies
  99. 99. Overhead measurements</li></ul>Facilitate development of RTSJ systems<br />45<br />
  100. 100. Conclusion<br />Selected Publications<br />International Conferences<br />FrédéricLoiret, Michal Malohlava, AlešPlšek, Philippe Merle, Lionel Seinturier. Constructing Domain-Specific Component Frameworks through Architecture Refinement. SEAA 2009<br />AlešPlšek, FrédéricLoiret, Philippe Merle, Lionel Seinturier. A Component Framework for Java-based Real-time Embedded Systems, Middleware 2008<br />AlešPlšek, JiříAdámek. Carmen: Software Component Model Checker. QoSA 2008<br />AlešPlšek, Philippe Merle, Lionel Seinturier. A Real-Time Java Component Model, ISORC 2008<br />International Workshops<br />Tomas Kalibera, Jeff Hagelberg, FilipPizlo, Ales Plsek, Ben Titzer, Jan VitekCDx: A Family of Real-time Java Benchmarks. JTRES 2009<br />Michal Malohlava, AlešPlšek, FrédéricLoiret, Philippe Merle and Lionel Seinturier. Introducing Distribution into a RTSJ-based Component Framework, JRWRTC 2008<br />AlešPlšek, Philippe Merle, Lionel Seinturier. Ambient-Oriented Programming in Fractal. ECOOP Workshop 2007<br />46<br />
  101. 101. Conclusion<br />Contributions cont.<br />Developed Software<br />SOLEILandHULOTTEFrameworks<br />Alloy: 400 signatures, facts, and predicates in 4.5KLoC<br />55kLoC<br />Available at<br />Real-time Collision Detector<br />30kLoC<br />Available at<br />Works influenced by the Dissertation<br />Annotation Framework for Domain-Specific Component Applications [NL09]<br />Homogenous validation of architectural and implementation concepts towards OCL rules<br />Domain Components expressed as annotations<br />47<br />
  102. 102. Conclusion<br />Future Work<br />Short-Term Perspective<br />Taxonomy of Domain Components<br />Resolve conflicts and dependencies between different Domain Components<br />Long-Term Perspective<br />Run-time Adaptation of RTSJ-based System<br />Reconfiguration support specified by domain components<br />Reconfiguration in the context of RTSJ<br />Model-Checking of RTSJ-based Components<br />48<br />
  103. 103. Questions<br />Conclusion<br />49<br />
  104. 104. Conclusion<br />Bibliography<br />50<br />
  105. 105. Conclusion<br />Bibliography cont.<br />51<br />