This document presents SOLEIL, an integrated approach for designing and developing component-based real-time Java systems. It proposes a component framework with two parts - SOLEIL for design and HULOTTE for implementation. SOLEIL includes domain components that abstract real-time concerns and a design methodology. HULOTTE supports component refinement and generates runtime infrastructures. The approach is validated through case studies on performance, extensibility, and facilitating RTSJ development.

1. SOLEIL : An Integrated Approach for Designing and Developing Component-based Real-time Java Systems AlešPlšek INRIA Lille, team ADAM Université de Lille, France Supervisors: Prof.LionelSeinturier Dr.PhilippeMerle 14.9.2009 Lille, France

4. High-Level AbstractionsThesis 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. 2

5. Introduction Outline Introduction State of the Art Proposal Validation Conclusion 3

6. Introduction Outline Introduction State of the Art Proposal Validation Conclusion 4

7. Why Real-Time? Introduction Real-time Programming A little interest in Real-time from the mainstream software engineering community Deadlines, interruption handling, too low-level… Real-Time Systems Trends Large-scale, heterogeneous systems Dynamically highly adaptable systems Systems composed from hard-, soft-, and non-real-time units Many software engineering techniques can be applied in the real-time domain Component oriented programming, Generative Programming, Model Driven Engineering, Formal Verification, etc. 5

8. Successful Stories Introduction Shipboard computing US navy Zumwalt-class Destroyer 5mio lines of Java code Red Hat Linux, RT GC the key part Avionics 787 Dreamliner saves 900kgs of weight A380 saves a half of the processing units Financial Information Systems 100 milliseconds deadlines Thomson Reuters Market Data System (powered by SUN RTS Java) 6

9. Why Java? Introduction Java Easy to use, familiar Popular programming language Libraries Portable across platforms But – non-predictable RTSJ – Real-time Specification for Java Making Java predictable Thread and Memory model 7

10. RTSJ Illustration Example Introduction SweetFactory A helloworld RTSJ example developed by IBM [GHMS07] Output statistics control, reporting anomalies and wrong values Real-time and non-real-time concerns coexist in the system RTSJ Implementation How to express RTSJ? RTSJ concerns mixed with system architecture 8

12. NoheapRealtime threads

13. Cannot be preempted by Garbage Collector

15. Bootstrapping threads

17. Objects are collected when the application terminates (live forever…)

18. Memory Scope

19. Size is fixed and pre-declared

21. Communication Rules

23. Non-intuitive rules and restrictions

24. Functional code tangled by the RTSJ code

25. Introducing a new programming style11

27. Separation of Concerns

28. Runtime Infrastructure

29. Component Container

30. Generative programming

31. Container Implementation automatically generated

33. State of the Art Outline Introduction State of the Art Proposal Validation Conclusion 13

35. Component Frameworks for Real-time Systems State of the Art Separation of Real-time and Functional Concerns AADL [FLV06], AdaCCM [PMPL08] Development Methodology AADL [FLV06], AdaCCM [PMPL08] Component-Oriented Containers SOFA HI [MWP+08] Active/Passive Components Fractal [BCL+06] Formalization Support Fractal in Alloy [MS08] Towards a specific programming language AdaCCM [PMPL08] Matured component models employed 15

36. Component Frameworks for RTSJ State of the Art CBSE Criterions Weak Component Models Only event-oriented Compadres [HGCK07], Golden Gate [DBC+04] Matured Model Etienne et al. [ECB06] Inspired by Fractal Development Methodology Compadres [HGCK07] Features not supported Component-Oriented Containers Formalization of the model 16

37. Component Frameworks for RTSJ State of the Art RTSJ criterions Memory model “one memory area per component” No other granularity or flexibility Compadres [HGCK07] No support for heap memory Etienne et al. [ECB06] Thread model Active/Passive components Etienne et al. [ECB06] No abstractions of RTSJ complexities provided Development process not facilitated RTSJ concepts not separated, this hinders reuse of components No support for cross-memory and cross-thread communication 17

38. Proposal Outline Introduction State of the Art Proposal Validation Conclusion 18

39. Our Goal Our Philosophy RTSJ considerably influences the architecture of the system, therefore has to be considered earlier than during the implementation Ultimate Goal: Component Framework for RTSJ Isolate RTSJ–related properties in clearly identified entities Manipulate RTSJ-concerns during the development lifecycle Separation of Concerns State of the Art 19

41. Runtime Infrastructure Generation

42. Methodology

43. Metamodel Formalization

46. Hierarchical model

48. Active and Passive Components

49. Implement functional services

50. Domain Component

52. Abstracting the complexities of real-time development

53. Evaluate RTSJ compatibility earlier than “after the implementation”23

57. Methodology how to gradually construct and merge design components with functional architecture

58. Defining and distinguishing between real-time and non-real-time parts of the system

59. Designing RTSJ concerns independently from the rest of the system26

61. Alloy specification languageabstractsigComponent { interface: setInterface superComponent : setComposite } sigComposite in Component { subComponents : setComponent } sigPrimitive inComponent { } sig FunctionalComponent { } fact { all f : FunctionalComponent| f in Primitive or f in Composite and not f in (Primitive and Composite) } 27

62. Proposal fact EveryCompHasMemory { all f : Component | one m: MemoryArea| f inm.^subComponent } Architecture Validation Process Composition Rules Validation Consistence with RTSJ RTSJ communication Patterns Formalized in the model The process facilitates Incremental design Reasoning about the system before starting with implementation Using the Formalized Metamodel 28

63. Proposal Outline Introduction State of the Art Proposal RTSJ-specific Metamodel SOLEIL Design Framework HULOTTE Implementation Framework Validation Conclusion 29

64. HULOTTE Implementation Framework Proposal Motivation Keep components also at the implementation layer Distinguish functional and domain components Implementation of Domain Components Component-Oriented Containers Hidden Intercepting and control mechanisms to manage RT concerns Component Refinement 30

65. HULOTTEMetamodel Proposal Metamodel Specifics Application and Container Level Fractal Component model concepts Container level Implements Domain Components Container architectures Component Refinement Process 31 Application Level Container Level Container Level Application Level Container Level

66. Component Refinement Example Proposal 32 Application Level Container Level

67. Component Refinement Example cont. Proposal 33 Application Level Container Level

69. Hulotte internal is implemented using CBSE

71. Mid-end: Step-by-step architecture refinement

73. Validation Outline Introduction State of the Art Proposal RTSJ-specific Metamodel SOLEIL Design Framework HULOTTE Implementation Framework Validation Conclusion 36

75. SweetFactory

76. Real-time Collision Detector

77. Ambient and Distributed Programming in Hulotte

78. Goals

79. Performance Evaluation

80. Software Engineering Perspectives

81. Extendability Towards Different Domains37

83. Performance Overhead

84. Comparing different Implementations

85. OO - IBM’s object-oriented

86. SOLEIL - SOLEIL implemented and optimized implementations38

87. Validation Performance Benchmarks Measuring overhead of the framework Different levels of optimization Memory Footprint Memory Footprint 5% Execution Time Distribution 39

88. Validation Real-time Collision Detector Real-Time Collision Detector Algorithm computing collision courses of aircraft in real-time A software engineering challenge A well-known Real-time Java benchmark [PFHV04, ABG+08] Goals of the Case Study Evaluation on a large real-life application Comparison with the state-of-the-art approaches Componentization of the Application 40

89. Validation Realtime Collision Detector RCD Architecture Results RTSJ concerns separated from the functional logic of the system Simplified design and development No trade-offs caused by RTSJ Separation of concerns 41 Refined Architecture

90. Validation Ambient and Distributed Programming Goals Evaluate SOLEIL&HULOTTE in a more general perspective Face challenges from different domains Targeted Domains Distributed Programming To provide a transparent implementation of a distributed system Ambient Programming To provide implementation of ambient services 42

91. Validation Distributed Programming A new domain component DistributedNode Execution infrastructure Distribution support implemented Transparent implementation for the functional components Using RTZenmiddleware [RZP+05] RTZen Stubs/skeletons 43

92. Outline Introduction State of the Art Proposal RTSJ-specific Metamodel SOLEIL framework HULOTTE framework Validation Conclusion and Perspectives 44

94. Domain component implementation

95. Component-Refinement Process

96. Automatic instantiation of runtime infrastructures

97. Evaluation [2,5,6,7]

98. Various case studies

99. Overhead measurementsFacilitate development of RTSJ systems 45

100. Conclusion Selected Publications International Conferences FrédéricLoiret, Michal Malohlava, AlešPlšek, Philippe Merle, Lionel Seinturier. Constructing Domain-Specific Component Frameworks through Architecture Refinement. SEAA 2009 AlešPlšek, FrédéricLoiret, Philippe Merle, Lionel Seinturier. A Component Framework for Java-based Real-time Embedded Systems, Middleware 2008 AlešPlšek, JiříAdámek. Carmen: Software Component Model Checker. QoSA 2008 AlešPlšek, Philippe Merle, Lionel Seinturier. A Real-Time Java Component Model, ISORC 2008 International Workshops Tomas Kalibera, Jeff Hagelberg, FilipPizlo, Ales Plsek, Ben Titzer, Jan VitekCDx: A Family of Real-time Java Benchmarks. JTRES 2009 Michal Malohlava, AlešPlšek, FrédéricLoiret, Philippe Merle and Lionel Seinturier. Introducing Distribution into a RTSJ-based Component Framework, JRWRTC 2008 AlešPlšek, Philippe Merle, Lionel Seinturier. Ambient-Oriented Programming in Fractal. ECOOP Workshop 2007 46

101. Conclusion Contributions cont. Developed Software SOLEILandHULOTTEFrameworks Alloy: 400 signatures, facts, and predicates in 4.5KLoC 55kLoC Available at http://adam.lille.inria.fr/soleil/ Real-time Collision Detector 30kLoC Available at www.ovj.org/cdx Works influenced by the Dissertation Annotation Framework for Domain-Specific Component Applications [NL09] Homogenous validation of architectural and implementation concepts towards OCL rules Domain Components expressed as annotations 47

102. Conclusion Future Work Short-Term Perspective Taxonomy of Domain Components Resolve conflicts and dependencies between different Domain Components Long-Term Perspective Run-time Adaptation of RTSJ-based System Reconfiguration support specified by domain components Reconfiguration in the context of RTSJ Model-Checking of RTSJ-based Components 48

103. Questions Conclusion 49

104. Conclusion Bibliography 50

105. Conclusion Bibliography cont. 51