Upload
ales-plsek
View
1.243
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
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
Ales Plsek, PhD Defense, 14/09/2009
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
Introduction
3
Ales Plsek, PhD Defense, 14/09/2009
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
Introduction
4
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
State of the Art
13
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
Outline
Introduction
State of the Art
Proposal
Validation
Conclusion
Proposal
18
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
Outline
Introduction
State of the Art
Proposal
SOLEIL Metamodel
SOLEIL Design Framework
HULOTTE Implementation Framework
Validation
Conclusion
Proposal
21
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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.
Ales Plsek, PhD Defense, 14/09/2009
OutlineIntroduction
State of the Art
Proposal
RTSJ-specific Metamodel
SOLEIL Design Framework
HULOTTE Implementation Framework
Validation
Conclusion
Proposal
25
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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}
Ales Plsek, PhD Defense, 14/09/2009
OutlineIntroduction
State of the Art
Proposal
RTSJ-specific Metamodel
SOLEIL Design Framework
HULOTTE Implementation Framework
Validation
Conclusion
Proposal
29
Ales Plsek, PhD Defense, 14/09/2009
HULOTTE Implementation Framework
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
Component Refinement ExampleProposal
32
Ap
plicati
on
Level
Con
tain
er
Level
Ales Plsek, PhD Defense, 14/09/2009
Component Refinement Example cont.Proposal
33
Ap
plicati
on
Level
Con
tain
er
Level
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
OutlineIntroduction
State of the Art
Proposal
RTSJ-specific Metamodel
SOLEIL Design Framework
HULOTTE Implementation Framework
Validation
Conclusion
Validation
36
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
Performance Benchmarks
Measuring overhead of the framework Different levels of optimization
Memory Footprint
Memory Footprint
Execution Time Distribution
Validation
39
5%
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
Outline
Introduction
State of the Art
Proposal
RTSJ-specific Metamodel
SOLEIL framework
HULOTTE framework
Validation
Conclusion and Perspectives
44
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
QuestionsConclusion
49
Ales Plsek, PhD Defense, 14/09/2009
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
Ales Plsek, PhD Defense, 14/09/2009
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