On Sat, 28 May 2016 10:21:57 -0400, rickman wrote:
> On 5/27/2016 11:01 PM, Tim Wescott wrote:
>> On Fri, 27 May 2016 22:44:29 -0400, rickman wrote:
>>
>>> On 5/26/2016 11:59 AM, Tim Wescott wrote:
>>>> On Wed, 25 May 2016 23:33:22 -0400, rickman wrote:
>>>>
>>>>> On 5/25/2016 10:35 PM, Tim Wescott wrote:
>>>>>> On Tue, 24 May 2016 23:52:43 -0400, rickman wrote:
>>>>>>
>>>>>>> On 5/24/2016 11:12 PM, Robert Wessel wrote:
>>>>>>>> On Tue, 24 May 2016 22:49:35 -0400, rickman <gnuarm@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On 5/24/2016 12:36 PM, Clifford Heath wrote:
>>>>>>>>>> Timer race condition on the electronic parking brake?
>>>>>>>>>>
>>>>>>>>>> <http://www.subaruoutback.org/forums/138-gen-5-2015-
>> present/345297-
>>>>>> new-recall-2015-outbacks.html>
>>>>>>>>>
>>>>>>>>> "9. Substantially similar U.S. vehicles: 2015MY Subaru
>>>>>>>>> Legacy/Outback and 2015MY Subaru WRX are substantially similar
>>>>>>>>> to their counterparts for sale in the United States. Subaru
>>>>>>>>> determined that this is not a safety issue since there is no
>>>>>>>>> comparable US safety regulation to UN No.
>>>>>>>>> 13-H. However, Subaru will initiate a service program to remedy
>>>>>>>>> affected vehicles in the US market"
>>>>>>>>>
>>>>>>>>> I think that is what is known as a "silent recall". They'll fix
>>>>>>>>> your car if you know to ask them.
>>>>>>>>>
>>>>>>>>> What I'm wondering is why they feel the need to activate the
>>>>>>>>> parking break twice?
>>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps to compensate for expansion and/or contraction of various
>>>>>>>> bits of the mechanism after a (potentially very hot) brake cools
>>>>>>>> down.
>>>>>>>>
>>>>>>>> On aircraft, it's common to avoid setting parking brakes if the
>>>>>>>> brakes are hot, or if a significant temperature changes is
>>>>>>>> expected. Although the mechanism there is usually rather
>>>>>>>> different (most aircraft parking brakes usually just trap
>>>>>>>> pressurized hydraulic fluid at the brake end of the system, and
>>>>>>>> expansion/contraction of that trapped fluid can do interesting
>>>>>>>> things). So it's not strictly comparable.
>>>>>>>
>>>>>>> I've never needed to put my parking brake on twice. Where's the
>>>>>>> difference? I think the expansion/contraction would be small
>>>>>>> compared to the amount of stretch in the cable pulling the brake
>>>>>>> in a manual brake. The electronic brake would be hydraulic I
>>>>>>> expect so no stretch.
>>>>>>> But the actuator could easily be designed with some compliance to
>>>>>>> compensate for a few thousandths of an inch as the parts cool
>>>>>>> down.
>>>>>>
>>>>>> But (A), they didn't do that, and (B) they proceeded to screw up
>>>>>> the software. At least it's not in something safety-related, so
>>>>>> it's not an inexcusable screwup -- but give them time.
>>>>>
>>>>> If I am not mistaken, the idea that they are applying the brake
>>>>> twice to deal with thermal issues is speculation. So you don't
>>>>> really know what they did or didn't do.
>>>>>
>>>>> I don't think it was a screw up in the software really, but maybe I
>>>>> missed that. I thought it was a systems design issue where they
>>>>> didn't catch that applying the brake at the same time the ignition
>>>>> was turned on would cause a problem.
>>>>
>>>> Why I think it's "software" rather than "systems" (even though
>>>> there's significant overlap in most companies):
>>>>
>>>> 1: Software engineers are the systems engineers of last resort. This
>>>> shouldn't be -- but it is.
>>>
>>> That's garbage. Systems engineering is looking at the system as a
>>> whole. Software engineers are dealing with the software in the
>>> environment defined by the system engineers. Sure, system errors may
>>> be found when testing software, but that doesn't make them system
>>> engineers.
>>>
>>>
>>>> 2: The service bulletin says it's a software problem. This is about
>>>> 1%
>>>> of the necessary proof -- but still, it's there.
>>>
>>> Yeah, so if the bulletin said it was caused by gremlins...
>>>
>>>
>>>> 3: Only the left rear wheel is affected. If it were a system
>>>> problem, you'd expect the entire emergency brake system to be
>>>> affected.
>>>
>>> No, I would expect it to be what it is.
>>>
>>>
>>>> 4: The effect is to damage hardware. Excluding software in bombs and
>>>> emergency fail-safe systems, software should never, ever, damage
>>>> hardware. That points to a bug severity known as "crazy way bad" in
>>>> the industry. Even if this were a job that was assigned to the
>>>> system's people, and that assignment was enforced by goons with
>>>> baseball bats, the software people should still make it not happen
>>>> (see item 1, above).
>>>
>>> Non sequitur. The systems level engineers should have considered the
>>> possibility of the concurrent application of ignition and brake. They
>>> didn't. The software has *no* control over the application of the
>>> ignition or the design of the hardware.
>>
>> I don't know where you've worked, but even the place where I worked
>> that _did_ have people with the job title "systems engineer", and even
>> when the term started to mean "people who dealt with the whole system"
>> and not "smart, necessary people whose work we don't understand", they
>> didn't get down to that sort of nitty-gritty level. Maybe in some
>> ideal world the system engineer's job is as you describe, but here in
>> this universe the people who need to insure correct operation at that
>> level have the word "software" in their job title, not "system".
>>
>> I know that anywhere that I've worked, and for every client, if there's
>> software that's capable of twiddling the pins on the board in such a
>> wise that a motor is left on until it burns up, that it is damned well
>> the responsibility of the person writing that software to damned well
>> make sure that that motor does, indeed, not burn up, ever, under any
>> circumstance except for the electronics faulting. And if it did
>> happen, saying "oh, it's not my job to make sure my software doesn't
>> burn up the motor that's at its mercy, that's the fault of the system
>> designer" would earn someone a place on the short-list of People to be
>> Laid Off First, if not a trip straight out the front door.
>
> If the software engineer doesn't know the motor will burn up, is it his
> fault?
If an embedded software engineer doesn't know that leaving a motor on, in
a stalled state, for an extended period of time, will burn it up, then he/
she needs to learn their business a lot better.
I agree that there was a failure of systems engineering here -- but
keeping stuff like this from happening is everyone's job.
--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com