@_hm: I have a very limited knowledge on DO-178B standard. But my guess is as like you have mentioned. I think DO-178B would mandate more stringent requirements in terms of having more redundancy (triple redundancy for every control), absolutely NO single point of failure in design and more process rigor etc. etc. Maintaining the similar safety rigor would be costly (more time, more effort and hence more money). Hence I guess ISO 26262 is customized as per the automotive industry requirements and mostly adapted from IEC 61508. The problem is it is up to the manufacturer to follow this as I have learned that it is not mandatory for an independent agency to assess and certify. This should be done,
I think DO-178B certification is not mandatory as it is applicable for avionics controls. For automotive electronics system there is a safety standard ISO 26262. I guess, if the application of this ARM processor with the Mentor Hypervisor is in the critiacal control system, it would need some certification...most probably per ISO 26262. I am amazed to see the trend of using hypervisor in the automotive industry is moving at a fast pace...not sure if the standards can keep up with this pace or not. :}
@prabhakar_deosthali: This article is actually talking about the "hypervisor" which would enable a "single" (one chip) multi-core processor to run multiple Operating Systems: "ranging from in-vehicle infomation systems to telematics, advanced driver assistance systems, and instrumentation"
Most systems in a car (except for infotainment) are driven by hard latecy requirements, and today are runing into a bare metal (or very close) environment. I guess you would not want your VM handling, say, the braking system to be respawned, would you? Consolidation will happen in the infotainment/instruments cluster subsystems. For the rest, I'm curious to see who dares to move to a virtualized environment.
Clearly, 1 processor does all is a very attractive proposition. With careful design and architect, the virtual machine will heal itself. 1 VM is crashing; another will be spawned and take over. In the world cloud computing, it isn't just a vision; it is a reality. What if this vision is applied to mcu to help running a vehicle?
People outside of the electronic and automotive industry properly doesn't realize there are so many MCU in any vehicles today. They cover injection control, transmission control, etc. With the advance of technology and market demand, infortainment, in-vehicle broadband, GPS tracking and light control are some of the new features. There are 10 of different kind of MCUs in the vehicle. Due to the installation location, they may have different requirement; definitely, they are sold with different price. On one hand, MCUs for injection control and transmission control, which are considered as mission critical, may be installed closer to the front potion of the vehicle. They require a better heat disspation and sustainility. They must last. They will likely cost more because they are fabricated with 10+ years of reliability. On the other hands, MCU for infotainment is likely installed inside a better weather/ dirt control environment. If it doesn't last, nobody will get hurt. As a matter of fact, the infotainment system can just be your mobile device with different form factor.
Applying virtualization of MCU used for automotive certainly makes a lot of sense. With time and resources, I am sure the vision of self-recovery and high availability using VM will become reality. The challenges remain on how the overall system is being architected and, how many MCUs will be used and which area of control shall be combined to 1 MCU.