drive by wire software..

Loading thread data ...

interesting comments. I wonder about the people that are calling for a completely shut throttle upon application of brakes though. I guess none of them have ever driven a Porsche 911. Some of the comments do resonate with me though, esp. the ones stating that there should be a mechanical connection between pedal and throttle, and those calling for a more methodical approach to software (breathalyzer anyone?)

nate

Reply to
N8N

A general question. I understand the need for drive-by-wire on hybrid/ electric car or on large airplanes/ships, but can someone enlighten me why drive-by-wire is pushed on to gas/diesel cars? The good old steel throttle cable has been very simple and reliable as far as I know. It can't be the cost cutting because a throttle actuator alone costs several times more than a 3-4 feet long cable assembly. If the auto engineers think everything has to be controlled by a computer, in this case, the driver's accelerator makes a request to the computer, the computer processes the request and makes a decision how much it will actually turn the throttle valve. This seems to open to more possibilities for malfunctioning. Yes, the jet liners have been using it for decades but it took much longer to develop a jet than a car and the jets have all the expensive redundancy built in. Beside, the average airline pilots are better trained than average car drivers to handle malfunctions.

Reply to
panabiker

I'm ASSuming that a) it's cheaper b) it makes compliance with emissions standards easier and c) it might also make cruise control, traction control, etc. integration easier

I agree that I also like my good old fashioned cable or linkage operated throttle plates...

nate

Reply to
N8N

Watching 5:00 PM local tv news, both of the Toyota dealerships around here said they are fixing Toyotas by appointment only.

As long as they are getting the parts (shims) and customers want to get their Toyotas fixed, they will be working through the weekend too. cuhulin

Reply to
cuhulin

Old fashioned pull rods/brakes/brake rods system.That is what my 1914 Ford Model T has, only on the rear wheels.The parking brake lever works those same pull rods too. Are we going Full Circle? cuhulin

Reply to
cuhulin

We might go back to levers and cables in the future and this will probably work fine since we'll be driving dune buggies and foraying into a post-apocalyptic landscape in a never ending search for non-radioactive canned foods.

Reply to
dsi1

This is not real new. My 1992 Ford van was in cruise control and went to full throttle. Starteling until I could pull over and shut it off. Brakes would not slow it down. (5.7 L engine) Took it to 3 different dealers as this happened 3 times while traveling. When I returned home I contacted Ford Motor Co about this. They had the selling dealer replace every electrical component. that any control of the engine. It was a long list. Worked OK since. No one had any idea which part cured it. ww

Reply to
WW

Actually, there ARE methods of testing and qualifying embedded control software, used in the aerospace industry. However, the designs used require a TRUE real time OS, and strict rules of design. The result is real deterministic software that can be fully tested, not just statistically tested. For instance, no conditional branching.

Reply to
Don Stauffer

Considering the small size of most automotive embedded firmware, and considering the huge number of vehicles that a given firmware kit will be installed in, it would seem worthwhile to do a proof of correctness on them.

I have seen proofs done on jet engine controllers, and I have seen such procedures turn up bugs too. It's a very expensive procedure, but when you're selling a million cars with the same software, the cost per car is not high.

--scott

Reply to
Scott Dorsey

I am not so sure it is so small. One article on the problem in yesterday's paper said a typical car now has thirty microcontrollers with 100 million lines of code. That is over three million lines of code per controller. I find this astonishing, and wonder how true it is.

I agree, but if the software is not deterministic it may require a LOT of money.

One course I took said that code of over a million lines of code could not be tested deterministically.

Reply to
Don Stauffer

I hope it's not true, but I fear it probably is. On the other hand, most of those microcontrollers aren't part of mission-critical systems. I don't consider the system that handles the radio or the heater anywhere near as important as an engine controller or an ABS processor and they don't need the same degree of scrutiny.

How can software not be deterministic? All software is deterministic, it's just that sometimes it gets complex enough that it becomes impossible to view that way.

It can't be tested statistically either. That's why we make small modules, test or verify the modules, put them together, and then test or verify the relationships between them.

A million lines of spaghetti is untestable, unverifiable, unmaintainable, and unfortunately too common.

--scott

Reply to
Scott Dorsey

Some cars have more computer codes than some Jet Fighter Aircraft.Some luxury cars have up to 100 computers.

That is a heck of a lot of computer codes. Wayyyyy too fancy for me! About a month ago, I read an article at

formatting link
that said General Motors is getting to where GM doesn't want anybody to work on GM cars but GM dealerships/shops.Something about new tools and manuals, stuff like that. I would like to find that article again at libertypost.org cuhulin

Reply to
cuhulin

I'm sure these tools will help to some extent but they never eliminate all software bugs, especially those "bugs" the designer didn't consider to be bugs. For example, if a designer of the brake system sets the objective to maximize the efficiency of the regenerative brake rather than to minimize the stopping distance, he/she may very well end up with a break system that would not stop the car very quickly. In this case, the tools will not catch the "bug" because the software does exactly it was designed to do.

Reply to
panabiker

snip

True. By "deterministic" I mean written to eliminate conditional branching. Much of that flight software does this, so there is only one path through the whole program before returning to the next iteration. Very easy to test code on those types of programs. There can be subroutines, but they exercise every subroutine every iteration.

Reply to
Don Stauffer

I'm pretty sure it's both true and very misleading.

Yes, there are a lot of little micros in a vehicle, but only a couple have anything to do with life safety functions (mostly the PCM and ABS micros). Most of the micros are in such things as the instrument cluster (important, but not a life safety function), radios, navigation, seat and mirror position memory control, etc. A few are in marginally life safety tasks like control of vehicle lighting systems.

Reply to
Pete C.

Nah, unlikely to happen. Civilization will simply collapse. Subsistence farming is the future.

Reply to
Pete C.

Yup. And the only way you find design issues like this is by putting the thing into service and having lots and lots of people try it out and see how it works. Sometimes it can take a decade to shake down a design, and that goes for hardware as well as software.

Problems happen when systems become obsolete and are replaced before all the major design bugs are found. They get replaced with new systems that have new bugs.

--scott

Reply to
Scott Dorsey

Ahh! We call that sequential!

Yup. A lot of the aircraft FADEC systems, and actually a lot of the automotive ECU systems consist of one huge loop. There are some operations in the loop that are executed conditionally, but they're always executed in the same order in each loop. Proof isn't as easy as with purely sequential code, but it's easier than with spaghetti.

--scott

Reply to
Scott Dorsey

MotorsForum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.