Middleware for Embedded Systems

1. Middleware for Embedded Systems Presenter: Qi Han ICS243F–Distributed 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. Protocol processing latency of a method invocation increases as the number of parameters increases • The worst case protocol processing latencies are less than 1 ms when the number of parameters are reasonably small. • Pure EIOP processing latency: 34.5%; CAN device drive: 24.6%; bus adaptor: 40.9% • EIOP yields 37.5% reduction in the GIOP message traffic on the average

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

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, Inthe proceedings of ACM SIGPLAN 2000 Workshop on Languages, Compilers, and Tools for Embedded Systems