OMG TECHNICAL MEETING
SPECIAL EVENT
Component Workshop
Toward the next component model generation for
distributed, real-time and embedded systems
Monday
Afternoon, 1300 - 1800, June 17, 2013
|
Introduction |
Agenda | Hotel
Information |
Registration |
All
Special Events |
Become A Sponsor |
AGENDA
| 1300
- 1310 |
Welcome
– Introduction to OMG
& Its Component Standards |
| Object
Management Group |
| The day begins with
presentations covering core Component concepts.
Presentations in the second session show how standards-based
Component software is used in mission-critical DRE
applications. The day concludes with an extended session on
the proposed next-generation Unified Component Model (UCM).
This new initiative will build on established OMG
Component-Based Software Engineering and modeling standards;
attendees will get an early insight into the thinking
driving the new proposals, and learn how they can influence
the future direction of this important specification. |
|
|
SESSION
1: Foundation Concepts - Component, Container,
Connector
- Session Chair:
Nawel Hamouche, Ph.D, PrismTech |
| 1310
- 1335 |
Connectors
: A Mechanism to Extend CCM with New Ports |
| Virginie
Watine, THALES |
| This session will
introduce the DDS4CCM specification adopted recently with a
specific focus on the Generic Interaction Support (extended
ports and connectors) that was incorporated into the
standard. This GIS was designed not to be dependent on any
DDS specificity, with the goal of being usable for any kind
of CCM port (i.e. not only those allowing interaction though
DDS). Due to its full genericity, it was then moved to the
CCM specification and used to define other types of ports
(AMI, events, and others) that will be detailed in other
talks. As this mechanism presents a great potential, it is
one strong pillar on which the renewed component model will
be built. |
|
|
| 1335
- 1400 |
Asynchronous
Invocations through Connectors, Custom DDS Connectors, and
the IDL to C++11 Language Mapping |
| Johnny
Willemsen, Remedy IT |
| Connectors are a
powerful concept as part of current and future component
frameworks. This session will demonstrate of how connectors
can be used to add asynchronous invocation support to a
component framework and how it can be used to provide custom
DDS connectors. Secondly we will present an overview of the
recently adopted IDL to C++11 Language Mapping. This new
IDL2C++11 mapping greatly simplifies the life for a
component developer compared to the IDL to C++ mapping. We
will highlight several of the simplifications and how this
can be used for a C++11 implementation of a component
standard. |
|
|
| 1400
- 1425 |
Robotics
Technology Component Specification |
| Geoffrey
Biggs and Noriaki Ando, AIST |
| The OMG Robotic
Technology Component (RTC) specification defines a component
model for distributed control applications including robotic
technology (RT) based systems. By extending the
general-purpose component model of UML with domain-specific
structural and behavioral design patterns, RTCs can serve as
powerful building block in an RT system. After adopted the
specification in 2008, various implementations have been
developed by several vendors. This talk will introduce the
specification, implementations, its applications, and issues
to be discussed for the future RTC or more generic component
specification. |
|
|
| 1425
- 1450 |
Finite
State Machine for Robotics Technology Component (FSM4RTC)
RFP |
| Makoto
Sekiya and Toyotaka Torii, Honda |
| The OMG Robotic
Technology Component (RTC) specification defines a component
model for distributed control applications including robotic
technology (RT) based systems. By extending the
general-purpose component model of UML with domain-specific
structural and behavioral design patterns, RTCs can serve as
powerful building block in an RT system. After adopted the
specification in 2008, various implementations have been
developed by several vendors. This talk will introduce the
specification, implementations, its applications, and issues
to be discussed for the future RTC or more generic component
specification. |
|
|
| 1450
- 1505 |
Afternoon
Refreshments |
|
|
SESSION
2: Use Cases
- Session
Chair: Johnny Willemsen, Remedy IT |
| 1505
- 1530 |
MyCCM
a Component Framework Tailored for RTE Systems |
| Olivier
Hachet, THALES |
| Thales has invested
for several years in the promotion and deployment of
component based software engineering (CBSE) based on the
lightweight CCM standard. This presentation will explain the
progression for the adoption of CBSE from its contribution
to the LwCCM standard up to the deployment of the MyCCM
framework on several Thales domains today. In many programs,
the targeted environments were constrained by strong
footprint or real-time requirements that have implied
several pragmatic adaptations to fit these constraints that
were not reachable natively by the LwCCM standard. These
adaptations and the associated return of experience will be
an input for future LwCCM evolutions toward a more real-time
and middleware agnostic component model. |
|
|
| 1530
- 1555 |
F6COM:
A Case Study in Extending Container Services through
Connectors |
| Marcel
Smit, RemedyIT |
| Component-Based
programming models are well-suited for the design,
development and deployment off large, distributed, real-time
and embedded (DRE) component based applications. Component
framework implementations, like CIAO (which implements the
OMG's CORBA Component Model (CCM) specification), can be
used to develop such applications. Together with DAnCE
(which implements the OMG's "Deployment and
Configuration of Component-based Distributed Applications
Specification") and modeling tools the system
development team has a powerful software development kit at
hand.
Although CCM is already suitable for developing
distributed, real-time and embedded applications, it can be
improved in some areas:
- CCM is implicitly bound to the CORBA specification.
Even in a deployment environment where no CORBA is used,
the CCM infrastructure does use CORBA for its own
communication.
- CCM is currently silent about threading models. The
CCM implementation is therefor responsible for
delivering suitable threading models. The CCM
specification should specify the possible threading
models and how they can be configured at run-time.
Possible threading models should range from a simple
single-threaded, non re-entrant model to more
sophisticated multi-threaded models.
- CCM lacks support for a standardized way to schedule
one-time and periodic timers. This again is left to the
CCM implementation, leading to interoperability issues.
- CCM does not have any notion for components
interacting with physical devices using blocking I/O
operations. Interactions between I/O operations and the
threading model used in a component are often realized
in an ad-hoc manner.
This presentation shows how the above issues were
addressed in the Information Architecture Platform (IAP)
being developed for the DARPA System F6 Program. IAP is a
vertically integrated software platform and includes a
software component framework. The F6 component framework
resolved the issues by using Generic Interaction Support
(GIS). By using GIS, the F6 component framework now delivers
a flexible request-reply communication paradigm, a
configurable component messaging framework, and has the
ability to schedule timer events.
All this together, the DARPA System F6 Program component
model is a concrete step in the direction of a Unified
Component Model (UCM). |
|
|
| 1555
- 1620 |
Architecting
Composite Component Systems for Heterogeneous Environments
with Open Standards |
| Derek
Dominish, DSTO |
| With the recent
adoption of a service oriented architectural (SOA) approach
to application development within defence worldwide there is
a need to provide architectural guidance coupled with
infrastructure mechanisms to assist developers through the
implementation process. Applications developed under a SOA
approach are more akin to an assemblage rather than the more
traditional development methodology of construct and
execute. With the introduction of newer style C2 platforms
into service within the Australian Defence Force (ADF),
including the future delivery of both the JSF and P8
aircraft on the horizon, all of which contain middleware
based SOA mission systems, it is expected that SOA will
dominate future air defence offerings. Furthermore there is
a growing collection of common services to aid in the
integration of such systems into the tactical defence
environment. However there exists the need to manage the
availability of these services and their usage by
applications and systems through a common approach to
infrastructure, configuration and deployment. This
presentation will firstly describe how an application can be
assembled with separate and distinct service components to
form a composite application and then secondly how these
components can be interconnected through a common patterned
approach to infrastructure that incorporates elements of CCM
with its connectors through a Gestalt patterned
approach. This common infrastructure, based on OMG open
standards, is necessary to manage the availability,
configuration and deployment of hosted components. This
change of emphasis to a patterned approach to application
composition and assembly brings with it some unique
challenges for both mission system architects and developers
alike. |
|
|
| 1620
- 1645 |
Using
SysML and Assurance Case in a Robotic Application: Case
Study & Tool Demonstration |
| Kenji
Hiranabe, Change Vision, Inc. |
| In this session, we
share our experience on how to effectively use both SysML
and Assurance Case (D-Case) for a sample robotic embedded
system. SysML describes the context, requirements, structure
and behavior of the domain, whereas D-Case describes
dependability goals which should be fulfilled by the system,
with strategies, and evidences to achieve the goal. We
explain our process of using the both visual languages in
parallel to construct the system and dependability
accountability at the same time with a short demonstration
of our SysML tool, Astah SysML. The sample system is an RTC
(Robotic Technology Component)-based robotic application,
using Roomba (vacuum cleaner robot) and Kinect. |
|
|
|
|
| 1645
- 1700 |
Dynamically
Scriptable Distributed Components in Lua using DDS |
| Dr.
Rajive Joshi, Real-Time Innovations, Inc. |
| Scripting languages
are widely used in the software industry to improve
productivity by bringing the best of both worlds: flexible
and extensible scripting and high performance where
necessary. Multi-language applications combine a
"kernel" of core functionality written in a
compiled language such as C or C++ and "scripts"
written in a higher-level language such as Python and Lua.
This presentation describes a Lua-DDS Component Model to
script flexible and highly reconfigurable distributed
components. Lua is a fast, lightweight, portable,
extensible, and stable scripting language, which can be
readily embedded in native C/C++ programs. Component
business logic is written in Lua whereas DDS-specific
activities, such as creating participants, topics,
DataReaders, DataWriters are managed by the
"container", which is nothing but RTI's XML-Based
application prototyper with an embedded Lua engine. The
container provides a simple reactive programming model to
read/write from/to the DDS bus. No code
generation/compilation is necessary, thanks to Lua Tables.
Additionally, the container supports run-time updates to the
component business logic by simply editing the Lua scripts.
Join us and find out why a tiny language that is older
than Java might be your next best friend. |
|
|
SESSION
3: Towards a Unified Component Model
- Session
Chair: Virginie Watine, Thales |
| 1700
- 1725 |
A
Middleware-agnostic Unified Component Model |
Nawel
Hamouche, Ph.D, PrismTech
Didier Becu, Gaetan Pruvost, Olivier Hachet, Thales
Johnny Willemsen, Remedy IT |
| Over the past few
years, middleware technologies has proven their value to
build an interoperable and networked world. This has been
achieved mainly by providing a platform and network
independence to the applications. Nowadays,
middleware-independence comes as the next requirement for
flexibility and reusability in distributed systems
development. Middleware independence allows user and
organizations to embrace new middleware technologies as the
market innovates with minimal impact on their applications,
thereby eliminating the threat of technology and vendor
lock-in. The benefit is clearly to protect their technology
investment and reduce time-to-market with new innovations.
Applied to distributed component-based architectures the
benefits are strongly increased.
The Lightweight CORBA Component Model is a distributed
component-based model that is platform and programming
language independent. It is specifically targeted at
resource-constrained environments. Its open, generic and
flexible architecture enables seamless integration of
multiple middleware technologies whatever their patterns are
– service-centric, data-centric... The DDS for Lightweight
CCM specification is a good illustration of LwCCM‘s
ability to host different middleware technologies. Such
flexibility is achieved through the concept of Connector.
Connectors decouple the component framework from the
underlying communication middleware technology. Despite this
interesting capability, the LwCCM remains strongly dependent
on its historical middleware: CORBA. Even if CORBA is not
necessarily used at the application level, the LwCCM
internal architecture remains strongly CORBA-aware, as the
deployment of such applications still require the deployment
of a CORBA Object Request Broker.
This presentation aims to feed the discussions about the
future evolution of the LwCCM towards the new Unified
Component Model (UCM) standard. The presentation will,
first, precisely highlight the LwCCM-to-CORBA dependency
points in order to introduce a set of requirements for the
UCM standard. Then, it will analyze the impact of these
requirements on the LwCCM architecture from both the
end-user and the implementer perspectives. |
|
|
| 1725
- 1750 |
Specifying
a Unified Component Model with UML and its Extension
Mechanism |
| Ansgar
Radermacher, CEA |
| This presentation
describes an approach based on the UML component model
enriched with the profiles MARTE (modeling and analysis of
RT/E systems) and FCM (Flex-eWare component model). The
latter had the objective to unify the component models of
CCM and Fractal. The idea is to support a set of concepts
that enable to create application components that are
independent of the underlying operating system and
interaction communication mechanisms. This is achieved by
means of flexibility for the following concepts: a generic
interaction support, ports adapted to these interaction
mechanisms and configurable container services. As such, it
shares many objectives with the upcoming OMG unified
component model.
We present the foundation concepts: we can show how to
model components, containers and connectors by means of UML
components, interception rules and UML connectors referring
to dedicated interaction components. We show some examples
of interaction components and container services modeled
with this approach. For each UML element, we outline the
corresponding element in the current CCM specification with
the DDS4CCM and QoS4CCM extensions. |
|
|
| 1750
- 1800 |
Wrap
Up & Get Involved |
| Object
Management Group |
|
|
NOTE:
If you register for the Technical Meeting Week, you do not have
to pay the additional fee(s) to attend any or all of the special
events. If you register only for special events, the special fees
apply. |
