Beware unnecessarily interlocked embedded systems. There are functions in a car that should have no idea of each other's existence. Throwing them all on one comm bus just multiplies the chances of obscure failure modes. Your dashboard multimedia device (aka Distractovision unit) shouldn't be able to talk to the ABS.
air_n_water: so voiding your warranty is a GOOD thing? I'm not advocating for one side or the other, just stating the situation. Good engineering has to recognize ALL reality, not just the laws of physics! That includes legal and political aspects. I'm pretty much a Libertarian at heart, but too many who claim that title come closer to being anarchists (and don't get me started on the members of the "self-righteous Right" who claim to be Libertarians but don't seem able to grasp the fundamental nature of true religious freedom and its place of prominence at the very top of the rights hierarchy). In any case, I would NOT be surprised to see the EPA decide to outlaw devices like Powerstroke in the name of preserving air quality!
When you buy a car do you truly own it? By locking service ports I argue that the owner would be denied ownership rights to do with his property as he pleases. Programmers are available now for popular cars to let the owner optimize operation for a particular task. This is like the smart key business a few years ago where only the dealer could duplicate a key to the tune of $600.00. Now you can get popular keys duplicated at stores like Walmart for less than $100.00. Locking up the system only serves to the benefit of the dealers, not to protect the owners.
Reprogramming of ANY ECU in-car by the owner will NEVER be allowed. Most cards thes days have the ability to reprogram most (not always all) ECUs via the ODB II port, but only with a high-security access mechanism. Why??? 2 related reasons: HACKERS and LAWYERS. If it was possible for some talented hacker to use some brute-force technique via USB, etc. to gain access to the car's networks and trigger reflash of, say, the engine control computer with the goal of souping up the engine, that would both screw up the fuel efficiency, emissions controls, etc. and expose the manufacrurer to lawsuits (let's just postulate a street-racing accident caused by a 'hacked" car whose tires, etc. couldn't deal with the increased power) beyond belief for ALLOWING this to happen! On the other hand, manufacturers are planning in many cases over the next few years (some cars have some minimal capability now) for "over-the-air-reflash" (OTAR) using the connectivity now becoming more common in vehicles, but using very high-security access controls to limit the possibility of unauthorized use. That's a much more realistic solution to the problem (also addresses those who refuse to bring in their vehicles for recall repairs).
It is possible to reprogram the onboard computer now, but it requires special hardware, cables, connectors. I would like to see the auto companies make it easy to deal with firmware upgrades as this article described by using INDUSTRY STANDARD components, cables, connectors. USB seems the easiest, most common.
Modern vehicles can connect to I-Phones. Why not have a USB port for firmware upgrades so Nissan can send the fix to customers instead of sendinig technicians? That sort of foresight would impress me much more than sending out someone to my driveway. It would prove to me that they acknowledge code bugs can happen, and have thought of a way to easily deal with them.
The good news is that it sounds like Nissan is dealing with the problem head on. They are quickly providing specific (and believable) reasons for the problems and talking to the press. Maybe they learned something from the the issues Toyota had with the gas pedal mechanism.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.