[Jeroen]

Some more insights and or predictions on what connected cars might bring.

This goes way beyond what you just see on your dashboard, obviously

Jeroen

http://www.fiercewireless.com/europe...m_campaign=rss

[ampere]

Check the Google IO as it happens. Lot many vendors (As many as 40) join the Open Automotive Alliance. (Google Driven). Google has also announced the Android Auto and its associated SDK. Nothing lot to do with interface, but lots on how to interact when in car.

[TorqueyTechie]

Originally Posted by ampere

Check the Google IO as it happens. Lot many vendors (As many as 40) join the Open Automotive Alliance. (Google Driven). Google has also announced the Android Auto and its associated SDK. Nothing lot to do with interface, but lots on how to interact when in car.

Yeah, Android Auto is announced and it is interesting to watch and see how it develops.

Its nice to see so many auto makers part of this including FIAT, VW, Suzuki, Honda. Should wait and watch when it gets inducted to production models.

Below is the link :

http://www.android.com/auto/

[acurafan]

Originally Posted by Jeroen

Some more insights and or predictions on what connected cars might bring.

This goes way beyond what you just see on your dashboard, obviously

Jeroen

http://www.fiercewireless.com/europe...m_campaign=rss

Infotainment and connectivity are probably the two most hot topics in automotive at this point, followed by Driver's assistance system and autonomous driving. Interestingly most players who dominate the smartphone markets are also players here as discussed earlier.

I see that there are couple of questions regarding why ICE UI has not evolved so far and what is automotive grade reliability ?

a) ICE UI has not improved because the aim of most car manufacturers were to provide functionality over aesthetics. Unfortunately with proliferation of smartphones people expect their car to have a similar and familiar UI. This resulted in Google and Apple's involvement in Car HMI (Human Machine Interface). Automotive folks don't call it UI but HMI.
But it is not easy as it looks. If you look at it, cars are lot more complex than smartphones with lot of tasks running concurrently. For example any given time you can have main cluster running with 3D Navigation, Rear Seat entertainment with a 1080p movie being played, instrument clusters being refreshed at 120 Hz and probably few camera feeds being processed for passive ADAS. It is quite taxing for even the best smartphone SoCs to run these tasks. On top of it we have the issue of real time OS. Android and IOS are not real time OS, so none of the tasks can be guaranteed to be serviced immediately, so in the backend there is always a real time OS running for example QNX, Greenhills or automotive grade linux. So the SoCs need to support HW based virtualization to improve performance which is an added cost.
Also automotive design cycles are quite long, typically around 5 years. So current state of art smartphone SoCs are being considered for 2018-2020 models and by the same logic you can see that 2014 model year cars have 2009-10 SoCs which were honestly lot less advanced. So long story short we can see Android UI through Open Automotive Alliance or IOS through Car Play will be fully baked in the cars around that time frame but the intermediate cars will have some bits and pieces support.

b) Automotive Grade Hardware
As all of us know cars are subjected to intense temperature, vibration, dust, moisture etc. So the hardware has to be immune to this. There are currently few standards that automotive grade chips adhere to. For infotainment solution we have AEC-Q certification. AEC-Q100 is the standard for the integrated circuits. The standard mandates that the parts should have an operating range of temperature of -45C to 105C plus lot of other electro-mechanical stresses.
http://www.aecouncil.com/AECDocuments.html

On the other hand Integrated circuits for active safety(ADAS) adheres to ISO26262 standard. There are different classification of safety standards defined under ASIL (Automotive Safety Integrity Level) which differentiates various control units. ASIL-D being the highest safety level and ASIL-A being the lowest. One can have whole new discussion of what differentiates ASIL-A from ASIL-D. All I can say it is really a pain the wrong place to design a SoC which adheres to ASIL-B or ASIL-C safety standards.