Porting to RTOS

[JakubSosnovec]

I would like to ask a pretty general question regarding the feasibility of porting Iceoryx to a real-time operating system, such as FreeRTOS.

It is clear the point of Iceoryx is inter-process communication, and FreeRTOS doesnt even have processes, just tasks which are analogous to threads. So, Iceoryx would just be another inter-task communication mechanism. However, I still believe there would be a lot of value in being able to use the convenient publish/subscribe API of Iceoryx to do inter-task communication with zero-copy data sharing, without worrying about task synchronization, signaling, etc.

For example, CycloneDDS can be built for FreeRTOS (https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/docs/dev/freertos.md).

To achieve such porting, something like the FreeRTOS+POSIX interface (https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_POSIX/index.html) could be used. Of course, it doesnt support POSIX shared memory for example, so that would have to replaced with normal memory allocation, accessible from multiple tasks.

So, I would like to pick the Iceoryx developers brain about:

• Does this idea even make sense?
• Is it even feasible?
• Was this ever considered?
• Are there some major technical challenges to this?

[elfenpiff]

@JakubSosnovec

Does this idea even make sense?

Yes it does.

Is it even feasible?

It should be feasible. Even when you are porting iceoryx to a non posix based operating system like windows it is possible.
The magic lies in our iceoryx_hoofs/platform abstraction. We implemented for every platform the features with a posix api we required. Sometimes we used different mechanisms, for instance posix condition variables in mac to support unnamed semaphores or introduced a named pipe as alternative for unix domain sockets in windows.

Was this ever considered?

We never considered FreeRTOS but we really welcome every additional platform. With every new platform we found some minor glitches and problems we had in iceoryx which most likely would be undiscovered for some time if it wasn't for the new platform.
So iceoryx would love to run on FreeRTOS!

Are there some major technical challenges to this?

I think we tackled all the major technical challenges when we ported iceoryx to mac os and windows. Porting it to FreeBSD was then just a piece of cake.

I think our current roadmap for this year is already quite ambitious and we would have no time to port iceoryx to FreeRTOS ourselves. But if someone would like to tackle this challenge we would support them in every step.

Here a rough plan how one has to proceed to get iceoryx running on FreeRTOS.

1. introduce a new platform called freertos and add it to cmake. You could use the freebsd platform as a template and adjust the implementation to freertos when needed.
2. If something is not available on freertos, remove the implementation from the freertos platform but keep the function since this is was iceoryx will call.
3. If everything is compiling start running the unit tests of iceoryx hoofs. ./build/hoofs/test/hoofs_moduletests. If something is failing adjust the platform implementation. Sometimes only errnos are set wrongly then you only have to forward the calls to the underlying freertos functions and adjust them on exit.

Now to posix shared memory. Iceoryx uses shm_open and mmap to create the shared memory partitions and map them into the process space.
I would guess that in freertos one could call malloc in the shm_open call and introduce an additional std::map<SharedMemoryName, void*> where the shared memory name is mapped to the pointer acquired by malloc when shared memory is created.
When you would like to open shared memory you look the name up in the map and return the pointer in mmap. Maybe you need also to introduce a container which maps the file handles to names.

I think with this approach you get iceoryx compiling on freertos in one day and most of the unit tests will most likely work out of the box.
Then the challenge of getting shared memory to work will remain but I think this shouldn't be much effort.

I have no idea if freertos supports unix domain sockets, but if not you could configure using IoxIpcChannelType = iox::posix::NamedPipe; like we do in our platform_settings.hpp in the windows platform.

[ugerthein]

@JakubSosnovec @elfenpiff

I think this is very interesting and great request and I would not only focus on FreeRTOS. Today a lot of embedded systems contain a hybrid architecture with a Real-time core cluster and an Application core cluster. As the target of iceoryx is automotive anyway I wonder if the predecessor of iceorxy hasn't been yet ported to AUTOSAR Classic as well for IPC communication between the RealTime cluster and Application cluster.

Thus, having a communication between AUTOSAR Classic and AUTOSAR adaptive or any other Automotive stack on the application side in zero copy manner. OpenAMP with supporting zero copy as well is a kind of this approach but has a different target application. I guess iceoryx can help here.

On both clusters on top of iceoryx a DDS middleware could be running plus on the application side a ROS 2 middleware might be used as well.

As starting point it would maybe helpful to have an example standalone implementation of iceoryx available or at least a Howto to port it to a specific HW platform.

[mossmaurice]

@ugerthein Thanks for your input! As mentioned in the latest vECM iceoryx Blueberry - Speeds up AUTOSAR Adaptive the predecessor of iceoryx called DADDY was created as a zero-copy replacement for the AUTOSAR Classic Runtime Environment (RTE), because it is doing copies for each subscriber which increases the runtime and latency for large samples. It's definitely an interesting thought to allow communication between AUTOSAR Classic and AUTOSAR Adaptive in a hybrid setup. A exemplary binding for ara::com based on iceoryx is available here. However, as you start sharing memory in a hybrid architecture it will very easily get tedious e.g. due the usage of different compilers with different memory alignments. Often, that means in such scenarios you would need to serialize and deserialize the data and loose the benefit of zero-copy.

Honestly, due to time constraints I don't think any of the iceoryx maintainers will work on this topic in the near future, but feel free to contribute. Happy to help with any questions that come up :)

As starting point it would maybe helpful to have an example standalone implementation of iceoryx available or at least a Howto to port it to a specific HW platform.

I think the best we currently have is what @elfenpiff mentioned in the above post. The iceoryx_platform in iceoryx_hoofs/platform is already very mature and if you compare e.g. Windows and Linux you should be able to get a feeling on what would have to be done for FreeRTOS or other platforms.

Which other platforms do you consider? Do you have any specific use case or scenarios in mind? Which CPU architecture would be interesting? Using a hypervisor?

[ugerthein]

@mossmaurice thanks for the quick response. Let me first answer your questions. My current target systems are ARM based devices like Versal. This system includes a Cortex R5 cluster and a Cortex A72 cluster. On the R5 domain within an automotive application typically SW stacks like AUTOSAR Classic is running. On the A72 domain you can think of many different approaches with and without a Hypervisor. For example a certified Hypervisor running QNX VM and a Linux VM. Within the QNX VM you may have ROS 2 related applications for autonomous driving and within the Linux VM you may have more driver information or infotainment related topics. I have also seen already system where AUTOSAR classic runs within a VM on Application cores like A53/A72 to address none timing critical services and to offload an the R5 cluster.

Thus, there are many different flavors of systems you can think off. In all these different scenarios data has to be shared or exchanged and because of this DDS is important to some degree. However DDS is currently thought of intercommunication with other ECUs or hosts via Ethernet, but in case of such Hybrid systems I see high potential that DDS can be used for intra-communication between On-Chip clusters or inter-process communication as well with the help of approaches like iceoryx.

Looking at your Video I am wondering now why Daddy itself was never brought up to the AUTOSAR classic consortium for enhancing the RTE? And maybe some technical question: Does Daddy replace RTE in your case completely and have you build your own AUTOSAR configuration tools around that?

For sure using Daddy and as such his follower iceoryx in AUTOSAR Adaptive makes a lot of sense according to the use case we anyway discuss here. But I think within the AUTOSAR classic world it would help as well as AUTOSAR classic is still alive and will stay for long time to address real time related tasks, determinism for sensor/actuator control, warnings, supervision/monitoring of other system elements and application cores etc. so all these static services which also generate more and more data compared to the past.

I guess there is no deep public information available on Daddy and AUTOSAR classic.

Thanks

[budrus]

@ugerthein

Looking at your Video I am wondering now why Daddy itself was never brought up to the AUTOSAR classic consortium for enhancing the RTE

DADDY was already written in C++. So a C version would have been required to bring it to AUTOSAR Classic. This was discussed but never started. When AUTOSAR Adaptive with C++ came up, it was the time to standardize the zero-copy API

I guess there is no deep public information available on Daddy and AUTOSAR classic.

Unfortunately not. This is all proprietary SW with proprietary tooling

An FreeRTOS port of iceoryx is maybe a good starting point for what you have in mind, or? I would assume there are also HW specific aspects for setting up a shared memory for a Cortex R5 cluster and a Cortex A72 cluster. If this is running with FreeRTOS and Linux, AUTOSAR Classic and AUTOSAR Adaptive could be a next step