QNX’s SDV Strategy: QNX Cabin

Last Wednesday and Thursday, QNX visited our company for two days. One day was dedicated to a demo, and the other to a full-day technical workshop. I attended both days and would like to briefly share my thoughts on QNX’s SDV strategy. It was nice to see webOS again after such a long time. :)”

 

In conclusion, if everything is implemented well as planned, OEMs using QNX will likely become less dependent on suppliers and slightly more reliant on QNX itself. The direction is really promising, and the current demo worked well on AWS Cloud, Qualcomm reference boards, and Samsung reference boards. Of course, there is often a gap between ideal and reality, but the platform and development environment seem excellent.

QNX Cabin

QNX introduced the new term ‘QNX Cabin,’ with the core focus being on VirtIO. QNX supports VirtIO, allowing easy deployment of guest operating systems that support VirtIO. Since VirtIO is a standard, it can either guide each SoC vendor or directly create the lower layers to support VirtIO. Operating systems like Android and others shown in the diagram can be configured to support VirtIO.

 

One of the demos involved downloading an arm64 qemu image of AGL (Automotive Grade Linux) and running it on AWS Cloud on top of QNX Cabin without modifications. It also demonstrated that the same image could be deployed on Samsung and Qualcomm reference hardware.

 

The biggest concern with VirtIO in product development is performance. QNX addressed this by demonstrating a complex graphics demo running at 60fps. However, real-world products are a different story, and challenges remain to be solved.

 

Additionally, QNX has implemented a server capable of receiving vehicle signal data as part of the Cabin.

 

Another issue is that using QNX Cabin incurs additional licensing costs. While I’m not sure of the exact cost, I suspect it might be expensive since it’s QNX. However, we can start by getting an evaluation to conduct a proof of concept (PoC).

QNX Support on AWS Cloud

Ref: https://aws.amazon.com/blogs /industries/accelerate-embedded-software-development-using-qnx-os-on-amazon-ec2-graviton/

 

QNX offers QNX Neutrino RTOS 7.1, QNX OS for Safety 2.2.3, QNX OS 8.0, and QNX Hypervisor 2.2 for sale on AWS Marketplace, running on AWS Graviton with ARM64 architecture. This allows OEMs using QNX or QNX HV in their products to more easily leverage cloud development strategies for software-defined vehicles (SDVs). Although this would mean reliance on AWS Cloud, QNX is expected to provide support for private cloud and other cloud platforms as well.

 

The setup process doesn’t seem particularly complex. For instance, with QNX HV, you can add a VM by uploading the kernel, image, and QNX HV configuration files to a location in the cloud storage and then executing with qvm or placing it into slm.

 

QNX Cabin is not officially available yet. It seems they plan to stabilize it further and conduct marketing efforts before releasing it.

Summary

The recent demo was one of the most realistic I have seen and closely aligns with my personal vision for such products. Many of my colleagues who participated also agreed with this perspective. For our next product, we are documenting the need for SoC vendors to strengthen VirtIO support and are working to gain their agreement. The strategy of using a ‘Virtual ECU’ to test the same binary on a cloud-based environment without recompilation seems similar and feasible to set up. We’ve made significant progress internally on this front.

 

As mentioned earlier, the core of QNX Cabin is VirtIO, and I am considering conducting a PoC while monitoring its stability and performance tuning. Separately, the strategy for Virtual ECU will continue as planned.