Middleware for Embedded Systems Presenter: Qi Han ICS243F–Distributed System Middleware Spring Quarter, 2001.

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