Ahh, firmware (Subaru this time)

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.


> So -- it's software.  It is, almost certainly, a dumb-ass race condition,
> and very possibly one that is very similar to the one that Toyota was
> using to kill people with their cruise control software a few years ago.
> Perhaps Toyota and Subaru buy their software from the same super-very-
> good consulting company, and the critical code was written by the same
> engineer.

-- 

Rick C

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.

-- 
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

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?  It is the system engineer's responsibility to define the 
operation of the system as a whole including the interaction of the 
parts.  As I have said, the environment must be defined for the software 
engineer and that is called systems engineering.  We aren't talking 
about something that can be read in a data sheet.  From what I have read 
this bug is complex and involves interaction of various parts of the 
car, the designers of no one part have known to prevent it.  It was a 
systems level design goof.

-- 

Rick C

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

On 5/28/2016 12:35 PM, Tim Wescott wrote:
>
> I agree that there was a failure of systems engineering here -- but
> keeping stuff like this from happening is everyone's job.

You can pick any isolated example and say someone should have a priori 
knowledge of it.  The *important* point is that important interactions 
of the hardware have to be specified at the systems level in order for 
the lower level sub-systems to be designed.  *That* is the critical 
aspect of designing any module, having proper specifications.  A car is 
such a complex system these days and no one, including the systems 
engineers have a *full* knowledge of the entire car.  Proper program 
management is essential to designing cars that work.

-- 

Rick C

On Fri, 27 May 2016 22:44:29 -0400, rickman wrote:

> On 5/26/2016 11:59 AM, Tim Wescott wrote:
[ ... ]
>> 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.

Over-quoting, people.

That's a beautiful dream, but, while it wasn't often, it was more than 
once that I had to cobble together a feature (yes, with inadequate 
information and imperfect control) that the designers upstream had 
decided it would be easier to sluff off.  So there I am, retro-designing 
the system to see what's available at the taps I can get at to do what 
needs doing.  Musikmesse two weeks away and me the only one who can 
change anything at all in that timeframe.

When it's too hard for hardware, give it to software.

	Mel.

rickman wrote:
> On 5/28/2016 12:35 PM, Tim Wescott wrote:
>>
>> I agree that there was a failure of systems engineering here -- but
>> keeping stuff like this from happening is everyone's job.
>
> You can pick any isolated example and say someone should have a priori
> knowledge of it.  The *important* point is that important interactions
> of the hardware have to be specified at the systems level in order for
> the lower level sub-systems to be designed.

Software people have to be able to put on the systems hat.

> *That* is the critical
> aspect of designing any module, having proper specifications.  A car is
> such a complex system these days and no one, including the systems
> engineers have a *full* knowledge of the entire car.  Proper program
> management is essential to designing cars that work.
>

-- 
Les Cargill

On 5/28/2016 7:38 PM, Les Cargill wrote:
> rickman wrote:
>> On 5/28/2016 12:35 PM, Tim Wescott wrote:
>>>
>>> I agree that there was a failure of systems engineering here -- but
>>> keeping stuff like this from happening is everyone's job.
>>
>> You can pick any isolated example and say someone should have a priori
>> knowledge of it.  The *important* point is that important interactions
>> of the hardware have to be specified at the systems level in order for
>> the lower level sub-systems to be designed.
>
> Software people have to be able to put on the systems hat.

Sure, why not let them design all the hardware and sell the cars too?

-- 

Rick C

rickman wrote:
> On 5/28/2016 7:38 PM, Les Cargill wrote:
>> rickman wrote:
>>> On 5/28/2016 12:35 PM, Tim Wescott wrote:
>>>>
>>>> I agree that there was a failure of systems engineering here -- but
>>>> keeping stuff like this from happening is everyone's job.
>>>
>>> You can pick any isolated example and say someone should have a priori
>>> knowledge of it.  The *important* point is that important interactions
>>> of the hardware have to be specified at the systems level in order for
>>> the lower level sub-systems to be designed.
>>
>> Software people have to be able to put on the systems hat.
>
> Sure, why not let them design all the hardware and sell the cars too?
>

Because there will be things about systems issues that software people
will be the best at.

Example: I once worked on a system where there was a throughput
"shall".  We had a board. I "proved" the board would not support
sustained rates required because of one of those fine Marvell Ethernet
chipsets.

I would have used a SmartBits but they wouldn't buy one, so I
wrote test drivers, with instrumentation (counters) accessible by
Telnet/SSH session. These were roughly proportional to RFC1213 style 
counters. Please note that the RFC1213 counters provided by the system 
didn't work. It didn't have any way to estimate dropped
packets because of the chip's architecture.

Then I wrote a Tcl script to put snapshots of this
instrumentation into Excel. Easy peasy.

This took approximately three man weeks.

There was no "systems engineer" there that could have even gotten
started on that task - note that a SmartBits was considered superfluous.

"Systems engineering" was nothing more than a career path to "program
management".

This is key: The organization itself *didn't want to know*. They didn't
care if it worked. They cared that there might be a contract award.

I don't work there any more. It continues as a confederacy of dunces.
If they made things that worked, people would have negative career impacts.

-- 
Les Cargill