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 ADAMUniversité de Lille, France

Supervisors: Prof.Lionel Seinturier Dr.Philippe Merle

14.9.2009Lille, France

Ales Plsek, PhD Defense, 14/09/2009

ContextDomains

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.

Introduction

2


Outline

Introduction

State of the Art

Proposal

Validation

Conclusion

Introduction

3


Outline

Introduction

State of the Art

Proposal

Validation

Conclusion

Introduction

4


Why Real-Time?

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.

Introduction

5


Successful Stories

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)

Introduction

6


Why Java?

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

Introduction

7


RTSJ Illustration Example

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

Introduction

8


RTSJ Thread Model Introduction

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-Thread

Communication


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

Introduction

10

Memory Management Issues Cross-Scope

communication Communication Rules RTSJ patterns


Lessons Learned from Real-Time Java

Advantages 1/9/90 Real-time Rule Standard Java advantages hard-, soft-, and non-real-time cooperation

Introduction

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


Outline

Introduction

State of the Art

Proposal

Validation

Conclusion

State of the Art

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

State of the Art


Component Frameworks for RTSJCBSE 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

State of the Art


Component Frameworks for RTSJRTSJ 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

communication17

State of the Art


Outline

Introduction

State of the Art

Proposal

Validation

Conclusion

Proposal

18


Our GoalOur 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


HULOTTE Implementation Framework

SOLEIL Design Framework

SOLEIL Metamodel

Contributions – Big Picture

Domain Component

RTSJ abstractions

Proposal

20

Methodology Metamodel

Formalization Validation

Support

Domain Component Implementation

Runtime Infrastructure Generation


Outline

Introduction

State of the Art

Proposal

SOLEIL Metamodel



Validation

Conclusion

Proposal

21


SOLEIL MetamodelProposal

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-specific Domain Components

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”

Proposal

23


Domain Components in SOLEIL

Thread Domains

Memory Domains

Proposal

24

Composition & Communication constraints to reason about the conformance

to RTSJ

Different assemblies of real-time components Adapting systems for different real-time

conditions.


OutlineIntroduction

State of the Art

Proposal

RTSJ-specific Metamodel



Validation

Conclusion

Proposal

25


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

SOLEIL FrameworkProposal

26


Metamodel Formalization

abstract sig Component { interface: set Interface superComponent : set Composite}

sig Composite in Component { subComponents : set Component}sig Primitive in Component { }

sig FunctionalComponent { }

fact { all f : FunctionalComponent | f in Primitive or f in Composite and not f in (Primitive and

Composite)}

Proposal

Motivation Exact definition of the component

model and its composition rules Alloy specification language

27


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 MetamodelProposal

28

fact EveryCompHasMemory { all f : Component | one m: MemoryArea | f in m.^subComponent}


OutlineIntroduction

State of the Art

Proposal




Validation

Conclusion

Proposal

29



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

Proposal

30


HULOTTE Metamodel

Metamodel Specifics Application and Container Level

Fractal Component model concepts

Container level Implements Domain Components Container architectures Component Refinement Process

Proposal

31

Container Level

Application Level

Container Level

Container Level

Application Level


Component Refinement ExampleProposal

32

Ap

plicati

on

Level

Con

tain

er

Level


Component Refinement Example cont.Proposal

33

Ap

plicati

on

Level

Con

tain

er

Level


HULOTTE ToolchainProposal

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


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

Proposal

35


OutlineIntroduction

State of the Art

Proposal




Validation

Conclusion

Validation

36


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

Validation

37


SweetFactory

SweetFactory [GHMS07]

Case Study Goal Componentize in SOLEIL Performance Overhead

Comparing different Implementations

OO - IBM’s object-oriented SOLEIL - SOLEIL implemented

and optimized implementations

Validation

38


Performance Benchmarks

Measuring overhead of the framework Different levels of optimization

Memory Footprint

Memory Footprint

Execution Time Distribution

Validation

39

5%


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

Validation

40


Realtime Collision Detector

Results RTSJ concerns separated from

the functional logic of the system

Simplified design and development

No trade-offs caused by RTSJ Separation of concerns

RCD Architecture

Validation

41

Refined Architecture


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

Validation

42


Distributed Programming

A new domain component DistributedNode

Execution infrastructure Distribution support implemented Transparent implementation for the functional components Using RTZen middleware [RZP+05]

RTZen Stubs/skeletons

Validation

43


Outline

Introduction

State of the Art

Proposal


SOLEIL framework

HULOTTE framework

Validation

Conclusion and Perspectives

44


Contributions 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 Development Methodology

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

Conclusion

45


Selected PublicationsInternational Conferences1. Frédéric Loiret, Michal Malohlava, Aleš Plšek, Philippe Merle,

Lionel Seinturier. Constructing Domain-Specific Component Frameworks through Architecture Refinement. SEAA 2009

2. Aleš Plšek, Frédéric Loiret, Philippe Merle, Lionel Seinturier. A Component Framework for Java-based Real-time Embedded Systems, Middleware 2008

3. Aleš Plšek, Jiří Adámek. Carmen: Software Component Model Checker. QoSA 2008

4. Aleš Plšek, Philippe Merle, Lionel Seinturier. A Real-Time Java Component Model, ISORC 2008

International Workshops5. Tomas Kalibera, Jeff Hagelberg, Filip Pizlo, Ales Plsek, Ben Titzer,

Jan Vitek CDx: A Family of Real-time Java Benchmarks. JTRES 2009

6. Michal Malohlava, Aleš Plšek, Frédéric Loiret, Philippe Merle and Lionel Seinturier. Introducing Distribution into a RTSJ-based Component Framework, JRWRTC 2008

7. Aleš Plšek, Philippe Merle, Lionel Seinturier. Ambient-Oriented Programming in Fractal. ECOOP Workshop 2007

Conclusion

46


Contributions cont.Developed Software

SOLEIL and HULOTTE Frameworks 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

Conclusion

47


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

Conclusion

48


QuestionsConclusion

49


BibliographyConclusion

50

[PFHV04] F. Pizlo, J. M. Fox, D. Holmes, and J. Vitek. Real-Time Java Scoped Memory Design Patterns and Semantics. ISORC 2004

[ABG+08] Joshua Auerbach, David F. Bacon, Rachid Guerraoui, Jesper Honig Spring, and Jan Vitek. Flexible Task Graphs: a unified restricted thread programming model for Java. LCTES 2008

[GHMS07] C. Gough, A. Hall, H. Masters, and A. Stevens. Real-Time Java: Writing and Deploying Real-Time Java Applications, 2007.

[PMPL08] Lopez Martinez Patricia, Drake Jose M., Pacheco Pablo, and Medina Julio L. Ada-ccm: Component-based technology for distributed real-time systems. CBSE 2008

[MWP+08] Prochazka M., R. Ward, Tuma P., Hnetynka P., and Adamek J. A Component-Oriented Framework for Spacecraft On-Board Software. DASIA 2008

[NL09] Carlos Noguera and Frederic Loiret. Checking Architectural and Implementations Constraints for Domain-Specific Component Frameworks using Models. SEAA 2009

[HGCK07] J. Hu, S. Gorappa, J. A. Colmenares, and R. Klefstad. Compadres: A Lightweight Component Middleware Framework for Composing Distributed, Real-Time, Embedded Systems with Real-Time Java. Middleware 2007

[RZP+05] Krishna Raman, Yue Zhang, Mark Panahi, Juan A. Colmenares, Raymond Klefstad, and Trevor Harmon. RTZen: Highly Predictable, Real-Time Java Middleware for Distributed and Embedded Systems. Middleware 2005

[ECB06] J.P. Etienne, J. Cordry, and S. Bouzefrane. Applying the CBSE Paradigm in the Real-Time Specification for Java. JTRES 2006


Bibliography cont.Conclusion

51

[DBC+04] D. Dvorak, G. Bollella, T. Canham, V. Carson, V. Champlin, B. Giovannoni, M. Indictor, K. Meyer, A. Murray, and K. Reinholtz. Project Golden Gate: Towards Real-Time Java in Space Missions. ISORC 2004.

[FLV06] Peter H. Feiler, Bruce A. Lewis, and Steve Vestal. The SAE Architecture Analysis and Design Language (AADL) a standard for engineering performance critical systems. 2006.

[BCL+06] E. Bruneton, T. Coupaye, M. Leclercq, V. Quéma, and J.B. Stefani. The FractalComponent Model and its Support in Java. Software: Practice and Experience, 2006.

[MS08] Philippe Merle and Jean-Bernard Stefani. A formal specification of the Fractalcomponent model in Alloy . In INRIA technical report, 2008

soleil: a component framework for rtsj

Technology

rtsj concerns

express rtsj

software engineering

nonrealtime concerns

model driven engineering

java systemsaleplekinria

noheaprealtime threads

bootstrapping threads