Experience with the integration of distribution middleware into partitioned systems

(1)

UNIVERSIDAD DE CANTABRIA

Experience with the integration of

distribution middleware into partitioned

systems

Héctor Pérez Tijero ([email protected]) J. Javier Gutiérrez García ([email protected])

Computers and Real-Time Group, University of Cantabria

(2)

Outline

1. Introduction and objectives

2. The XtratuM hypervisor

3. Integration of distribution middleware into XtratuM

4. Case study

(3)

Introduction

Partitioned systems

• Development of safety-critical software

- certification requirements

• Memory and time isolation properties

- the execution of partitions is restricted to predefined intervals

PARTITIONINGKERNEL

DEVICE #1 DEVICE #2 DEVICE #N

P AR TITION #1 . . . P AR TITION #2 P AR TITION #N

(4)

Introduction (cont’d)

Distributed partitioned systems

• Special purpose networks

• Common distribution middleware increases complexity

Research on middleware for safety-critical systems

• Custom distribution facilitites

- automatic generation of source code from system models

- e.g., PolyORB-HI

• Distribution facilities based on standards

- Safety-critical DDS

(5)

Introduction (cont’d)

Partitioning based on a hypervisor

• Thin layer with low overhead

• Independent execution environments (multiple OS)

- mixed-criticality partitions on top of different OS

• Eases the integration of distribution middleware

Benefits of using distribution middleware in partitioned systems

• Enables transparent communications between subsystems

- network services, connection management

- regardless of partitions in different/same core module

- interoperability (standards)

• Allows to schedule a multicore as if it were distributed

(6)

Objective

Two approaches

• Specific profile of distribution standards (high-criticality)

• Standard distribution middleware (low-criticality)

DEVICE #GP DEVICE #RT PARTITION #A MW . . . CORE MODULE . . . PARTITION #N MW PARTITION #T MW PARTITION #Z PARTITION #M MIW COMMUNICATION SERVICES HYPERVISOR

(7)

XtratuM hypervisor

• Design based on the ARINC-653 standard

- time and space isolation features

• Partition as an application executed on top of the OS

XtratuM API XtratuM Services

Device #1 Device #2 Device #3 Device #N Partition #1 Linux OS Partition #N Other OS . . . CORE MODULE

(8)

XtratuM Communication Services

XtratuM I/O virtualization engine (XMIO)

• Device and transport virtualization

• Only Linux-based partitions

ARINC-like communication ports

• Sampling ports

- storage for a single message

• Queuing ports

- storage for a fixed number of

messages (FIFO)

• Channels to interconnect them

XTRATUM API XTRATUM ARINC-LIKE SERVICES HARDWARE PARTITION #A . . . PARTITION #N CORE MODULE

SENDINGPORT RECEIVINGPORT

XTRATUM XMIO SERVICES HARDWARE PARTITION #A CORE MODULE V-NIC V-NETWORK PARTITION #N V-NIC . . .

(9)

XtratuM Communication Services:

ARINC-like communication ports

• Sampling and queuing ports

- offline configuration

- allow one-way operation mode

- provide non-blocking communications

- single source of messages for a receiving port

XtratuM API XtratuM ARING-Like Services Hardware Partition #1 Partition #N . . . CORE MODULE Sending port Receiving port

(10)

XtratuM Communication Services:

ARINC-like communication ports

Management of devices left to partitions

• Exclusive access to device

- drivers must be implemented by partitions

- offline configuration

XtratuM API

XtratuM ARING-Like Services

Hardware _NIC

I/O Partition Partition #N

. . .

CORE MODULE

Sending port Receiving port

(11)

System architectures

Integration of middleware within partitioned systems

• Communications between core modules

• Communications between partitions

XTRATUM API

XTRATUM ARINC-LIKE SERVICES

HARDWARE

PARTITION I/O . . . PARTITION #N

CORE MODULE

NIC

HARDWARE

PARTITION I/O . . . PARTITION #X CORE

MODULE

NIC HARDWARE

PARTITION I/O . . . PARTITION #N CORE

MODULE

NIC

NETWORK

(12)

System architectures (cont’d)

Communications between core modules

1. I/O partition with distribution middleware

- message processing, open systems

2. "Bare" I/O partition to forward messages

- opaque messages, static connections

Platform design issues

• Fixed and predefined communication channels

- static routing table for the I/O partition

(13)

System architectures (cont’d)

Communications between partitions

• Use of distribution middleware

Platform design issues

• Asynchronous communications

- synchronous remote calls are not allowed • Non-blocking communications

- middleware cannot be blocked awaiting for incoming messages

• Single source of messages for a receiving port

- common strategy in middleware (single listening port)

(14)

Proposed system architecture (cont’d)

XTRATUM API

HARDWARE _NIC

I/O PARTITION PARTITION #Y

. . . CORE MODULE #2 MIDLEWARE XTRATUM API HARDWARE _NIC I/O PARTITION CORE MODULE #1 PARTITION #X MIDLEWARE SENDINGPORT RECEIVINGPORT CHANNEL N (#X => #Z) CHANNEL M (#Z => #X)

CHANNEL T (#X => #Y) NIC

I/O PARTITION PARTITION #Z

. . . XTRATUM API HARDWARE CORE MODULE #3 MIDLEWARE NETWORK

XTRATUM ARINC-LIKE

SERVICES

XTRATUM ARINC-LIKE

SERVICES

XTRATUM ARINC-LIKE

(15)

Case Study: Video-surveillance

- Multiple display monitors may request video captures from recording app.

- Key feature: reliability of recording application

SENDINGPORT

RECEIVINGPORT

CHANNEL 1

CHANNEL 2

XTRATUM API

XTRATUM ARINC-LIKE

SERVICES HARDWARE _NIC IO_SERVER CORE MODULE #1 VIDEO_RECORDER MIDDLEWARE CORE MODULE #2 THIRD-PARTY APP CORE MODULE #NN RTOS RTOS NETWORK NETWORK

(16)

Case Study: Objectives

Performance of the proposed architecture

• overhead introduced by hypervisor

Interoperability between heterogeneous subsystems

• partitioned and non-partitioned systems

Development of a prototype to validate the approach

• retrieval of a previous distributed real-time platform

- PolyORB as distribution middleware

- application personalities, microkernel and protocol personalities

- RT-EP as the real-time network

- token management in partitioned systems

- MaRTE OS as the real-time operating system

(17)

Case Study: Prototype

OPERATING SYSTEM

HYPERVISOR

COMMUNICATION

SERVICES ETHERNET

ADA CODE ADA CODE

ADABINDINGS (XTRATUMAPI) POLYORB-CORBA POLYORB-ICMC ARINC-LIKE MARTEOS MARTEOS MARTEOS MIDDLEWARE APPLICATION

VIDEO_RECORDER IO_SERVER CLIENT

ADA CODE XTRATUM XTRATUM ARINC-LIKE & ETHERNET POLYORB-CORBA POLYORB-ETHERNET

(18)

Case Study: Configuration

1. Assignment of partitions to core modules

2. Number and type of ports in each partition

- decoupled model

3. Definition of communication channels

4. Cyclic scheduling plan

- IO_Server partition should fulfils the I/O requirements of remaining

partitions

- execution of I/O operations "in one go" to minimize idle times

<IO_SERVER>

<VIDEO_RECORDER>

M A F

CPU-0

SCHEDULING CYCLIC PLAN (TIMES IN μS)

400 500

(19)

Case Study: Preliminary results

• Platform: 800 Mhz embedded nodes, 100 Mbps Ethernet

• Time required to request and obtain a video capture

• Three experiments

- Non-partitioned

- Single partition

- Partitioned

OVERHEAD PERFOMANCELOSS COMMENTS

HYPERVISOR < 1 % ARINC-LIKE PORTS

ARCHITECTURE 29 % 25 % PARTITIONCONFIGURATION

(20)

Conclusions

Integration of distribution middleware into partitioned systems

• Inter-core modules communications

- I/O partition required, middleware may be required

• Inter-partitions communications

- asynchonous and non-blocking communications

- multiple reception ports per partition

• Benefits of the proposed integration

- avoid complexity in communications between partitions

(21)

Future work

New features of XtratuM v3

• multicore support

- dedicated core to the I/O partition

• asynchronous management of communication ports

Exploring an asynchronous and decoupled distribution model

• source and destination are unknown at partition-level

• incoming safe-critical profile for DDS

Other communication approaches to ease portability

(22)