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.
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.
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.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.