Transcript No Slide Title

Future of CORBA for Distributed
Real-time & Embedded Systems
Thursday, July 16, 2015, ICALEPCS
Douglas C. Schmidt
[email protected]
www.dre.vanderbilt.edu/~schmidt/
Institute for Software
Integrated Systems
Vanderbilt University
Nashville, Tennessee
Distributed Real-time & Embedded (DRE) Systems
Present & Future
The Past
Stand-alone real-time &
embedded systems
• Stringent quality of service (QoS)
demands
• e.g., latency, jitter, footprint
• Resource constrained
Enterprise distributed real-time & embedded (DRE)
systems
• Network-centric “systems of systems”
• Stringent simultaneous QoS demands
• e.g., dependability, security, scalability, etc.
• Dynamic context
This talk focuses on technologies for enhancing DRE system QoS, productivity, & quality
2
Diverse Mission-Critical DRE System Characteristics
SCADA & C2
Transport Management
Air Traffic Control
Op
Control
These systems have characteristics of enterprise & real-time embedded systems
• Typically heterogeneous &
complex, requiring support for:
– Different hardware platforms
– Software written in different
programming languages
– Highly distributed net-centric
environment(s)
• Need to assure efficient, predictable, &
scalable end-to-end QoS
• Need dynamic reconfiguration to support
varying workloads over operational lifecycle of
system
• Need to be affordable to reduce initial system
acquisition costs & recurring upgrade &
evolution costs
3
Challenge: Selecting Middleware for DRE Systems
• Develop software entirely in-house
using proprietary solutions
• Develop software using domainspecific, community-based
technologies
• Develop software using latest
commercial-off-the-shelf (COTS)
technologies
• Develop software using mature
standards-based technologies
4
Overview of CORBA
Interface
Repository
IDL
Compiler
• Common Object Request Broker
Architecture (CORBA)
Implementation
Repository
• A family of specifications
• OMG is the standards body
Client
OBJ
REF
Object
(Servant)
in args
operation()
out args +
return
IDL
SKEL
DII
IDL
STUBS
ORB CORE
ORB
INTERFACE
DSI
• CORBA defines interfaces, not
implementations
• It simplifies development of
distributed applications by
automating/encapsulating
• Object location
Object Adapter
GIOP/IIOP/ESIOPS
• Connection & memory mgmt.
• Parameter (de)marshaling
• Event & request demultiplexing
• Error handling & fault tolerance
• CORBA shields applications from heterogeneous platform dependencies
•e.g., languages, operating systems,
networking protocols, hardware
5
• Object/server activation
• Concurrency
• Security
Overview of Real-time CORBA
End-to-End Priority
Propagation
Client
OBJ
REF
in args
operation()
Object
(Servant)
out args + return
Scheduling
Service
IDL
SKEL
IDL
STUBS
Explicit
Binding
ORB CORE
Standard
Synchronizers
Thread
Pools
Object Adapter
Portable Priorities
GIOP
Protocol Properties
Real-time CORBA address some (but by
no means all) important DRE system
development challenges
6
•Real-time CORBA adds QoS
control to regular CORBA to
improve application predictability,
e.g.,
–Bounding priority inversions &
–Managing resources end-to-end
•Policies & mechanisms for
resource configuration/control in
Real-time CORBA include:
1.Processor Resources
•Thread pools
•Priority models
•Portable priorities
•Synchronization
2.Communication Resources
•Protocol policies
•Explicit binding
3.Memory Resources
•Request buffering
Why Use CORBA?
• After all people think CORBA is dead
• Why?
– Associated with legacy systems
– Mid 90’s technology therefore must be obsolete
– Perceived as “big & slow”
– Not exciting to write about
– They think it died of complexity
• Why not?
– Inclusive technology
– Committed, seasoned user base
– Maturity has led to highly time/space optimized
ORBs
– What works is boring
– It is solving increasingly complex issues
7
Span of Middleware Technologies for DRE Systems
MicroSoft .NET
Market
Share
Java / RMI
CORBA (GPP)
RT CORBA (DSP)
RT CORBA (FPGA)
OMG Data Distribution Service (DDS)
MPI
Non-real-time
Business
Systems
Soft Real-time
(Display and
decision
support
Source: OACE Tech. & Stds. Sept. 2003
9
Hard Realtime (sensor
and actuator
Control)
Extreme Realtime (signal
processing)
Alternate Technology Message Speeds
Transport
characteristics
eventually
dominate large
messages
Source:Gautam H. Thaker Lockheed Martin Advanced Technology Labs Camden, NJ
10
www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare_ipc.html
The Future of CORBA
• Improvements in CORBA features & performance
• Extensions to the CORBA object model
• Complementary technologies
11
The Future of CORBA
• Improvements in CORBA features & performance
• Extensions to the CORBA object model
• Complementary technologies
12
Fixing Problems with the CORBA C++ Mapping
1.Memory management is too
complicated & easy to get
wrong due to lots of rules to
memorize, e.g.,
• Storing strings within
sequences & structs
2.Lack of standard C++ classes makes CORBA look
“old & lame” & causes extra work for programmers
• e.g., it’s a lot of work to move the data back &
forth between the standard C++ types you want
to manipulate & the types you need to pass as
parameters
• Not handling the return
3.A tremendous amount of code gets generated for
reference from an operation,
the C++ mapping, leading to bloat & slow
but passing it to another
compilation
operation
• The size difference between the same essential
• Not setting length() of
set of functionality can be roughly on the order
sequence properly
of 5:1
• Not duplicating object
references properly
• Not using ServantBase_var
properly
• e.g., for e*ORB C & C++ on Red Hat 9 Linux
compiled with gcc 3.2 the C libec_poa.so is 29
kbytes C++ vs libe_mpoa.so is 105 kbytes
13
Top 10 Things to Fix in C++ Mapping
1.All memory should be self-managed
• This includes CORBA::Object,
sequences, strings, structures of
all types, etc
2.Structs & unions should have useful
constructors
3.Arrays should be implemented using
std::vector<>
4.Fix valuetypes so they use consistent
reference counting scheme
5.All types should offer exception-safe swap()
operations
6.Use bool, wchar_t, wstring, std::string,
std::vector, etc.
• Do not introduce new types unless you
must
7.Repeat number (1) until you reach (10)
Many more suggestions in CUJ columns by Vinoski & Schmidt
• http://www.ddj.com/dept/cpp/184403757
• http://www.ddj.com/dept/cpp/184403765
• http://www.ddj.com/dept/cpp/184403778
14
Improvements in CORBA Performance
One benefit of CORBA being a mature standard is that it runs in multiple
processor types, including GPP, DSP, & FPGA environments
GIOP Everywhere
GPP
DSP
FPGA
e*ORB
C & C++
e*ORB
C & C++
ICO
Extensible Transport Framework
Key Advantages:
• CORBA message processing can be executed directly in H/W, which is 100x faster
than in S/W
• Eliminates the need for S/W proxies/adapters on GPPs, which Reduces
overhead/latency & increases throughput
• Supports direct access to application components running on H/W
• Supports vision of architectural consistency across all aspects of the application
15
The Future of CORBA
• Improvements in CORBA features & performance
• Extensions to the CORBA object model
• Complementary technologies
16
Drawbacks of CORBA Middleware
Distributed Object Computing (DOC) CORBA 2.x application development can be tedious
Application
Interface
Development &
Design
Deployment
IDL
Definitions
Object
“Other”
Implementations
Implementations
IDL
Compiler
Language
Tools
Stubs
&
Skeletons
• DOC CORBA IDL doesn’t
specify how to group related
interfaces to offer a service
family
–Such “bundling” must be
done by developers via
idioms & patterns
Applications
Libraries
• DOC CORBA doesn’t specify how
configuration & deployment of objects should
be done to create complete applications
–Proprietary infrastructure & scripts are
written by developers to facilitate this
DOC CORBA 2.x defines interfaces & policies, but not implementations
17
Solution: Component Middleware
• Creates a standard
• Define standard
• Specify the infrastructure
“virtual boundary” around container mechanisms needed to configure &
application component
needed to execute
deploy components
implementations that
components in
throughout a distributed
interact only via wellgeneric component
system
defined interfaces
servers
…
…
Container
…
…
<ComponentAssemblyDescription id="a_HUDDisplay"> ...
<connection>
<name>GPS-RateGen</name>
<internalEndPoint><portName>Refresh</portName><instance>a_GPS</instance>
</internalEndPoint>
<internalEndPoint>
<portName>Pulse</portName><instance>a_RateGen</instance>
</internalEndPoint>
</connection>
<connection>
<name>NavDisplay-GPS</name>
…
<internalEndPoint><portName>Refresh</portName><instance>a_NavDisplay</insta
nce>
</internalEndPoint>
<internalEndPoint><portName>Ready</portName><instance>a_GPS</instance>
</internalEndPoint>
</connection> ...
</ComponentAssemblyDescription>
18
Overview of Lightweight CORBA Component Model
…
…
…
…
Container
Container
Middleware Bus
Replication
A/V Streaming
Security
Persistence
Scheduling
Notification
Load Balancing
•Components encapsulate application
“business” logic
•Components interact via ports
•Provided interfaces, e.g.,facets
•Required connection points, e.g.,
receptacles
•Event sinks & sources
•Attributes
•Containers provide execution
environment for components with
common operating requirements
•Components/containers can also
•Communicate via a middleware bus
and
•Reuse common middleware
services
Lightweight CCM defines interfaces & policies, & some implementations
19
www.dre.vanderbilt.edu/~schmidt/OMG-CCM-Tutorial.ppt
Applying Model-Driven Engineering to Lightweight CCM
…
1
…
…
…
Container
Container
3
20
www.dre.vanderbilt.edu/~schmidt/OMG-CCM-Tutorial.ppt
2
The Future of CORBA
• Improvements in CORBA features & performance
• Extensions to the CORBA object model
• Complementary technologies
21
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard
Topic
• e.g., fewer layers, less
overhead
R
Data
Writer
R
Data
Reader
R
Publisher
Subscriber
RT Info to Cockpit &
Track Processing
DDS Pub/Sub
Infrastructure
Tactical
Network & RTOS
22
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard
Topic
• e.g., fewer layers, less
overhead
• DDS provides meta-events for
detecting dynamic changes
NEW TOPIC
R
Data
Writer
R
Data
Reader
R
NEW
SUBSCRIBER
Publisher
Subscriber
NEW
PUBLISHER
23
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard
• e.g., fewer layers, less
overhead
• DDS provides meta-events for
detecting dynamic changes
• DDS provides policies for
specifying many QoS requirements
of tactical information management
systems, e.g.,
Topic
HISTORY
RESOURCE LIMITS
R
Data
Writer
R
S1
Data
Reader
R
S2
S3
S4
S5
Publisher
• Establish contracts that
precisely specify a wide variety
of QoS policies at multiple
system layers
Subscriber
S6
S7
LATENCY
S7
X
S7
S6
S5
S4
S3
S2
S1
COHERENCY
RELIABILITY
24
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard
DESTINATION
Topic
• e.g., fewer layers, less
overhead
• DDS provides meta-events for
detecting dynamic changes
• DDS provides policies for
specifying many QoS requirements
of tactical information management
systems, e.g.,
FILTER
R
Data
Writer
R
S1
S2
SOURCE
FILTER
Data
Reader
R
S3
S4
S5
Publisher
• Establish contracts that
precisely specify a wide variety
of QoS policies at multiple
system layers
Subscriber
S6
S7
• Move processing closer to data
TIME-BASED
FILTER
25
Concluding Remarks
• Software industry is
heavily driven by “fads”
• i.e., “Teen-age boy
band” syndrome
• CORBA is no longer the
new kid on the block
• In fact, it has a lot of
facial hair, much of it
gray ;-)
• With maturity comes
certain virtues
• High performance &
integration with many
platforms, languages,
& technologies
26
www.dre.vanderbilt.edu/~schmidt/ICALEPCS.ppt