Middleware for Embedded Systems

1
Middleware for Embedded Systems

• Presenter Qi Han
• ICS243FDistributed System Middleware
• Spring Quarter, 2001

2
What is Embedded Systems

• Definition
• 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 work
• How do we work on the system?

4
Challenges in Distributed Embedded Software Design

• Distribution Flexibility
• Scalability
• Performance
• Memory
• Heterogeneous Systems
• Project Costs and Risks

5
Minimum CORBA

• A subset of CORBA designed for systems with
  limited resources
• Remove 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 CORBA
• Support full IDL

6
LegORB--Why

• Motivation
• 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--How

• Configurable component-based reflective ORB
• A well defined interface and implementations of
  those components
• allow tracking dependencies among different
  components
• Microkernel-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
Motivation

• Growing demand for distributed computer control
  in sophisticated embedded control systems
• Needed 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-CORBA

• Requirements
• 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 Protocols

• Support both group and point-to-point
  communication capabilities
• Protocol 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 Protocol

• Compact Common Data Representation
• EIOP messages supported

20
Experiment Platforms
21
Performance Results

• Performance 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
(No Transcript)
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-CORBA

• General 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 Objects

• Three 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
(No Transcript)
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 Conjoiner

• To 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
Conclusions

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