Embedded Systems Conference
Breaking News
Newest First | Oldest First | Threaded View
User Rank
Re: Why not separate OSes?
MClayton200   1/11/2014 12:38:27 PM
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.

User Rank
Re: Competition is heating up for automotive
krisi   1/6/2014 7:18:52 PM
Very good point @Larry...I change phones every 2-3 years, cars 6-10 years...Kris

User Rank
Re: Competition is heating up for automotive
LarryM99   1/6/2014 5:44:17 PM
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.

User Rank
Why not separate OSes?
JeffL_2   1/6/2014 1:07:23 PM
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.

User Rank
Competition is heating up for automotive
JimMcGregor   1/6/2014 12:33:17 PM
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.

As data rates begin to move beyond 25 Gbps channels, new problems arise. Getting to 50 Gbps channels might not be possible with the traditional NRZ (2-level) signaling. PAM4 lets data rates double with only a small increase in channel bandwidth by sending two bits per symbol. But, it brings new measurement and analysis problems. Signal integrity sage Ransom Stephens will explain how PAM4 differs from NRZ and what to expect in design, measurement, and signal analysis.

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
Special Video Section
The LTC®6363 is a low power, low noise, fully differential ...
Vincent Ching, applications engineer at Avago Technologies, ...
The LT®6375 is a unity-gain difference amplifier which ...
The LTC®4015 is a complete synchronous buck controller/ ...
The LTC®2983 measures a wide variety of temperature sensors ...
The LTC®3886 is a dual PolyPhase DC/DC synchronous ...
The LTC®2348-18 is an 18-bit, low noise 8-channel ...
The LT®3042 is a high performance low dropout linear ...
Chwan-Jye Foo (C.J Foo), product marketing manager for ...
The LT®3752/LT3752-1 are current mode PWM controllers ...
LED lighting is an important feature in today’s and future ...
Active balancing of series connected battery stacks exists ...
After a four-year absence, Infineon returns to Mobile World ...
A laptop’s 65-watt adapter can be made 6 times smaller and ...
An industry network should have device and data security at ...
The LTC2975 is a four-channel PMBus Power System Manager ...
In this video, a new high speed CMOS output comparator ...
The LT8640 is a 42V, 5A synchronous step-down regulator ...
The LTC2000 high-speed DAC has low noise and excellent ...
How do you protect the load and ensure output continues to ...