Hello RTI team :)
We are considering the porting of RTI Connext Micro to an ARINC-653-like platform called XtratuM. It is an open source hypervisor designed for real-time embedded and high integrity systems. Although it does not follow a specific standard, its design is based on ARINC-653 so it provides the applications executing on top of it with time and space isolation. It allows the execution of different operating systems (e.g., a general purpose OS, a real-time OS, or an ARINC-653 OS).
Our main concern is the use of DDS with ARINC-653 inter-partition communication facilities (e.g., sampling and queuing ports). We are aware of the RTI Connext Micro Porting Guide, but it does not include any guidelines for the communication layer. Any extra documentation or advice for this task?
Thanks in advance & best regards!
Hector
Hi Hector,
RTI Connext Micro has an abstract communication interface that enables different kinds of transports to be implemented. This interface is used between different I/O layers in the RTI Connext Micro core library. However, the interface is a recent addition and some aspects of the interface as well as some parts of the core library is still being updated. Documentation will be available when the interface is complete.
With that being said, we still want to help you get started with a transport. But, before going into the details regarding how to implement the transport it would be helpful to know where you are in the design of the transport functionality itself. A few things to consider when designing a transport are:
- Have you considered an addressing schema to identify DDS applications across APEX ports? A RTI Connext Micro transport needs an addressing schema to identify and direct messages to other RTI Connext Micro applications. The addressing schema is user-defined and uses the RTPS locator format.
- Are you familiar with the DDS discovery protocol? Are you planning any type of dynamic discovery of DDS applications, or will it be only static configuration? A RTI Connext Micro transport will use the addressing schema to reach other RTI Connext Micro applications, and the transport is responsible for resolving an address into, in this case, an APEX port to send to.
- Typically, a RTI Connext Micro transport will receive and send RTPS messages, although this is not strictly required. However, even when sending and receiving RTPS messages it is neccessary to encapsulate the RTPS message with sufficient addressing information to reach the correct DDS domain participant. This is up to the transport. For example, in UDP the port numbers are used to reach the correct DDS domain participant.
Regards,
Tron