Soleil: A Component Framework for RTSJ

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

Introduction
Context
Domains
Component-based Software Engineering (CBSE)
Real-time Java Programming (RTSJ)
Our Approach
Solution through Software Engineering Methods
High-Level Abstractions
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.
2

Introduction
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
3

Introduction
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
4

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

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

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

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

Introduction
RTSJ Thread Model
2 New Types of Threads
Realtime threads
NoheapRealtime threads
Cannot be preempted by Garbage Collector
No heap memory access
9
Thread Management Issues
Priorities setting and management
Bootstrapping threads
Cross-ThreadCommunication

Introduction
RTSJ Memory Model
Memory Management
Immortal Memory
Objects are collected when the application terminates (live forever…)
Memory Scope
Size is fixed and pre-declared
Lifetime of objects in the Scope
10
Memory Management Issues
Cross-Scope communication
Communication Rules
RTSJ patterns

Introduction
Lessons Learned from Real-Time Java
Advantages
1/9/90 Real-time Rule
Standard Java advantages
hard-, soft-, and non-real-time cooperation
Complexities
Error-prone process
Non-intuitive rules and restrictions
Functional code tangled by the RTSJ code
Introducing a new programming style
11

Remedy?
Component-based Software Engineering (CBSE)
Higher levels of abstraction
Separation of Concerns
Runtime Infrastructure
Component Container
Generative programming
Container Implementation automatically generated
Adaptation Support
Component Framework for Real-time Java
To shield developers from the RTSJ complexities
Introduction
12

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

State of the Art
Component Frameworks for Real-time Systems
AADL[FLV06], AdaCCM[PMPL08] , SOFA HI [MWP+08]
Component Frameworks for Real-time Java Systems
Compadres [HGCK07], Etienne et al. [ECB06], Golden Gate [DBC+04]
State of the Art
14

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

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
Compadres [HGCK07]
Features not supported
Formalization of the model
16

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
Thread model
Active/Passive components
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

Proposal
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
18

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

Proposal
SOLEIL Design Framework
HULOTTE Implementation Framework
SOLEILMetamodel
Contributions – Big Picture
Domain Component
RTSJ abstractions
20
Domain Component Implementation
Runtime Infrastructure Generation
Methodology
Metamodel Formalization
Validation Support

Proposal
Outline
Introduction
State of the Art
Proposal
SOLEILMetamodel
Validation
Conclusion
21

SOLEILMetamodel
Proposal
22
Metamodel
Fractal Component Model inspired
Hierarchical model
Component sharing
New concepts:
Functional Component
Active and Passive Components
Implement functional services
Domain Component
Represents non-functional services

RTSJ-specificDomain Components
Proposal
RTSJ Domain Components
For each domain, rules and restriction of its application are defined, in compliance with RTSJ
Advantages
Real-Time concerns at the architectural level as components
Abstracting the complexities of real-time development
Evaluate RTSJ compatibility earlier than “after the implementation”
23

Domain Components in SOLEIL
Proposal
Memory Domains
Composition & Communication constraints
to reason about the conformance to RTSJ
Thread Domains
24
Different assemblies of real-time components
Adapting systems for different real-time conditions.

Proposal
Outline
Introduction
State of the Art
Proposal
RTSJ-specific Metamodel
Validation
Conclusion
25

SOLEIL Framework
Proposal
Design Methodology
Methodology how to gradually construct and merge design components with functional architecture
Defining and distinguishing between real-time and non-real-time parts of the system
Designing RTSJ concerns independently from the rest of the system
26

Proposal
Metamodel Formalization
Motivation
Exact definition of the component model and its composition rules
Alloy specification language
abstractsigComponent {
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

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

Proposal
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
29

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

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

Component Refinement Example
Proposal
32
Application Level
Container Level

Component Refinement Example cont.
Proposal
33
Application Level
Container Level

HULOTTEToolchain
Proposal
34
Key features:
Step-wise refinement process
Hulotte internal is implemented using CBSE
Fully extensible / provides a plugin-oriented architecture
Internal structure & compilation flow:
Front-end: Process a description of a functional architecture stored in ADL
Mid-end: Step-by-step architecture refinement
Back-end: Container Implementation Generation

Proposal
Generation of Container Implementations
Reducing overhead of the framework
A tradeoff between flexibility and performance
3 levels of optimization
Soleil
Full componentization of Execution
Infrastructure
Merge All
Membrane and functional component merged
No reconfiguration at the membrane level
Ultra Merge
The application merged into one class
Static infrastructure, No reconfiguration
35

Validation
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
36

Validation
Validation
Case studies
3 Case Studies
SweetFactory
Real-time Collision Detector
Ambient and Distributed Programming in Hulotte
Goals
Performance Evaluation
Software Engineering Perspectives
Extendability Towards Different Domains
37

SweetFactory
Validation
SweetFactory[GHMS07]
Case Study Goal
Componentize in SOLEIL
Performance Overhead
Comparing different Implementations
OO - IBM’s object-oriented
SOLEIL - SOLEIL implemented and optimized implementations
38

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

Validation
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

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

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

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

Outline
Introduction
State of the Art
Proposal
SOLEIL framework
HULOTTE framework
Validation
Conclusion and Perspectives
44

Contributions
Conclusion
SOLEIL Design Framework[2,4]
a matured component model - Fractal, in the world of real-time programming
Domain Components and RTSJ abstractions
Explicit separation of functional and real-time concerns
RTJS formalization
HULOTTE Implementation Framework [1]
Domain component implementation
Component-Refinement Process
Automatic instantiation of runtime infrastructures
Evaluation [2,5,6,7]
Various case studies
Overhead measurements
Facilitate development of RTSJ systems
45

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

Conclusion
Contributions cont.
Developed Software
SOLEILandHULOTTEFrameworks
Alloy: 400 signatures, facts, and predicates in 4.5KLoC
55kLoC
Available at http://adam.lille.inria.fr/soleil/
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

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

Questions
Conclusion
49

Conclusion
Bibliography
50

Conclusion
Bibliography cont.
51

http://rtjava.blogspot.com	174
http://www.slideshare.net	3
http://rtjava.blogspot.fr	3
http://rtjava.blogspot.com.au	2
http://rtjava.blogspot.co.uk	1
http://rtjava.blogspot.com.br	1

Soleil: A Component Framework for RTSJ

by Ales Plsek on Sep 22, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 184

Statistics

Soleil: A Component Framework for RTSJ — Presentation Transcript