Upload
annabella-mason
View
233
Download
1
Tags:
Embed Size (px)
Citation preview
Middleware for Embedded Systems
Presenter: Qi Han
ICS243F–Distributed System Middleware
Spring Quarter, 2001
2
What is Embedded SystemsDefinition
a special computer system housed on a single microprocessor w/ firmware OS or a single program
Example: virtually all appliances with digital interface from massive central office switches and
routers to compact cell phones
3
Challenges in Embedded System Design
How much hardware do we need? How big is the CPU? Memory?
How do we minimize power? Turn off unnecessary logic? Reduce memory
access?
Does it really workHow do we work on the system?
4
Challenges in Distributed Embedded Software Design
Distribution FlexibilityScalabilityPerformanceMemoryHeterogeneous SystemsProject Costs and Risks
5
Minimum CORBAA subset of CORBA designed for systems with
limited resourcesRemove the dynamic facilities for creating,
activating, passivating and interrogating objects and for serving requests
Predictable system environment: Design time decisions on resource allocation, object location and creation; pre-determined patterns of interaction
Has broad capability within the world of limited resource systems
Fully interoperable with CORBASupport full IDL
6
LegORB--WhyMotivation
small memory footprint dynamically adaptation
Design principles what you get is what you need Simplicity
Versions LegORB for the PalmPilot: 6KB LegORB for Windows CE: 20KB
7
LegORB--HowConfigurable component-based reflective ORBA well defined interface and implementations of
those components allow tracking dependencies among different
componentsMicrokernel-like approach
core: only the low-level essential components• LegORB configurator: provides the entry point to the Orb
functionality and clearly separates the client and server-side functinality
• client-side configurator• server-side configurator
application: implements customized policies or selects from a collection of policies
8
CAN-CORBA
CAN-CORBA a new CORBA design for CAN-based distributed embedded
control systems
CAN(controller area network) Is a high-integrity serial data communications bus for real-time
applications
Operates at data rates of up to 1 Megabits per second
Has excellent error detection and confinement capabilities
Was originally developed for use in cars
Is now being used in many other industrial automation and control applications
CAN Spec 2.0 is a standard for embedded real-time network substrates
9
MotivationGrowing demand for distributed computer control
in sophisticated embedded control systemsNeeded: distributed embedded system
merits• more cost effective than using a single high performance
microprocessor
• more reliable than using a centralized control system
• composability, extensibility, maintainability supports needed:
• real-time operating system
• well-defined network protocols
• component-based middleware systems
10
Why CAN-CORBARequirements
Small memory footprint: not exceeding a few hundred kilobytes
Low message traffic per service invocation• CAN network bandwidth is only 1Mbps
Group communication support• To facilitate easy dissemination of sensory data
Contributions Redesign GIOP into ESIOP Define CCDR Develop a new transport protocol to support group
object communication
11
Target System Hardware Model Distributed embedded control system
a large number of function control units embedded control networks
12
Overview of CAN-CORBA
13
Abstract Communication Channels Invocation Channel
Publisher/subscriber scheme: • Subscription based• Anonymous group communication
Virtual broadcast channel from publishers to a group of subscribers
Data producer announces a predefined invocation channel; data consumers subscribe to an announced invocation channel
Connection Bi-directional connection-oriented point-to-point
communication A virtual channel which must be established between a
client and a server before message transmission
14
Transport ProtocolsSupport both group and point-to-point
communication capabilitiesProtocol header format
15
Channel Binding Protocol for Subscription-based Communication
Invocation channel Conjoiner
Resides on a CAN node Started right after network initialization and operational during the
entire system service period
16
Anonymous Publisher/Subscriber Programming Model for Subscription-based Communication
17
Connection Establishment Protocol for Point-to-Point Communication
18
Client/Server Programming Model for Connection Oriented Communication
19
Embedded Inter-ORB ProtocolCompact Common Data Representation
EIOP messages supported
20
Experiment Platforms
21
Performance ResultsPerformance metrics
Protocol processing latency• Sender side: the execution time of the invocation
stub called by the sender, the CAN device driver and CAN controller
• Receiver side: a time interval from when the first CAN message of a CORBA method invocation is received to when the skeleton code is dispatched
Static memory footprint• The sum of the sizes of code and data sections of the
ORB core and its accompanying library
22
1. Protocol processing latency of a method invocation increases as the number of parameters increases
2. The worst case protocol processing latencies are less than 1 ms when the number of parameters are reasonably small.
3. Pure EIOP processing latency: 34.5%; CAN device drive: 24.6%; bus adaptor: 40.9%
4. EIOP yields 37.5% reduction in the GIOP message traffic on the average
23
24
1.The dynamic invocation/skeleton and other features saves a lot;---not recommended in Minimum CORBA specification
2.EIOP itself requires much smaller memory than GIOP and IIOP.
25
Summary of CAN-CORBA Communications ORB core of CAN-CORBA
Supports subscription-based group comm. & the classical connection-oriented point-to-point communication
Reduces the amount of message traffic required for each CORBA method invocation
Designed a transport layer protocol that can support up to four upper layer protocols
Refined CDR and message types and headers of GIOP
26
Fault Tolerance in CAN-CORBAGeneral replication strategies
Passive replication• Only one replica for an object executes designated operations;
other replicas wait for an activating signal to be delivered when a fault is detected
Active replication• When an object invokes a replicated service, all replicas service
the request and actively reply with their own results
Stateless replication mechanism in CAN-CORBA The state of a primary replica need not be preserved or
transferred to non-primary replicas This argument can be justified in the context of control
systems theory• Control performance is seriously affected by the freshness of
sampled data
27
Replicating CAN-CORBA ObjectsThree different entities for replication
Publishers: general CORBA objects Subscribers: general CORBA objects Conjoiner: pseudo CORBA object
Passive replication Publishers and subscribers are replicated in a
similar manner But, the primary subscriber periodically emits
an “I am alive” signal to its fellow non-primary replicas
28
29
Passive Replication of Publisher (1) P1 announces its registration to PCH and BCH (2) S and T request subscription to PCH (3) P2 and P3 request subscription to BCH (4) P1 periodically publishes messages, S and T keep listening to PCH, P2 and
P3 keep monitoring P1
(5) P2 (or P3 or both) detects a timeout and requests channel switching to the conjoiner
(6) The conjoiner decides the next primary It broadcasts the newly modified binding information: (PCH, primary interface,
TxNode(P2), TxPort(P2)) Upon receiving this information:
• S and T update their local binding database with an entry (PCH, primary interface, TxNode(P2), TxPort(P2))
• P1 and P2 switch the role between primary and non-primary replicas: P1 updates its local binding database with (BCH, backup interface, TxNode(P2), TxPort(P2))
• P3 updates its local binding database: (BCH, backup interface, TxNode(P2), TxPort(P2))
(7) Step (6) completes channel switching. P2 becomes a new primary and now starts to publish.
30
Active Replication Active replication for publishers
A subscriber must subscribes to one and each of replicated publishers
Subscribers have a responsibility to multiplex all data from replicated publishers, a voting logic is included in subscribers
Active replication for subscribers An external voter object must be created
31
Replicated & Distributed ConjoinerTo eliminate the single point of failure introduced by
a centralized single conjoiner The binding database is replicated: each binding entry is
stored at more than two distinct locations The conjoiner is actively replicated so that any of the
replicated conjoiners can deliver correct binding information to its clients
Data consistency among replicated global binding database is maintained using reliable broadcast CAN bus
To mitigate performance degradation due to a large number of binding and switching channel requests, the global binding database is fragmented
• When a subscription request is made, conjoiner replicas need to search only global binding database fragments and thus shortens the response time
32
Summary of CAN-CORBA Fault-tolerance
Adopt the OMG fault tolerant CORBA specification
Incorporate into CAN-CORBA both passive and active replication strategies
Fault tolerant CAN-CORBA Free programmers from the single point of
failure caused by the centralized conjoiner Let programmers freely add fault tolerance to
their designs through replicating CAN-CORBA objects
33
ConclusionsDistributed embedded software projects have
unique distribution infrastructure challenges.To focus on the development of the application
rather than the distribution infrastructure, many projects are using standard commercial ORB solutions such as CORBA.
However, general purpose middleware such as CORBA can not be applied to embedded control systems immediately. It is one of the tasks for middleware researchers to design embedded middleware.
34
References Garth Gullekson, ORBs for Distributed Embedded Software, Technical paper, Object
Time Limited Object Management Group, Minimum CORBA-joint revised submission, OMG
document orbos/98-08-04 edition, August 1998 Manuel Roman, Dennis Mickunas, Fabio Kon and Roy H. Campbell, LegORB and
Ubiquitous CORBA, IFIP/ACM Middleware'2000 Workshop on Reflective Middleware, NY, April 2000.
Bosch. CAN specification, version 2.0, 1991 K. Kim, G. Jeon, S. Hong, S. Kim, T. Kim, Resource-conscious customization of
CORBA for CAN-based distributed embedded systems, IEEE International Symposium on Object-Oriented Real-time Computing, March 2000
K. Kim, G. Jeon, S. Hong, S. Kim, T. Kim, Integrating Subscription-based and Connection-oriented Communications into the Embedded CORBA for the CAN Bus, IEEE Real-time Technology and Applications Symposium, 2000
G. Jeon, T.-H. Kim, S. Hong, and S. Kim., A Fault Tolerance Extension to the Embedded CORBA for the CAN Bus Systems, In the proceedings of ACM SIGPLAN 2000 Workshop on Languages, Compilers, and Tools for Embedded Systems