Great comment on contention risks with common OS for entertainment and safety software. Also, the driver assist evolution process will vary greatly vendor to vendor, as fully autonomous vehicles evolve as well for special locations and vehicle types.
Standards organizations will pay attention to issues like isolation of safety systems and software from entertainment systems and software including perhaps hard isolation of associated hardware. So Qualcomm should have someone deeply involved in European, Asian, and American car safety standardization efforts I would think. Events (nasty ones) will drive the standards folks, so early adoptors with get arrows in the back, mud in the face, like all pioneers. But saving lives and repair costs with fewer accidents can be low hanging fruit. Example: Tesla battery fires made big news...but gasoline cars explode very often with no news, so are batteries safer long term...since passengers have time to get out? Media focus impacts standards as well as real problems.
This has been suggested before, and I still have the basic problem with it that I am not necessarily willing to pay for a separate "phone" for my car. I would much rather have it use the external connectivity provided by the handset in my pocket. This is particularly true given the mismatch in lifetime between a phone and a car. What they really need to do is provide a modular standardized socket into which I can plug a network interface, be it Bluetooth, Wifi, or cellular.
It puzzles me, if the car itself already has 60 to 100 ECUs, why a single OS needs to support both ADAS (which is completely safety-critical) and IVI (which obviously isn't)? It's not even clear that they ought to be running on the same core. I don't think anyone will want to see vehicle safety compromised if the app running the access for Spotify (for example) crashes! As Toyota found out the hard way you can land yourself in big trouble when you start cutting corners in an automotive safety environment. It could be that someone is thinking "oh no, if they're on different processors we'll have ANOTHER interface 'standard' between cores that the individual OEMs won't be able to agree on" but that's WAY short-term thinking that will eventually come back to bite everyone on the rear end. As someone with quite a bit of experience with safety-critical software development to FAA-approved standards, hard real-time coding for safety in aviation applications requires that the code execution be strictly deterministic, so you're prohibited from using most of the popular object-oriented languages which have features that are problematic in this regard like late binding or heap management, not to mention "certifying" which of several classes evaluated a particular expression. I'm not saying that the automotive standards will necessarily be that strict but I doubt that infotainment programmers will want to put up with the other requirements like independent code certification and the schedule delays that imposes, maybe even going as far as requiring each compiler to be certified as a "qualified tool" for safety purposes. Safety is not and never was free or easy, and that's not just an opinion.
It appears that most of the mobile SoC vendors are setting their sights on automotive. However, beyond the infotainment and control, the car will also become a key hub for managing communications and data. Thus, wireless connectivity will become just as important as in handsets, and just as in handsets, it may determine the victors.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.