Red Bend Software: Separation Using Type-1 Virtualization in Vehicles and Automotive Devices
•Download as PPTX, PDF•
5 likes•5,006 views
Satish Varma from Red Bend Software presents at TI Tech Day Detroit 2013 on how to use Type-1 virtualization to consolidate hardware in automotive ECUs. Panelists included QNX Software Systems and Crank Software.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Red Bend Software: Separation Using Type-1 Virtualization in Vehicles and Automotive Devices
Similar to Red Bend Software: Separation Using Type-1 Virtualization in Vehicles and Automotive Devices (20)
More from Red Bend Software
More from Red Bend Software (7)
Recently uploaded
Recently uploaded (20)
Red Bend Software: Separation Using Type-1 Virtualization in Vehicles and Automotive Devices
- 1. Satish Varma, Director of Technology and New Business, U.S. September 26, 2013 Separation Using Type-1 Virtualization Presented at TI Tech Day Detroit Session: “Accelerated Graphics in virtualized and non-virtualized environments on Jacinto 6 and OMAP5 SoC” 1 Presenters:
- 2. Red Bend Software Background • Founded in 1999 with a novel approach to remote software updating • Entered Mobile industry in 2003 to solve complex problem of over- the-air software management, expanded to M2M and Automotive in 2007 • Innovated with smallest delta file size, fastest updates, instant fail- safe and background updates, making Red Bend the most trusted mobile software management company • In Sept. 2010, acquired VirtualLogix, the leader in Mobile Virtualization, to bring greater security to the next generation of smart devices • Today, 1.75 Billion smartphones, tablets, M2M devices and connected vehicles are Red Bend-Enabled™ 2
- 3. • Run multiple OSs on the same platform • The challenges: – Enable some, or all OSs to use the device’s peripherals – Support close-to-native performance – Securely separate the OSs – Minimize the disruption on the customer development process What is Virtualization? 3 Hardware Hardware OS1 App OS2 App vLogix Mobile® (vLM) vLogix Mobile® acts like an OS scheduler
- 4. • The pressure to consolidate car ECUs and head units drives the need to use virtualization on future embedded platforms • Embedded systems are optimized for a Type 1 virtualization solution • Red Bend Type 1 hypervisor provides: – Swift integration with current Cortex A9 – OOTB integration with Cortex A15 – Minimal performance degradation – Security & Separation Why Use Virtualization in Automotive? 4
- 5. Virtualization Potential 5 RTOS Digital Cluster, ADAS IVI Rear-seat entertainment
- 6. • Modern head-units have ~10s of peripherals • Hardware peripherals and software drivers are not designed to be shared • The solution: – One OS physically responsible for the HW – Enable virtual drivers to access the peripherals through back-end / front-end architecture Device Sharing is Key to the Success 6 Hardware OS1 App OS2 App vLogix Mobile (vLM) Disk Network LCD Hardware Disk Network LCD vLM product comprises of hypervisor and virtual drivers in multiple configuration addressing various use-cases
- 7. Architecture Overview Apps Apps vOGL FE vEGL FE vAlloc FE vDisp FE WS vOGL BE vEGL BE vAlloc BE vDisp BE WSAllocEGL Display OGL Off screen memory rendering Display memory rendering Frame buffer Virtual sidePhysical side Off screen memory rendering Display memory rendering Frame buffer(s) Off screen memory rendering Display memory rendering Virtual Frame buffer 8
- 8. Configuration with Two Displays Apps vOGL BE vEGL BE vAlloc BE vDisp BE WSAllocEGLOGL Off screen memory rendering Physical side Off screen memory rendering Display memory rendering Frame buffer 2 FB1 display WS is configured as follow: Frame Buffer 1 dedicated to one display for the physical VM Frame Buffer 2 dedicated to second display of the virtual VM Frame buffer 1 Frame buffer 2 FB2display 9
- 9. Considerations • An excellent solution for reducing hardware costs – Separate OSs for each functional area – Separate CPU cores to guarantee compute resources • Things to consider… – Performance impact of the hypervisor: Real or FUD? • True Type 1 hypervisors’ performance impact is negligible – TI OMAP5 and Jacinto 6 processors have hardware-support for virtualization: less code running in the hypervisor – Board-level device assignment: complicated? • Devices can be directly assigned to individual guest OSes without the need for sharing – Licensing • BOM savings more than offsets the increase in runtime costs • OS runtimes remain the same as two SoCs 10
- 10. Cluster+Infotainment Graphics Use Case demo • TI hardware – OMAP5432 uEVM • QNX Platform Software – QNX CAR 2.1 for OMAP5, Crank Software HMI – Accelerated OpenGL cluster • Red Bend Virtualization – Virtualized Graphics Driver 11 • Challenge: – Maintain a constant cluster frame rate during heavy rendering on the IVI display • Solutions – (1) QNX Scheduler – adaptive partitioning – (2) Virtualization + 2 QNX guest OS’s • Other ideas? Tweet out to #TItechday !
Editor's Notes
- As described by Andy, there is a great opportunity to consolidate some of the functions within the car and still not compromise security and reliability. Virtualization is a platform that can help realize this opportunity.Apps: Users buy computing devices to use/run applications. Enabling “connected car” vision without compromising security and safety OS: Role of OS is to get resources from HW to give to appsHW: Role of HW is to provide compute resources as directed by OS. Efficient hardware utilizationEconomy (size, weight, wiring)PowervLM is NOT an OS - Does not manage threads or memoryCost reduction Improving time to marketThe best separation between RTOS and Open OSLegacy migration
- The drive to use V12N is clear – cost reduction, less E/E complexity , less wires which can lead to reduction in weight – less fuelType 2 V12N is not suitable for embedded system We believe that Hypervisor (Red Bend) comparing to Microkernel (Green Hills) and Microvisor (OKL) provide the best solution in term of performance, time-to-market, isolation, E2Emanagment and future prove OOTB- Out of the boxCore resources – memory, clock, CPU, interruptsPeripheral Devices – network, I/0, Storage Performance. We cannot know for sure until we get a real device from one of our competitors, which I guess is not a realistic option. OpenSynergy showed very partial benchmarks for only one side, which really does not reveal anything about the technology. When talking about benchmarks, it is important to discuss more complex services than CPU and I/O such as 3D, multimedia etc,. We have internal benchmarks we run on each release.Isolation.With Isolator (planned for 2H13 and CA15, we are at par with the offering with our uKernel based competition. With CA9 w/o Isolator, we are at dis-advantageIntegration. vLM is far less intrusive than uKernel integration for any given system. However, some of the competitors have already para-virtualized complete system, or partnered with solution vendors to enables “OOTB” automotive suites, in that respect, they might have an edge on RB when customer uses such a package.CA15. With CA15 hypervisor approach make more sense, will reduce integration time and enable a more secure solution and less impact on customer OSes.Feature Comparison. All virtualization solutions enables running multiple-OSes on multi-core devices, the feature parameters to compare are platform support. Currently, vLM support OOTB Android/Android and to some extent QNX/QNX. All other combinations and new OSes will require more work. Starting Q2 of 2013, we plan to focus on automotive and enhance our existing portfolio.
- As I mentioned earlier we take it very serious when it comes to safety-critical functions within the car. In vLM, which is a type-1 hypervisor, we ensure the real time characteristics of an RTOS are preserved. And for multiple operating systems that run on top of the hypervisor, scheduling and watch-dog timers, stage 2 MMU, the additional ring of security that VE brings in OMAP5/Jacinto6 are some of the features that ensure excellent performance without compromising the security and reliability.Seamless operation of two QNX VMs, one for infotainment (QNX CAR 2.1) and the second for DICDIC is the first priority – no matter what will happen to the infotainment VM , the DIC performance and operation will not be influencedTI OMAP 5 with VE enables fast integration and smooth operation of both VMsThere is a total separation between both VMs, for example an update to QNX CAR 2.1 will not influence the DIC
- Secure, greatly optimized, FE/BE architecture to sharing devices.