New Jaguar XJ Suffers Blue Screen of Death
An anonymous reader writes "CNET UK is reporting that it crashed a £90,000 Jaguar XJ Super Sport — one of the most technologically advanced cars on the planet today. It's not the sort of crash you'd imagine, however — An unforseen glitch somewhere within the car's dozens of separate onboard computers, hundreds of millions of lines of code, or its internal vehicular network, led to the dramatic BSOD, which had to be resolved with the use of a web-connected laptop."
If you RTFA, there' no mention of Windows. The Car just wouldn't start. They disconnected the battery, and reconnected it.
They're not, though. The car didn't BSOD, and TFA makes no mention of them running any Microsoft software. They did, however, mention Linux.
Three words -- Body Control Module. I don't know a damned thing about Jaguars, but with GM vehicles in general they all have a Body Control Module installed. Anything that isn't directly related to the powertrain is controlled by the BCM (incidentally, the powertrain is controlled by the Powertrain Control Module). In many GM vehicles, the BCM can be communicated with via the radio; this is to set certain user options like how long the headlamps will remain illuminated after exiting the vehicle. In the event that something goes wrong with the BCM, the radio will lock because it gets put into an anti-theft state, and typically the car will not start. All because a single capacitor on a shitty little Motorola board got cooked, for example.
Then, even if you get a used BCM with the same option codes as the one you're replacing, the radio will remain in an anti-theft state because the thinking of the designers (I guess) was that people would start swapping BCMs just to steal radios -- dumb.
GM, of course, has a tool to reprogram BCMs, but even they say there's a 50/50 shot their programming will render the BCM unusable. From my limited research of the boards they use, it seems there is little if any CRC done in any shape or form, so it sounds like the board will happily write bad or invalid data to the PROM.
Again, I don't know how a Jaguar design works, but there are vehicles where the radio does indeed affect other parts of the vehicle, much to the dismay of owners and dealers alike.
For the last time, PIN Number and ATM Machine are redundancies!
Diagnostics is the first reason. The amount of information you can get on any car the past 10-15 years is absolutely amazing. Acceleration levels, fuel usage levels, break levels, even tire pressure levels, and logs of many of these functions. It dramatically reduces the cost and time to check a car for problems and unusual behaviour when you have very small very simple computers monitoring all the essential systems on your car. The software also usually permits altering a lot of parameters - useful when finetuning the car in question. The logs in particular are frequently used to assess crashes - which is for example how we have discovered that vast majority of crashes the driver either does not brake at all, or only applied a small amount of braking force. This information is why a lot of manufacturers are now looking at into installing systems into cars that will automatically apply the brakes if a crash is inevitable (to get down the speed and reduce the damage and danger of the crash).
Engine management is a lot more sophisticated than a mechanical carburettor can ever hope to be. Between environmental regulations (cleaner air), diagnostics (cutting down on repair time) and performance (getting more from a smaller, lighter engine without compromising reliability) it's gotten quite complicated. Then there's the chassis, with ABS, ESP and other electronic driver aids. Miles of wiring have been replaced by a lighter, more reliable bus system for all electric functions in the car.
Some of this is down to ever-tighter regulation (emissions, safety). Others are due to the competitive nature of car sales: ever more features get tacked on.
Thanks to electronics, cars have gotten a lot more reliable over time. The last few years, car companies have overstepped, though, offering new features before they were ready, and not doing enough testing for proper integration.
For instance, before GM had the Passkey system the Camaro was the most stolen car year after year. Once Passkey was introduced it completely dropped off the list.
GM also stopped making the Camaro from 2002-2010, that will help reduce the number stolen.
I laughed at the weak who considered themselves good because they lacked claws.
They are the most singularly unhelpful and woefully incomplete design documents ever created.
They should be generated from the design, not the other way around.
Wow. No. Use cases are the single most important design document in a system. They outline a task that the user wants to accomplish, and software that isn't designed around them is always a PITA to use.
Here's an real world example I'm dealing with right now, anonymized somewhat.
We manufacture widgets to client specifications. The specifications include selecting parameters within a set range. However a set of 'easy' parameters is SKU X with one set of pricing, while if they spec outside those easy parameters within a more difficult set, its SKU Y, with a different pricing and warranty.
This is fine.
However the software was designed around the client calling up, identifying the product they want, and then listing the specs. The screens are set up in such a way that you look up the customer, create, and order, add the product, and then fill out the specs.
So far so good.
Unfortunately the people communicating orders to us don't differentiate between X and Y. They just want a 'widget' and then give us parameters. So our order entry people have to essentially take note of the parameters they want, determine which sku it is, and then enter the sku and then enter the parameters.
This is because the designer failed to understand the use-case for playing an order for these widgets.
Were are looking to rectify the system by creating a product 'families' which contain the same parameter inputs. This will allow the order entry person to select the product family (which the customer knows), enter in the parameters - which they know, and the software will determine the final SKU to use at the end, based on the parameters that were entered.
This is a design that follows a use-case. We are modelling the systems behavioral requirements by detailing the actual scenario under which it gets used; in this case the particular order information is 'naturally' passed from client to order entry.
Discounting use-cases results in software that doesn't work in a way that is convenient for the user. It may be more convenient for the developer.
Getting good use cases is difficult, and its frequently done VERY POORLY. Where they often model poor processes that were being done with 'the previous system' or 'by hand'. But use cases that model what actually needs to be accomplished, and reflect the flow of information proplerly, results in elegant and easy to use systems.
The diagnostic systems that you plug in are very, very expensive. I once had to do some work on an IBM Thinkpad with an ancient version of SCO OpenServer that was running reverse-engineered BMW/Mini diagnostic software. This unit cost $600. The official unit costs $20,000. That $85 charge seems fairly small in comparison.
why would it not be legal for sale again???
.. i get 35mpg around town... it has all of 4 fuses and no computing power at all..
crash tests?? hey if people can still legaly ride motor cycles then i don't see the problem with not having air bags in my car.
sorry i drive a 70's MG
and if your excuse is emissions - well i pass that too (well did until 2 years ago when they got rid of doing sniffer testing)
I honestly haven't seen any real gains from what they are doing - they say that this and that gives x and y but i just don't see it.
and as for reliability.. i've had more trouble with cars with ECU's than cars with out.. to the point that i don't buy them.
'...if only "Jumping to a Conclusion" was an event in the Olympics.'