Software for brakes, yah right

And, how much of that crap can therefore be safely deleted, in an effort to simplify the VOS? Somehow, I'd be willing to bet that "An awful lot of it" can be axed - or separated from vital controls (creature features don't need to share clocks with brakes & steering, y'ask me. Put them on an entirely separate system, starting with a separate u-processor... And a separate data bus. Don't mix vital systems with non-essentials!)

And just why is it we need 70-100 u-processors in a vehicle anyhow? Does, say, an F/A-18 have that many on board - including in the "smart weapons" in a full loadout? Just wondering...
Seriously. However, I think that's talking about modern vehicles, and even then I can't account for most of that number. On an XJ (OBD II, 97+):
* ECU has one, a Motorola M68k. There are two other PQFP-package ICs near the 68k that I can't account for, they may be MCUs as well, we'll be generous and call the ECU 3 MCUs.
* TCU has one, a Fujitsu 89665, mask-ROM with AW's brand logo on it.
* ACM has one (iirc) - it's sitting on my desk at work, can't verify right now.
* OHC has one, I seem to recall it being some sort of Motorola embedded product with a part number starting with SC.
* Dash cluster has one, I think it's another Motorola embedded. Be generous and call it two if you want to include the VFD controller (likely just an ASIC with a bunch of shift registers and flipflops in it) mounted under the mileage display.
* Haven't opened an ABS controller, let's be generous and call it five in there. It's probably only one.

Anything I'm forgetting? The XJ didn't have a BCM iirc, though the ZJ/WJ/WK sure do.

Even erring on the "too many" side, the XJ has 13 MCUs in it. That's a number I can deal with...
 
Seriously. However, I think that's talking about modern vehicles, and even then I can't account for most of that number. On an XJ (OBD II, 97+):
* ECU has one, a Motorola M68k. There are two other PQFP-package ICs near the 68k that I can't account for, they may be MCUs as well, we'll be generous and call the ECU 3 MCUs.
* TCU has one, a Fujitsu 89665, mask-ROM with AW's brand logo on it.
* ACM has one (iirc) - it's sitting on my desk at work, can't verify right now.
* OHC has one, I seem to recall it being some sort of Motorola embedded product with a part number starting with SC.
* Dash cluster has one, I think it's another Motorola embedded. Be generous and call it two if you want to include the VFD controller (likely just an ASIC with a bunch of shift registers and flipflops in it) mounted under the mileage display.
* Haven't opened an ABS controller, let's be generous and call it five in there. It's probably only one.

Anything I'm forgetting? The XJ didn't have a BCM iirc, though the ZJ/WJ/WK sure do.

Even erring on the "too many" side, the XJ has 13 MCUs in it. That's a number I can deal with...

So, I was engaging in hyperbole. My point still stands - howcumzit that a road vehicle (moving in two dimensions, constantly supported by the ground) should require more u-controllers and lines of code than should a modern warplane (moving in three dimensions, requiring a higher degree of reliability, more systems to control, and interfacing with yet more systems to programme "smart weapons" on the fly?)

And just what's the point of a "Body Control Module" anyhow? Sheetmetal doesn't need any sort of control, once it's welded/bolted/screwed/otherwise stuck together, does it? ECU/TCU/ABSCU seems to be all that's really needed - that's three u-processors, nine tops (assuming triple redundancy.) And for damned sure not 75-100 Mlines of code!
 
I agree... I'm not sure where these statistics are coming from, really.

The BCM does all sorts of mundane crap - light control (that nifty fade out thing instead of turning on and off probably), temp control (on cars that you give a temperature instead of adjusting the knobs yourself), door ajar beepers, locks, all that kind of stuff. It also handles the fuel level sensor and whatnot on the grand cherokees that have the more advanced trip computer.

... that reminds me. If you have RKE on your XJ, add another MCU to the list, the one that listens for a remote signal and then triggers the lock/unlock solenoids etc.

As for why it takes so many, I think it's because they hire much cheaper engineers to do it, and the code isn't really audited with anywhere near the care as aerospace/military stuff is. I doubt that 75-100 million lines of code is anywhere near accurate however, you know what they say about statistics... and the entire Linux kernel only has something like 30 million lines, so I find it difficult to believe that those numbers aren't just some idiot pulling numbers out of their nether regions. Assuming a line of code equates to a single, one-byte machine language instruction, that means each of those MCUs has to have on average ~1MByte of code space. I know for a fact that the TCU and most of the others do NOT have anywhere near that much on board, though the ECU from a 97+ definitely does, the one I have here on my desk from a 98 has an Intel 28F200 for code storage which is a 2MByte chip.

Most of the controllers I've seen in the automotive world have around 64kBytes of code storage, as they are 16 bit MCUs. I believe the TCU in the 97+ XJ has either 8kB or 16kB.

Cliff notes: whatever statistician produced this 75-100MB stat, and the 70-100 MCUs stat, needs to show me some sources and hard numbers before I'm going to believe it.
 
This is all the code I need:

Start
Run
Stop


LOL!:laugh3:

Oh, and maybe

Reverse

So make that 4 lines of code.

Use the Kiss principle.
 
Why does everyone hate electronics so much? I mean inevitably more parts = greater chance of failure, but simply because something is electronic, rather than mechanical, doesn't make it inferior... Simply different.

/EE student.
 
CherBear, I'm an electrical and computer engineer with two degrees. I don't HATE electronics, I love them - you should see my apartment. What I hate is badly designed electronics and badly written code that kills people who were admittedly too unfamiliar with the workings of their vehicles to put the darn thing in neutral.
 
CherBear, I'm an electrical and computer engineer with two degrees. I don't HATE electronics, I love them - you should see my apartment. What I hate is badly designed electronics and badly written code that kills people who were admittedly too unfamiliar with the workings of their vehicles to put the darn thing in neutral.

Well of course, poorly designed electronics can fail and hurt people. Just like a poorly designed mechanical piece can fail and hurt people.

Just seems like the consensus on here is that "electronics = bad"

I would have to guess that most people feel more comfortable with mechanical parts because they more familiar with them than electronics. Id bet that everyone here picked up a wrench before a multimeter...

"There are 10 types of people in this world, those who can count in binary and those who can't"
 
no... there are 11 types. Those who can detect and correct single-bit ECC errors and those who can't.

I think the mistrust for electronics on vehicles really comes down to visibility - most mechanics, and car drivers, do not have any way to see what's going on in the electrical portions of their vehicles. Heck, even engineers can't unless they've heavily modified and tweaked the systems, and/or have a bunch of very expensive tools. Even then it is difficult or impossible to see bugs in the code because all you have is the machine code burned into a ROM of some sort, and you probably won't spend the weeks it takes to reverse engineer it till you need to or see a reason to.

However, you can see, hear, or feel most mechanical problems, usually before they become a major issue.
 
Why does everyone hate electronics so much? I mean inevitably more parts = greater chance of failure, but simply because something is electronic, rather than mechanical, doesn't make it inferior... Simply different.

/EE student.

Show me electric windows that work once the car or truck is submerged or even up to it's hood in water.
Electric windows and door locks are great while the vehicle is under warranty, not so great after it's out of warranty.
Electric replacement parts from the parts stores are 'non-returnable' after purchase.
 
Show me electric windows that work once the car or truck is submerged or even up to it's hood in water.
Electric windows and door locks are great while the vehicle is under warranty, not so great after it's out of warranty.
Electric replacement parts from the parts stores are 'non-returnable' after purchase.

Of course electronics have some disadvantages too. That isn't the point.

You COULD build windows that are fully functional while submerged, but that isnt what most drivers need.
 
Of course electronics have some disadvantages too. That isn't the point.

You COULD build windows that are fully functional while submerged, but that isnt what most drivers need.

I thought mythbusters tested that during the car-submersion episode? I guess maybe after it goes from the battery through all the electronics, to the door...it may fail by then. They just tested it from battery to door, and the windows still worked
 
It's pretty hard to kill the switched 12 volt stuff (as long as the motors are waterproofed), what's really easy to kill is the sensors and computerized portions.
 
That's the number 3

/geek :eyes:

x2

I believe what kastein was trying to show is that with single bit errors, the number 2(10) can be incorrectly read as 3 (11) because of an erroneous bit...

I think ECC mean error correcting code, but I dont know how that really applies here.

Maybe you could fill us in on that one.
 
no... there are 11 types. Those who can detect and correct single-bit ECC errors and those who can't.

I think the mistrust for electronics on vehicles really comes down to visibility - most mechanics, and car drivers, do not have any way to see what's going on in the electrical portions of their vehicles. Heck, even engineers can't unless they've heavily modified and tweaked the systems, and/or have a bunch of very expensive tools. Even then it is difficult or impossible to see bugs in the code because all you have is the machine code burned into a ROM of some sort, and you probably won't spend the weeks it takes to reverse engineer it till you need to or see a reason to.

However, you can see, hear, or feel most mechanical problems, usually before they become a major issue.


Bingo! You win the prize here! :D I would have thought that would be obvious to everyone else here, but allas, not so.
 
x2

I believe what kastein was trying to show is that with single bit errors, the number 2(10) can be incorrectly read as 3 (11) because of an erroneous bit...

I think ECC mean error correcting code, but I dont know how that really applies here.

Maybe you could fill us in on that one.
Exactly. It's somewhat of a nerdy joke...

Bingo! You win the prize here! :D I would have thought that would be obvious to everyone else here, but allas, not so.
I dunno, it's my hobby + job... I'm a validator at Intel, specializing in RAS (reliability/accessibility/serviceability - basically, error handling/correction hardware/firmware) functionality, if I wasn't skeptical of designs and usually thinking "what if this breaks just when that happens..." I'd be pretty bad at my job.

(this also explains why I think the 11 types of people in the world is a good joke)
 
Back
Top