My car tried to kill me AGAIN

On Oct 10, 11:52*pm, "Daniel W. Rouse Jr."
> wrote:

> * No internally split brake hoses (can restrict brake fluid)

How does one check that?

> * Brake fluid too dirty (can boil at a lower temperature)

I once had a '63 Vette, driving it up Waterman Canyon to 18 the brakes
started to apply themselves. This happened repeatedly, I'd let the
car sit a while, then it would be OK. Later I found out what was
happening; a rear brake return spring had broken, letting the shoe rub
on the drum. Eventually, this would heat up the brake fluid enough to
apply other brakes (probably the other side front, but I never knew
for sure).

Always fun driving on mountain roads not knowing what the deal is with
your brakes.

> * Brake booster defective (requires more power to apply the power brakes)

Circa 1968, I remember being at a friends house in the back yard,
heard a scrrrreeeeeeeeeech - pause - BLAM!

We ran out front, my friend's sister had been stopped waiting to turn
her bug left into the driveway, a '56 (IIRC) Chevy blew the master
cylinder while trying to panic stop, having seen the bug too late.
She was OK (but needed a neck brace, IIRC), but the bug was squashed.
You could see the skid marks end with a stain of brake fluid.

Thank goodness for modern braking systems.

jg
--
@home.com is bogus.
Why I was driving in the ****ing rain for a 2 hour commute this
morning: http://www.trainorders.com/discussio....php?4,2892956
Last night I saw a tweet (or more accurately, half a tweet, someone at
metrolink seems unfamiliar with the character limit) that the train
had hit someone. So I drove my station car to the other station. As
I switched cars at the Oceanside station, a bus pulled up and
disgorged passengers. Wondering if I should have just waited for the
bus, I asked someone, and found out it was for the earlier train, they
were coming in 2 hours late...

>"jgar the jorrible" > wrote in message
...
>> On Oct 10, 11:52 pm, "Daniel W. Rouse Jr."
> wrote:

>> * No internally split brake hoses (can restrict brake fluid)

> How does one check that?

I suppose they or a qualified brake technician would have to remove the
brake hoses and check them.

>> * Brake fluid too dirty (can boil at a lower temperature)

> I once had a '63 Vette, driving it up Waterman Canyon to 18 the brakes
> started to apply themselves. This happened repeatedly, I'd let the
> car sit a while, then it would be OK. Later I found out what was
> happening; a rear brake return spring had broken, letting the shoe rub
> on the drum. Eventually, this would heat up the brake fluid enough to
> apply other brakes (probably the other side front, but I never knew
> for sure).

> Always fun driving on mountain roads not knowing what the deal is with
> your brakes.

>> * Brake booster defective (requires more power to apply the power brakes)

> Circa 1968, I remember being at a friends house in the back yard,
heard a scrrrreeeeeeeeeech - pause - BLAM!

> We ran out front, my friend's sister had been stopped waiting to turn
> her bug left into the driveway, a '56 (IIRC) Chevy blew the master
> cylinder while trying to panic stop, having seen the bug too late.
> She was OK (but needed a neck brace, IIRC), but the bug was squashed.
> You could see the skid marks end with a stain of brake fluid.

When the brake booster failed on one of my vehicles it was a silent failure,
just one day it required much more force to apply the brakes.

> Thank goodness for modern braking systems.

As long as the computer controlled system does not fail, I do worry that if
a vehicle model is rushed out the door that inadequate QA testing of the
firmware might be a non-trivial issue. That said, I've driven rental cars
with traction control and the steering was much more precise. And, though I
did not need to use the anti-lock feature of the brakes, I was happy to know
it was there and ready if I needed to slam on the brakes at any time.

On 2012-10-11, jgar the jorrible > wrote:

> I once had a '63 Vette, driving it up Waterman Canyon to 18 the brakes
> started to apply themselves. This happened repeatedly, I'd let the
> car sit a while, then it would be OK. Later I found out what was
> happening; a rear brake return spring had broken, letting the shoe rub
> on the drum. Eventually, this would heat up the brake fluid enough to
> apply other brakes (probably the other side front, but I never knew
> for sure).

Drum brakes are self-energizing. It could have been just that one brake
applying. One drum brake locking up can practically keep a car from
moving.

On Oct 11, 5:36*pm, "Daniel W. Rouse Jr."
> wrote:

>
> As long as the computer controlled system does not fail, I do worry that if
> a vehicle model is rushed out the door that inadequate QA testing of the
> firmware might be a non-trivial issue. That said, I've driven rental cars
> with traction control and the steering was much more precise. And, though I
> did not need to use the anti-lock feature of the brakes, I was happy to know
> it was there and ready if I needed to slam on the brakes at any time.

Pretty much every car I've had with ABS gets confused going over wet
railroad tracks. They aren't as bad as the '80's versions.

With 30+ years of software development, I just assume there is bad QA,
and it's getting worse.

jg
--
@home.com is bogus.
http://www.nydailynews.com/autos/eme...icle-1.1182119

> "jgar the jorrible" > wrote in message
> ...
> On Oct 11, 5:36 pm, "Daniel W. Rouse Jr."
> wrote:

>>
>> As long as the computer controlled system does not fail, I do worry that
>> if
>> a vehicle model is rushed out the door that inadequate QA testing of the
>> firmware might be a non-trivial issue. That said, I've driven rental cars
>> with traction control and the steering was much more precise. And, though
>> I
>> did not need to use the anti-lock feature of the brakes, I was happy to
>> know
>> it was there and ready if I needed to slam on the brakes at any time.

> Pretty much every car I've had with ABS gets confused going over wet
> railroad tracks. They aren't as bad as the '80's versions.

> With 30+ years of software development, I just assume there is bad QA,
> and it's getting worse.

And though I did mention inadequate QA testing, I'll also follow up that it
is not always just QA to blame. Sometimes teams try to take a concept like
Agile or Extreme Programming and run with it for a project... with
shortcuts! They don't do it by the book.

Then it means more rushed deadlines and potentially buggier than ever
software releases (keeping in mind that firmware is essentially embedded
software). It can lead to but not be limited to: development taking as long
as possible to implement and then giving QA inadequate time to test as the
development team has already began their next sprint (which will make QA
fall behind when development finished their next sprint before QA has
finished testing the development's previous sprint), developers trying to
lower severity of issues that are easily reproducible or highly visible,
more issues deferred (forwarded to the next project) or outright not fixed,
add to that the program manager(s) may have given a no slip project schedule
so the project must release on time provided there are no showstoppers,
developers having to have outsource vendor(s) fix substandard code or else
having to rewrite an outsource vendor's code. A finished product does get
released anyway, but it certainly the best software it could have been.

Anyway, when it's software that can be patched, a rushed project is able to
be tolerated. When it's something safety related or mission critical, I
would hope that every known corner case or edge case was tested in addition
to just the known functionality, that more than just the easy to find issues
were fixed.

Now I don't know the exact process for automotive firmware, but I would also
expect, for something like auto firmware, that the names of the project
manager, developers, and QA team were all attached to the documentation of
the firmware being put into the relevant auto module (e.g., ECU, ABS braking
system). Just in case someone needed to be held liable for a blatant issue
that escaped into production, or in case they needed to be contacted about
the issue so the same team could get back together and fix it (ideally).

In article >,
"Daniel W. Rouse Jr." > wrote:

> "The Real Bev" > wrote in message
> ...
> > On 10/10/2012 11:24 AM, Daniel W. Rouse Jr. wrote:
> >
> >> "The Real Bev" > wrote in message
> >> ...
> >>> This is the third time my 1988 Eldorado has tried to kill me and my
> >>> passengers. Sudden acceleration, barely stoppable with the brake. Turn
> >>> off the engine, turn it on again and everything is OK. 3x on one trip,
> >>> 1x
> >>> on one trip one year later and once again today, ~6 months later.
> >>>
> >>> The independent GM repair guy fixed one part of the acceleration-control
> >>> (HA!) system the first time, and a different part of the system (very
> >>> hard
> >>> to find that part) the second time. And here we have the same problem
> >>> again.
> >>>
> >>> Surely I'm not the only one to experience this. Anybody ever heard of
> >>> this before?
> >>>
> >> I had this happen many years ago on a 1976 Caprice Classic when I engaged
> >> cruise control and the pedal dropped all the way to the floor.
> >> Thankfully,
> >> using the brakes disengaged cruise. Not saying that is the problem, but
> >> does
> >> your vehicle also have cruise control?
> >
> > It does, but it hasn't worked since before 2007. I don't like cruise
> > controls and don't use them voluntarily. In any case, stepping on the
> > brake did NOT cause the engine to slow.
> >
> That may disprove those who insist that the brakes can always overpower the
> engine, but the brakes should also be checked for the following (at the
> minimum I would insist on checking):
[snip]

I tried this in older cars without a lock-out. The brakes overpowered
the engine if I hit them HARD. Anything less caused them to overheat.
--
I will not see posts from Google because I must filter them as spam

On 10/16/2012 1:47 AM, Daniel W. Rouse Jr. wrote:

> And though I did mention inadequate QA testing, I'll also follow up that
> it is not always just QA to blame. Sometimes teams try to take a concept
> like Agile or Extreme Programming and run with it for a project... with
> shortcuts! They don't do it by the book.

You obviously have no idea what's involved in software development, do
you. Those software development methodologies aren't applicable to
firmware development.

> Now I don't know the exact process for automotive firmware, but I would
> also expect, for something like auto firmware, that the names of the
> project manager, developers, and QA team were all attached to the
> documentation of the firmware being put into the relevant auto module
> (e.g., ECU, ABS braking system). Just in case someone needed to be held
> liable for a blatant issue that escaped into production, or in case they
> needed to be contacted about the issue so the same team could get back
> together and fix it (ideally).

The entity that would be held liable in this case is the company, not an
individual employee (unless he or she was doing something not sanctioned
by company policy).

On Oct 17, 4:19*am, Arif Khokar > wrote:
> On 10/16/2012 1:47 AM, Daniel W. Rouse Jr. wrote:
>
> > And though I did mention inadequate QA testing, I'll also follow up that
> > it is not always just QA to blame. Sometimes teams try to take a concept
> > like Agile or Extreme Programming and run with it for a project... with
> > shortcuts! They don't do it by the book.
>
> You obviously have no idea what's involved in software development, do
> you. *Those software development methodologies aren't applicable to
> firmware development.

I once had a firmware development contract, I was very surprised at
how little methodology they had at all, they just relied on me to do
it right. I can easily imagine big companies farming this stuff out
to small companies with no idea what is really going on. I hope most
firmware development is not like that - but I would expect a
disconnect between upper management bean counters and the actual
departments. Especially with selling or restructuring departments or
divisions, bankruptcies and so forth.

I wonder who worked on the electronics for those Toyotas and Pontiacs
that were built on the same line? Delphi, while they were cutting
tens of thousands of jobs, eventually to go bankrupt?

Plenty of stories over in comp.risks of aircraft software and hardware
development fails. You'd think they would be better than automotive,
eh?

>
> > Now I don't know the exact process for automotive firmware, but I would
> > also expect, for something like auto firmware, that the names of the
> > project manager, developers, and QA team were all attached to the
> > documentation of the firmware being put into the relevant auto module
> > (e.g., ECU, ABS braking system). Just in case someone needed to be held
> > liable for a blatant issue that escaped into production, or in case they
> > needed to be contacted about the issue so the same team could get back
> > together and fix it (ideally).
>
> The entity that would be held liable in this case is the company, not an
> individual employee (unless he or she was doing something not sanctioned
> by company policy).

Agreed. Those darn fictional people that can go bankrupt to avoid
liabilities.

jg
--
@home.com is bogus.
http://www.utsandiego.com/news/2012/...light-cameras/

"The Real Bev" > wrote in message
...
> On 10/10/2012 11:24 AM, Daniel W. Rouse Jr. wrote:
>
>> "The Real Bev" > wrote in message
>> ...
>>> This is the third time my 1988 Eldorado has tried to kill me and my
>>> passengers. Sudden acceleration, barely stoppable with the brake. Turn
>>> off the engine, turn it on again and everything is OK. 3x on one trip,
>>> 1x
>>> on one trip one year later and once again today, ~6 months later.
>>>
>>> The independent GM repair guy fixed one part of the acceleration-control
>>> (HA!) system the first time, and a different part of the system (very
>>> hard
>>> to find that part) the second time. And here we have the same problem
>>> again.
>>>
>>> Surely I'm not the only one to experience this. Anybody ever heard of
>>> this before?
>>>
>> I had this happen many years ago on a 1976 Caprice Classic when I engaged
>> cruise control and the pedal dropped all the way to the floor.
>> Thankfully,
>> using the brakes disengaged cruise. Not saying that is the problem, but
>> does
>> your vehicle also have cruise control?
>
> It does, but it hasn't worked since before 2007.
Perhaps it is still working in the back ground in a bad way.
Was this car a previous wreck?
I don't like cruise
> controls and don't use them voluntarily. In any case, stepping on the
> brake did NOT cause the engine to slow.
>
>
> --
> Cheers,
> Bev
> ++++++++++++++++++++++++++++++++++++++++++++++++++ ++
> To define recursion, we must first define recursion.

"Arif Khokar" > wrote in message
...
> On 10/16/2012 1:47 AM, Daniel W. Rouse Jr. wrote:
>
>> And though I did mention inadequate QA testing, I'll also follow up that
>> it is not always just QA to blame. Sometimes teams try to take a concept
>> like Agile or Extreme Programming and run with it for a project... with
>> shortcuts! They don't do it by the book.
>
> You obviously have no idea what's involved in software development, do
> you. Those software development methodologies aren't applicable to
> firmware development.
>
Well, I do know about software development quite a bit. Please do tell me
more about firmware development, beyond what I already know about firmware
development.

>> Now I don't know the exact process for automotive firmware, but I would
>> also expect, for something like auto firmware, that the names of the
>> project manager, developers, and QA team were all attached to the
>> documentation of the firmware being put into the relevant auto module
>> (e.g., ECU, ABS braking system). Just in case someone needed to be held
>> liable for a blatant issue that escaped into production, or in case they
>> needed to be contacted about the issue so the same team could get back
>> together and fix it (ideally).
>
> The entity that would be held liable in this case is the company, not an
> individual employee (unless he or she was doing something not sanctioned
> by company policy).

But I think the team should also be held liable since they were part of the
company at the time the software/firmware (hint: embedded software) was
made, if the severity is high enough to hold someone liable.