"Command and control functions"? I like the sound of that. So I'm an hour late paying my Verizon bill, they cut off my LTE access and my self-driving car promptly crashes into the nearest utility pole. What a terrific technological accomplishment!
On a more serious note, I'm sure one of these days they'll have "system safety standards for computer-assisted automobiles" but they're a LONG way from being able to write a specification for anything that will actually work in the field. (Anyone who wants to give me an argument on this can try and dispute whether Toyota's failure-prone accelerator software actually failed any safety regulations that may have been in effect at the time it was designed, it's just that in practice IT WASN'T SAFE because the requirements it met weren't strict enough, I've done all kinds of systems to RTCA DO-178 so I know what it really takes.) So I doubt that running some kind of test to designate some module is "automotive grade" really establishes much more than "as far as we're concerned it was working over some specified temp and vibration range when it left the factory". Oh and how much testing are they going to do to the rest of the cellular communications network to protect against it blowing a fart and sending along some meaningless noise with which to reprogram the ECU as the car rolls down the highway? I expect this will all be VERY entertaining watching it all roll out, but I'll choose to let someone else do the live beta-testing for a few years before I ever get into one of those deathtraps if it's all the same with you...
AZskibum, that's what everyone expected in mil/ero applications, but you would be surprised at how many applications use commercial grade products. Granted, automotive grade ICs are easier to get that mil spec, but I'll bet that we see more applications in the cabin of the vehicle that are more modular commercial grade solutions than automotive grade.
It's a question of who bears the cost of qualification & the cost of failed units. Modules containing consumer grade ICs seem like more of a quick go-to-market solution that eventually will be replaced with a module containing only automotive grade ICs.
Junko, If history in mil/aero applications is any indication, you will likely see more modules in the future. It is time consuming and costly to support more stringent qualification standards at the chip level, which is why many defense applications shifted to using off-the-shelf solutions and then just ruggedizing at the chassis level.
Agreed, Jim. As I pointed out in the story, there are several different degrees of grades within AEC Q100. And depending on where the module is going to be used inside the car, the requirements differ.
That said, as we expect more electronics is getting integrated into the dash -- not just for entertainment, but for telematics and even for advanced driver assistance system in the future -- will the modules be the way to go, or will we be seeing even a tighter requirement for pre-qualified automotive chips? I am not sure.
Junko, it is more than just making the car a connected device, it is about making the car a hub for gathering and communicating information to and from the car as well as other consumer devices being used in the car.
When it comes to automotive grade vs. commercial grade, it really depends on the system in the vehicle. If this system is used for command and control functions, it MUST be automotive grade. If the system is just used for cellualr and Wi-Fi communications, you do not need automotive grade. The infotainment system is a bit of a gray area. As these systems become more integrated into the standard functions of the car, like what is being done with the electronic dash displays, automotive grade will be a requirement. So, look for a mixture of both depending on how tightly it is integrated into the other electronic systems of the vehicle.
And yet, carmakers are intent to turn their vehicle into "a connected device."
Once there is an LTE modem (and by the way car OEMs are "future proofing" it by jumping on LTE) installed inside a car, they see nivirna of bringing apps (for remote auto repair, software upgrades) into a car.
To find out more about the in-vehicle software battle, take a look at this:
I wonder whether others see this the way I do, as a relatively low-volume luxury market? How many folks would trade in their car because 5G has just come out and their car only supports 4G? Probably the same proportion that in an earlier generation when smoking was common traded in their Cadillacs "when the ashtrays got full" and the ones who install transponders so they can use the horribly overpriced "Lexus lanes" to commute to work. It's not even clear that an in-dash GPS driving aid that could access the Web would be "immune" to tempting the owner to accumulate expensive "distracted driving" tickets, especially in those states controlled by ever-greedier big-spending politicians that write traffic laws based mostly on maximum revenue to the state. Even if you don't need a separate data plan for your car (if it fits somehow under a "shared data" plan, that doesn't seem to be a given either) do you want your local auto mechanic trying to repair this stuff when most of the time he can't quite seem to even keep your engine running right? What does this REALLY do for the car occupants, give you the ability to get multi-channel sound out of the car's speakers to accompany the video, what if the occupants are watching different programs? I just don't get the premise, yeah it could be a "hotspot" for the passengers' phones but they have to have data plans anyway, the "need" this meets is lost on me, maybe someone can tell me what I'm missing?
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. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.